This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
F&O 3.0 changes the resolution of relative $collation URis from resolving against the static base URI to resolving against the dynamic base URI. Since collations and collation URIs are part of the static context, it seems (to me at least) better to retain the previous behaviour. Note that default collation declarations continue to resolve against the static base URI. Here's a contrived example which illustrates the issue. (: assume the dyanmic base URI is not http://example.org :) declare base-uri "http://example.org"; declare default collation "/languages/Icelandic"; declare variable $s as xs:string external; compare("a", $s) eq compare("a", $s, "/languages/Icelandic)
I think the only justifiable use case for relative collation URIs is where the URI actually identifies some resource, perhaps a piece of code that implements the collation or a data resource used to control or parameterize the collation. Since in general (with some exceptions like XQuery "order by") the collation URI is supplied dynamically rather than statically, this resource will be fetched and interpreted at evaluation time rather than at compile time. Since (in the scenario where queries are distributed in compiled form) the static base URI may well be a location that isn't accessible at evaluation time, I think it can only make sense to fetch the collation resource from somewhere relative to the deployment location of the query, that is, the "dynamic base URI". I agree that this fits oddly with collations being part of the static rather than the dynamic context. I've always been unclear why this should be the case: since collation names are in most cases supplied dynamically, what does it mean for us to insist that all collations are known statically? Perhaps this thinking is unduly influenced by the single case where dynamic collation URIs are not allowed, namely XQuery "order by" (the equivalent in XSLT, xsl:sort, does allow a dynamic collation).
I've thought of the URIs as being just an identifier scheme, as opposed to a means of locating some resource which needs to be fetched. In this sense, the implementation uses the identifier to determine which of some set of collations supported by the implementation's runtime to use. Thus it makes sense for collations to be part of the static tcontext. As the specification stands, whether a collation is specified statically or dynamically, it still has to identify one of the statically known collations. However, your viewpoint is more flexible in that collations can be selected outside of those statically known to the implementation. Locating the implementation of a collation at runtime does lead to the possibility of that implementation changing its behaviour. For example, it might change (or disappear) between compile time and runtime. Thus compile-time evaluation of any exprssions involving collations might lead to incorrect results. I'd expect there to be some use in the wild of relative collation URIs in combination with a static base URI declaration just to save typing out some long and forgettable URIs!
The Working Group resolved this as follows: Whether relative collation URIs are resolved resolved against the static base URI or the dynamic base URI is implementation defined.
Just a pedantic editorial note: technically we should not refer to "relative URIs" but to relative URI references". A relative reference is not a kind of URI.
Thanks.
We no longer distinguish static vs. dynamic base URIs. See Bug 17595.