RE: The Label header, and other issues raised since draft-14

> - Internationalizable display of labels:
>
> This actually has little to do with the label header, since you don't
> use the label header to create labels, but rather use the body of the
> LABEL method.  In the body of LABEL method, you can annotate the label
> with as many internationalization attributes as it wishes, and you
> query for labels with PROPFIND, which will give you all those
> attributes back.

Ah, this makes sense to me now. I agree that, since can set and retrieve the
label information via properties, it is OK to state that the label *header*
is in one (and only one) fixed encoding, and doesn't need a language or
encoding tag.  All you need to do is compare Unicode string values for exact
equality. The ability to set and retrieve this with full encoding and
language tagging information via the property mechanism makes all the
difference.

Now that I get it, sorry for all the fuss I raised. :-(


>
> - Label matching
>
> Here is the area where the Label header does come into play, because
> it is the way several methods will pass in the label to be "matched".
> My impression is that most of the members of the working group that
> care about labels find a simple byte string matching of the label to
> be sufficient for their needs.  It is OK for an Englishman to label a
> version "gross", and then have this version be selected by a German
> that asks for the "large" version (i.e.  "gross" in German, put please
> don't get too concerned about the details of this example :-).

I agree.


> The Variant-Control Feature:
>    Defer it to another spec. focused on variants.

Agreed.


> The Fork-Control Feature:
>    Merge it into the checkout feature.

Agreed.

> The Update Feature:
>    Keep it, and make it part of the basic-client-workspace package
>    (needed so that a new version created by checking in a working
>    resource can be made the "checked-in" version of its version
>    controlled resource).

*sigh* OK.

> The Label Feature:
>    Keep it as is (i.e. with the Label header), and make it part of the
>    basic-client-workspace package (so that a client can define a
>    lightweight configuration of versions on the server).

OK.

>
> The "checked-out version-controlled configuration" issue:
>    Add a "checkout-on-update-and-keep-checked-out" variant to the
>    auto-versioning mechanism.  Also, simplify DAV:auto-version
>    by replacing it with DAV:auto-checkout and DAV:auto-checkin.

OK.

> Packages:
>    Define 5 packages: core-versioning, basic/advanced-client-workspace,
>    and basic/advanced-server-workspace.
>
> In other words, the mailing list accepted 3 of the proposals from
> the Minneapolis meeting, rejected 2 of the proposals from the
> Minneapolis meeting, and accept the latest variant of the one
> issue that originated on the mailing list (auto-checkout of a VCC).

Guess we have to sharpen that knife some more.

- Jim

Received on Tuesday, 17 April 2001 18:09:37 UTC