RE: Proposal for marshalling property type information

> 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