-----Original Message-----
From: Rick JELLIFFE [SMTP:ricko@geotempo.com]
Sent: Friday, November 10, 2000 5:18 AM
To: ,Xml-Dev (E-mail)
Subject: Re: Pull-based XML parsers?
But I urge developers to boycott any XML parsers that do not attempt to
provide full support for XML 1.0, in any general-purpose development.
If you use them, *you* are creating interoperability problems, not the
people who use XML 1.0 in their documents. Perhaps the kxml people
might put in a paragraph in their documentation warning against using
their system in general-purpose applications too.
This nicely pulls together many of the things we disagree about on this list :~)
First, it is non-trivial to move from "Common XML" to full XML support. I had the opportunity to observe a project in which an XML novice built successive iterations of an XML system. MinML (Common XML without even attributes or mixed content) only took a few days to imlement (and out of the box, with no optimization, it could parse "MinML" as fast as expat could). The second iteration with Common XML support took a couple of weeks. The third iteration to fully support well-formed XML 1.0 took maybe a month. The fourth iteration to add namespaces took maybe another month. The fifth iteration to support validation took several months. It's not clear to me that the theoretical concept of "interoperabity" is worth all the extra work unless there is a very clear business case for supporting every bit of the spec. Many users of XML building custom processing applications won't have this business case.
Second, should XML 1.0 be seen as simply a Recommendation from a group of experienced SGML users/developers, or does it really have standing as a Real Standard? If the latter, I'd have to agree with Rick that supporting a subset creates interoperability problems. But if it's seen as a Recommendation for how to get the whole process started, we (XML vendors, users, and spec-writers) should be listening carefully to the voice of the marketplace ... if a subset of XML 1.0 actually meets the needs of the vast majority of users, perhaps the subset should be the basis for the real "international standard." In other words, shouldn't the "real standard" reflect what is learned in actual practice in the marketplace more than the best guesses and poltical compromises of a group of experts?
Finally, don't we want to encourage innovation rather than simple implementation of (alleged) standards at this point in the evolution of XML? I may be exaggerating slightly for rhetorical purposes :~) but the commandment "thou shalt implement the W3C Recommendation, the whole W3C Recommendation, and nothing but the W3C Recommendation" would have tended to throw cold water on lots of things that have turned out to be very useful, such as SAX, RELAX ... Schematron????
So, to belabor my favorite rant, there's a real difference between "Recommendations", which are very useful starting points, and "Standards", which set the lessons of experience in concrete. A lot of people agree that XML 1.0 +namespaces is not ready to be set in concrete. Of course developers of tools should make very clear what set of features (be it a subset or superset of a Recommendation) that they do support. If that set is not adequate, the tool will find a richly-deserved place in oblivion. But if that set of features does hit the "sweet spot", we as specification developers should be listening, not complaining.
