- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Fri, 22 Jun 2001 14:58:30 +0200
- To: "Ietf-Dav-Versioning" <ietf-dav-versioning@w3.org>
> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von Tim Ellison > > [...] > 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. I try to summarize a partial definition of supported-live-property-set: Every existing live property of a resource, be it in the DAV: or any other namespace, is part of the DAV:supported-live-property-set on a server which complies to DAV:supported-*-set as defined in DeltaV. > [...] > > 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 you mean "defining a new DAV protocol which assigns new semantics to a property defined in earlier protocols, is extremely dangerous." This is done, IMHO, for DAV:resourcetype and especially for DAV:supported-live-property-set. DeltaV explicitly proposes that semantics for DAV:supported-live-property-set does change with every addition or removal in its content. The difference between changes of DAV:resourcetype and DAV:supported-live-property-set is that the latter requires set operations to discover the semantics. When a client discovers DAV:collection in DAV:resourcetype, it is safe to assume that it can treat the resource as a collection. When a client discovers DAV:checked-in in DAV:supported-live-property-set it has to look for the appearance or absence of other properties in this set in order to know what it can do with the resource. This makes writing a client, which is foolproof to future extensions and different servers (in that way that it does not screw up), much more challenging. ...even if we could assume all servers to implement DeltaV correctly with the same interpretation of the spec. > > > 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. Agreed, but will the one change and the other stay the same? > > 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 Let's turn version-history for Tim's mail on: "...if you know the resource types^H^H^H^H^H^Hs defined in the specification". ;) > you may like to know we have these a-la-carte properties and methods that > are defined in the "XYZ:" namespace. Stefan
Received on Friday, 22 June 2001 08:59:15 UTC