I was concerned late last week when I read that the XHTML Working Group will not be allowed to finish its work. The announcement indicates that this is being done to speed the work of HTML5 - but it also raises important questions about how XML will work with data on the Web.
http://www.w3.org/News/2009#item119
2009-07-02: Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the HTML Working Group, W3C hopes to accelerate the progress of HTML 5 and clarify W3C’s position regarding the future of HTML. A FAQ answers questions about the future of deliverables of the XHTML 2 Working Group, and the status of various discussions related to HTML. Learn more about the HTML Activity.
Originally, HTML was based on SGML. XML was designed to make SGML easier to parse, so that it would be more accessible to software. From the beginning, XML was designed to support documents meant for humans to read, and data designed for programs. In modern software, there is no firm boundary between the two - data is often transformed on the fly for humans to read, and software often mixes human-readable content with data.
By representing HTML as an XML vocabulary, XHTML addresses HTML parsing issues, difficulty combining HTML with XML data, and extensibility issues:
- An XML parser can not parse arbitrary HTML, and parsers which do are extremely complex. Tools like Tag Soup parse arbitrary HTML and convert it into XHTML, so that even legacy content in odd dialects of HTML can be processed by XML tools.
- XML vocabularies like SVG (a graphics format) and MathML (a mathematical notation format) need to play nicely with HTML. XHTML lets them be combined with HTML using the same mechanisms all XML tools use to combine vocabularies.
- HTML has become quite large, and XHTML provides a modularization of HTML, using XML mechanisms, that makes it easier to maintain and extend.
Typically, Working Groups are rechartered if there is active interest in their work and they are close to their goal, as the XHTML Working Group is. Another year of effort would probably be sufficient to finish the XHTML specifications. And the XHTML people are intimately familiar with XML and namespace issues, plus the issues that arise with XML and HTML software.
The FAQ that the announcement points to concerns me. Some of the work of the XHTML Working Group will not be finished, and there is even a suggestion that HTML5 will not handle namespaces correctly, and that XML vocabularies will not be able to mix freely with HTML5!
Consider this issue, to which the FAQ points:
http://www.w3.org/html/wg/tracker/issues/41
The HTML5 specification does not have a mechanism to allow decentralized parties to create their own languages, typically XML languages, and exchange them in HTML5 text/html serializations. This would allow languages such as SVG, MathML, FBML and a host of others to be included. At one point, an editors version of the HTML5 specification contained a subset and reformulation of SVG and MathML. Tim Berners-Lee described this incorporation of SVG and MathML without namespaces as horrific and the issue raiser [Dave Orchard] completely concurs with the him.
This issue limits the ability of non-HTML5 working groups to define languages as the languages must be “brought into” the HTML5 language. This dramatically increases the scope of HTML5 and decreases the ability to modularize development of orthogonal languages.
In the end, the problem could result in the text/html serialization rules becoming the standard serialization rules for XML languages, replacing XML itself. This could occur if every decentralized language has a choice between the XML serialization, the text/html serialization or both. In many cases, the language may choose the text/html serialization.
I find this last paragraph alarming. XML was designed specifically to allow decentralized parties to create their own languages, and to combine them cleanly using namespaces. By using the mechanisms defined in XML, XHTML inherits this ability, an ability that HTML5 lacks. One proposed solution is to absorb XML entirely into the HTML5 specification. I agree with Tim and Dave that incorporating SVG and MathML without namespaces is horrific, but the obvious solution is for HTML5 to support namespaces and XML cleanly - just as XHTML does.
I would like to see the XHTML Working Group finish their work, and I would like to see the result used as the XML serialization of HTML5. Legacy HTML ensures that there will always be large amounts of HTML content that is difficult to parse without tools like Tag Soup. But XHTML gives us a very sane XML vocabulary to convert such content into, and makes HTML accessible to the wide variety of XML tools that make up much of the infrastructure of the Web.
They were not called the “XHTML WG”, they were called the “XHTML 2 WG”.
If you want to use XML on the client side, you can use XHTML5. This is the name given to a document that uses the HTML5 vocabulary and served as application/xhtml+xml. If you just want to use XML on the server side, but text/html on the client side, then you can use HTML5 (text/html) as the HTML5 spec allows this to have a limited amount of XML syntax so you can parse it by a HTML parser or a XML parser.
Again: XHTML continues to be supported as one of the two serializations of HTML5.
The main thing that *is* going to stop is work on XHTML2, which is incompatible with XHTML-as-we-know-it anyway.
Rob, Julian,
The issue I quoted in the blog post indicates that the current XHTML5 flunks the “plays well with others” test, by making it difficult to use vocabularies not defined by the HTML5 Working Group. Or am I overinterpreting that?
I think cleanly handling namespaces is important for XML tools to work with this data.
Jonathan
The issue quoted discussed the HTML serialization of HTML5, not the XML serialization, so it’s wrong by not examining the entire picture.
I’m curious, tho: when have you ever had a reason to run generic XML tools on XHTML that contained content from multiple namespaces beyond the XHTML/SVG/MathML set? I see namespaces in HTML as a solution in need of a problem, because nobody seriously cares to use that other-namespaced content, because browsers are going to treat it entirely generically anyway (except in the individual cases where they make the effort to treat it specially — which is by necessity fundamentally non-modular anyway).
Jeff: The single most important issue is this: HTML is not just data for web browsers, it’s data that can be used in many different applications, or transformed into other HTML representations to be presented in different ways.
This data is used together with data from other source. For screen scraping and data integration, it is common for some of the content to be HTML content, and other content to be represented as XML (the original source may or may not be physical XML). These tools should be able to work on all the data the application needs.
If HTML is only data that can be read by human beings in web browsers, it’s much less valuable.
“For screen scraping and data integration, it is common for some of the content to be HTML content, and other content to be represented as XML”
Accepting that we’re outside of the browser realm for the moment, what backend systems keep content in this manner, with both HTML and other-namespaced content in a single document/fragment? I’m curious.
Jeff - think mashups. You get some data as XML, combine it with HTML data that you fetch using HTTP.
Or applications in which people write in HTML, but what they write is combined with data, as real or virtual XML. In other words, applications that combine documents with data on the back end.
In many of these cases, the system doing the integration does not keep the HTML content on the back end, it retrieves it using HTTP.
“combine” how? Namespaces provide mechanism, but mechanism without a detailed description of the interaction - interaction which necessarily happens on a pair-by-pair basis, for the most part, and which therefore will happen to a very limited extent - has no semantic meaning. Also, I was asking for existing systems, not theoretical ones which may be interesting but not actually practical if created in the real world.
Except for namespaces being hard for humans to work with because we often start assuming prefixes are meaningful in our code — when really they only have meaning lexically — namespaces are almost the easiest part of integrating two separate structure-data languages. The remaining part is not simple enough in my view to make the incremental step all that interesting.
IMHO the way HTML5 now is going (and killing the namespace effort), is that it will become a nice flashy User Interface programming environment nothing more nothing less. Client Server environments all over, just packaged in new colors.
With no means and precise agreements, now and in the future ,about data exchange, it will become almost impossible to do with all the info present on HTML pages. IMHO it is apparently more important to support “cool things” and also do more with the info presented.
I’m not much of a fan of namespaces, but I still note that, as far as namespaces make it easy to integrate two different languages, the XML formulation of HTML5 will allow integration of content from non-HTML5 namespaces. The whole “HTML5 kills namespaces” shibboleth is incorrect; the XML formulation of HTML5 is a perfectly acceptable, competent, and feature-ful way to include namespaced content in HTML5.
Jeff - but the XML serialization of HTML5 does not represent the same thing as the HTML serialization, they claim to be two different serializations of the same thing, but they do not represent the same post-parsed structure, and they do not round-trip.
And without namespaces, how do you intend to handle clashes in names between different vocabularies?
For years, we’ve emphasized the ability to reuse data in different ways, integrating document data with data from programs, repurposing it flexibly. HTML5 takes the perspective that HTML is meant only for web browsers, and the ability to use XML tools and mix data from different domains is not important. That’s a giant step backward.
Jonathan, that’s always been true of HTML versus XHTML, regardless whether we consider XHTML1 or XHTML5, as long as you actually interpret the XHTML as XML and don’t process it with an HTML processor — which means you must use application/xhtml+xml as the MIME type. Consider even a table that doesn’t include a tbody element, for perhaps the simplest example.