W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

RE: Proposal for marshalling property type information

From: <Tim_Ellison@uk.ibm.com>
Date: Thu, 14 Jun 2001 14:48:28 +0100
To: "WebDAV WG" <w3c-dist-auth@w3.org>
Message-ID: <80256A6B.004C5E0B.00@d06mta06.portsmouth.uk.ibm.com>

"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...)?


Received on Thursday, 14 June 2001 09:56:18 UTC

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