[Monetdb-developers] MonetDB support of ordered XPath, mistake regarding reverse doc order
Hi,
I'm interested in ordered XPath. How much support of ordered XPath that monetDB has?
In MonetDB, I found that the following XPath:
/a/b/c/preceding-sibling::*[1] /a/b/c/preceding-sibling::d[1]
return the first node according to document order, not according to reverse document order (http://www.w3.org/TR/xpath20/ section 3.2.1.1 and 3.2.2)
I tried using bib.xml from XQuery Use Cases (http://www.w3.org/TR/xquery-use-cases/#xmp-data) and compare the result with commercial XML editor.
/bib/book/price/preceding-sibling::*[1] - MonetDB returns <title> - supposedly returns <publisher>
/bib/book/price/preceding-sibling::author[1] - MonetDB returns Stevens W, Stevens W, and Abiteboul Serge (the first author in document order, similar to /bib/book/author[1]) - supposedly returns Stevens W, Stevens W, and Suciu Dan
Regards,
Klarinda
On Mon, Aug 21, 2006 at 10:19:57AM +0800, kla gw wrote:
I'm interested in ordered XPath. How much support of ordered XPath that monetDB has?
In MonetDB, I found that the following XPath:
/a/b/c/preceding-sibling::*[1] /a/b/c/preceding-sibling::d[1]
return the first node according to document order, not according to reverse document order (http://www.w3.org/TR/xpath20/ section 3.2.1.1 and 3.2.2)
I tried using bib.xml from XQuery Use Cases (http://www.w3.org/TR/xquery-use-cases/#xmp-data) and compare the result with commercial XML editor.
Hi Klarinda,
you are right. MonetDB/XQuery does not fully comply with the W3C specs here. Instead, we do not distinguish between forward and reverse axes, but always interpret positional predicates in document order.
This is mainly for historic reasons. Earlier W3C specifications have been quite unclear about the semantics of positional predicates and reverse axes and parts of our code date back to that time. Unfortunately, the design of our code makes it non-trivial to fix this problem, and I guess we (you) will have to live with it for now.
Nevertheless, I will particularly look into this issue and see if I can still find a solution.
On the other hand, this is the only situation that comes to my mind, where we actually do violate XQuery's ordering requirements. In fact, our current development version not only correctly implements XQuery's order constraints, but will also exploit the fact that order does *not* matter in certain situations. The observable effect is a significant improvement in query performance under such circumstances.
Regards,
Jens
participants (2)
-
Jens Teubner -
kla gw