- From: <bugzilla@jessica.w3.org>
- Date: Sat, 31 Mar 2012 11:39:25 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16565 --- Comment #1 from Michael Kay <mike@saxonica.com> 2012-03-31 11:39:24 UTC --- 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). -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Saturday, 31 March 2012 11:39:27 UTC