Lists Home |
Date Index |
- From: email@example.com
- To: firstname.lastname@example.org
- Date: Fri, 12 Feb 1999 11:58:55 -0700
>>There will always be a tradeoff between code size,
>>performance and conformance to the spec. We have taken the same
>>for XML which might go outside our environment or some in from outside,
>>use a heavyweight parser with full validation. But where it's "behind
>>covers" we use a homegrown (tiny, nonconformant) parser and just check
>>structures a few times during design, with a validating parser.
>If we could work with parser layers rather than parsers, this might become
>a lot easier to manage. We could just turn on the parts we need and turn
>off the ones we don't.
We have taken that approach with our 'Version 2" parsers, Java and C++.
They are pretty well layered and pluggable. Don't plug in a validation
handler and you won't do any validation work. Don't plug in an entity
handler, and you won't get any entity information, etc... Basically we've
just extended the concept of a SAX-like handler all the way into the core
of the parser. It allows both for extensibility by rolling your own
handler, and for the client who is putting together a particular type of
parser configuration to tell the lowest level of the parser "do the least
work possible for this group of things, since I'm not even interested".
Though, relative to the original conversation, despite allowing for better
scalability and optimization in the field according to need, it does
increase the complexity of the parser itself in some ways.
BTW, the C++ version should hopefully hit Alphaworks before too much
longer. We are on our 4th or 5th internal release and the next weeks will
be 'making the last details work' part of the effort. I can't say when it
will get out there, since I dunno about such things (I'm just the measly
author :-), but it should be relatively soon. In terms of the external
interfaces to the client code, it pretty much matches our version 2 Java
parser architecture, though internally it is quite different.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)