xml-dev - Forget yee not the DOCTYPE, was Re: Dangers of Subsetting? (was RE:Pull-

[Jonathan Borden <jborden@mediaone.net>]

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@SoftwareAG-USA.com
To: xml-dev@lists.xml.org
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@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.