RE: Proposal for marshalling property type information

"Julian Reschke" <julian.reschke@gmx.de> wrote:
> > >
> > > 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?

Any client retrieving a property whose type is unknown to them would
benefit. For example, if a RFC2518 (but not DeltaV) aware client retrieved
a DeltaV property it seems unfair that the client was not told of its data
type simply because "the property's data type is defined in [RFC2518] or a
related specification."  It does not make clients forward compatible with
those future specifications.

> I think it's safe to always suppress xs:string (as a default type).

Agreed, there is a default.

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

Yes.  For clients that are expecting a known type the information will be
redundant.

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

You don't have to specify the negotiation, and there are examples of this
approach in DeltaV error reporting.

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

It was generally agreed on this list a while back that total success may be
condensed to a simple 200 OK response.  Your suggestion would require a
further modification to these servers.

Tim

Received on Thursday, 14 June 2001 11:20:40 UTC