Current WebDAV Versioning Issues

jamsden@us.ibm.com
Tue, 5 Oct 1999 12:20:09 -0400 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256801.0059C8DA.00@d54mta03.raleigh.ibm.com>
Date: Tue, 5 Oct 1999 12:20:09 -0400
Subject: Current WebDAV Versioning Issues



Here is the set of issues that came out of our last design team meeting (end of
May in Concord). Many of these issues have been resolved, but perhaps we should
give them a quick review to make sure they are in the updated versioning spec.
Also, let me know if there are any new issues so we can formulate an updated
list for the Washington IETF Meeting.


Issues/Actions for next rev of spec:

DONE: Do one method completely to show the method template and establish an
expectation for all the methods.

IN PROGRESS: Add the template to all other methods, but it is not necessary to
fill them all in for the next revision of the draft. (Target completion of
initial pass through all methods by October deadline for IETF submission).

DONE: Decide on leveling, especially as it effects spec organization
More levels? optionally functionality? delete optionally functionality and let
servers add it? The issue is that level two is too hard to do in a scalable way,
or is not required by most users so there won't be many servers that will ever
implement it. Jeff: define base versioning and have each additional capability
be optional. This could result in combinatoric expansion of client
implementations. Each feature would need to be orthogonal to make this
tractable. Decision start with DAV versioning core (what's currently in level 1)
with options:
   - extended workspaces (with modifiable revision selection rules)
   - activities
   - configurations
   - versioned collections
   - baselined collections: requires configurations and versioned collections
   - merging: requires extended workspaces
   - compare/reporting: requires configurations as defined
   x checkin policy: discovery is in level 1 and all entries are always optional
   x collections behind "property collections": discovery information must be in
level 1 anyway

Resolve use of '-' in property name and terminology
Property names should look like DAV. See if the mailing list cares if '-''s are
used in property names. The documents should not use words in inconsistent ways
whether they are hyphenated or not. Use proper English conventions for -'s in
the document.

For the property collection issue, is there one property with an href to the
collection, or separate properties
Why are two ways to get this information required? There is a set of information
we want to get and sometimes edit. For example the merge-predecessors of a
resource. This information is accessed through properties. Accessing the
properties returns an XML document containing the data. for example:
  <predecessors>
      <predecessor href="..." revisionId="..."/>
  </predecessors>
This has all the information needed and is extensible and internationalized.
Modifying this requires lock, propfind, proppatch, and unlock, lots of round
trips. Document may be large, and editing through DOM is an issue. But it is
easy to return to the client and display. Solve these problems by introducing a
property resource to identify a resource that captures the same information and
is edited with existing collection and resource editing mechanisms.
  <predecessors>
      <property-resource>http://server/repo/aa/bb/</property-resource>
      <predecessor href="..." revisionId="..."/>
  </predecessors>
or double the number of properties
  <property-resource>http://server/repo/aa/bb/</property-resource>
  <predecessors>
      <predecessor href="..." revisionId="..."/>
  </predecessors>
Edit by adding or removing bindings in the collection. No need to lock because
bind is atomic. Limits the number of round trips. Allows PROPFIND to get
extended information. Having both is not necessarily redundant data. These are
just different representations of the same data. Resolution is to present and
manipulate the data through both views, and see if the mailing list members
prefer one or the other or both. Use a header to select which view to return.
Never return both. Propfind allprop returns the default which is the XML
document.

DONE: Decide on name for selected revision (target). Resolution: keep target but
define it a little better. Overview should introduce it.

How is server versioning meta-data discovered? Properties on a distinguished
collection? On '/'? With OPTIONS?
Consider two approaches: implicit property on all resources, or OPTIONS on a
resource or *. Properties can be structured, options can't. Could consider
extending options to take and return an XML request/response body. Use PROPFIND
semantics to specify the body. Options exists because properties didn't. OPTIONS
* is the only way to talk to the server. Everything else is to a resource.
Resolution: use OPTIONS with PROPFIND entity request body on * for server and
resources for meta-data on resources. Returns server/versioning meta-data. Don't
want this information on allprop. Provides extensibility for OPTIONS. Geoff
wants to use a repository object so it can be a resource to provide
extensibility. Want to put in the repository: workspaces, activities, history
resources, configurations, ...? Discover the location of the repositories from
OPTIONS *.

DAV:checkout-discovery vs. DAV:workspaces: what is the name of the property and
what is returned. Two questions: 1) what workspace is this resource checked out
in, and 2) that resources are checked out in this workspace? DAV:resources
answers 1, DAV:checkout-discovery answers both. Resolution: do
DAV:checkout-discovery, Geoff will see if there are any problems.

Decide on a name for the versioned resource as a whole, currently called a
history resource. Use the new name in the *-id property names.
Resolution: use resource, revision, and versioned resource instead of versioned
resource, revision, history resource. In cases where it the resource must be a
revision, note it.

compare vs. generic report. Chris's suggestion: REPORT is a method that has a
request URL. URL determines what the report is on. Entity request body specifies
report type and any additional required parameters. Entity response body is
returned. Have some way to discover what reports are available. Only server
implementer can extend report types. Specify a report type for compare. Probably
should be doing history this way too. Don't use it for something that can be
done with a PROPFIND. That is, there are not executable semantics associated
with the report type that need to be calculated. Looks like there is some
overlap with this and PROPFIND. Reports need to be read-only, require
calculation, need parameters, don't need to be searched with DASL, etc.
Otherwise use property. Use a property unless you can't. Consider using DXML for
a formalized, extensible way of handling reports and other behavior.

Can servers restrict where resource types can be mapped? Workspaces, activities,
etc. If so, how do we find them? (Related to OPTIONS/repository/meta-data
properties issue) Can servers deny BIND to them? Can users create these
resources (with MKRESOURCE) in their namespaces and the server creates its own
binding for its own use? Geoff will see if this restriction is required.