W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2001

Baselines and Bindings

From: Alison Macmillan <alison.macmillan@oracle.com>
Date: Wed, 10 Oct 2001 19:39:03 +0100
Message-ID: <3BC495C7.DC21AA5@oracle.com>
To: ietf-dav-versioning@w3.org
The protocol seems to allow a workspace to contain multiple bindings
(names) for a single version-controlled resource.  We're trying to
understand how multiple bindings coexist with workspaces and baselines,
for our implementation.

The multiple bindings are introduced in the MERGE and UPDATE semantic
additions of the VERSION-CONTROLLED-COLLECTION feature. The
DAV:update-version-controlled-collection-members postcondition includes
the following condition on new version-controlled member creation:


>          If a new version-controlled member is in a workspace that already
>          has a version-controlled resource for that version history, then
>          the new version-controlled member MUST be just a binding (i.e.
>          another name for) that existing version-controlled resource.
>

And an earlier thread talked about UPDATE of a Version Controlled
Configuration:


>      Is This A Bug?
>
>      - Baseline feature: Is it possible to construct a workspace which
>        contains multiple VCR's with different DAV:checked-in versions
>        for a given VHR by doing a MOVE of a VCR from one
>        baseline-controlled collection to another, and then UPDATING the
>        VCC's for those BCC's?
>
>   I think the intent of the spec is clear (only one VCC for a given
>   version history in a given workspace), but I agree that
>   we are missing a postcondition on the MOVE operation.  A
>   workspace is required to have only one VCR for a given version
>   history, so any operation that would violate that constraint (which a
>   MOVE could) should fail.  Similarly, we should clarify in the extended
>   UPDATE semantics, so that it is clear that the UPDATE of a VCC causes
>   an existing VCR to be bound into a collection, if there already is a
>   VCR for a given version history in the workspace.
>

I interpreted the last sentence of the reply to mean that the
DAV:set-baseline-controlled-collection-members postcondition added by
BASELINE to UPDATE (and
MERGE), should include a statement similar to that in
DAV:update-version-controlled-collection-members,  requiring the
creation of a binding to an existing
VCR in the workspace.  Is this the right interpretation?

Is it also right to imply that the DAV:checked-in version of the VCR
(assuming that it is checked-in) remains as it was preceding the MERGE /
UPDATE, in particular the DAV:checked-in version does _not_ necessarily
match the version held in the baseline?

Should there be a similar extension to the DAV:select-existing-baseline
postcondition? This would cover the case of initializing a collection
from an existing baseline, where the collection is a member of a
workspace, and both the workspace and baseline contain VCRs for the same
version history.

Also, how should BASELINE-CONTROL behave on a workspace containing such
duplicate bindings? For example, suppose a workspace contains
/ws/cmp1/src/foo.html and /ws/cmp2/src/bar.html, and that
/ws/cmp2/src/bar.html is a binding (another name for) the resource,
/ws/cmp1/src/foo.html.  If you  first
BASELINE-CONTROL /ws/cmp1, and then BASELINE-CONTROL /ws/cmp2, should
the second BASELINE-CONTROL operation  omit the VCR identified by
/ws/cmp2/src/bar.html (because it is already a member of a configuration
created by baseline-controlling  /ws/cmp1)? If it is omitted, then it
seems like the baseline of cmp2 has lost some important information
about the structure of component 2 (cmp2). If it is not omitted, then it
seems to conflict with the description of configuration membership.

Thanks,
Alison.
--
 -------------------------------------------------------------
 The statements and opinions expressed here are my own
 and do not necessarily represent those of Oracle Corporation.
 -------------------------------------------------------------
Received on Wednesday, 10 October 2001 15:36:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:42 GMT