Re: Comments on bind-08

Julian wrote on 11/29/2004 05:58:51 PM:

> Jim Whitehead wrote:

> > * Section 2.3. This section doesn't clearly address the semantics of 
COPY
> > with Depth infinity. My recommendation is to add, after paragraph 3, 
text
> > like this:
> > 
> > "As specified in [RFC2518], a COPY with Depth infinity causes the 
collection
> > resource to be duplicated, all of its bound children to be duplicated, 
and
> > their children's bound children, and so on, to the bottom of the 
containment
> > hierarchy. All of the segments of the bindings of the destination 
collection
> > are the same as for the destination collection. However, the 
destination
> > resource for all bindings in the destination collection are different 
from
> > those of the source collection, since all resources have been 
duplicated,
> > creating new resources with distinct DAV:resource-id properties."
> 
> As far as I understand, the depth:infinity semantics for COPY follow 
> from what's being said about depth:0 and the RFC2518 infinity semantics 
> (just checking...). Thus, I'm not convinced that we need to say this, 
> but it probably wouldn't hurt either. Feedback appreciated.

Jim: I'm OK with adding the paragraph, but what was the possible 
misunderstanding
that this additional text was intended to clear up?  How else could a 
Depth=infinity
COPY work?

> > * One gap in the current COPY semantics is the ability to copy a 
collection
> > and its bindings. COPY depth 0 says copy all non-binding state. COPY 
depth
> > infinity copies all bindings and makes duplicates of all bound 
resources.
> > But, there's no single atomic operation (call it BINDDUP) that 
duplicates
> > the collection and its bindings, but doesn't duplicate the bound 
resources.
> > That is, there is no operation that does a COPY Depth 0 plus BIND for 
all
> > members. So, two questions. Is there a compelling scenario for having 
a
> > BINDDUP method? I confess I'm having a hard time coming up with one. 
Second,
> > assuming there is a compelling scenario, can it be accomplished just 
using
> > COPY, LOCK, and BIND, rather than having a special purpose method. 
Also
> > unclear.
> 
> I do agree we don't have that. I have no idea whether anybody needs it. 
> If it's needed, you can get very close to it using MKCOL, LOCK, n * BIND 

> and UNLOCK.

I do not thing we need to special case this particular scenario, so I 
would vote
not to add anything to handle it.

> > * Section 2.6 -- there needs to be some discussion on the interactions 
of
> > DAV:resource-id and versioning. As near as I can tell, the intent is 
that
> > every revision will have a unique DAV:resource-id value.
> 
> That's correct. I'm not sure why we would need to state this -- a 
> version resource clearly is not the same resource as it's VCR, so it 
> seems clear they'll never have the same DAV:resource-id.

I agree with Julian.  A version is a new resource created by the CHECKIN 
method.
According to section 2.6, a new resource must be assigned a new 
resource-id,
so each new version needs to be assigned a new, distinct resource-id.

> > * Section 2.6, final paragraph, last two sentences. Change "must not" 
to
> > "MUST NOT" (and eliminate the "For example" at the start of the 
sentence --
> > perhaps change to "Specifically,"
> 
> I agree for PUT/COPY, but things get unclear when we talk about MOVE (as 

> RFC2518 allows this to be implemented in terms of COPY/DELETE). REBIND, 
> on the other hand, has that property. Feedback appreciated.

I'd vote to take Jim's suggested changes here.  A UUID that is not 
preserved
by the MOVE implementation for a repository should not be a candidate for 
a
DAV:resource-id implementation.

> > * Section 6.2. I think it would be helpful to have an example 
including
> > REBIND and locks, showing submission of one or more lock tokens in the 
If
> > header.
> 
> Such as one involving locked source and destination collections? That 
> may be useful. What do others think?

I continue to believe that the right place for locking examples is in a
locking spec, and that the binding spec just needs to make clear which 
resources
and which URL mappings are being modified by an operation, since this is 
all
you need to know which locks are required.  I believe this information is
well-defined in the pre-conditions of the methods introduced by the 
binding
spec.  So I'd vote not to add such an example, but I could live with it,
if a majority is for it.

Cheers,
Geoff