Re: Re: What is a supported property?

> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von Tim Ellison
>
> [...]
> I agree it doesn't need to be in the DAV: namespace to be in the
> supported-live-property-set, rather that every existant property
> in the DAV
> namespace will be in the set.

I try to summarize a partial definition of supported-live-property-set:

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.

> [...]
> > Imagine a server which complies to DeltaV in regard to
> > supported-*-set, but does not implement DeltaV resource
> > types. This server could allow a PROPPATCH on DAV:checked-in.
> > If you call such a resource versionable would depend
> > on the supported-method-set then, not on the
> > supported-property-set.
>
> 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."

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.

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

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

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.

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.

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

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

> > Well, I still have no definition of a supported property
> > which does not use the word "type" in any way. :(
> >
> > I smell a certain odor of circular reasoning here:
> > Client: "How do I determine the resource type?"
> > Server: "You don't. Types are bad for you, look at the properties."
> > Client: "Ok, what properties can I expect?"
> > Server: "That depends on the type of the resource!"
>
> Client: "How do I determine the resource type?"
> Server: What do you mean by 'type'?
> Client: I mean what characteristics can I expect of this resource?
> Server: Well we have a menu of properties and methods, whose semantics you
> are familiar with if you know the DAV specification; and as a side-order

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

> you may like to know we have these a-la-carte properties and methods that
> are defined in the "XYZ:" namespace.

Stefan

Received on Friday, 22 June 2001 08:59:15 UTC