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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Does SAX make sense?

[ Lists Home | Date Index | Thread Index ]

> * have the SAX stream kept cached for the lifetime of the document
> (or have some kind of weak reference perhaps) since they are in memory
> anyway (though unreachable), allowing backward-looking XPaths; or

XPath comes up here and came up in several of the other responses. Perhaps
someone could answer what class of XPaths, if known prior to document parse,
can not be satisfied during the document parsing?

  <child name="C1">Foo</child>
  <child name="C2">Bar</child>

If, before parsing, we know that we need to satisfy
"/root/child[@name='C2']" Why could this not be satisfied? Maybe coming up
with a common SAX->XPath->Results Filter which had a standard mechanism
(e.g. Interface?) for passing back XPath results as encountered in the
process of a SAX stream would be a good plan.

It strikes me that even the preceding-sibling and ancestor axes could be
handled with a simple stack. This would still limit memory consumption and
the objects in the stack could be reused for different "branches".

If all of this was embedded in an interface so that you could register
XPaths before the document parse, and then receive callbacks (or store) the
results of those XPaths you would have something pretty nice. Does this
already exist?

Jeff Rafter


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

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