The future of web development - XML vs. XHTML

[bcarl314]

As I sit here writing this (ok, not AS I write it, but you know what I mean), I'm working on a web site for out intranet coding to XHTML 1.1. Then I open my email and see my latest sitepoint article talking about Semantic Mark-up. There's alot of you around here who are intimatly familiar with the subject. The article pointed to the XHTML 2 (http://www.w3.org/TR/xhtml2/) standard and looking it over I got to wondering, "What will the future bring for HTML"?

As we all know XHTML is a derivative of XML, and we should be using semantically correct markup for our web pages, but my question is, do you think at some point in the very near future, HTML (including XHTML) will be completly replaced with XML and XSL?

Why bother with a XHTML 2 standard? Wouldn't it make more sense to emphasize XML and XSL compliance? Or will there alway be a need to be backwards compatible to older browser which do not interpret XSL tranformations?

What are your thoughts? I'm thinking of beginning to create all my web sites in XML and use PHP to apply the XSL I need and plop that out to the browser, the idea being that eventually, the PHP processing can go bye bye and I can simply send the XML and XSL to the browser.

[liorean]

Well, I think if anything is going to replace HTML, it will be another applied markup language, not a general markup language. For example, I can see Docbook, RDF, Atom, RSS and SVG taking over part of what HTML has done. But the major part of what HTML did will not do lateral moves, to other languages, but instead to new generations of HTML. HTML is small, but still expressive enough for most purposes.

As for XSL-FO, I don't think it will ever grow an especially large following in the web design world, as CSS provides a more practical way of styling. XSLT on the other hand may grow strong, but the fact still stands - XSLT just changes a document from one XML based source document, to another end document. PHP can do everything XSLT can, and more. STTS can do most of what XSLT can, but has a more easy to grasp syntax based on the CSS lexer. BECSS, if it ever becomes reality, can do most of XSLT's job without having to actually transform the document. A kind of XSL-FO versus CSS analogy for XSLT if you like. However, XSLT requires a target document format. If you send the browser XML + XSLT, and the XSLT transforms to XHTML, for all practical purposes you ARE serving it XHTML, and you are adding yet another reliance on the client, on top ot XHTML and CSS parsing.

In short: XML is a structure building format, that can be used as a document format. A document that is not purely for storage needs to have some form of semantics, assigned meaning, functionality, behavior or presentation attached to it, or else it is useless. That is what the XML Applications, among them XHTML, XHTML2.0, SVG etc. are there for. Sure; CSS, XLink, XInclude, XML Events, Namespaces in XML, XSLT and other XML related specs allow you to add all of these, but they do that by making it no longer just XML. XHTML delegates styling out to CSS, but otherwise provides all of these by itself. That's the benefit of using XHTML.

[me']

Extremely Related (http://annevankesteren.nl/archives/2004/01/xml-versus-xhtml).

My views: I'd like to stick to XHTML, but not just XHTML. Any time you find yourself struggling to find a semantically good tag, I'd like to use one I just made up. I havn't thought about this much (several issues immediately jump to mind, most prominately validation). But surely the mime-type application/xhtml+xml implies I can do this already?

I won't dive into the XML semantics vs. XHTML semantics debate, but I will say that I believe XHTML is applicable to enough of websites these days to stick around. Inevitably, I think we'll see specialised versions of XHTML emerge to suit the different needs of the web (personal site, blog, scientific paper etc.). At first these are bound to be like XHTML but in, say, 10 years, we may find ourselves using completely different standards.

[Alex Vincent]

I have to concede a few points about XHTML:

(1) You have to have a good reason for using it instead of valid HTML.

If you can't answer the question, "Why do you need the XML aspects of XHTML?" you probably want HTML.

Yes, I did look at the Sitepoint article. :) Yes, I wholly advocate using XHTML. :)

me: You might want to look up the XHTML Family portion of the Modularization of XHTML specification. That's the sort of thing you're talking about.

Incidentally, XHTML 2 is a long way off. Do not use it yet; it's a working draft at the W3C and, the last time I saw it, a very heavily debated one...