Next message: Geoffrey M. Clemm: "Re: DAV:version-set"
Message-Id: <200009222349.TAA09892@tux.w3.org>
Date: Fri, 22 Sep 2000 19:48:00 -0400
To: ietf-dav-versioning@w3.org
From: Ross Wetmore <rwetmore@verticalsky.com> (by way of "Ralph R. Swick" <swick@w3.org>)
Subject: Re: Comments on draft-ietf-deltav-versioning-08
[freed from spam filter -rrs]
Date: Fri, 22 Sep 2000 12:30:09 -0400 (EDT)
Message-ID: <39CB890F.6E2E758F@verticalsky.com>
From: Ross Wetmore <rwetmore@verticalsky.com>
Organization: Vertical Sky Canada, Inc.
To: ietf-dav-versioning@w3.org
References: <39C76F6A.9AB4F2C7@verticalsky.com>
<200009200341.XAA16472@tantalum.atria.com>
I apologize if this has taken longer to get back to than anticipated.
I have trimmed the original significantly but left some tags under
the assumption that the original is archived for reference to the full
context.
Many thanks, Geoffrey for the detailed explanations and patient
corrections where I wandered off the beaten trail.
Cheers,
RossW
=====
"Geoffrey M. Clemm" wrote:
>
> From: Ross Wetmore <rwetmore@verticalsky.com>
[...]
> The intent was for RFC-2616 (HTTP-1.1) and RFC-2518 (WebDAV) to be
> required reading, and then the sections in this document are marked
> indicating whether they contain "new stuff" or "effects of extensions
> on old stuff". Can you give an example of some places where it was
> unclear what was base material, and what was extensions?
When the whole of HTTP and WebDAV context are assumed, rather than
at least some indication of which element or section is applicable to
a given point, then terseness can introduce significant ambiguity which
may confuse those not sufficiently experienced to winnow down, or with
insufficient mental capacity to hold the whole. Your response to the
reference to 16.8 in 8.1 (restriction to a single version selector per
workspace) shows that even when localized, ambiguities can lead to
problems in understanding.
But I bow to the strong desires to limit introduction of any material
that is dealt with elsewhere, and make this document a supplemental part
rather than a standalone entity. :-)
[...]
> You should be able to get much of the optimization you need from
> the HTTP-1.1 ability to keep a connection alive.
If conditional execution or rollback is required, then one is limited
to complete network turnaround between operations, plus the added burden
of additional checks to make sure that overlapping operations have not
modified the underlying state, or for 3rd parties, that they have not
picked up partial state for a composite operation. This is significant
overhead vs a BATCHed atomic operation and is not helped by keep-alive.
This is personal opinion, but the excellent work of reducing the problem
to small well-defined operations may produce an unusable system if there is
no indication of a standard corresponding way to reassemble such operations
into a larger atomic unit of execution. My feeling is that this
reconstruction
aspect is missing in the current document and may cause significant obstacles
to implementation/acceptance.
Is there the intention to have such issues be addressed in a broader context
or a supplement to this suppplement? Or is it the collected wisdom that these
are not (at least immediately, or without further experience) issues for
concern?
> =====
>
> Section 4.1
>
> There are efforts such as the Dublin Core work, to identify standard
> properties. Should WebDAV properties be selected to conform with such
> systems wherever possible to maximize recognition?
>
> Any particular suggestion for how we might make them conform better?
>
> Which is the precise concept desired here for creator-displayname
> author or owner, (content or object) creator?
>
> It's intended to be resource (object) creator, but in the case of
> a versioning system, where each new interesting state is stored as
> a separate resource (a version), the distinction becomes fuzzy.
In this case "creator" carries the semantics of "content creator". There
is not a good match for "object owner" though "publisher" comes closest. It
appears that "creator-displayname" is actually the wrong connotation. For
the versioning history object "owner-displayname" might be better.
[...]
> =====
>
> Section 8
[...]
The explanations here were very helpful, many thanks.
To summarize my understanding, it is possible to automatically share
updates by using a common version selector. If two version selectors
point to the same version, then the second will only see changes from
checkin of the first after a merge is performed. A working version may
be checked out through a version selector to a new Url (if the target
version was selected by 10.2 checkout <target>), or the version selector
may be checked out in-place. If checked out to a new Url, it is the
responsibility of collaborating processes to pass the Url of the working
version for any shared updates. If checked out to a new Url, the version
selector will be unaffected and still contain the contents and dead
properties of the original version until the working resource is checked
in (can the working resource be checked in through the version selector?
or must the version selector be explicitly updated after working resource
checkin?). If a version selector is checked out in-place, it in effect
becomes the working version. It will have a "checked-out" property pointing
to the original target version and the original target property will be
missing. It will be automatically updated on checkin to remove the
checked-out property and restore the target now pointing to the new version.
> Each workspace has its own set of version selectors (so they don't
> redirect through a common version selector).
This raises further questions about collaborative sharing of versioned
resources. Let me try to setup a scenario to illustrate.
If there are three teams sharing a common set of resources, one can
draw overlapping circles to represent the "workspaces" which define each
team's conceptual set of interest. In the general case there will be
resources shared by all, shared by each of the 3 pairs and 3 not-shared.
Each team may have more than one workspace: headrev (for live changes),
latest build (a consistent set of resources) and qa-approved (a tested
set of consistent resources). Ideally, one would like to consider the
latest-build and qa-approved sets in each team as workspace versions or
baselines of each headrev workspace. For the moment, consider only headrev
in which all teams automatically share any new versions.
How might the headrev workspaces for each of the 3 teams be setup if
version selectors cannot be shared? Does this mean that one must setup
appropriate combinations of 7 sub-workspaces? If so, what does this mean
when a team decides it wants to add or drop a resource from its headrev
workspace, i.e. will it have to move from one of the sub-workspaces to
another?
This is a reasonably common scenario, but I don't really see how the
current proposed standard would handle it. What have I missed?
[...]
> =====
>
> 10.6
To clarify "There is no corresponding pre-condition 'cannot move label'"
the unstated implications are:
Apart from version selection errors, a "set" command always succeeds. It
will delete any current label if present (but not require one) and apply the
new label to the indicated version.
Correspondingly, an "add" performed twice in succession is guaranteed to
produce an error on the second application, even though the new label is
that of the version to which it is applied.
Are these interpretations correct?
[...]
> =====
>
> 14.6.1 (also 17.3)
These are much clearer in 8.2. The description of workspaces and baselines
to include references to collections aspects makes it less of an intuitive
leap to fill in the gaps. The difference between a collection version selector
and corresponding collection version in the history is also key. Again,
thanks.
[...]
> =====
>
> Thanks for the great review, Ross! Please follow-up if anything
> is still unclear. I'll try to get an 8.2 draft out soon, with
> the changes based on your review.
>
> Cheers,
> Geoff