I think the binding of URIs to actual collations is something that's best left
to configuration parameters, APIs, and the like - in other words, it's outside
the scope of the language.

One thing we might consider, though, is to encourage implementors to provide 
configuration mechanisms that allow users to choose their own URIs to refer to
collations, rather than only providing a fixed set of vendor-supplied URIs. If
implementors do this, it will greatly improve interoperability.

Michael Kay (personal response)

(In reply to comment #1)
> I think the binding of URIs to actual collations is something that's best left
> to configuration parameters, APIs, and the like - in other words, it's outside
> the scope of the language.
> 
> One thing we might consider, though, is to encourage implementors to provide 
> configuration mechanisms that allow users to choose their own URIs to refer to
> collations, rather than only providing a fixed set of vendor-supplied URIs. If
> implementors do this, it will greatly improve interoperability.
> 
> Michael Kay (personal response)

Suppose a user who wants to make a linguistic analysis of texts, and variation
in collations - e.g. due to historic differences - is a crucial part of the
analysis. Of course this is an unusal case, but my point is that such a user
would not like to change the API or a parameter. The collation would be part of
the query / analysis.

What you seem to be asking for here is the ability to choose the collation
dynamically rather than statically. Is that correct? Currently, our
specifications allow collations to be selected dynamically in all situations
where they are used, with one exception - sorting in XQuery (collations can be
selected dynamically in XSLT sorting, but not in XQuery sorting).

But perhaps I've misunderstood the comment.

Michael Kay (personal response)

(In reply to comment #2)

First off, I *think* that this is all referring to the following comment, right?

   The current rules, which allow only one collation to be specified,
   raise an error if the collation is not supported, and use anyURIs
   to identify collations without any mechanism for giving anyURIs to
   well-known collations, are bound to lead to interoperability
   problems. Collations should not be the major source of
   interoperability problems. With the current design, even vendors
   who want to be interoperable have no chance of doing so. It will
   often be the case that e.g. a user wants just 'a French
   collation'. How can this be indicated?

> Suppose a user who wants to make a linguistic analysis of texts, and variation
> in collations - e.g. due to historic differences - is a crucial part of the
> analysis. Of course this is an unusal case, but my point is that such a user
> would not like to change the API or a parameter. The collation would be part of
> the query / analysis.

It's extremely unlikely, of course, that a standard collation for Greek would
take into account the historical variations in spelling over the last 7,000
years, and I can't figure out how the proposed solution fits your use case. I
think your user is better served by the ability to bind a collation URI to a
custom collation that takes itacization into account, a collation that may be
tailored to the specific kind of analysis intended.

You also say we should consider the case where "a user wants just 'a French
collation'. I would welcome a standard set of names for collations, if one
emerges, but this is way beyond the scope of the XML Query Working Group, and
might require years of effort, negotiating with representatives of the countries
involved. And it would also require significant domain expertise - which of the
potential French collations should be used for the person who wants just 'a
French collation'? We have the mechanism to refer to these collations by URI if
such a standard emerges.

(In reply to comment #3)
> What you seem to be asking for here is the ability to choose the collation
> dynamically rather than statically. Is that correct? Currently, our
> specifications allow collations to be selected dynamically in all situations
> where they are used, with one exception - sorting in XQuery (collations can be
> selected dynamically in XSLT sorting, but not in XQuery sorting).
> 
> But perhaps I've misunderstood the comment.
> 
> Michael Kay (personal response)

 
I don't aks for dynamically choosing the collation. I am asking for the same as
in the first version of the comment, just with a different example, i.e. the
ancient greek example. I don't ask a standard Greek collation to take into
account all ancient Greek characters, but to allow the user to differentiate two
kinds of things: (1) I want a specific collation which I know the URI of and
which does a very specific thing for me, i.e. sorting in an ancient Greek style.
(2) I just want some collation of Greek. I don't care about the details, give me
anything which is available for Greek.
Felix (as a reply to #2, #3, #4

This is clearly outside the scope of our work in my personal opinion. We are 
not defining the semantics of a specific collation URI. We provide the 
mechanism to refer to the collation URIs that a system provides. 

new version of the comment (consensus of i18n-core-wg, telecon 25 may 2005):

The i18n-core-wg accepts the issue to be closed, Nevertheless, we would like to
note that standard URIs for collations are a necessary thing.