|Can XML Replace HTML in the future?|
Can it be?
its already happening [w3.org]
Well, XHTML is intended to replace HTML eventually. Can it take HTML's place completely? Technically I'd say yes. It may take some time--or maybe a lot of time--but I think it'll happen.
Welcome to the board xicixiaoqi yhn,
In the sense I think you are asking, no not really. XML is a portable document structure, which is not really for presentation. XSL or CSS may replace HTML, but really XML is meant to be a storage medium. It is like asking if databases will replace HTML.
The one aspect that makes this whole thing blurry is that HTML and now XHTML is a subset of XML. It is just used to make documents render in browsers.
HTML's future really will rely on Browser manufacturers and the W3C. To me XHTML is HTML, it is just the new version. I see XHTML or HTML being around for a while.
XHTML can replace HTML now, with browsers in their current state. All my new documents are written in XHTML 1.1 with CSS2 styling, and served with the application/xhtml+xml mime type where possible.
XML and XSLT are making strides on the server side, where the process can go something like this:
1) Receive request
2) Get data from database in XML format
3) Merge an XSL stylesheet with the data
4) Return the data as XHTML to the browser
Technologies such as XUL now make it possible to build cross-platform client-side engines (like Mozilla Firebird [mozilla.org]) that could use web services at the back end. Although it's unlikely to spell the death of conventional websites, it's already possible to make a portable piece of client software that can talk to the Amazon website (for example) with a standard windowed interface.
I see XHTML taking over as the defacto commerical web standard, since XHTML2 is already on the horizon with some more improvements. I feel that XSLT might have its place on the server, but it's unlikely that the transformations will be commonly performed on the client side within the next 6-8 years.
The Internet has not replaced books. TV did not replace radio. Even with videos and DVD, we still go to the cinema. Each new technology adds to the media spectrum.
There are billions of web pages already created using HTML. It is unlikely that these pages will all be re-coded into newer formats. So HTML will never be completely replaced. However, when creating new web pages, designers will use HTML less and less. Favoring the current fashion whither that is XML, XHTML, Flash or something else.
This industry moves very fast. Every day, new technology is created. The one thing we can be sure of is that the Internet as we know it now is only temporary. It won't disappear or be replaced, but it will not remain as dominant technology on the Internet. Something else, maybe xml, maybe something we don't know about yet, will take over that position.
I see what you are saying, but as we keep moving forward, we will keep moving into new areas that will become more of the mainstream. I have no doubt in my mind that XML will be the next place everyone goes.
Dont get me wrong, people will still use HTML, just like people read books and listen to the radio, but there will be more focus on XML in the future.
If "replacing" means "changing", then yes. But if "replacing" means that one day we'll all drop HTML and go over to XML, it ain't gonna happen ;)
XML is a reasonable storage format for certain types of data, and can be converted server-side with XSL, etc. XHTML 2 is showing some mildly interesting advances, but it is way off replacing HTML.
XHTML 1.x (a pseudo-XML version of HTML 4) is available now, but it offers pain for no gain - it offers virtually nothing that HTML4 can't do, but comes with significant disadvantages, especially if you serve it up as application/xhtml+xml (one improperly-nested tag and the page is replaced by an error message - just what you want on a CMS-driven site, or on any site which is not a hand-crafted hobby site). Of course, if you don't use application/xhtml+xml, you are just serving up invalid tag soup like its 1995. (Yes, I know, I'm in a minority on this!)
In short, XML on the server-side is already making it's mark, but on the client side, its inability to handle parsing errors (in its true form) will mean that HTML will remain strong for a long while yet.
Using X(HT)ML instead of HTML assumes that a) you need to give parts of your audience automated access to your content via an XML parser, and b) machines and humans can both use the same interface effectively.
On the first point, I suspect there are very few sites that need to offer this facility. Some sites I'm involved with spend significant amounts of time compiling product spec information, and making it even easier for competitors to steal this content is not currently seen as a high priority ;) Even sites that do want/need to distribute their content will imho find separate interfaces for humans and machines are a more effective solution.
Machines do not benefit from the same information and structure that humans find useful: e.g. audience-based information architecture, multiple paths to the same information, human-sized chunks of information, help pages, calls to action, pictures etc.
I agree with encyclo that xhtml is mostly pointless, and I think the strategy of offering one set of content for both machines and humans is sub-optimal. Humans benefit from an interface optimised for humans (via HTML web pages), and machine access is best delivered through a machine-optimised interface e.g. RSS or SOAP.
>> The one aspect that makes this whole thing blurry is that HTML and now XHTML is a subset of XML.
Not quite. ;)
All of them are subsets of SGML - the heart of every browser. HTML was meant as a tool to display text easily because SGML is a complex language to write. Overkill, in fact, for displaying a simple text document. When the US government and universities began sharing data all they wanted was a simple tool to display text on screen. Something with limited formatting ability - the basics really. Paragraphs, headers, and line breaks. The birth of HTML.
But then we wanted the simple text documents to look better so we began to push the limits of what HTML could do. We wanted colors, tables, indents, and other formatting features that changed how the data looked.
Somewhere along the line someone developed XML as a way for us to seperate data from how we format the data. But XML itself is pretty ugly. And so we use a variety of technologies to render XML data into something more recognizable. Think of XML data as if it were a database. Once you grasp that, it's simply a matter of getting the data out of the db, formatting it the way you want to see it, and then sending it to screen.
XHTML has little to do with XML as far as I can tell. It's out there on it's own and while I've built websites with it, the only advantage I see to using it is in combination with CSS where I can basically remove the bulky formatting containers required in HTML (like tables and fonts).
Will XML replace HTML? Not as a method for viewing data. But as a method for storing and retrieving data - you betcha and has already made significant inroads. Anyone who has used and RSS/RDF feed has used XML technology. The same goes for anyone using the Amazon API toolkit to access the Amazon database. XML is here to stay as a backbone for data formatting and data exchange but will not, and never was meant to, replace HTML.
That being said, technologies like XSLT and various parsers for script languages are in use now to take XML data and present it to screen. But in the end - even their output is HTML (or XHTML if you desire).
|Using X(HT)ML instead of HTML assumes that a) you need to give parts of your audience automated access to your content via an XML parser, and b) machines and humans can both use the same interface effectively. |
Humans and machines do not view XML in the same way. It is the responsibility of the client software to format the XML into a human readable format.
I agree that XHTML is less than ideal for machine analysis; XHTML markup conveys only page-layout, not semantics. XHTML enables access to the efficient, simple and reliable properties of XML (compared to the inefficiency, complexity and unreliability of modern HTML implementations), but more importantly performs well as a simple data transformation.
In a data-oriented website, content can be retrieved in XML format, even if the underlying mechanism is a relational database. This data can be served as SOAP via one data transformation, or as XHTML via another. These transformations are fixed, easy to maintain, and do away with much of the multi-language mess that forms the core of contemporary CGI scripts. The XML -> XHTML -> Render transformation may take place at the client or server end, but in essence it is no different from the XML -> SOAP -> Render transformation that takes place when a user agent requests data by web-service. Moreover, taking this approach allows support of multiple disparate user agents, from Web Browsers, to Perl scripts, to Desktop software, to other websites, and all just by writing an additional transformation script (in XSL, for example) and setting appropriate access constraints.
To put it succinctly; Whilst XHTML alone offers several benefits, adopting a full XML-based transformation approach enables you to serve and sell data to more than just web browsers. Try to see beyond creation of HTML markup to an automated mechanism that doesn't need you to watch over every last tag.
|adopting a full XML-based transformation approach enables you to serve and sell data to more than just web browsers |
A very good point indeed. XML as a backbone for distributing data is something much larger than most folks are able to see. It's a pretty big picture to see all at once. The fact that there are nearly a 100 initiatives that are working to develop specs for different ways to utilize, exchange, and format XML data should be a good indicator of it's potential.
BTW - I noticed that several of you are relative new-comers here. Welcome to WebmasterWorld!