Re: Core versioning issues and nits

> I've had a fresh pair of eyes (thanks Barry!) look at
> the core versioning sections of
> http://www.webdav.org/deltav/protocol/draft-ietf-deltav-versioning-12.ht
m,
> and here is the list of issues -- often things which a
> pair of reasonably intelligent folks couldn't reliably
> infer from the draft, or things in core which refer to
> or require things outside of core.

Always good to get fresh eyes looking at it, ... but only 'reasonably'
intelligent<g>.

> 1) URLs
>
> One fact: The draft currently defines versions, version
> histories, and version-controlled "things" as resources (not,
> for example, as URLs).

Agreed. As resources they can have properties etc.

> One more fact: The definiton of resources in 2518 states
> that a URLs which differ only in their parameter set MUST
> refer to the same resource.

This is reasonable.

> When I add one and one together,
> my value for "two" is that it's illegal to take a base
> URL to refer to a VCR, and add parameters to get individual
> versions and VHRs.

My 2 equals your 2<g>.

> That would mean we cannot have URLs of the form (partial
> URLs shown only):
> VCR:    /lisa/index.html
> VR:     /lisa/index.html?version=1203987150
> VHR:    /lisa/index.html?version=version-history

I agree with your observation.

> That would mean we must use URLs like:
> VCR:    /lisa/index.html now
> VR:     /__versions/lisa/index.html__1203987150
> VHR:    /__vh/lisa/index.html
>
> The draft ought to state clearly whether parameterized
> URLs are acceptable or not as URLs for VRs, VHRs.

The draft typically will not restate information that is already in other
standards, but will refer to them, rely upon them, or extend them where
necessary.

> IMHO, it would be perfectly fine to use parameterized URLs
> to refer to versions and VHRs.  Yes, it's ugly, but it's
> less ugly than the alternative.

IMHO it would not be fine to break the semantics of existing standards
(people rely on this stuff).  Beauty is in the eye of the beholder.

> (BTW, he second class of URLs above is clearly only
> suitable for automated access in some fashion, not by
> somebody typing in the URL.  I

I would no more like to type
     /lisa/index.html?version=1203987150
than
      /his/23/ver/42

the version URLs are not meant to be human readable.

> can't think of a good way to make them prettier without
> using up valuable URLs that users might want for other
> purposes.

I guess that I'm of a different opinion -- namely that URLs are cheap and
not in danger of being all 'used up'.  The spec. explicitly allows
versioning metadata to reside on other hosts, so you can (dare I say,
easily) virtually host the metadata in it's own URL namespace without
impinging on the creativity of clients.

> I know I've covered this in earlier mails, but I'll
> repeat: I'm unhappy with that, it would be nasty to
> force all implementations to have rather ugly URLs,
> by the combination of requiring non-reusable version
> URLs and not allowing parameterized URLs.  Failing
> changes along those lines, does somebody have a
> better legal suggestion for pretty URLs?)

I'm out of the competition because I don't want pretty URLs.  My clients
will ultimately identify versions by their version names, comments and
contents not by URL.  (They will typically get to the versions via a VCR
with a meaningful name.)

> 2) Versioning of Properties
>
> We need a kind of property that applies to all versions,
> or to put another way, properties that apply to the
> version-controlled resource itself.  For example, the
> "owner" property maybe ought to apply to the whole shebang:
> when you change the owner, the new owner has to be responsible
> for everything, from the first version to the last and
> including the version-controlled resource and version history.

The version history refers to all the versions, and so that would be the
natural place to put the creator display name of the 'component' owner.

What would be the meaning/role of a resource that refers to all the version
history and all the version-controlled resources?

> Other properties might change every day, and we don't
> necessarily want to create a new version of the document (a
> copy of the body??!!) every time that property changes.  One
> way of dealing with this is to make the frequently-changed
> properties apply to the VCR.

Agreed.  If you don't want to capture these properties in a version then
they are better placed on a version-controlled resource.

> This doesn't seem possible with the current draft, because
> PROPFIND and PROPPATCH methods applied to the VCR's URL are
> interpreted with respect to the default version.  This is
> related to "passthrough" issue which I'll bring up in another
> email.

I don't understand this comment.  PROPFIND and PROPPATCH applied to a
version-controlled resource get/set properties on the VCR directly (the
exception to this being if a Label: header is specified).

I'm eager to see the "pasthrough" issue...

> 3) Definiton of Version History Resource
>
> The draft states 'A "version history" is a resource that
> contains all the versions of a particular version-controlled
> resource.'
>
>  - What does 'contains' mean?

Good question, I also raised this because I also dislike the word
'contains' here.
Geoff's answer was "We've defined the deletion of a version history to
result in the
deletion of all versions in that version history, so I think "contains" is
better here.".

>  - How does this mesh with later implications, that there can
> be more than one version history resource for a VCR?  This
> may be a misunderstanding however please clarify.

A version-controlled resource can only be associated with a single version
history.  If there is something that implies otherwise please call it out.

> 4) The existence of version history resources
>
> Section 2.1.1 "In core versioning, a version is exposed
> as an HTTP resource with a server-defined URL, but a
> version history is exposed as an HTTP resource only when
> the server supports the version-history option (see Section 5)."
>
> Section 2.4: "If the request-URL identifies a versionable
> resource, a new version history resource is created."
>
> Do core versioning servers need to create VHRs and not
> expose them, or not create them at all?  Please clarify
> that core need not create new version history resources
> at all :)

<g>  If a core versioning server created/did not create a version history
resource and didn't expose it, how would you know?  If a tree falls in a
wood ...<g>

> 5) Definitions of precursor-set and predecessor-set
>
> These definitions are circular.  The predecessor set is
> defined as containing the set of predecessors.  This
> does not define what a predecessor is, or how it is
> different from a precursor (aren't they more or less
> synonyms?).

The terms "predecessor" and "precursor" are defined in Section 1.3 Terms.
They are semantically very similar.

> 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.)

In as much as the concept of version history belongs in core, these
properties are correctly defined there.

> 6) DAV:version
>
> I think somebody already pointed out that the DAV:version
> property was redundant since it only contained the URL for
> the version it was on...

Yep.

> 7) How do you distinguish between:
>  - A versionable resource
>  - A non-versionable resource
>  - A version-controlled resource
>
> Let's say the client wishes to present a simple UI which
> lists all the resources in a collection, and can tell
> what each resource is, allowing operations like "show me
> the version history" or "turn versioning on" to be
> available only when appropriate.  How, exactly, is this
> accomplished?  What property is retrieved?

Good question.
A versionable resource will answer with (at least) Allow: VERSION-CONTROL
to an OPTIONS request, a non-versionable resource will not.  A
version-controlled resource is the only resource with a DAV:checked-in or
DAV:checked-out property.

There was some debate a while ago about making the resource types explicit,
with various methods sugested.  I have to say that determining type by the
presence or absence of properties is sub-optimal since, among other things,
it makes for careful consideration when defining new resources with
overlapping property names.

> 8) Clarify status reporting functionality early
>
> The document uses the headers "Postconditions" and shows
> strings like "DAV:put-under-version-control", throughout
> the document.  However, the way status reporting is handled
> is only explained very late in the document.  Please explain
> this early on.

It is defined in Section 1.4 Notational Conventions before any
pre/postconditions are defined.

> Also the draft MUST define for each response string, what
> numerical HTTP response code MUST be used in the response
> header.  Don't leave this up to variation among implementations.

Hey, I thought of that too!
See
http://lists.w3.org/Archives/Public/ietf-dav-versioning/2000OctDec/0142.html
for the put-down (only kidding!)

> 9) What is DAV:checkout-response
>
> The definition of the "DAV:already-under-version-control"
> status message (er, I mean 'postcondition') uses the
> "DAV:checkout-response" element.
> That's not part of core.

Good catch, I suspect that is a typo. -- it should of course be
<DAV:version-control>.

p.s., the postconditions are not equivalent to status messages, they are
statements that MUST hold true after the method has ben applied to the
resource.  If the postcondition cannot be met then the corresponding status
code is reported as an indication of the cause of failure.

> 10) Interactions between LOCK and VERSION-CONTROL
>
> State whether a locked resource can be placed under
> version-control, and whether the lock-token must be supplied
> with the VERSION-CONTROL method.

Sounds reasonable.

> 11) Interaction between existing headers and new methods
>
> What happens when Depth is applied to the VERSION-CONTROL
> method?  It seems that this is being addressed in a mail
> thread, but the specification must define the behaviour.
> What exactly happens if anything in the scope can't be
> turned into a VCR?

My vote is for Depth: to be ignored for VERSION-CONTROL, but as you say
this is being debated on a separate thread.

> Or Depth and the REPORT method?  Is Overwrite header
> ignored on REPORT?
> FOrbidden?

Depth and report is defined in Section 23.4 (in revision -12).
Since REPORT is defined as read-only Overwrite: will have no effect.

> What about existing HTTP headers such as Chunked-encoding
> and MD5?  Do any of them apply?  Are they ignored? Forbidden?

They will all retain their defined meaning without modification.

> 12) Version-tree report
>
> In 2.5, the version-tree report is required to be a
> "DAV:multistatus".  The response could for that could
> reasonably be 200 Success or 207 multistatus.  Your
> example shows 200.  Please state normatively, which
> response code is required.

Another good one, I think that should be 207 Multistatus.

> 13) Root versions
>
> In 2.9, the root version of a version history "must
> not be deleted".  Why is that?  This seems like an
> implementation issue, not a protocol/interoperability
> issue.  Please leave this issue up to the implementation
> to decide whether or not to allow deletion of old versions,
> and how to deal with any subsequent rearrangements that
> might be necessary.

I queried this one too

The principal author writes:
"Then you lose a key semantic of a version tree, namely it is connected
and every version is reachable from the DAV:root-version.  I don't see
that the benefit of allowing deletion of the root version outweighs the
benefit of have the version tree be connected."

> 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)."

> 15) Version-history-is-tree
>
> "(DAV:version-history-is-tree): If the request-URL
> identifies a version-controlled resource that was
> automatically checked out because DAV:auto-version was
> DAV:when-locked, then the versions identified by the
> DAV:predecessor-set of the checked-out resource MUST
> be descendants of the root version of the version
> history for the DAV:checked-out version."
>
> What does locking have to do with whether the versions
> must be descendants of the root version?  Wouldn't
> this also apply when doing autoversioning when unlocked?
> We don't really understand this paragraph.  Again, we
> wonder what this is doing in core.

I don't understand this either.  Given that the root version cannot be
deleted to maintain connectivity, surely all versions are descendants of
the root version.

> 16) New definition of Overwrite
>
> Please clarify the new definition of Overwrite.
>
> If you COPY directory 'mydir' with 'mydir/foo' and
> 'mydir/bar' to a directory elsewhere with 'mydir/baz',
> do you end up with a directory at the destination with
> TWO children, or THREE children?  In other words, do
> resources at the destination which do not overlap
> resources from the source get deleted?
>
> I prefer 'no', btw.

No, they do not get deleted.

> 17) OPTIONS supported-method-set
>
> Section 23.6:  this defines 'supported-method-set',
> but in fact there's already a header that expresses this.
> How are you dealing with that redundancy?

In a separate mail thread!

Thanks for the comments, I hope my answers were not too flippant -- I'm
just in that kind of mood today.
For those points where I was able to give a satisfactory answer I strongly
encourage you to add a Q&A to the Delta-V FAQ
(http://www.webdav.org/deltav/faq); where I didn't please set me right, on
the list.

Regards,
Tim

Received on Friday, 2 February 2001 07:11:34 UTC