- From: Clemm, Geoff <gclemm@rational.com>
- Date: Tue, 10 Apr 2001 18:21:34 -0400
- To: ietf-dav-versioning@w3.org
From: Eric Sedlar [mailto:Eric.Sedlar@oracle.com]
Take the word 'schon' in German, which can also be spelled
'schoen'. There is a convention that specifies that umlauts can
be replaced by a following "e" and still be the same word. It is
not the case that binary comparisons can be done even for equality
for natural language strings.
However, your point is still valid--I thought the reasons to get
rid of the Label header were:
* make label just a property and remove an option, simplifying
the client testing problem
I don't think we proposed removing the LABEL method that updates
the value of the label property, did we? In particular, there
are several folks that object to having a non-protected property
that when updated has a side-effect on another non-protectected
property (i.e. the label properties on two different version
resources of the same version history).
Also, once we use the "package" approach, whether or not the
label is a separately identifiable feature doesn't matter as
long as it is bundled into a package with the other advanced
features.
But simplifying testing is certainly an issue, since there are
all the interactions of the Label header with various methods
that would have to be tested.
* shorten the spec
Yes.
* nobody at the working group cared that much about the header
It's true that none of the folks that care were at that meeting, but I
don't think we believed that nobody cared. Currently, it does look
like just a few people care (about the Label header, that is ...
several people care about the label feature).
* avoid the language pain in the a** with respect to internationalizing
the header
The language issue isn't sufficient by itself.
My preference was affected by all the issues you describe, but
it was the internationalization issues that tipped my vote for
removing the Label header.
Cheers,
Geoff
Received on Tuesday, 10 April 2001 18:20:34 UTC