- From: Martin Duerst <duerst@it.aoyama.ac.jp>
- Date: Wed, 18 May 2005 15:56:04 +0900
- To: public-ietf-collation@w3.org
[With recently obtained permission, I'm forwarding a few mails from a private discussion a while ago.] >To: Chris Newman <chris.newman@sun.com>,Martin Duerst <duerst@w3.org> >From: Lisa Dusseault <lisa@osafoundation.org> >Subject: Feedback on comparator draft >Date: Mon, 6 Dec 2004 17:11:18 -0800 >Hi Chris, Martin, > >At last IETF I promised to review the comparator draft. I've now read it and have three comments or questions, although be warned that I'm not the best reviewer (I find many more issues when I start using something, than when I just read it through) > >Section 3.2: I don't understand the requirement for clients supporting disconnected operation SHOULD NOT use wildcards. I can imagine a client synchronizing data with a WebDAV server -- the client would like to download the contents of a collection in a certain order and cache the results locally (potentially for offline use). Why shouldn't this client use wildcard matching while selecting the collation? > >Overall, I'm surprised not to see some discussion about providing the language to be used during collation. A list of words is sorted differently in a Spanish dictionary than an English dictionary. Did I miss something? has this already been discussed? They can even be obsolete usages of collations since these examples would be firmly non-normative. > >I generally prefer more examples in specifications but I can see how hard this would be for this spec. Unless it's possible to briefly illustrate the use of collations by drawing an example from sieve and/or ACAP... > >As an approach to the problem I worry that it might be overkill but I have a lot of confidence that you two would know that better than I do. E.g. if it were possible to have only one recommended collation then we wouldn't need a registry or a way to negotiate collations, but I'm sure that approach was tried first. > >Lisa >
Received on Wednesday, 18 May 2005 08:10:33 UTC