Meanwhile I managed to create simple dummy online demo of ForwardXPathNavigator (XPathNavigator implementation over XmlReader) I was talking about. Here it is.
It allows to test what ForwardXPathNavigator can and what cannot select. Upload XML document you like to test (please don't abuse loading huge ones), then enter XPath expression and click "RunQuery" button. I know it looks badly in mozilla, but I have no idea how to insert transformation result into HTML page so it gets styled in mozilla too. There are lots of issues, such as namespace declararation isn't showed etc, come on, that's not online XPath tutorial, but just simple demo.
Talking about difference between XSE and ForwardXPathNavigator, Daniel writes:
Back to the issue, there's a fundamental difference in the approach between his class and my XSE API: his will consume the stream with a single query. Mine supports multiple handlers matching multiple elements at the same time. And it's still a pull-based API, where you have to iterate results, instead of being called when something you care happened (was matched).Well, ForwardXPathNavigator wasn't designed to be compared with XSE! It's simple poor man's (XmlReader) XPathNavigator. But as XPathNavigator it allows not only evaluate XPath queries, but to navigate node by node over XML too. I was planning to build XSE-like system based on ForwardXPathNavigator. Actually I must admit I didn't go far from proving the concept and don't have code to publish yet (in the face of brilliant XSE impl :). The idea behind XmlUpdater/XPathFilter was the following: just navigate over XML using ForwardXPathNavigator and check each node if it matches any registered XPath patterns. On each matched node call associated with the pattern callback method, providing it with enough context to to what it want - to skip node (transparency), to modify it etc.
I found pattern matching cheap enough operation and the whole prototype quite satisfying. What I dislike is too fragile nature of ForwardXPathNavigator. It's forward-only, so XPath patterns and the whole application must be too-carefully defined with forward-only concept in mind, what's not usual concept when working with XPath, right? Funny thing - ForwardXPathNavigator may move irrevocably when you just inspecting its properties in the debugger! Count property of XPathNodeIterator becomes obviously unusabe too. To put it another way - it's to hard to work with this stuff. And benefits are not so striking by the way. May be that's my bad design, dunno...
Oh, come on, Daniel. May be I was overdramatizing.
Yeah, point taken.
I didn't intend to take an in-depth comparison (and who's the winner) approach. I'm sorry if it sounded like that. Just to analyze different approaches to the issue...
Exactly because of the subtle issues with forward-only XPath, I explicitly don't claim to implement any of it in my XSE. It's an inevitable thing that users of such a subset of XPath (and the corresponding issues with an XPathNavigator-based implementation, as you mention) will get confused by resulting "strange" (with respect to regular navigators) behavior, and decide to stick to full-document loading and XPath querying.
By providing an explicit expression language (and its corresponding factory), the user is very aware of what he can do. I believe XSE should offer an extensible framework for expression language development and pluggability (similar to XPath impl. in .NET, but more streaming-aware and codegen-related), so that creating your own FSM for your expressions is straightforward enough.
For example, it would be great if it was easy enough to create factories that I decided to create an AtomProcessingFactory, an RssProcessingFactory, CustomerProcessingFactory (well, you get the idea)...