This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29406 - [FO31] no error conditions for invalid URI for fn:collation-key
Summary: [FO31] no error conditions for invalid URI for fn:collation-key
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2016-01-30 02:19 UTC by Abel Braaksma
Modified: 2016-03-22 09:36 UTC (History)
1 user (show)

See Also:


Description Abel Braaksma 2016-01-30 02:19:21 UTC
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.
Comment 1 Michael Kay 2016-01-30 09:28:44 UTC
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.
Comment 2 Andrew Coleman 2016-02-04 14:31:14 UTC
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.
Comment 3 Michael Kay 2016-03-22 09:36:30 UTC
The changes have been applied.