RE: Core versioning issues and nits

> > Also, what's the meaning of these on the VCR, vs the
> > same properties on the version?  Why do you need these
> > properties on a VCR when they're already on the version?
> > (Do these belong in CORE at all?)
>
> On the version-controlled resource they are essentially properties
> 'in-waiting', their true value is apparent when they are
> applied to the
> version created by checking in the VCR.  (Though the
> predecessor/precursor
> is still valid on the VCR itself, just that the values may be
> modified by
> the client to reflect their view of the resource's history.)

"Predecessor-set" makes decent sense.  Of course for simple versioning
servers this will be a protected and computed property, single-valued
(that value being the URL of the previous version).

However "precursor-set" doesn't make sense in core, if it in fact makes
sense anywhere.  Why is the client supposed to put values in
precursor-set?  Is the server expected to validate those values?  What
use is supposed to be made of this value?   If the client isn't forced
to fill in this property when copying content, how are other clients
expected to be able to rely on the property being meaningful?  I don't
see that the server is expected to calculate a value either, although
theoretically it could if a COPY was performed.

Basically, if the "precursor-set" property can be empty either if there
were no precursors OR if the client ommitted to correctly set this
property, then it's not useful -- other clients can't tell if the empty
property is meaningful or not.

Isn't this just a dead/custom property, therefore no need to
standardize?

If it's legal for "precursor-set" to be unused, then I predict it will
remain unused on many systems.

lisa

Received on Friday, 2 February 2001 15:10:48 UTC