W3C Technical Plenary: The Future of XML
I just returned from the W3C Technical Plenary week in freezing Boston (how can one have meetings in Boston in late February/early March?!) mainly to attend some XQuery working group meetings. On Wednesday, the W3C organized a true plenary meeting (only one meeting track for all). One session was on the future of XML with several esteemed colleagues of mine such as Jim Melton, Noah Mendelson, Liam Quin, Norm Walsh, Rich Salz, and Robin Berjon sitting on the panel. Each panelist gave a statement of varying length (and content :-)) about future aspects of XML. After that the audience had time to make a statement or ask questions. Since I gave a statement that nicely summarizes my thoughts on this, I decided to repost it here (paraphrasing it).
Before I do this, I want to give a quick synopsis of some (but not all) the statements made on the panel. Robin reported on the Binary Characterization working group which unfortunately, but not surprisingly came to the conclusion that it is a good idea to attempt to standardize binary XML along the 18 dimensions they identified. Norm recommended to jumble many of the existing specs together into a super XML spec. Unfortunately, he proposed to include APIs such as DOM and SAX. Liam stressed that even though XML 1.1 does not seem to be a success (Noah pointed out the problem that XML 1.1 brought to using XML Schema), it is still important to add support for the languages that currently cannot be used in XML names to not disenfranchize parts of the world population. One of the panelists, I don't remember who, argued that it is time to get rid of the warts of XML (not saying what they were).
Here is the statement I made:
My first question to Liam: What percentage of the world population speaks binary XML? :-)
The XML standardization process is similar to building a house: XML 1.0 serves as the foundation, and each specification adds another floor. Once you have build several floors on top of the foundations, you are not starting to replace the foundation. And if you fix or renovate it, you do it very carefully without affecting the higher floors. XML 1.1 was not such a careful renovation and was close to making the house unstable.
One of the reasons for XML's success was certainly that it provides functionality for many different constituencies. However, this means that somebody's wart is somebody else's beautyspot. So removing warts from XML will lessen the wide-ranging appeal and may again affect the foundation negatively. In other words: Success breeds responsibility.
Similar issues have to be considered with binary XML (see also my previous postings). Standardizing binary XML may potentially widen the foundation, but if it does not do it in a way that keeps the original aspects in place, the house will either fall down or you basically build another house. In the later case, you are going to loose the benefit of the large networking effect that you get by fitting into the already built eco-system.
To conclude, here is what I would like to see as the future of XML:
- Let the foundation be. It may have some small cracks but it is stable enough and should last for a while. We have build quite a house on it already and we should continue to build with what we have and innovate on the top in areas such as XQuery, XSLT, programming language integration, semantic web, web services etc.
- If you must standardize binary XML, do it right. The right way to add binary XML encodings (note the plural) is to
- Use the encoding property of the XML declaration to indicate the binary encoding. Some people claim that this makes it impossible to mix different code page encodings. But that is incorrect since the binary representation can provide for that.
- Still mandate the two required encodings UTF-8 and UTF-16 for binary XML parsers. If you don't, you bifurcate the XML world and weaken the foundation of the floors above.
- Unterstand that there will be more than one binary XML format. Thus leave it to the domain specific groups to define a binary XML and do not attempt to define the one to rule them all. It is very unlikely to define a format that optimizes a dozen, partially conflicting goals.
One binary XML proponent then argued that binary XML is not so bad since one can take care of finding out whether to ship textual or binary with content-negotiation between the server and the client. While this works in a closely-coupled environment (where I see lots of uses for binary XML), this is not feasible in loosely-coupled environments where the big advantage is that you do not need to negotiate with your client. You publish, the client consumes. Noah and I were in agreement on this.
[Update: Norm posted his thoughts and clarified his position on the spec refactoring. It was not Microsoft that suggested rescinding XML 1.1 (I think it is an interesting idea), but Jonathan Marsh who works for it. I would think that Norm understands the difference. And we have to distinguish between the idea of a more inclusive XML spec and the reality of the existing XML 1.1 situation. Many good ideas with bad execution have been cheered on in history...].