This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Is the following expression permitted? xs:anyURI("http://a.com/") lt xs:anyURI("http://b.com/") The rules for ValueComparison say: "Next, if possible, the two operands are converted to their least common type by a combination of type promotion and subtype substitution. ... Finally, if the types of the operands are a valid combination for the given operator, the operator is applied to the operands." Type promotion has no effect because the least common type is xs:anyURI. There is no entry in the operator mapping table for appling the "lt" operator to two xs:anyURI values. So the above expression appears to be illegal. This is unfortunate. It blows a hole in transitivity, since it is legal to compare an xs:anyURI with a string. It means that max((Uri1, Uri2)) is an error, whereas max((Uri1, Uri2, "")) might or might not succeed depending on the sequence of evaluation. Proposed change: value comparisons should promote xs:anyURI arguments unconditionally to strings, regardless of the type of the other operand. Alternative (equivalent): add entries in the operator mapping table to do order comparison on xs:anyURI values. XSLT test case sort144 applies.
On reflection, it's probably best to fix this by adding entries to the operator mapping table. Otherwise we hit similar problems for min() and max(), which also invoke the "least common type" rule. Sorting in XSLT also refers to "the most specific type to which all the values can be converted by subtype substitution and/or type promotion". Sorting in XQuery says: "The ordering is performed in the least common type that has a gt operator." This formula works, one solution would be to use it elsewhere where the problem arises.
Note, in XQTS, the tests K-SeqMAXFunc-35, K-SeqMAXFunc-36, K-SeqMINFunc-35, and K-SeqMINFunc-36 assume that min() and max() cannot be applied to a sequence consisting solely of xs:anyURI values. (If this is the case, then we have to keep reading to the end of the sequence, and the function becomes legal if an xs:string is encountered, because the xs:anyURI values then get promoted.)
With reference to XSLT test sort144, see also http://www.w3.org/Member/bugzilla/show_bug.cgi?id=522 (member only)
I think it's actually K-SeqMINFunc-39 and -40 (and MAX respecively), at least in the current CVS version of the test suite. I support the proposed fix. The easy solution to all this xs:anyURI stuff would probably have been to regard xs:anyURI as a subtype of xs:string for all operations in XQuery...
For your information, the latest XQTS_current.zip carries additions and corrections to align with the resolution of this report(XML Query/XSL WG Joint Teleconference 304 Minutes 2006-08-01). Frans
I was actioned to propose detailed textual changes to resolve this (action A-304-01, aka A-304-1). 1. [XPath/XQuery] In 3.5.1 Value Comparisons, change this paragraph: Next, if possible, the two operands are converted to their least common type by a combination of type promotion and subtype substitution. For example, if the operands are of type hatsize (derived from xs:integer) and shoesize (derived from xs:float), their least common type is xs:float. to read: Next, if there is no entry in the operator mapping table for the types of the two operands, then the operands are converted (if possible) to the least common type for which there is such an entry. For example, (a) if the operands are of type hatsize (derived from xs:integer) and shoesize (derived from xs:float), their least common type is xs:float; (b) if the operands are both of type xs:anyURI, the least common type that has a suitable entry is xs:string. 2. [XQuery] "order by" requires no change. The existing text is adequate: "The ordering is performed in the least common type that has a gt operator." 3. [XSLT] (sorting) requires no change. The existing text is adequate: "To ensure a total ordering, the same implementation of the lt operator must be used for all the comparisons: the one that is chosen is the one appropriate to the most specific type to which all the values can be converted by subtype substitution and/or type promotion". 4. [F+O] min()/max(). I believe that we previously agreed a change in this area to talk about converting all the values to their least common type. I'm not sure of the exact wording. We need to change it to say "the least common type that has a gt operator". Michael Kay
See also bug #3670
Michael, On Sept. 19, 2006, the Query and XSLT working groups decided to resolve this issue by adding four new entries to the Operator Mapping Table, implementing the gt, ge, lt, and le operators for the type xs:anyURI. The mapping for each operator will be the same as the mapping for the equivalent operator on xs:string. The working groups do not believe that any further textual changes are necessary. Since you were present at the discussion, I am marking this bug report as fixed and closed. Regards, Don Chamberlin (for the Query and XSLT working groups)