[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 14:21:11 -0500

From: Lars Marius Garshol <larsga@i...>
>| I'd like to suggest another method in Parser2:
>| 
>|     public String unique(String);
>| 
>| as well as a featureID for requesting unique element and attribute
>| names.
>
>Bill, is this meant to be an interface to the string interning scheme
>of the parser? If so, maybe we should call it intern?
>
>Anyway, if that's what it is I support it. I'm a bit unsure why you
>think the unique method is needed, though. What kinds of uses do you
>have in mind for it?


It would be great if filters had the same advantages as parsers in being able
to simply test for equality (x==y) rather than having to do a string comparison
(x.equals(y)) when checking for a specific element or attribute name. 

>From previous discussion on this list, I gathered that many parsers did the 
equivalent of String.intern(), but avoided the JavaSoft implementation for
extra speed. If this is the case, then a filter needs to use the parser's own
intern function to preprocess its constants before testing for matches in the
startElement events.

So the short answer is yes, intern is beter than unique. I should have checked 
the lang package first. 


>| If a parser supports both the unique feature and provides access to
>| its element stack,
>
>Hmmm. I think this should be skipped. We'll need a special interface
>to represent the stack, and parsers will probably have to do some
>internal juggling to weed out information from the internal stack
>that's only for internal use (and to adapt it to the SAX2 interface).
>
>I think the result will be lower performance than if the application
>maintained its own element stack.


When you are working with filter structures, it is difficult to say where the
parser ends and the application begins. You raise an implementation
issue that there should be a separate stack that is accessable, distinct
from the one used by the parser. 

My interest here is, instead, to define a means for sharing the element 
stack across independently developed filters. Just about every filter
which does anything interesting ends up implementing its own element
stack. Why not have one filter that does that, and let the rest get it from
their "parser". (Think of parser as a role, a source of events relative to a
particular event consumer, not an implementation. The confusion here
comes from giving the interface the name Parser or Parser2, when it
can be either the actual parser or just another filter.)

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

• Follow-Ups:
  • Re: Fast filter support in SAX2
    • From: David Megginson <david@m...>
  • Re: Fast filter support in SAX2
    • From: Lars Marius Garshol <larsga@i...>

• Prev by Date: DOM: notations and unparsed entities
• Next by Date: Re: Fast filter support in SAX2
• Previous by thread: Re: Fast filter support in SAX2
• Next by thread: Re: Fast filter support in SAX2
• Index(es):
  • Date
  • Thread