Conformance in XML processors
jeremie at netins.net
Sat Jan 17 17:39:13 GMT 1998
> [some content removed from Tim Bray]
>If there are widely-available fully-conformant processors which are
>already there in the browser and OS, why would you want to use a
>"simple tool" which will fail to accept conformant documents? Seems
>like a way to lose customers, to me.
Excellent point, but we're not quite there yet :)
conformant java based parsers available, is simply because I wanted
extremely simple way to immediately access the contents of any XML fragment
would be foolish to not use them.
Until fully-conformant processors are widely available, I suspect we'll be
seeing lots of "smaller" processors in use, mostly as a bridge to reach the
point when it's a non-issue. Speaking of XML processors in operating
systems, would it be apropriate to have a libXML shared library for Unix
systems? If so, is this being done?
> [more content removed]
>No. The spec is clear; a non-validating processor is required to
>do internal entities and default attribute values. Nobody should
>expect one to do anything with notations or unparsed entities or
>anything else. You want that, get a validating processor.
I think that's clear enough for me, but as you mentioned, after some time,
an _only_ non-validating processor shouldn't exist, as validating processors
should be in wide use and will act in a non-validating mode when a DTD is
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev