Issues from the May 25 Design Team meeting
From: jamsden@us.ibm.com
Date: Fri, Jun 30 2000
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525690E.005B7DC3.00@d54mta02.raleigh.ibm.com>
Date: Fri, 30 Jun 2000 12:42:07 -0400
Subject: Issues from the May 25 Design Team meeting
Here's the issues from the May 25 DeltaV design team meeting. Sorry about
getting these out so late, I've been on vacation.
- Discussion of the REPORT method. Text needs to be added to motivate the
need for these reports (e.g., getting a history listing for a version tree,
for DAV:property-report). Another scenario is getting a couple of
properties off of just the predecessors of a particular resource in a tree
that has a lot of revisions. The example for REPORT should have a
description that lists, using ASCII art, the revision history that is being
listed in the REPORT result. Discussion on making the marshalling for
REPORT
more consistent with PROPFIND. Discussion on whether REPORT should be
optional. Discussion on how to add new reports in the future. Should
property report be handled by extension to PROPFIND? Take to mailing list.
- Can a server specify if PUT creates a versioned resource revision or not.
Agreed yes, but Chris wants to have client control with failure if server
can't support.
- Some discussion on the marshalling & name of the SET-LABEL-TARGET method.
Several people preferred to revert back to the name LABEL, which is applied
to a versioned resource with the revision picked using a Target-Selector
header. Discussion of using Depth with SET-LABEL-TARGET to set the label on
all revisions in a collection. Need to define the interaction with Depth.
Add an example showing what happens when a label is deleted. What response
should removing a content return on success (200 OK). Issue results from
multiple possible user views - taken from the versioned resource, or taken
from the revision.
Leave it as it is, and reraise the issue on the list. If method takes
versioned resource, can't use revision URL to set a label. That's OK.
Advanced versioning issues:
- Issue: is it possible to have workspace-private unversioned resources
(for
example .o files, or other intermediate compilation files, created during a
build). This issue was discussed, but was not resolved. One of the
difficulties for DeltaV is the fact that workspaces are viewed as filters
on
the same portion of the namespace, as opposed to projections into different
sections of the namespace. When workspaces are projections, then having
unversioned, uncontrolled resources in a specific projection does not
affect
any other workspace/projection. But, when everyone is sharing the same
portion of the namespace, it is possible that people's unversioned objects
will end up overwriting each other. For example, since people are sharing
the same portion of the namespace, then the .o files created during
different user's compiles will overwrite each other.
Workspace is a collection that must be able to contain unversioned
resources - that's how you get things in them. The URL has the workspace as
a resource. (Don't know that workspace target selector would mean).
Baseline is a copy of the workspace that can't be changed. (i.e., a
revision of a workspace). Workspace contains map of versioned resource
relative URL segments (members of the workspace), to revisions. Need a way
for a baseline to be able to reconstruct the namespace structure of the
versioned resources in the workspace.
- server side merge, merge states
- Is it server defined whether a PUT creates a versioned resource in a
versioned collection?
No resolution. Chris want's client to override policy and have server fail
if cannot perform the operation. This will require a new header on effected
methods.
- Issue: can versioned collection revisions contain non-versioned
resources.
- Issue: can baselines contain non-versioned resources.
- Do we need any other reports? If so, how should the available reports be
extended?
- Do we need to introduce branches.
Don't seem to need them. Activities provide more capability. Chris will see
if there's a scenario he wants that activities don't support.
RESOLVED:
- Need to constraints on what characters can appears in an id.
- Need to describe how ids are marshalled into a header
- May need to separate labels from ids, since they may end up being handled
separately.
- Need to explicitly state whether ids and labels are case sensitive,
and/or
case preserving. Tentatively in favor of requiring case preservation. Will
take this to the list. Concern that we need to be consistent with URL
behavior. Recommend case preserving.
- Need to state how whitespace is handled, especially for ids and labels
marshalled within XML
- Discussion of DAV:label-set. Issue: should the maximum length of the
header be specified? HTTP is silent on the length of headers. There is the
related issue of whether to restrict the length of labels. Discussion on
whether it should be possible to discover the maximum label length. Raised
the issue of whether there should be an error response for label too long
on
setting a label. Possibility to report the maximum length allowed in an
error response to setting a label. Some reports that automatically
generated
labels can be long, and can run into label length limitations.
No specified maximum lenght or report providing server restrictions.
- Issue: need for a destination target selector for use with diadic methods
(copy/move). With copy allowed, there now is a need for a destination
target
selector.
Destination target selector was added.
- Can you version a locked versionable resource. No
- Issue: need to introduce an option for overwrite, overwrite="update",
that
allows copying of a source to destination with update instead of delete and
put.
Agreement to put the description of this into an Appendix that states that
the functionality will be added into the WebDAV spec. once it is moved to
draft standard status.
- Discussion on whether a label should be able to automatically propagate
(or "float") to the latest revision upon checkin, so as to simulate
"latest"
revision selection. General sentiment against adding this feature.
Agreed to add DAV:latest target selector based on checkin date. Server may
fail if it doesn't support reasonable dates.
- Some discussion that there needs to be a new name for "private" checkin
option. New wording needed for DAV:private (express using positive language
"if DAV:private option is set then...") e.g., dont-update-default.
- VERSION vs. CHECKIN: topic noted for future discussion
Agreed that VERSION is ok as long as VERSION on an already versioned
resource is not an error. The reason for this is to simplify clients for
situations where servers may automatically create versioned resources on
PUT.
- Can we checkout using a revision URL.
Working resource id you get back needs to be applied to the versioned
resource URL, not the revision URL. Doing a checkout on the revision URL
would require the revision to have a backpointer to its versioned resource.
Sense of the room is that it should not be allowed. But the spec should not
rule it out. Servers should disallow it.
- Replace working resource with working revision. There are a number of
properties and behaviors of a working resource that make it not a revision.
e.g., it does not have a revision id, and the working resource id has
different semantics. Resolution: continue to user working resource and
attempt to unify the syntax and semantics between revisions and working
resources where it makes sense.
- Discussion about, for linear versioning, whether it is possible to check
out from other than the tip version. Concerns: want to track that the
checkout occurred from a specific revision, and this wouldn't be possible
if
you check out the tip, then get the previous revision, then check in to the
tip. Agree, multiple checkouts are allowed. Checkin must result in a linear
history. This implies that clients must be responsible for client-side
merge before checkin.
- Chould have an option to fail a checkout or checkin to fail if would
result in a branch.
- Should depth be allowed on SET-TARGET, LABEL? Best effort?
Yes
- How is the Target-Selector used for depth operations? Like all other
depth methods, all headers are applied to all effected resources.
- Discussion over what happens when a Target Selector is used to select a
specific resource, and that resource is dynamic, and during its dynamic
operation, it retrieves other resources. Should the value of the Target
Selector be used to select a revision of those other resources? Or should
the default target be used instead. This is related to the issue of, when
there are versioned collections, and there is a path specified, what should
the scope of the Target Selector header be? Should the Target Selector
(using something other than a workspace as a selector, since workspaces do
specifiy the revision of the collections) affect every collection in the
path, or should it only affect the leaf node, with interior nodes selected
using their default revision. Agreed to delete the last sentence of section
2.2. That is, what resources is the Target-Selector applied to in
processing a request?
By default, the Target-Selector is applied to all versioned resources
encountered in the request, including those in entity request bodies. New
entity request bodies (i.e., SEARCH for DASL) may include more complex
href's that include a Target-Selector element that overrides the default.
Another alternative to consider is to use the default target selector.
- Discussion on whether a versioned resource should have a stable URL as
well. Currently a versioned resource can only be accessed by using
Target-Selector header.
Yes.
- Should a working resource have a stable URL.
Yes.
- Do we allow a structured versioned resource type?
No.
- Discussion of extensibility of options for checkin and checkout. Need to
add some general language stating that these can have extra elements added
to them in the future. General issue of when to ignore unknown elements,
and
when unknown elements cause method failure. How are unknown XML elements in
entity request bodies handled? Do they ever cause the request to fail.
WebDAV and XML extensibility currently specify they are ignored. Agreed to
add some mechanism (an attribute) to indicate that an element is manditory.
- What does it mean to delete a versioned resource?
Just means the member is removed from the parent collection. No statement
about what happens with respect to garbage collection. May result in broken
references in workspaces and baselines.
- Is it possible to delete a revision? If so, what effect does it have on
predecessor/successor properties, target selection for a workspace, default
target selector for the versioned resource, activities, and baselines.
What happens to the history? Could allow it and leave broken links. But
then couldn't use links to recreate history. Could just marked deleted and
not show in history. Could copy all predecessor links to successors. But
this would be a lie. Can't delete if there are merge links, or it is a
member of a baseline or a workspace. Could allow delete when no successors
(tip only). (Someone checked in a version with a virus). Could leave this
as an out of band administrative function.
Can fail the delete. If server supports delete, spec doesn't say what
happens. May result in broken references and partitioned histories. Delete
has to be done through revision URL. Using versioned resource URL and
target selector would remove the versioned resource from its parent
collection.
- Is the property report optional? Core versioning must provide an
efficient mechanism for providing a history report. Property report is not
a minimal way to do this.
Agree that there will be a history report, not optional. Property report is
optional.