Subject: RE: Proposal for marshalling property type information

From: [email-masked]
Date: Tue, 12 Jun 2001 14:51:06 +0100

> 5. Changes for PROPFIND method
>
>    PROPFIND is extended to return the data type information for
>    properties that satisfy the following conditions:
>
>    o  The data type is different from "xs:string".
>
>    o  The property's data type is not defined in [RFC2518] or a related
>       specification.

This seems too strict, how about servers MAY excluse the data type
attributes where ...

> 6. Compatibility Considerations
>    ...
>    Servers not aware of this specification either drop the "xsi:type"
>    attribute, or persist it along with the property value.  However,
>    they will never indicate successfull parsing of the data type by
>    returning back the type in the response to PROPPATCH.

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?

Apart from that, the proposal seems straight forward enough.

Tim

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 12 Jun 2001 19:24:00 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of [email-masked]
> Sent: Tuesday, June 12, 2001 3:51 PM
> To: WebDAV WG
> Subject: RE: Proposal for marshalling property type information

Hi Tim,

thanks for the feedback.

> This seems too strict, how about servers MAY excluse the data type

The idea was to be specific here to avoid "polluting" PROPFIND replies with
unnecessary information (as seen, for instance, in IIS).

> Are you suggesting that aervers should ignore unknown attributes?

I think you misread.

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

An old server will never do this upon PROPPATCH. So this remark applies to
PROPPATCH, not a subsequent PROPFIND.

> Apart from that, the proposal seems straight forward enough.

Thanks.

Do you think it would be worthwhile to extend this for passing arrays (I've
got a proposal for using the SOAP encoding ready...)?

Julian