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

Re: What is a supported property?

From: Tim Ellison <Tim_Ellison@uk.ibm.com>
Date: Thu, 21 Jun 2001 17:06:06 +0100
To: "Ietf-Dav-Versioning" <ietf-dav-versioning@w3.org>
Message-ID: <OF2DBF2AE9.497613A1-ON80256A72.0055B296@portsmouth.uk.ibm.com>
"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.

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

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

The DAV:supported-*-set properties are defined for each type of resource.
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.

Tim
Received on Thursday, 21 June 2001 12:06:46 GMT

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