Partial XML Processors (was Re: JavaScript parser update and Questions)

Peter Murray-Rust peter at
Fri Jan 16 23:48:35 GMT 1998

FORWARDED from David Durand (who has mailer problems) [mentally subtract
one level of >s]

>Return-Path: <david at>
>From: "David G. Durand" <david at>
>Date: Fri, 16 Jan 1998 11:37:28 -0500
>On Jan 16, 10:41am, Peter Murray-Rust wrote:
>> You are not alone :-). There is a difficult decision here for parser
>> writers - do they implement everything in the spec or do they go for a
>> subset? If the latter they are not full XML implementations (and therefore
>> cannot use the label "XML parser"). If the former, they have a *lot* of
>> work to do in understanding the spec and getting it right. I have heralded
>> my own incompetence in understanding NOTATION on this list :-)
>But that got better, right?
>> ....  [trimmed]
>> So you have the following choice:
>> 	- encode the *whole* spec (and nothing but the spec - i.e. no tricky
>> non-compliant extensions) and give yourself the label "conforming XML
>> 	- encode the bits you feel are cost effective and label it "processes
>> XML documents, but gives 'Sorry' messages for some".
>No, this is a choice that it's irresponsible to present, in my opinion. The
>point of XML is to be a _standard_ format. That means that you should use it,
>or not use it. If you're not willing or able to write a conforming parser,
>you should use one or the other of the publically available ones -- even if
>they have bugs, they are under active development and wider use -- the bugs
>will probably be fixed, with a compatible interface.
>Tracking any standard is hard work, because of the way standards have to be
>written, because some things in them are hard to understand, because
people are
>not perfect and our standards never are either.
>In other words, use XML, or don't use XML, but don't muddy the waters by
>propagating a host of almost-XMLs. There's enough free software out there
>already that you can come very close to conformance already, and expect to
>reach conformance simply by use of FTP.
>[digression: my favorite standard _is_ perfect. Rough rendering from memory:
>"The musical note A above middle C shall be defined to be 440 cycles per
>second." A 1-page ISO standard with no ambiguities or flaws.]
>> So the bottom line is that *if* the document author uses ENTITYs, and your
>> software doesn't then you will end up with something radically different
>> from what the author intended. This may or may not matter.
>> If you are the author of the document as well as the parser, then you can
>> make a bargain with yourself that you will never use ENTITYs so your
>> software doesn't need to.
>But of course, the documents that one writes with the intention of never
>sharing them are few and (for obvious reasons) rarely involve special
>>If you then want other people to use your
>> software you either have to add in entity processing OR give them a
>> statement that you cannot process the document. What you must not do (IMO)
>> is to ignore ENTITYs and assume the result is more or less OK :-)
>I'd say that if you're ignoring entities, the most mention of XML that is
>making is to say "an XML-like language, defined by the following grammar:
>In other words, if you're not using XML, make clear that you're defining a
>language (and make clear _what_ that language actually is!).
>David Durand                 dgd at| david at
>Boston University Computer Science        | Dynamic Diagrams
>  |
>                                          | MAPA: mapping for the WWW
>---End of forwarded mail from Mail Delivery System <Mailer-Daemon at>

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS, Virtual Hyperglossary

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list