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