- From: <Tim_Ellison@uk.ibm.com>
- Date: Thu, 14 Jun 2001 14:48:28 +0100
- To: "WebDAV WG" <w3c-dist-auth@w3.org>
"Julian Reschke" <julian.reschke@gmx.de> wrote: > > > 5. Changes for PROPFIND method ... > > This seems too strict, how about servers MAY exclude > > the data type attributes where ... > > The idea was to be specific here to avoid "polluting" > PROPFIND replies with unnecessary information (as seen, > for instance, in IIS). I understand, however what is pollution to one client is useful information to another. I don't feel strongly about this, but it seems that the type information should be returned in a PROPFIND unless "otherwise negotiated". > > > 6. Compatibility Considerations ... > > Huh? If it is persisted as an attribute why would the > > server not return it in PROPFIND? > > Are you suggesting that aervers should ignore unknown > > attributes? > > I think you misread. Oops, I did misread it, thanks. > PROPPATCH, when a datatype was supplied and recognized, is > going to report that by adding it to it's response body: > > "The server should indicate successfull detection and parsing > of the typed value by setting the xsi:type attribute on the > property element in the response body.". So I presume you are advocating always returning a multistat for a successful PROPPATCH? Then clients can tell that the PROPPATCH succeeded and that the type information was considered. Alternatively, if a server just returned 200 OK that would mean the property values were not validated by type. > An old server will never do this upon PROPPATCH. So this remark > applies to PROPPATCH, not a subsequent PROPFIND. Agreed. My mistake. > Do you think it would be worthwhile to extend this for passing > arrays (I've got a proposal for using the SOAP encoding ready...)? Sure. Tim
Received on Thursday, 14 June 2001 09:56:18 UTC