draft-newman-i18n-comparator: issue wildcards-07

I have assigned this issue wildcards-07
(http://www.w3.org/2004/08/ietf-collation#wildcards-07).

At 17:29 04/08/25, Michael Kay wrote:
 >
 >Comments on Jim's comments:
 >>
 >> On 2004-08-24, Mike Kay said the following, on which I would like to
 >> comment; my comments are preceded by "Jim:":

 >> (b) Because the protocol is out of scope, discussions of how
 >> to search for a
 >> collation using wildcards are also out of scope.
 >>
 >> Jim: I don't understand this point.
 >
 >I'm basically trying to map the idea to the way XPath/XQuery use collations.
 >I find it hard to see us supporting a collation value of
 >"http://www.*.com/french" - it's just not the way URIs work.

Mostly agreed (except if e.g. various companies would assign
http://www.company.com/french, to their French collations, but
we don't want to go there) but that wouldn't mean that wild cards
are useless, they are still useful in parts of the URI that may
contain key/value pairs,...

 >One might
 >instead want to have a much more sophisticated mechanism in which collations
 >have properties and one can search for them by their properties. My basic
 >point was that I think the query language used to access a repository of
 >collations is out of scope for this spec.

Well, I think the wildcard construct recognizes that there is a general
need for something like a fallback. I remember that the W3C I18N WG
commented on XQuery at one point to say that just allowing a single
collation for a certain operation, and making it an error if that
collation wasn't available, would make interoperability really difficult.
With wildcards, that would be less of a problem. Being able to negotiate
collations (a protocol such as IMAP could do that), or having a list
of fallbacks (in the case of XQuery) would be one solution, wildcards
are another.

Also, if all 'customers' of this draft except for XQuery want
wildcards, then it's probably better to include them (as an option)
in this draft.


Regards,     Martin.

Received on Tuesday, 19 October 2004 08:43:44 UTC