Re: Comments on bind-08

I agree with Julian.  A new section of text or example can do more
harm than good (a classic being the "MOVE is logically a COPY/DELETE"
section from 2518).

So I think it is a reasonable criteria to require that any proposed
addition be motivated by at least one example of a misunderstanding
that may arise with the current text.

Cheers,
Geoff

Julian wrote on 11/30/2004 01:17:15 PM:

> 
> Lisa Dusseault 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?
> > 
> > 
> > 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.
> 
> I'd still like to know how it is clearer...
> 
> >> 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.
> 
> Again, before we put additional spec into the spec, it should be clear 
> what problem it solves. I understand that you lean to "more is better", 
> but please acknowledge that many people writing specs disagree.
> 
> >>>> * 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.
> 
> I'm not sure how locking examples for REBIND are going to help much. 
> REBIND is just like MOVE, except for slightly different marshalling. I'm 

> not against adding an example per se, but if we do it it should really 
> contain something that's not available elsewhere.
> 
> Julian
> 
> 
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>