Request for comments (alpha)

[Ian E. Gorman]

While I am releasing alpha versions, it will be possible to make changes that are incompatible with preceding versions.  My current goal is to make the interfaces compatible with implementations for XERCES and ESIS, and perhaps compatible with event-based SGML parsers as well.  This would be a good time to make suggestions or point out any problems that arise from my current design.

[aanno]

Dear Ian,

had a look on your gxparse. I think you are going to the right direction: enhance SAX to simplify the use (and preserve the memory advantage).

However, I always dreamed about supporting XPath in SAX. In principle, this should be possible, at least if all XPath expressions are known in advance (i.e. before triggering any SAX event).

My idea is to have a new SAX like event that is triggered when the (predefined) XPath expression(s) are fullfilled while parsing the XML. (This would result in more than one event in the case of XPath expression leading to node lists.)

I wonder if using Jaxen (jaxen.sf.net) would get me half the way to it. At least, they have a nice XPath (String) expression to Java Object Parser. The other part however (mapping the Objects to SAX events) looks like a bunch of work to me.

Cheers,

aanno

[Ian E. Gorman]

anno:

I don't know enough about XPath and Jaxen to answer your question at this time.

However, the little bit that I know about XSLT and XPath causes  me to believe that they work very well with DOM, because you can use the DocumentBuilder class to load the document, and the Transformer class to process it.

My hope is that GXPARSE will make SAX just as easy as DOM to use, so that people can choose SAX or DOM for other reasons.  For example, DOM to have the document in memory, SAX to do a single pass on a big document.

From this point of view, one might use DOM with an XPath expression, or GXPARSE with an element method to process the same element that the XPath expression would identify.

I now realize that a tutorial is needed, an will have to think how your suggestion mignt fit into that.

Best regards and thanks

Ian

[Ian E. Gorman]

aanno:

My apologies for mis-spelling your name before.

Does the resequencing example (http://gxparse.sourceforge.net/doc/ca/gorman/xml/parse/demo/doc-files/Resequencing.html) do part of what you want to do?  The element_title method does some of what you can do with XPath.  The method picks up the title element, and treats that element differently according to where the element appears in the document.  Thus the element_title method acts in place of a group of several XPath expressions.

In this respect, the XPath expressions are a little simpler, because each one is coded independently of the others.  However, the element method only has to be applied once, which is what we would want to do on single-pass stream processing.

This illustrates one of the tradeoffs between GXPARSE and XPath/XSLT.  Because of these tradeoffs, GXPARSE will be a  better approach to some problems, but XPath/XSLT will be a better approach to other problems (and not just because a wider range of tools is available for XSLT).

Best regards and thanks again

Ian