> my problem is, whenever i come to a point in the proposed
> recommendation at which a parser is required to report an error and
> "must not continue normal processing" even though the result which
> the stream would denote would be sufficiently unambiguous if
> allowed, then i feel compelled to ask, "why does one have to
> exclude this"?
[...]
> more than likely, when i've followed discussions of similar
> questions, the design goal #3 gets hoisted like a commandment: "XML
> shall be compatible with SGML".
No, it's not SGML's fault, at least not this time. Conforming SGML
parsers are allowed to continue processing if they want to, and are
even allowed not to report errors at all (as long as they don't claim
to be "validating parsers"). XML has gone way beyond any SGML
requirements with this one.
All the best,
David
--
David Megginson ak117@freenet.carleton.ca
Microstar Software Ltd. dmeggins@microstar.com
http://home.sprynet.com/sprynet/dmeggins/
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)