- 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>
> [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 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 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?" ;) //Stefan
Received on Friday, 22 June 2001 04:56:32 UTC