|
>XPath user
navigation for selecting data going down a path does require coding the data
types in the order they are retrieved.
Sorry, but that simply isn't true. You can (and products
do) implement a path expression such as A/B[@id='4']/C using a wide variety of
different access strategies. You do not have to "go down the path" from the root
to the leaves; you can start at the leaves and work up, or start in the middle
and work both ways. This expression is not a sequence of step-by-step
instructions, it is a request to find C elements that have a B parent
whose @id is 4 and whose parent is an A: it is a declarative specification of
the characteristics of the elements that you want to retrieve. Suggesting
this is procedural is like suggesting that regular expressions are procedural -
you've confused the specification and your first instinct at a
naive algorithm for implementing it.
Multi-leg queries (known as LCA queries) such as selecting data from one leg of a hierarchical structure based on data in another leg of the structure was used in the example at the end of the article. So there was an example demonstrating a multi-leg query.
Sorry, I only got to about page 6 before giving up. Page 6 has a "Conclusion", namely "Even XQuery designed from the ground up to process XML structures requires procedural navigation keeping its processing limited to linear processing for the most part." which I think is so fundamentally wrong (and it's not exactly a pleasure to read either) that I didn't feel it was worth reading on to the Appendix.
I believe that XPath 2.0 is relationally complete and that it can therefore perform any query that SQL can perform. In fact it can do more, because it can do some (not all) recursive queries, which are beyond the capability of SQL without extensions, and which are very important in processing many kinds of hierarchical data. For queries of this complexity, however, XQuery is a much more suitable candidate than XPath. I agree that XPath 1.0 was not able to perform arbitrary joins - but that's history. The main reason XQuery is more suitable is that it allows you to write functions, which are the equivalent of views in SQL (though again they are more powerful because they can be recursive, which is needed for hierarchical data).
I haven't attempted to code your example in XQuery because I don't think I have fully understood the query specification.That's partly because I haven't written any SQL for about 25 years and I find it very hard to remember its arcane syntax and semantics; also you seem to be using SQL extensions that I haven't come across before.
Michael Kay |