Lists Home |
Date Index |
- From: "Simon St.Laurent" <email@example.com>
- To: firstname.lastname@example.org
- Date: Fri, 12 Feb 1999 17:19:46 -0500
At 11:58 AM 2/12/99 -0700, email@example.com wrote:
>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".
This sounds (and looks) promising. I'm not clear exactly _how_ modular it
is, though. Can I take info from the SAX parser, abuse (or nicely process)
it, and feed it back into the DOM tree builder? Or am I stuck to choosing
validating/non-validating and DOM/SAX? Is the 'SAX-like handler' really
SAX with extras, or is it incompatible?
Reading the API is kind of weird. I'd like to know what this 'scanner'
critter is doing too.
Fun stuff, though!
XML: A Primer / Building XML Applications (April)
Sharing Bandwidth / Cookies
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)