Lists Home |
Date Index |
- From: "Bill la Forge" <email@example.com>
- To: "Lars Marius Garshol" <firstname.lastname@example.org>, <email@example.com>
- Date: Sat, 27 Mar 1999 15:46:52 -0500
From: Lars Marius Garshol <firstname.lastname@example.org>
>However, then we need to define the element stack interface and what
>should be included there. Just the elements? Elements and attributes?
>Elements, attributes and sibling number? Which entity each element
>Maybe this should be done outside the SAX core? On the other hand, if
>filters are included I think this should be too.
I'm all for delaying things which are independent of the SAX2 core. It will be
good to be able to focus on filter considerations, aka MDSAX2. The
complication is when filter considerations impact SAX2.
For example, where would be the best place for the intern method? I would
hate to see it on Parser2, as that creates added overhead for each filter.
(Yes, and I was the one who suggested it. :-)
So far, I have a pretty short list of things we might need for filter structures:
1. An intern interface.
2. Request that element and attribute names be intern'ed. (Might be combined
with a successful get on the intern interface.)
3. Element stack interface.
4. Application event routing. Necessary for non-linear filter structures where more
than one filter needs access to the events coming from the application, like handler
In addition, I also see a need for a DOMWalker interface:
public interface DOMWalkerContext
public Element getCurrentElement();
A filter could ask this of its parser and then be able to process "parse" events
based on their source in the DOM. A good start for a SAX-based XSL, I suspect.
But like I said, this should wait.
On the other hand, I would like to suggest that Parser2 NOT be derived from
Parser. We could then have a pure SAX2 implementation, where things like
document handler would be registered just like any other SAX2 event handler.
This would make for much cleaner filter2s. And there's going to be a whole lot
more filters than parsers, mm?
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)