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
http://www.saxonica.com/
