Fwd: Re: Feedback on comparator draft

 >Cc: Martin Duerst <duerst@w3.org>
 >From: Lisa Dusseault <lisa@osafoundation.org>
 >Subject: Re: Feedback on comparator draft
 >Date: Mon, 6 Dec 2004 17:46:55 -0800
 >To: Chris Newman <Chris.Newman@Sun.COM>

 >On Dec 6, 2004, at 5:30 PM, Chris Newman wrote:
 >
 >> Lisa Dusseault wrote on 12/6/04 17:11 -0800:
 >>> 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?
 >>
 >> For disconnected operation, the client needs to be able to replicate the exact
 >> same ordering that the server uses in order to provide a consistent UI. 
With a
 >> wildcard, the orderings could be different (if, for example, the client had a
 >> newer collation than the server in addition to the server-compatible one) and
 >> that would not be detected and confuse the user.
 >
 >So this SHOULD NOT requirement only matters if the client intends to use 
the same ordering while offline...  The choice of an ordering (and 
therefore a collation) may simply be so that the synchronization operation 
happens in a predictable order.  You're making an assumption that the 
client will display in a certain order.
 >
 >This is totally minor however -- I suspect clients will learn to do the 
right thing here in any case, and I can't see wildcards being wildly useful.
 >
 >>
 >>> 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.
 >>
 >> A collation can be designed for a specific language (en;ascii-casemap is one
 >> such example).  And the basic comparator can be "tailored" or "customized" for
 >> a specific language (creating a new comparator).  Both cases are mentioned in
 >> the draft, I believe.
 >>
 >>> 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.
 >>
 >> Your observation about the English and Spanish dictionaries is by itself
 >> sufficient justification for a registry.  There is no one-size-fits-all
 >> collation and we know it by observation.
 >>
 >
 >Ok, there was a basic model assumption or model choice that I missed in 
my read-through: that the client would use its knowledge of locale and 
language (and maybe other stuff too)  in order to select an appropriate 
collation for the user.
 >
 >My assumption had been that the client would select a collation and 
orthogonally, tell the server what language to apply the collation in.
 >I believe that's wrong but that was what I initially thought the model would be.
 >
 >If you care to make the model/assumption clear in the draft, I think that 
would be a useful addition (unless you think that's already covered and I 
overlooked it)
 >
 >Lisa
 >

Received on Wednesday, 18 May 2005 08:09:41 UTC