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

AW: What is a supported property?

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Fri, 22 Jun 2001 10:55:57 +0200
To: "Ietf-Dav-Versioning" <ietf-dav-versioning@w3.org>
Message-ID: <NDBBKJABLJNMLJELONBKKEHCCOAA.stefan.eissing@greenbytes.de>
> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von Tim Ellison
> "Stefan Eissing" <stefan.eissing@greenbytes.de> wrote:
> > All this resourcetype and state thing aside:
> >
> > What is a supported property?
> >
> > A resource has properties, let's call these existing
> > properties, which might or might not have values. But
> > when a client does a PROPFIND on them, he will get
> > them listed in a propstat element with 200 OK status
> > code. I think that is a good definition of an "existing
> > property of a resource".
> If I was going to be pedantic I'd say that the status code for an existing
> property is not 404 Not Found, since the PROPFIND may fail due to
> authorization problems etc., but I know what you mean.

<g/> Ok.

> > Now, every existing property would also be a supported
> > property and, being live, would appear in the
> > supported-live-property-set. Ok.
> 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?

> > Now Geoff mentioned that a VCR with in-place editing
> > would have both DAV:checked-in and DAV:checked-out as
> > supported properties, and that independant of the
> > checked in/out state of the resource!
> (I've not received Geoff's post on that yet, I think it was held up in
> customs<g>)
> I agree with this view.  The server supports the semantics of
> DAV:checked-in and DAV:checked-out on a version-controlled resource even
> though those properties cannot appear simultaneously.
> > Now, here I became confused, since it means that not
> > every supported property is an existing property!
> Correct.
> > If we define supported properties with:
> >    a property which will exist, when a method is applied
> >     successfully
> > then all non-versioned resources will have the
> > DAV:checked-in as supported property, since you can
> > apply VERSION-CONTROL. So, that does not seem to be
> > a good definition...
> Well we are back to that _type_ thing again I'm afraid.  The document

I was afraid so, too.

> states that a versionable resource is a different type of resource to a
> version-controlled resource, and so on.  It makes these distinctions so
> that we can talk about "Activities" and "Workspaces" and
> "Version-controlled resources" and know what affect named property values
> and methods have on that resource.
> 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.
Imagine a server which complies to DeltaV in regard to supported-*-set, but
does not implement DeltaV resource types. This server could allow a
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 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.

> The DAV:supported-*-set properties are defined for each type of resource.

There you go with this type thing again. <g/>

> The supported-property-set tells you which properties will/can be defined
> for that resource _and_ have the meaning defined in the
> specification.  (It
> therefore states that DAV:checked-in will&can not be defined on a
> versionable resource.)
> > And what about supported methods? Is CHECKIN a supported
> > method for a checked-in resource, too? It will fail all
> > the time...
> The CHECKIN method is not supported for a checked-in resource, i.e., there
> are no (non-failure) semantics for that operation in the specification.
> The analogy is with HTTP/1.1 Allow.

So, supported-method-set will change for a resource type, but
supported-live-property-set will not. Correct?

> Tim

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!"

I could live with the current way of things, like it or not. But
I have this nagging feeling that someday my daughter will come
to me and ask: "Daddy, what did you do when they defined deltaV?"


Received on Friday, 22 June 2001 04:56:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC