W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2004

Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Fri, 10 Dec 2004 12:38:25 -0800
Message-Id: <70B3C698-4AEB-11D9-AC43-000A95B2BB72@osafoundation.org>
Cc: ejw@cs.ucsc.edu, "'webdav'" <w3c-dist-auth@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

>
>> This kind of thing could be useful for other applications as well.  
>> It could even work with PROPPATCH, because the server knows to treat 
>> this as a "per-binding" property and change only the value that 
>> applies for this binding.
>
> So where do you store it? Either on the resource itself (in which case 
> you need to maintain that property for each parent collection, so you 
> could simply expose that information as well), or on the collection.

WebDAV servers *store* things any way they like.  E.g. a new table in 
the backend database called "PER_BINDING_PROPS" with column headers for 
binding, property name and value. Who cares how they store it -- that's 
what gives the implementors flexibility.  WebDAV's model and 
marshalling are what we're talking about.

>
> BTW: you seem to be changing positions frequently :-) May I remind you 
> that you asked that the BIND spec mandates that properties MUST NOT 
> vary across bindings?
>
As it happens, I am not changing positions on this issue (although I 
reserve my right to change my mind if I'm convinced by an argument or 
think of new cases).  I have held this position for a year or more now 
and will try to state it again another way:

That servers should be allowed to vary properties per binding and IF 
that's the consensus...
     then the specification should warn clients that "clients MUST be 
prepared for properties that vary per binding"
ELSE IF the consensus (despite my opinion) is that properties can't 
vary per binding
     then the specification should say that properties MUST NOT vary 
across bindings.

Lisa
Received on Friday, 10 December 2004 20:38:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:17:51 UTC