2634 2006-01-03 18:06:23 +0000 [XPath] Comparing QNames 2006-02-15 21:50:51 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XPath 2.0 Candidate Recommendation PC Windows XP CLOSED FIXED P2 normal --- 1 mike chamberl public-qt-comments oldest_to_newest 7586 0 mike 2006-01-03 18:06:23 +0000 There are many places in the language where we compare QNames. We have two different ways of comparing QNames: by codepoint-comparison, and using the default collation. We either need to converge on a single way of comparing QNames, or we need to be very explicit which method is used on every occasion that the need for comparison arises. Where a QName is used as a NameTest in a path expression, we are explicit that codepoint comparison is used. Where the eq operator is used to compare two values of type xs:QName, we are explicit that the default collation is used. In many other cases we are imprecise. Here are some examples from XPath; there are many more examples of similarly fuzzy language in XSLT and XQuery: XPath 3.1.2: "Two variable references are equivalent if their local names are the same..." XPath 3.1.5: "If the expanded QName and number of arguments in a function call do not match the name and arity of a function signature..." XPath 2.5.4: "As usual, two expanded QNames are equal if their local parts are the same and their namespace URI's are the same. " (!) XPath 2.5.4.4: "the name of the candidate node is customer " XPath 2.5.4.5: "attribute(AttributeName) matches any attribute node whose name is AttributeName," It's my belief that in all the above cases, the intent is actually to use codepoint comparison on both the URI and the local-name. So the real question that arises is, why do we have an "eq" operator on QNames that does something different? What purpose does it serve? If we defined "eq" to use codepoint comparison, then all the comparisons we perform in the language could be specified to use the semantics of "eq"; and moreover, people doing queries on stylesheets or schemas that make extensive use of QNames-in-content would get the right answer. Michael Kay 7588 1 mrys 2006-01-03 19:11:21 +0000 For all the path comparisons and node name tests it certainly should be codepoint based (otherwise we will get a completely different, harder to understand language). For xs:QName, I would prefer also that we do not fall back to the default collation but do code point. Where does it say that we use default collation? 7590 2 mike 2006-01-03 20:17:39 +0000 >Where does it say that we use default collation? http://www.w3.org/TR/xpath-functions/#func-QName-equal It surprised me! Michael Kay 7591 3 mrys 2006-01-03 20:20:23 +0000 It actually says: Summary: Returns true if the namespace URIs of $arg1 and $arg2 are equal and the local names of $arg1 and $arg2 are identical based on the default collation. Otherwise, returns false. Two namespace URIs are considered equal if they are either both absent or both present and identical based on the Unicode code point collation (http://www.w3.org/2005/xpath- functions/collation/codepoint). The prefix parts of $arg1 and $arg2, if any, are ignored. Which mixes UCC and default collation.... IMO, it should just be UCC... 7592 4 mike 2006-01-03 21:03:07 +0000 Delving a bit further, this has changed since the October 2004 draft http://www.w3.org/TR/2004/WD-xpath-functions-20041029/#func-QName-equal In the minutes from Brisbane (Jan 2005) http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2005Jan/0112 we see: RESOLUTION: "[IR] IBM-FO-112: comparisons of URIs" is closed. op:QName-equal will be based on codepoint comparison. This was done in the previous version of the document and needs to be rolled back. This comment is at http://lists.w3.org/Archives/Member/w3c-xsl-query/2004Dec/0013.html It proposes changing the URI comparison to use the default collation, but says nothing about the local name comparison. It seems to me entirely possible that the change happened as a result of some confusion over the URI/string comparison issue (witness the decision first to accept IBM-FO-112 and then to roll it back), and that there was no conscious decision after October 2004 to change the comparison semantics for the local part of the QName. Certainly I recall no such discussion. Unfortunately, unlike many of our documents, the Feb 2005 working draft of F+O does not include a change log. Michael Kay 8273 5 chamberl 2006-02-15 21:50:38 +0000 Mike, The Query and XSLT working groups considered your comment at their joint meeting on 01 Feb 2006, and decided that all comparisons of QNames should be performed using code-point comparisons on both the local name and the namespace URI. The description of op:QName-equal in Functions and Operators will be edited accordingly, and clarifying text will be added to the XPath and XQuery specifications as needed. Thanks for calling this issue to the attention of the working groups. Since you were present during the discussion, I will mark this issue as Closed. --Don Chamberlin (for the joint working groups)