Subject: RE: Proposal for marshalling property type information

From: [email-masked]
Date: Thu, 14 Jun 2001 14:48:28 +0100

"Julian Reschke" <[email-masked]> 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

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 14 Jun 2001 16:16:22 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of [email-masked]
> Sent: Thursday, June 14, 2001 3:48 PM
> To: WebDAV WG
> Subject: RE: Proposal for marshalling property type information
>
> (stuff deleted)
>

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

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

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