Re: Comments on bind-08

Weighing in...

On Nov 29, 2004, at 7:57 PM, Geoffrey M Clemm wrote:

> 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?

I agree with Jim that we should add clearer wording here.  The 
ingenuity of
implementors is great, and that includes a surprising ability to come to
different conclusions than the writers of a specification.

>
>>> * 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.

Great -- so we agree on what should happen.  As Jim suggests,
let's put it in the spec.

>
>>> * 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.

An example with locks and REBIND would be great.  Other examples with 
locks
and bound resources (and requirements about what URL must be 
used/supported
in the requests) would also be great.

Lisa

Received on Tuesday, 30 November 2004 17:33:15 UTC