The IETF, Best Practices and XML Schemas

June 12, 2002

Leigh Dodds

In this week's XML-Deviant column, I examine an XML best practice guide under development by the IETF, as well as the XML Schema language debate which it has reignited.

Best Practices

An new Internet Draft, "Guidelines for the Use of XML within IETF Protocols", is currently working its way through the IETF process. Its authors have recognized the growing interest in using XML to represent structured data within Internet protocols; thus, they're producing a document that "...describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols."

The document's scope explains that its guidelines are not applicable to carrying XML over SMTP or HTTP, nor does it provide guidelines for "XML Protocols" in the SOAP and XML-RPC sense. Indeed, the document even falls short of recommending XML for describing data. Rather, the document aims to present best practices once the decision to use XML has been made, demonstrating the customary IETF pragmatism.

The contents of the draft are largely uncontroversial and have strong parallels with the Common XML specification produced by the SML-DEV mailing list, edited by Simon St. Laurent. The IETF's recommendations, including to avoid reliance on processing instructions and comments and avoiding the use of entities, are such common parts of XML folklore that an extremely enthused Tim Bray remarked on the ietf-xml-use mailing list that:

I should add that I believe that this is turning into a very significant document indeed. While the title may say "... within IETF Protocols", this is on its way to being IMHO the best single reference I've seen anywhere on The Right Way To Do XML....I think we're gonna be living with this one a loooooooooong time and it's worth going the extra mile to get right.

However, during the discussion of the latest draft it became clear that it was still some way from achieving the rough consensus which would allow it to move to a more formal status.

One point of discord was the recommendation that, on considerations of simplicity, only the UTF-8 encoding be allowed in protocol data, rather than the UTF-8 or UTF-16 option mandated by the XML specification. Tim Bray and Murata Makoto were among those who argued for lifting this restriction, without much success so far, as the discussion appears to have reached deadlock.

The other contentious point was over the recommended choice of schema languages. The Internet Draft acknowledges that there is an ongoing schema debate in the XML community and that several alternatives are available, but it concluded that unless a good reason could be identified, W3C XML Schemas (XSD) should be the schema language of choice.

Schemas Debated

This recommendation triggered a response from James Clark which set out in no uncertain terms his view of XML Schema. In the posting Clark underscored RELAX NG's strengths, including stability, open development, the presence of independent interoperable implementations, its grounding in tree automata theory, and its ease of use. Clark explained that in his estimation the key criteria for selection of a schema language should be its ability to "...communicate unambiguously and precisely to a human reader what XML documents are legal for that application; it serves a similar role for XML that ABNF does for text." The remainder of his message makes a very strong case that RELAX NG (RNG) meets this criterion better than XML Schema.

Clark explained that he and others had worked hard on making RELAX NG a credible alternative to XSD:

I am sorry to have gone on at such length, but I think this is an important issue. There seems to be a tendency for people to suspend their technical judgment when it comes to W3C XML Schema. The attitude seems to be "It's a W3C Recommendation; everybody is using it, so we should too, regardless of its technical merits." I don't think this attitude serves the best long-term interests of the Internet. I and others have sacrificed a huge amount of time and effort to try and provide the community with a solid, technically credible alternative and I think it deserves to be considered seriously on its technical merits and not dismissed on the basis of its current level of market acceptance.

There was whole-hearted support for Clark's view from a number of contributors. Tim Bray considered RELAX NG to be closer to the " IETF style" of development and also noted that

In terms of de jure blessing by official bodies (if IETF cares) XSD's standing is effectively equal. In terms of technical quality, I challenge you to find anybody anywhere who will argue that XSD comes close to RNG.

Miloslav Nic and Jiri Jirat suggested that the adoption of XSD for IETF protocols "would have very unfortunate effects on the future and it could create tremendous problems for everyone." And Rick Jelliffe again promoted his view of a plurality of schema languages, arguing that not limiting the choices in higher application layers stays closer to the spirit of the successful layered design pattern (i.e., the protocol stack) which has worked so well on the Internet. Jelliffe argued that DSDL, which supports a more modular framework, is more like the Internet in this regard.

The strong response was seriously considered by the IETF editors, who expressed a preference to simply remove the recommendation and continue to acknowledge the issues under debate. Which is something like "rough consensus" in action.

Rippling Outwards and Onwards

Not surprisingly, given the personalities involved, this debate has rippled into a number of areas, causing XML-DEV to surf the anti-W3C Schema wave once more. This topic has been recurring for some time, although the fresh angle here was the exchange of ideas on ways to evangelize RNG. The number of feature rich RELAX NG tools and the specification's blessing from ISO seem to be allowing it to gain further traction.

It's interesting, however, to see that this debate hasn't been confined to the XML-DEV cognoscenti. Other developers are beginning to air their frustrations with XML Schema or report on experiencing an "aha!" moment after taking a closer look at RELAX NG. Simon St. Laurent's weblog entry, "Rising Rebellion Against W3C XML Schema" captures the current mood very well. Although the negative comments don't stop there.

For example, Thomas Passin reported that working with XSD has proven to be time-consuming and not without interoperability problems.

...I find XML schema to require far more experimental computing to get right, and to be less predictable, than any other XML thing I have been involved with. I have to experiment a lot with XSLT, too, but when I'm done I generally understand what is going on and what that part of the Rec means. Not with XML Schema.

In his XML Europe 2002 paper (the complete proceedings of which are now online), " XSD Schemas in Book and Journal Publishing", Alex Brown concludes that

...publishers should be very wary of this technology and weigh carefully the benefits that may be getting from it, before committing. In my judgment for such applications they are difficult to use, poorly supported, offer little more than DTDs, and cost too much to implement.

As frustration spreads it becomes harder to dismiss this as general XSD bashing; there are clearly issues with the technology which can't just be solved by improving the level of documentation. James Clark and others have raised technical issues with XSD which have yet to be clearly answered. However, there are clearly use cases for which XSD is eminently suited, notably data exchange. Its strong typing features, while clearly controversial for many, are needed for some applications. We might then recommend the alternatives, as Rick Jelliffe advises, based on their strengths in particular application domains: XSD for exchange of strongly typed data and RNG for document validation. This certainly seems the safest course at present.

Yet there are signs that the RELAX NG developers are setting their sights on addressing this imbalance. In a message to XML-DEV James Clark explained that type assignment could be achieved in a modular way, possibly defined in a separate "RELAX NG Type Assignment" specification.

[A]lthough XSD out of the box provides much more support for data-binding than RELAX NG, nonetheless RELAX NG provides a suitable basis on which to build support for data-binding. The RELAX NG approach gives a lot of flexibility and avoids imposing costs on those who do not use XML just as a serialization format for C# and Java. However, I have to admit that until such time as the [relevant] kinds of annotation...get standardized, RELAX NG provides less interoperability than XSD for data-binding.

This area of research also seems to be of interest to Murata Makoto who recently explained that type assignments can be made from RELAX NG schemas without having to perform full validation. While these kind of layered architectures have been discussed for some time, the fact that RELAX NG and DSDL have these as core design principles suggests that they have a very real chance of delivering them.