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: Tue, 14 Sep 2004 15:35:22 -0700
Message-Id: <5D6773F4-069E-11D9-9C6B-000A95B2BB72@osafoundation.org>
Cc: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>, webdav <w3c-dist-auth@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

Responses inline...

On Sep 14, 2004, at 2:05 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> I have a nit on the draft: the example shows a boolean value of '1'  
>> in  section 5.1, but the text below says this is a value of 'true'.
> The *typed* value is the same. Both "1" and "true" are legal  
> serializations of the XML Schema datatype "boolean".

It seemed like a bug to me, so maybe the example needs more explanation.

>> More globally, some issues:
>>  - I had some understanding from previous discussions that this was   
>> supposed to allow multi-valued properties.  However, it appears that   
>> the entire property value must be provided in each PROPPATCH request.  
>>   It would be helpful if the specification communicated this.
> Well, the spec doesn't change basic PROPPATCH semantics (and it never  
> was claimed it does). Does it really need to state that it doesn't?  
> Why?

Only a matter of setting expectations -- what this spec does provide,  
what it doesn't provide.  Human-readable overview text to provide  
context for how to consider this work.

>>  - I'm a little concerned that the multi-valued stuff is in an   
>> appendix.  If this functionality MUST be supported (by servers that   
>> support the draft) then the examples should be in the main text, so   
>> that server implementors aren't tempted not to support it.
> No, it's an appendix because it's entirely optional. All that the spec  
> defines is how you can use the xsi:type attribute from XML Schema to  
> forward type information. It doesn't mandate support for any specific  
> types.

If it were going to the regular standards track I'd strongly push for a  
list of mandated types to support.  Since you're proposing this for the  
experimental track, I suppose it can be conceptualized as a description  
of the way an implementor might do things with very little (nothing?)  
in the draft being required.

One consequence of having weak or no requirements, and no advertisement  
of the feature, you might find that it's difficult to get critical mass  
of support for this stuff, beyond the implementations that already  
support this or something of the kind.

>>  - The draft should make more explicit requirements on server   
>> implementors, to help ensure more interoperable and consistent   
>> implementations.  For example, the draft should say something along  
>> the  lines of "Servers supporting this feature MUST support the  
>> following  list of data types and the array data type... [etc] "
> See above, they don't have to. Is there any hope that we can get a  
> consensus of a minimum set?  I guess it wouldn't contain more than  
> strings, dates and integers (I wouldn't even expect boolean support  
> from everybody).

Depending on the concept for the document, I would go so far as to  
propose that all the built-in primitive types would be required,  
possibly also integer and a few of the integer-derived types.  Also the  
server would be required to support lists of any of the supported  

>> if there's no way, then there should be some guidance for clients  
>> along  the lines of "If the client supports this draft, the client  
>> SHOULD send  data typing information for all non-string data types,  
>> without even  knowing whether the server supports the feature."
> Section 6  
> (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property- 
> datatypes-latest.html#rfc.section.6>) states that it's harmless to  
> provide data type information upon PROPPATCH. Is there any need to  
> expand this?

Depends on how readable you want the spec to be.  I would consider that  
information very helpful and clarifying.

Received on Tuesday, 14 September 2004 22:35:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:32 UTC