Re: SEARCH by last path segment, Was: SEARCH for displayname

Lisa Dusseault wrote:

> I think we may actually be getting somewhere here.  *Why* should we
> have this architectural principle?  What purpose does it serve?  What
> makes WebDAV better if we push URL-varying properties to the parent
> collection? 

We don't push it. That's how it currently is defined in the specs 
(partly implicitly, but anyway).

Either we agree that the state is completely defined by the resource and 
the collection(s) it lives in. In which case we can state that a 
property either is part of the resource's state, or of the collection 
it's in. That's what the current specs are doing.

We can probably also invent a third place that can have state, in which 
we need to give it a name and need to define how it's adressed and so 
on. However this seems to be a rather uncommon way to model containment 
and resources.

> The is-hidden example is one which is harder to do if we push it to
> the parent collection.  A resource which is hidden in one collection
> may be visible in another due to different behavior of the two bindings.

Actually that's why it makes sense to see this as part of the state of 
the parent collection, not the resource itself.

> With your proposed architectural principle, we couldn't have 'is-hidden'
> be true on one binding and false on the other, as I understand it. 

Of couse you could.

> So the parent collections of the two bindings would have to have lists
> of hidden resources instead.  That's harder for clients to change 
> than a simple 'is-hidden' boolean on each binding.

The binding *is* part of the state of the collection. Thus if a binding 
can be "hidden, this is naturally a property of the binding, and thus 
part of the state of the collection.

> Why have an architectural principle that holds us back, if it doesn't
> give us something in return?

It does. For instance, it allows us to define how locks and multiple 
bindings interact in a logical way.

Regards, Julian

<green/>bytes GmbH -- -- tel:+492512807760

Received on Tuesday, 18 November 2003 16:01:33 UTC