Re: Comments on bind-08

The problem here is that Julian is using the intended marshalling
of REBIND (which is like BIND, i.e. the request-URI identifies the
collection into which the new binding will be created), while Jim
is using the incorrectly updated definition in the current spec,
which inverts the intended meaning (i.e. in the current draft,
the syntax has been incorrectly "clarified" as having the request-URI
identify the existing binding).

I've submitted a bug on this.

Cheers,
Geoff

Julian wrote on 12/03/2004 02:12:06 PM:
> 
> Jim Whitehead wrote:
> > Julian writes:
> > 
> > 
> >>I guess we should stick with diagrams until we agree on the operation 
> >>we're performing...:
> > 
> > 
> > Yes, good point. Hmm, the figures you drew weren't quite right.
> > 
> > Before (this is OK, I added lock token identifiers for clarity):
> > 
> > +------------------+
> > | Root Collection  |
> > |  bindings:       |
> > |  CollW           |
> > +------------------+
> >      |
> >      |
> >      |
> > +-------------------------------+
> > | Collection C1                 |<--------+
> > | bindings:                     |         |
> > | CollX               CollY     |         |
> > +-------------------------------+         |
> >      |                  |                 |
> >      |                  |  (creates loop) |
> >      |                  |                 |
> > +-----------------+  +------------------+ |
> > | Collection C2   |  | Collection C3    | |
> > | LOCKED infinity |  | LOCKED infinity  | |
> > | (lock token L2) |  | (lock token L3)  | |
> > | bindings:       |  | bindings:        | |
> > |  {none}         |  | y.gif     CollZ  | |
> > +-----------------+  +------------------+ |
> >                        |            |     |
> >                        |            +-----+
> >                        |
> >                    +---------------------------+
> >                    | Resource R2               |
> >                    | (lock inhereited from C3) |
> >                    | (lock token L3)           |
> >                    +---------------------------+
> > 
> > After (this is changed -- CollZ now points to C2, not C1)
> > 
> > +------------------+
> > | Root Collection  |
> > |  bindings:       |
> > |  CollW           |
> > +------------------+
> >      |
> >      |
> >      |
> > +-------------------------------+
> > | Collection C1                 |
> > | bindings:                     |
> > | CollX               CollY     |
> > +-------------------------------+
> >      |                  |
> >      |                  |
> >      |                  |
> > +-----------------+  +------------------+
> > | Collection C2   |  | Collection C3    |
> > | LOCKED infinity |  | LOCKED infinity  |
> > | (lock token L2) |  | (lock token L3)  |
> > | bindings:       |  | bindings:        |
> > |  {none}         |  | CollZ     y.gif  |
> > +-----------------+  +------------------+
> >        ^                |           |
> >        +----------------+           |
> >                                     |
> >                    +---------------------------+
> >                    | Resource R2               |
> >                    | (lock inhereited from C3) |
> >                    | (lock token L3)           |
> >                    +---------------------------+
> 
> I guess this explains the confusion. The operation that you're showing 
> here keeps the binding name (CollZ), but changes the resource to which 
> it refers (from C1 to C2). This is neither a MOVE nor a REBIND 
operation.
> 
> You can express this as
> 
> 1) UNBIND /collW/CollY/
>     <unbind xmlns="DAV:">
>       <segment>CollZ</segment>
>     </unbind>
> 
> followed by
> 
> 2) BIND /collW/CollY/
>     <bind xmlns="DAV:">
>       <segment>CollZ</segment>
>       <href>/CollW/CollX</href>
>     </bind>
> 
> The other obviously open question was whether bind loops need special 
> treatment regarding depth:infinity locks. I wasn't under the impression 
> they do. Is there a specific problem that needs to be solved?
> 
> Best regards, Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>