I still don't understand how you think you increase interoperability by limiting a system in what it takes as input, but I guess it's ok...
There's no big secret here. It's *exactly* how XML increases interoperability by requiring draconian well-formedness checking. As the number of maybe right/maybe wrong formats increases interoperability decreases. The XML philosophy is fail as early and as fast as possible, and that works.
When I see XML 1.1, I want the parser to fail immediately and at the first opportunity. I don't want to let the document propagate through the system until it finally runs up against some component that can't handle it. I certainly don't want to accept a million documents needlessly labelled as XML 1.1, only to have the system fail unexpectedly in production when one of those documents uses a NEL or a Linear B tag name or something equally pointless. I want to debug it as near the source as possible, not a thousand miles and six months away.
Failing fast on any variation from a single syntax is one of the pillars of XML's interoperability. It's sad to see this lesson has not been learned or the principle adopted by so many purveyors of XML tools. In fact, I'd venture to say that most non-parser XML tools are far too accepting of bad data.
In any case, I have now added unit tests to my code to verify that version="1.1" (and 1.2, and 2.0) generate a fatal error; so I should notice if this bug slips in again in the future, either in Xerces or a different parser. I'm not surprised that all other parsers haven't been noticing this. I've certainly found a lot of bugs in them. Xerces 2.6 currently has one conformance bug that affects me <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24124>. The next best parser, the latest Oracle beta, has about ten. The remaining parsers written in Java all number in the dozens.
Sadly, XML's goal of being simple enough to be implemented by the desperate Perl hacker was not met. If after six years and the application of huge amounts of effort and brain power, we still don't have one parser that gets the basic spec right, then there's something wrong with the spec. Sadly most of these problems are not addressed by XML 1.1. :-(
--
Elliotte Rusty Harold
[EMAIL PROTECTED]
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
