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

Re: Request for feedback: WebDAV property datatype draft

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Thu, 23 Sep 2004 07:21:02 -0700
Message-Id: <CC4D9B6C-0D6B-11D9-AE25-000A95B2BB72@osafoundation.org>
Cc: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>, webdav <w3c-dist-auth@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

Having the data-types spec stay out of arrays would certainly simplify 
it, so I can't object to that approach.  Certainly I would think that 
if somebody does an array/list/set property draft later the property 
data-type stuff can be re-used then.

What about clarifying that XML-valued properties don't need a data type?

I do disagree with the approach of minimizing examples for the reasons 
you cited.  Isn't it a *bad* thing if people have different tastes 
about types and optimal serializations, and doesn't that lead to lower 
interoperability?  Within an experimental protocol, that approach may 
be acceptable, but still undesirable.


On Sep 23, 2004, at 7:06 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> Can we include an example of an array of XML elements in the draft, 
>> so that implementors are likely to do it the same way?
> I'd prefer not to. Adding examples for more then the absolute trivial 
> things (like booleans or dates) is likely to open the proverbial can 
> of worms, because people have different tastes about types and optimal 
> serializations. So in doubt I'd even prefer to *remove* the current 
> appendix (as I'm not convinced that this is a good serialization 
> format given it's based on an outdated SOAP spec; it just happens to 
> be what we *do* implement right now).
>> I would also like to request some words on ordering in the draft, 
>> although I agree that the W3C Note says that ordering is significant 
>> that doesn't say everything.
>>  - Say that "servers MUST preserve ordering if the server is storing 
>> a dead property in array format" or something equivalent
> Again, I'd prefer not to. An array is an array; not a set.
>>  - What clients should do is a little less clear but let's take a 
>> stab at it:  clients that are adding a new value, removing a value, 
>> or changing a value in an array SHOULD maintain the rest of the array 
>> ordering, unless the user actually intends to resort the array to a 
>> different order.
> Well, that's the whole point of having an array.
> I understand that you are particulary interested in this data type 
> because you'll need it. It seems to me that the best strategy for you 
> is to define that type in a separate document (possibly standalone or 
> caldav), and let the property types spec stay out of this business.
> Best regards, Julian
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 23 September 2004 14:22:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:30 UTC