- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 14 Jun 2001 16:16:22 +0200
- To: <Tim_Ellison@uk.ibm.com>, "WebDAV WG" <w3c-dist-auth@w3.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Tim_Ellison@uk.ibm.com > Sent: Thursday, June 14, 2001 3:48 PM > To: WebDAV WG > Subject: RE: Proposal for marshalling property type information > > (stuff deleted) > > > > 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. Example? I think it's safe to always suppress xs:string (as a default type). Do you think it would be useful to return types for the second case of server-defined properties? (I think I could live with that). > I don't feel strongly about this, but it seems that the type information > should be returned in a PROPFIND unless "otherwise negotiated". My goal was to keep the protocol change minimal, so I didn't want to introduce a negotiation scheme. > > > > 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. Good point. I always thought that a server MUST return <multistatus> on success, but RFC2518 seems to be silent about that. Certainly all examples show a 207. > > 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.
Received on Thursday, 14 June 2001 10:17:02 UTC