W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > October to December 2003

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

From: Lisa Dusseault <lisa@xythos.com>
Date: Tue, 18 Nov 2003 12:49:33 -0800
To: "'Julian Reschke'" <julian.reschke@gmx.de>
Cc: "'Wallmer, Martin'" <Martin.Wallmer@softwareag.com>, "'Kevin Wiggen'" <kwiggen@xythos.com>, <www-webdav-dasl@w3.org>
Message-ID: <023701c3ae15$787d7520$75c990c6@lisalap>

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

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?

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:43 UTC