Towards an XML Parser Compliance Table Version:17-11-99-15:16

[David Brownell]

> BTW, I think a more useful table would include what other features the
> parsers have, rather than just a strict compliance/validating judgement.
> 
> Example features to consider would be: parser size (why I use aelfred),
> parser speed (why XP is a good choice), language supported (Java/C/C++),
> DOM1 support, DOM2 support, SAX support, SAX2 support, namespace support,
> external entities support, memory usage, maximum file size supported,
> and last but not least character set encodings supported.

Size, speed, and memory are unrelated to spec conformance; seems to
me they should be in a different table.


A curious attribute to consider:  what's the length of the longest
name (or name token) the parser can accept?

Straightforward implementations of an XML parser will often end up
putting some sort of limit there, for example 4K characters might
be an internal buffer size.  With a bit of work, such limitations
can sometimes be removed.

While I would assert that anyone using 4K character names is really
asking for trouble (even in computer generated output!), I'd expect
that an embedded XML engine might find good reasons to have much lower
limits, such as 16 or 32 characters.

- Dave

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/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe 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)