- From: Clemm, Geoff <gclemm@rational.com>
- Date: Tue, 17 Apr 2001 00:07:20 -0400
- To: ietf-dav-versioning@w3.org
I believe it is fair to say that based on activity in the mailing list, there appears to be strong support for the Label header within the working group. As for the issues raised concerning the Label header: - 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. - 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 :-). This is no more likely to happen than for some other client to use the word "gross" in English to mean something other than what the second client had in mind. In fact, it is probably much *more* likely for the two different English uses of a string to collide, than it is for an English use to collide with a German use. Clients that really care about his issue will just use baselines instead of labels, since a baseline selection of a version can never "collide" with another baseline (which is why I think we should just get rid of the label feature altogether, but that's just me :-). So if we accept all that, the only thing left to do is to decide which packages (if any) will contain the label header. After staring at our current packages (core, basic/advanced client workspaces, and basic/advanced servers workspaces), I believe it makes sense to bundle labels into the "client workspace" packages. My reasoning is as follows: I believe most client-workspace servers do in fact support labels, and Greg (who is known to be producing an advanced-client-workspace server) was one of the vocal supporters of labels. This makes sense, because although a server-workspace server can just allocate a "workspace" when it wants to expose a set of related versions, a basic client workspace server cannot, and labels give it a simple way to do so. So, I propose that we define the label feature as being part of the basic-client-workspace package. Any objections? This means that the proposed resolution of the issues raised since draft 14 are: The Variant-Control Feature: Defer it to another spec. focused on variants. The Fork-Control Feature: Merge it into the checkout feature. 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). 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). 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. 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). Does anyone disagree/object to the resolutions described here? If not, I'll write this up as draft-15, and submit it to the IETF so that JimA can officially submit it to Ned for the next step of the process. Cheers, Geoff
Received on Tuesday, 17 April 2001 00:07:55 UTC