RE: Comments on bind-08

Jim wrote on 12/01/2004 01:45:02 PM:

> Geoff Clemm wrote:
> 
>    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? 
> 
> There are two possible confusions.
> 
> 1) An implementer could implement the BINDDUP semantics (i.e., duplicate
> bindings, but not resources), rather than the desired semantics of
> duplicating resources and bindings. I agree that someone who reads and
> understands the current specification and RFC 2518 should not come to 
this
> misunderstanding. However, since the bind specification doesn't 
explicitly
> address Depth infinity copies, there is no explicit information that 
would
> clearly and definitively cause someone to stop thinking that BINDDUP
> semantics are the intent.
> 
> 2) It's not clear how to handle bindings that cause containment loops, 
since
> in this case you do just want to only duplicate the binding, and not the
> bound resource. This is enough different from the mainline COPY 
semantics
> (duplicate binding and bound resource) that it's worth explicitly 
mentioning
> it. For example, a reasonable interpretation of the current 
specification,
> when copying loopback bindings, is to create a new binding to a new
> collection, where the new collection's bindings point to the resources 
bound
> by the collection originally pointed to by the loopback binding. This
> preserves the "copy binding and duplicate destination resource" 
semantics
> described for COPY.

OK, thanks, now I understand your concern.

I suggest that rather than adding additional text, that we add an 
additional
diagram showing what the result is of a copy in this case (I believe a
single example can illustrate both of these points).

Note: The reason I (and I believe Julian) push back on "just adding text"
is that there are various ways to clarify (text, pictures, examples), and
until we understand the specific problem, we cannot have a discussion 
about
the best way to address the concern.

>    > > * 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.
> 
> Glad we're in agreement. It should be trivial to add a sentence to this
> effect in the bind specification.

I'm OK with adding this as the form of an example, i.e., in section 2.6,
after the sentence stating that new resources get new resource-id's, we
could say that "for example, when a new version resource is created, it 
receives a new resource-id".

>    > > * 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. 
> 
> I just wanted to clarify the use of the If header to pass lock tokens 
for
> already locked resources, since there have been client implementation 
issues
> concerning If implementation in this past. I agree that we should, for 
now,
> avoid discussion of the interactions of LOCK and bindings.

I agree.  The last thing I want us to do is make a statement about
lock token marshalling in the binding specification.

Cheers,
Geoff