RE: Core versioning issues and nits

> > 14) (DAV:initialize-precursor)
> >
> > "(DAV:initialize-precursor): If the source of the COPY
> > was a version and if the destination of the COPY supports
> > the DAV:precursor-set property, the DAV:precursor-set of
> > the destination MUST identify that version.  If the source
> > of the COPY was a version-controlled resource, the
> > DAV:precursor-set MUST identify the DAV:checked-in or
> > DAV:checked-out version of that resource."
> >
> > We don't understand this paragraph at all.  We don't know
> > what a precursor is, or what to identify, or what this
> > is doing in CORE.
> > Please move this entirely out of CORE.
>
> If I can answer by referring to my question...
>
> My question was:
>     "Why are we required to make this distinction between
> predecessors and
> precursors?"
>
> The answer was:
>     "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.  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".

Also, your explanation refers to UPDATE, which is not part of core.

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.

Lisa

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