29406 2016-01-30 02:19:21 +0000 [FO31] no error conditions for invalid URI for fn:collation-key 2016-03-22 09:36:30 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 3.1 Candidate Recommendation PC Windows NT CLOSED FIXED P2 normal --- 1 abel.braaksma mike andrew_coleman public-qt-comments oldest_to_newest 124749 0 abel.braaksma 2016-01-30 02:19:21 +0000 The text of fn:collation-key suggests that the input of the second argument must be some kind of URI, but the hint toward this is vague: "If the collation URI is a relative reference, it is resolved against the static base URI." There is nothing in the text that suggests that it should otherwise be an absolute URI, that it should be in the value space of xs:anyURI or what happens when the $collation argument is not a URI at all. Perhaps it is meant to allow any string value without error, but then the sentence on the URI should perhaps be removed or refactored. I also wonder whether an error should be raised in case the collation is unknown. Currently, FOCH0004 might be thrown in that case, implying that if a collation is now known, it cannot possibly create a key from it, but that seems convoluted. 124757 1 mike 2016-01-30 09:28:44 +0000 The handling of collation URIs in fn:collation-key() is no different from any other function with a collation argument. It should have a reference to section 5.3.5 to make this clear. The validation of collation URIs (as URIs) is based closely on that for namespace URIs. Implementations can decide what set of collation names they will recognize, and they can confiine this set to string that are valid URIs if they wish, but they are not constrained to do so. 124834 2 andrew_coleman 2016-02-04 14:31:14 +0000 At the teleconference on 2016-02-02, the WG agreed to resolve this by added the cross-reference to section 5.3.5 as described in comment #1. 125582 3 mike 2016-03-22 09:36:30 +0000 The changes have been applied.