Conformance in XML processors

[Jeremie Miller]

> [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 :)
The only reason I wrote a JavaScript XML parser even with the existance of
conformant java based parsers available, is simply because I wanted
extremely simple way to immediately access the contents of any XML fragment
via JavaScript.  Once XML parsers are built into the browser and OS, it
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
not available.

Jer



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;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)