- From: Tim Ellison <Tim_Ellison@uk.ibm.com>
- Date: Mon, 20 Aug 2001 10:01:15 +0100
- To: ietf-dav-versioning@w3.org
Peter Raymond <Peter.Raymond@merant.com> wrote: > Hi, > > I was thinking about the issue of properties being removed > or empty depending on the state of the resource and the > effect this has on PROPFIND and supported-property-set > etc. It struck me as odd that the protocol defines > DAV:checked-in and DAV:checked-out as two separate > properties, rather than having one property to identify > the version and another to identify the state (eg is it > checked-in or checked-out). I would have thought something > like the following would be more logical, this way the > properties are always present: > > 3.2.1DAV:version (protected) > > This property appears on a version-controlled resource, > and identifies a version that has the same content and > dead properties as the version-controlled resource. > > <!ELEMENT version (href)> Well, it has the same content and dead properties as a checked-in version-controlled resource, since when the version-controlled resource is checked-out the content and dead proeprties can be modified. So the description you gave would have to be conditional, or state that the checked-out version-controlled resource was based on... > 3.2.2DAV:status (protected) > > This property appears on a version-controlled resource, > and identifies the state of that resource (checked-in > or checked-out). This property is changed when the resource > is checked out or checked-in. > > <!ELEMENT status ANY> > ANY value: A single element which can be either a > DAV:checked-in element or a DAV:checked-out element. > > <!ELEMENT checked-in EMPTY> > <!ELEMENT checked-out EMPTY> This would require retrieving the property and parsing it to determine the checked-in status rather than using the PROPFIND propname construct -- a minor distinction I grant you. > Is there a good reason why the above is not desirable or > why the current behaviour is better? I'd be a bit concerned that the description for DAV:version would be complex since it's meaning would be dependent upon the value in DAV:status. I also thought that separate properties would allow an expand property report to naturally terminate if the property is missing -- but have no use case to back it up. Regards, Tim
Received on Monday, 20 August 2001 05:09:31 UTC