W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2002

RE: Clarification: extended baseline semantics of UPDATE

From: Clemm, Geoff <gclemm@rational.com>
Date: Wed, 20 Mar 2002 23:34:45 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B1063C34F5@SUS-MA1IT01>
To: "Ietf-Dav-Versioning@W3. Org" <ietf-dav-versioning@w3.org>
That isn't anything that we ever discussed, but I agree
that it would be a very reasonable extension.
If you could write this up, we could add it to 
the "proposed extensions" list.

Cheers,
Geoff 

-----Original Message-----
From: Roy Seto [mailto:Roy.Seto@oracle.com]
Sent: Wednesday, March 20, 2002 10:01 PM
To: Ietf-Dav-Versioning@W3. Org
Subject: RE: Clarification: extended baseline semantics of UPDATE


Suppose I have a workspace that includes several baseline-controlled
collections. My client can MERGE a new baseline into the appropriate
baseline-controlled-collection within that workspace by issuing a MERGE
request where the merge source is the baseline, and where the request-URL is
the workspace.

Similarly, I would like my client to be able to UPDATE a workspace with a
new baseline by sending an UPDATE request where the version is the baseline,
and where the request-URL is the workspace. Would this work if the
version-controlled configurations associated with the workspace's
baseline-controlled collections were not members of the workspace? 

I'm trying to avoid the extra roundtrip and client complexity to retrieve
the DAV:version-controlled-configurations of the
DAV:baseline-controlled-collection-set of the workspace in this case, and
figuring out which of those DAV:version-controlled-configuration's
DAV:version-history property values is the same as the DAV:version-history
for the baseline I want to UPDATE my workspace with.

So I'd like an UPDATE whose version is a baseline and whose request-URL
includes baseline-controlled members to automatically apply to the
version-controlled configuration for the appropriate baseline-controlled
collection, even if that VCCfg isn't a member of the request-URL.

Roy

-----Original Message-----
From: ietf-dav-versioning-request@w3.org
[mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
Sent: Wednesday, March 20, 2002 2:22 PM
To: Ietf-Dav-Versioning@W3. Org
Subject: RE: Clarification: extended baseline semantics of UPDATE


The UPDATE method explicitly identifies the "update target"
for the "update source", so there is no need for such a rule
(i.e. you can only update a version-controlled-configuration
with a baseline from the baseline history of that 
version-controlled configiguration).

So this statement (which is about how to find the merge target
for a baseline MERGE request) is not needed for UPDATE.

Cheers,
Geoff

-----Original Message-----
From: Roy Seto [mailto:Roy.Seto@oracle.com]
Sent: Wednesday, March 20, 2002 2:34 PM
To: Ietf-Dav-Versioning@W3. Org
Subject: Clarification: extended baseline semantics of UPDATE


Section 12.14, which defines the extended baseline semantics of MERGE,
includes the statement

   If the merge source is a baseline, the merge target is a version-
   controlled configuration for the baseline history of that baseline,
   where the baseline-controlled collection of that version-controlled
   configuration is a member of the collection identified by the
   request-URL.

Section 12.13, which defines the extended baseline semantics of UPDATE, does
not include a similar statement, but I think it should. 

Is this the working group's intention? Would this be a reasonable edit to
make in the next rev of the spec?

Roy
Received on Wednesday, 20 March 2002 23:35:18 GMT

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