ModSax Suggestion

[Bill la Forge]

From: David Brownell <db at eng.sun.com>

>I've always liked the idea of filters in the SAX event chain.
>As Bill la Forge (and you) noted, that's a fine way to address that
>general issue.  One can overdo layers, of course, and pay for it
>in performance.  But filters are a good architectural notion, and
>there's been lots of discussion about how to use them well with
>SAX and DOM.
>
>That does imply keeping DOM out of the basic parser API, which
>I still think is the best way to go.  An event generator (say,
>a SAX parser, or something walking a DOM tree) can have its
>events filtered, and delivered to acomponent building a DOM tree.


A filter can itself hold a stack of other filters, or even a set of filters
to which events are routed based on some pattern. Being able
to place just one filter in front of the DOM built by the parser
is all you really need.

Using the ModParser interface, can do the following:

1. Use setFeature to turn on DOM construction.

2. Use set to insert a filter in front of the DOM.

3. Parse a document.

4. Use get to retrieve the constructed DOM.

Bill


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 (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)