Re: Comments on bind-08

Geoffrey M Clemm wrote:
>  > 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).

OK. Any proposed text/artwork for inclusion into the spec? (I'll work on 
the other issues in the meantime :-).

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

Agreed. In particular, when I myself read specs that (under my 
impression) repeat information that was already provided before/by 
reference, I start asking myself: "why are they repeating this? -- is 
this intended to *change* something that was said before?". So, if 
something's just intended to repeat something that was already specified 
somewhere else, it makes a lot of sense to say that, instead of leaving 
readers like myself confused :-)

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

Sounds like a good compromise. Unless there are objections, I'll make 
that change right away.

> ...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 1 December 2004 20:29:27 UTC