W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

Re: AW: What is a supported property?

From: Tim Ellison <Tim_Ellison@uk.ibm.com>
Date: Fri, 22 Jun 2001 12:35:01 +0100
To: "Ietf-Dav-Versioning" <ietf-dav-versioning@w3.org>
Message-ID: <OFFB1164AE.064F5535-ON80256A73.003D6E91@portsmouth.uk.ibm.com>
"Stefan Eissing" <stefan.eissing@greenbytes.de> wrote:
> > Again, just to be completely precise, every live
> > property (in the DAV:namespace) of a DeltaV-compliant
> > resource will be in the DAV:supported-live-property-set.
>
> I don't buy that it needs to be in the DAV: namespace.
> After all, what is the namespace attribute in
> DAV:supported-live-property then good for?

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.

> > To avoid confusion the server is required to disallow
> > setting resource properties that are defined in the
> > specification but are not supported (i.e. a PROPPATCH
> > of DAV:checked-in on a DeltaV-compliant versionable
> > resource MUST fail).
>
> It does not say so in the spec. In fact, I think it would
> be unwise to say so in the spec.

You're right, I can't find that statement any longer in the spec.

I think it is useful to have such a requirement otherwise any client can
set, say, DAV:checked-in and DAV:checked-out to a resource (with
unspecified semantics).

> 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 that is a valid case, since you cannot couple
> supported-*-set to implementation of DeltaV resource types.
> supported-*-set has to be a feature that can be used by
> other (orthogonal) extensions as well in the future.

I agree that the supported sets will be used by other protocol extensions
to declare the capabilities of a resource.

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

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

Tim
Received on Friday, 22 June 2001 07:34:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:41 GMT