- From: XQuery <xquery@attbi.com>
- Date: Sun, 2 Feb 2003 19:22:30 -0800
- To: <public-qt-comments@w3.org>
These comments pertain to http://www.w3.org/TR/2002/WD-xquery-20021115/ ---- 3.2.1.1 (Axes) contains this peculiar remark: "In XQuery, the parent axis is a reverse axis; all other axes are forward axes. Since the self axis always contains at most one node, it makes no difference whether it is a forward or reverse axis." However, the parent axis also always contains at most one node... There are some other parts here that appear to have just been copy-pasted out of the XPath draft, and should probably be rewritten for XQuery. For example, the distinction of principal node kind is unnecessary for XQuery, since there is only one exceptional axis (the attribute axis). ---- B.2 (Operator mapping) The table contains some errors. For example the entries for A eq B and A ne B when A/B are xs:string should compare against 0 not 1. (fn:compare() returns 0 if they are equal). I also suspect there are some other design mistakes here. For example, the definition of the id() function makes it clear that ID/IDREF values are matched without respect to the default collation (which is good, since these indices are typically created when the data model is loaded, without respect to any query collations). However, the rules for comparing xs:ID or xs:IDREF values using any of the value comparison operators fall back on the xs:string comparison rules, which depend on the default collation. Similarly, xs:anyURI and xs:NOTATION are compared with eq/ne using code points, but with gt/ge/lt/le using collations (because then they fall back on xs:string comparisons). Inconsistencies like these will drive users crazy.
Received on Sunday, 2 February 2003 22:23:07 UTC