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