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

I have to agree.  The wildcard solution depends too much on how collations
are named.  Seems ad hoc.

All the best, Ashok


-----Original Message-----
From: public-ietf-collation-request@w3.org
[mailto:public-ietf-collation-request@w3.org]On Behalf Of Michael Kay
Sent: Tuesday, October 19, 2004 3:23 AM
To: 'Martin Duerst'; 'Jim Melton'; public-ietf-collation@w3.org
Subject: RE: draft-newman-i18n-comparator: issue wildcards-07



You should either design a complete protocol that allows searching for
collations given partial knowledge of the name or other attributes of the
collation you are looking for (e.g. language and strength), or you should
leave the job to someone else.

Providing a wildcard search is neither one thing nor the other.

Michael Kay 


> -----Original Message-----
> From: Martin Duerst [mailto:duerst@w3.org] 
> Sent: 19 October 2004 08:05
> To: Michael Kay; 'Jim Melton'; public-ietf-collation@w3.org
> Subject: 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 12:55:01 UTC