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

> > I propose that we do not rule out properties that vary 
> based on URL, 
> > when these are useful and the simplest way to specify a feature.
> >
> > You propose that we rule out properties based on URLs but that will 
> > make some features harder to implement and specify.  I do not see 
> > sufficient reason for that.
> 
> If making it "more convenient" means breaking an architectural 
> principle, then yes, I disagree.
> 
> The WebDAV architecture talks about URI mappings being created by 
> collection containment and internal member names (bindings). So 
> everything that does indeed vary on the actual mapping that was used 
> belongs to the state of the collection, not the resource, and 
> therefore 
> should be modelled as a property of the collection.
> 

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? 

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

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

Lisa

Received on Tuesday, 18 November 2003 15:49:50 UTC