XPath vs pseudo-XPath
Note: this entry has moved.
Oleg commented on my XSE (Xml Streaming Events) implementation. He has a nice code snipped with something called an XmlUpdater. Really cool. I'd like to see that code!
He has a couple of observations about my wildcard syntax.
Clarifying them:
":*" = any element with an empty namespace.
"*.*" = any element in any namespace.
Those are
different things ;).
All available wildcards are explained in
the previous post, towards the end.
Strictly speaking, his forwardonly navigator is not XPath
either, just like my two initial XSE factories. XPath is a
very concrete concept and specification. If I'm not going to
support it, well, I don't need to care about its syntax,
providing I give users something easy to understand. I
believe the wildcards are FAR more easier to grasp than the
local-name and namespace-uri XPath
counterparts.
The RootedPath and
RelativePath are just factories for concrete
compiled algorithms that are different in implementation
(codegen). Note there's no X in the middle, so it's no XPath
at all ;).
Of course, calling something akin to folder browsing
anything else than "path" would be unnatural, that's why I
chose it.
My idea was to implement compiled algorithms that (IMO) will
always be more performant than generic ones. In the code
download I even provide an
InterpretedPath factory that does just this.
Doesn't compile anything and evaluates dynamically. There's
a price to pay, just like I guessed.
Bottom lines:
- Naming XPath things that are not, confuses developers.
- Seeking XPath support where it's overkill is not wise, IMO.
- XPath will NEVER be available in streaming APIs.
- Having path-like expression syntax for streaming XML handling can hardly be called "reinventing the wheel". You have to choose the solution that best applies to your problem. Call it whatever you like ;).
Update: read these follow-up: