Re: Re: What is a supported property?

"Stefan Eissing" <stefan.eissing@greenbytes.de> wrote:
> Every existing live property of a resource, be it in the
> DAV: or any other namespace, is part of the
> DAV:supported-live-property-set on a server which complies
> to DAV:supported-*-set as defined in DeltaV.

Agreed.

> > I think allowing properties to be set in the DAV: namespace
> > that do not have the semantics defined in the DAV protocols
> > is extremely dangerous.
>
> I think you mean "defining a new DAV protocol which assigns new
> semantics to a property defined in earlier protocols, is extremely
> dangerous."

No, I really meant it as I wrote it (though I also agree with what you
wrote).

I mean that if a client or server is allowed to set, say
DAV:getcontentlength, it had better mean what RFC2518 says it means.

> This is done, IMHO, for DAV:resourcetype and especially for
> DAV:supported-live-property-set. DeltaV explicitly proposes that
> semantics for DAV:supported-live-property-set does change with
> every addition or removal in its content.

I don't understand this.

> The difference between changes of DAV:resourcetype and
> DAV:supported-live-property-set is that the latter requires
> set operations to discover the semantics.

I suggest that since the DAV:resourcetype will be multi-valued, clients
will be required to perform the set operations either way.

> When a client discovers DAV:collection in DAV:resourcetype, it
> is safe to assume that it can treat the resource as a collection.

Agreed.  It can treat it as a collection as defined by RFC2518.

> When a client discovers DAV:checked-in in DAV:supported-live-property-set
> it has to look for the appearance or absence of other properties in
> this set in order to know what it can do with the resource.

How much more difficult is it to look for multiple values than single
values?

> This makes writing a client, which is foolproof to future
> extensions and different servers (in that way that it does
> not screw up), much more challenging.

I disagree.  Provided protocol designers do not redefine an existing
property (which we agree is bad), clients will still "look for" the subset
of properties and methods in just the same way; and their existance will
afford just the same assurances.

> ...even if we could assume all servers to implement DeltaV correctly
> with the same interpretation of the spec.

I think we always have to assume erroneous clients can screw up.

> > > So, supported-method-set will change for a resource type, but
> > > supported-live-property-set will not. Correct?
> >
> > Lets not use 'type' -- debating that word is getting us into too much
> > trouble.
>
> Agreed, but will the one change and the other stay the same?

No, that is not guranteed.

> Let's turn version-history for Tim's mail on:
>    "...if you know the resource types^H^H^H^H^H^Hs defined
> in the specification".

Sorry, this one is lost on me?

Tim

Received on Friday, 22 June 2001 09:27:51 UTC