- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Sun, 4 Feb 2001 16:50:11 -0500 (EST)
- To: ietf-dav-versioning@w3.org
From: "Lisa Dusseault" <lisa@xythos.com> > "Why are we required to make this distinction between > predecessors and precursors?" > "Because it makes a big difference to the client whether a > version is in the same history as another version, in terms of > what you can do (for example, you cannot UPDATE a vcr to be a > precursor of the checked-in version, but you can UPDATE it to a > predecessor)." But the Core versioning section is supposed to be features that MUST be supported by all versioning servers. There are a variety of conditionals in core. For example, auto-versioning behavior happens only if the DAV:auto-version property is set, and a server is allowed to refuse to let a client modify the value of DAV:auto-version. Yet, the original paragraph implies that "precursor-set" and the "initialize-precursor" condition aren't required to be implemented because it says "if the destionation of the COPY supports the DAV:precursor-set property". Yes, but having certain behavior (i.e. setting the DAV:precursor-set) happen only if the resource supports it is consistent with the way the rest of core is defined (i.e. auto-versioning happens only if DAV:auto-version is set). Also, your explanation refers to UPDATE, which is not part of core. OK, so another difference is "the DAV:predecessor-set versions of a version MUST show up in a DAV:version-history report containing that version, while the DAV:precursor-set versions MUST NOT show up in a DAV:version-history report containing that version. Frankly, it looks like "precursor" support is yet another option, or part of the UPDATE option. It's important for the client to know if it's supported or not (to know whether an missing/empty value of precursor-set is meaningful or not) but it's optional. Thus, it's an option. If you want to know whether the property is supported by a given resource, you can use the DAV:supported-live-property OPTIONS request. If it is supported, then a core versioning server MUST set it whenever there is a copy into that resource. Again, this is no different from auto-versioning behavior. You have to check the DAV:auto-version property of a resource to know whether or not it will have the auto-versioning behavior defined in core. Cheers, Geoff
Received on Sunday, 4 February 2001 16:51:12 UTC