OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Fast filter support in SAX2

[ Lists Home | Date Index | Thread Index ]
  • From: "Bill la Forge" <b.laforge@jxml.com>
  • To: "Lars Marius Garshol" <larsga@ifi.uio.no>, <xml-dev@ic.ac.uk>
  • Date: Sat, 27 Mar 1999 15:46:52 -0500

From: Lars Marius Garshol <larsga@ifi.uio.no>
>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
>comes from?
>
>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
    registration.

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?

Bill




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS