-----Original Message-----
From: Gavin Thomas Nicol [SMTP:gtn@ebt.com]
Sent: Saturday, November 11, 2000 5:33 PM
To: xml-dev
Subject: RE: Subsetting/ Canonical Parsers/ XML Compliance/ etc.
> XML *syntax* compliance (especially for well-formend parsers)
> is relatively easy to achieve, and should be the basis upon
> which we can build *reliable* applications. If you can't
> trust the foundations, you're toast.
I'm having trouble reconciling this assertion with David Brownell's results (see http://www.xml.com/pub/2000/05/10/conformance/conformance.html ). Even the largest vendors of XML tools distribute parsers that are not fully conformant. Furthermore, there were numerous outright errors in the XML spec itself (which presumably have been addressed by the recent Version 2 spec), and some dispute (by Microsoft, mostly) about what parts of the spec really mean, which means that even the OASIS test suite itself is not universally regarded as an accurate tool to judge conformance. Finally, there are a number of features that an XML processor "may" implement (validation, of course, but also a number of other things, e.g. whether a non-validating parser processes entity declarations from a DTD). In short, the combination of implementation conformance errors, spec errors (at least in the past), and spec ambiguities does not provide as solid a foundation as we would like to believe.
I (personally) think that this illustrates the points made earlier in this thread that generated some rather sharp responses: it's *not* all that easy to achieve XML syntax compliance, hence even syntax-level interoperability (never mind semantic or schema interoperability) is achieveable more easily in theory than practice. No one disagrees that a tool that claims to be XML conformant should *be* XML conformant, nor that it is critical for interoperability that producers and consumers of XML messages and documents completely support some common syntax. A number of us simply believe that as a *practical* matter, at this point in time, something like "Common XML Core" more closely describes an interoperable syntax than does the full XML 1.0 Recommendation. Or to put it another way, *since* you can't trust the foundations as much as we would like, and since you don't want to be "toast", build close to the ground.
The conventional answer is to be "conservative in what you send; generous in what you accept." That is, users can feel free to define a subset of XML features that they employ, but should use tools that support the Recommendations in their entirety. Again, as a purely *practical* matter, an application may need the features of a particular XML implementation (speed, small footprint, platform supported, etc.) even if it is not fully conformant to the XML Recommendations. In an ideal world, that would not be an issue -- everyone would simply implement tools that conform to XML 1.0 + Namespaces. In the world we live in, one of those specs has been out for almost 3 years, the other almost 2 years, and application developers still don't have a good selection of tools that meet the necessary conformance, speed, size, and platform constraints. We can argue about *why* there isn't a good selection of such tools, but let's not assume that this is "easy to achive".
Some of us would ask of the XML standards community (ISO, W3C, and/or OASIS) -- give us a means to define XML "profiles" for a specific class of applications (e.g. Common XML Core, MinML, or "I'll be glad to process external entity declarations from a DTD but won't insist on an instance conforming to that DTD") so that producers and consumers of messages can both be conservative. In other words, since acceptable conformance hasn't been achieved, and with more XML-related specifications at various levels of maturity coming into play all the time, the alternative of defining "profiles" that describe what features a tool does conform to seems reasonable to me. [personally, not speaking for my employer, blah blah blah!]
