RE: label header (was: Re: Versioning TeleConf Agenda, 4/6/01 (Fr iday) 12-1pm EST)

   From: Greg Stein [mailto:gstein@lyra.org]

   On Sun, Apr 08, 2001 at 12:04:06AM -0400, Clemm, Geoff wrote:
   >...
   >    - defer label header, but keep LABEL method
   > 
   > Example of reason why you don't want human meaningful strings in
   > a header: The Label value needs to be matched against values
   > stored on the server.  For some languages, the encoding is not
   > enough to decide whether or not there is a match ... you need
   > something like a language attribute.  With labels in XML, that's
   > no problem ... you add the language information as an optional
   > element or attribute.  With a header, there is no good way to
   > provide this info.
   > 
   > Consensus of con-call: Label header can be removed.

   I was talking about this with somebody yesterday. I don't see the
   argument at all. Please give an example where a Label needs a
   language to resolve properly.

   As I see it, we compare the (character) encoded string against
   those on the server. "le" and "le" are exactly the same whether the
   language is French or English.

If a user wants the "tested" version, and so types in "tested" to his
client, but goes against a server which has some Swahili labels, where
the string "tested" happens to mean "just broke all the nightly builds",
then the user won't get what they wanted (possibly what they deserved,
but not what they wanted :-).

   By suggesting that there is some language component in there, you
   are then stating that the comparison function on the server must
   account for language. That just doesn't seem right. The logical
   mechanism is to convert the Label: header value into Unicode and
   compare that to all the labels stored on the server (which are also
   stored as Unicode).

That would be algorithmically simpler, but wouldn't get the user what
they wanted (although some software vendors have a tradition of 
telling the user that they *really* want what is algorithmically
simpler :-).

   Unless/until somebody can come up with an example of a string that
   is encoded the same, but interpreted differently based on language,
   *and* argue the expectation that the server should treat that
   string/language pair differently... then I might agree to dropping
   the Label header.

I believe the major point of labels is that they provide a human with
a way of meaningfully naming something, and not just to be some
string.  You already have the version-name if you just want some
string that identifies a version.

   But until then, let's keep the Label header. Tossing it means we
   must replace our PROPFINDs with some silly new report and an extra
   round trip.  Where is the benefit!?!

I'm not sure that the "label" report is any sillier than any other
report (:-), and I don't think an extra round trip will materially
affect us here.  The label is primarily for individual resources.  If
you are manipulating sets of resources, you have the baseline and
workspace features.

   Finally... even if you can show a similarly-encoded string which
   needs to also account for the language, then the Label header can
   simply look like:

     Label: my-label; language="en-us"

   If we want to be anal about it:

     Label: my-label; language="en-us"; charset="iso-8859-1"

   But the whole language thing seems like a red herring.

Replicating XML attribute information in a header does not seem
like the right thing to do here, especially if it just is to save an
occasional round trip.  But I believe we need that information
to do correct label matching.

Cheers,
Geoff

Received on Tuesday, 10 April 2001 12:43:36 UTC