Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Forget yee not the DOCTYPE, was Re: Dangers of Subsetting? (was RE:Pull-
 Dangers of Subsetting? (was RE: Pull-based XML parsers?)Mike, Another way to define Common XML is by a 'meta' DTD specification (meta in quotes to distinguish from other distinct usages of the term "meta DTD") along the lines: A DTD conforming to the Common XML specification MUST NOT use attributes etc etc... A document conforming to the Common XML specification MUST include the DOCTYPE directive and MUST NOT include an internal subset. Parsers conforming to the Common XML specification MAY NOT read the actual DTD but are free to assume that no attributes will be present (or whatever the actual rules are...) Jonathan Borden The Open Healthcare Group http://www.openhealth.org ---- Original Message ----- From: Mike.Champion@S... To: xml-dev@l... Sent: Friday, November 10, 2000 9:30 AM Subject: Dangers of Subsetting? (was RE: Pull-based XML parsers?) -----Original Message----- From: Rick JELLIFFE [SMTP:ricko@g...] 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
