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

AltStyle によって変換されたページ (->オリジナル) /