[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Fast filter support in SAX2

  • From: "Bill la Forge" <b.laforge@j...>
  • To: "Lars Marius Garshol" <larsga@i...>, <xml-dev@i...>
  • Date: Sat, 27 Mar 1999 15:46:52 -0500

fast filter
From: Lars Marius Garshol <larsga@i...>
>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@i...
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@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.