RE: UPDATE responses for versioned collections

OK, we could add some words about this in the Errata and the
revised draft, if you think that would be good.

(And I agree that the Label case is not very important, since
we've deprecated the header, so it really is just the baseline
case that matters).

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
Sent: Tuesday, October 01, 2002 3:43 PM
To: Clemm, Geoff; ietf-dav-versioning@w3.org
Subject: RE: UPDATE responses for versioned collections


Ok,

that other case didn't occur me because we have deprecated the label header,
and thus we don't implement it.

I think the multistatus format is fine, it's just not entirely clear what
"modified by the request" means in case of a versioned collection.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 
-----Original Message-----
From: ietf-dav-versioning-request@w3.org
[mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
Sent: Tuesday, October 01, 2002 9:31 PM
To: ietf-dav-versioning@w3.org
Subject: RE: UPDATE responses for versioned collections


The other case would be with Depth and labels 
(see section 8.5).  So the marshalling for UPDATE 
was defined with those two cases in mind (i.e. when 
multiple resources could be affected by an UPDATE). 
We could have defined UPDATE to return DAV:multistatus 
only if there were multiple resources affected by the 
UPDATE, but it was thought simpler to just always require 
the multistatus (probably not a big deal either way, 
but that was where we ended up). 
Cheers, 
Geoff 
-----Original Message----- 
From: Julian Reschke [mailto:julian.reschke@greenbytes.de] 
Sent: Tuesday, October 01, 2002 3:24 PM 
To: Clemm, Geoff; ietf-dav-versioning@w3.org 
Subject: RE: UPDATE responses for versioned collections 


Hmm. 
Let's phrase it differently: in the absence of the baseline feature, is
there any case where an update for a version controlled collection would
affect the state of more than one resource (being the collection itself)?
Julian 
-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 
-----Original Message----- 
From: ietf-dav-versioning-request@w3.org
[mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff 
Sent: Tuesday, October 01, 2002 9:09 PM 
To: ietf-dav-versioning@w3.org 
Subject: RE: UPDATE responses for versioned collections 


Why do we need an errata entry?  The question is whether removing a 
binding to a resource is considered a modification to the 
resource, or a modification to the collection containing the 
binding.  For the purposes of UPDATE, I believe it should be 
considered a modification to the collection containing the 
binding only. 
The "move" (lower case) I was referring to was a multi-resource 
update that would result from a labeled update, or a baseline update. 
Such a multi-resource update could result in a logical move of 
a subtree from one URL to another. 
Cheers, 
Geoff 
-----Original Message----- 
From: Julian Reschke [mailto:julian.reschke@greenbytes.de] 
Sent: Tuesday, October 01, 2002 2:54 PM 
To: Clemm, Geoff; ietf-dav-versioning@w3.org 
Subject: RE: UPDATE responses for versioned collections 


Well, 
in this case we would have an erratum for 7.1: 
"The response for a successful request MUST be a 207 Multi-Status, where the

DAV:multistatus XML element in the response body identifies all resources 
that have been modified by the request." 
I also don't understand the second part of your reply -- we're talking about

response marshalling for UPDATE, not MOVE. What am I missing? 
Julian 
-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 
-----Original Message----- 
From: ietf-dav-versioning-request@w3.org 
[mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff 
Sent: Tuesday, October 01, 2002 8:25 PM 
To: ietf-dav-versioning@w3.org 
Subject: RE: UPDATE responses for versioned collections 


I would expect the latter, i.e. just the fact that the 
versioned collection had changed.  The client would then 
look at the DAV:version-controlled-binding-set of the 
DAV:checked-in version of the collection to see how it 
should update its local state (it needs to do that to 
differentiate a delete/add from a move). 
One benefit of this approach is that it doesn't cause 
a flood of responses if you move a folder with 1000 
members (i.e. it would return just the source and destination 
collections of the move, rather that 1000 added entries 
and 1000 deleted entries). 
Cheers, 
Geoff