W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Minutes Delta-V breakout meeting 13-Dec-00

From: <Tim_Ellison@uk.ibm.com>
Date: Thu, 14 Dec 2000 13:07:30 +0000
To: ietf-dav-versioning@w3.org
Message-ID: <802569B5.0049F711.00@d06mta07.portsmouth.uk.ibm.com>


Delta-V Design Group Meeting
IETF San Diego

9:00 am - 3:00 pm
Wednesday 13 December 2000

Attendees:
    Jim Amsden (IBM Raleigh)
    Geoff Clemm (Rational Software)
    Tim Ellison (IBM UK)
    James Hunt (Universitšt Karlsruhe / FZI)
    Eric Sedlar (Oracle)

[Note: section references are based on draft-ietf-deltav-versioning-10.9]

Set and agreed on agenda:
  1.   Review changes that have been made to the protocol document since
       the last submission.
  2.   Review items raised by Yaron Goland conveyed by Geoff.
  3.   Review changes raised by Greg Stein (working collections, checkout
       in a baseline).
  4.   Help define the criteria for setting levelling.
  5.   Discuss the use of XML and DTD's/XML schema.
  6.   Ordering of set properties (e.g., successors, ...)
  7.   Why are change sets and branching are both modelled by activities?
  8.   Use of labels vs. baselines for configurations.

The group went through the list of changes since the last Internet draft
(section 21)

"Moved version-controlled resource DAV:predecessor-set property to core.
(Boris)"
Reviewed and agreed.

"Made label support optional. (Lisa)"
Debated why labels should not be in core -- primarily because it is not
required by
document management systems, and it is not viable in distributed
disconnected
implementations.  Agreed that it should not be in core.

"Removed Workspace header (Geoff)"
Discussed why the workspace header is problematic.  The problem is
illustrated by the
use of absolute URLs embedded in documents (i.e., links).  When resources
are in
workspaces it is usual that the absolute URL should be interpreted relative
to the
workspace.  The workspace header was proposed to provide a prefix for all
URLs in the
request.
However, not all URLs should be interpreted relative to the workspace.  For
example,
version URLs would not be interpreted relative to the workspace.  The
server has no way
of knowing when a URL is workspace relative, and when it is root relative.
It was proposed that the server should be able to recognise a URL as a
server generated
URL and thereby not interpret it workspace relative (not apply the
workspace header),
however, it was agreed that we cannot dictate that the server allocate a
fixed part of the
namespace for version URLs.
It was recognised that this means that server side includes will not work.

"Added DAV:must-not-be-checked-out precondition for LABEL (John)"
Agreed.

"Only require Multi-Status if there was an error in a Depth operation (e.g.
LABEL and
SET-TARGET). (John)"
Briefly discussed using multi-status only if there was >1 error.  This idea
was abandoned
and the original update was agreed upon.

"Got rid of "parent workspace" for MKWORKSPACE (Tim/Geoff)"
Agreed.

"Added DAV:no-checkout argument to MERGE (Tim)"
Agreed.

"Fixed BASELINE-CONTROL so that baseline (not baseline history) is the
argument
(Tim)
Disallowed checkout of a baseline (only makes sense for a
baseline-selector) (Tim)
Added CHECKIN behavior for a baseline-selector (Tim)
Added DAV:baseline-controlled-collection property for baseline-selectors
(Geoff)"
The proceeding four updates are deferred to a later discussion on baselines
in general.

"Changed "advanced" to "optional", since that is what it means (Geoff)"
Some discussion that 'advanced' sounds sexier for marketing reasons, but
that 'optional'
was more accurate.  Agreed that we should adopt 'optional' but think of
ways to entice
people to implement it.

"Changed the DAV:repository-report into DAV:workspace-collection-set and
DAV:activity-collection-set properties. (Ross)"
In as much as this represents splitting the repository report into separate
queries for
workspace collections and activity collections, this was agreed, but this
is likely
subsumed by a later suggestion for making this information available
through OPTIONS.

"Marked the DAV:supported-xxx properties as "protected". (JimW)"
This is also in OPTIONS and subsumed by a later recommendation.

"Cleaned up bad ANY syntax for the DTD's. (Geoff)"
Agreed.

"Use strings in DAV:method elements to define DAV:supported-methods.
(Juergen)"
Agreed.

"Removed DAV:if-unsupported (use If header when needed) (Yaron)."
The protocol doesn't rely on this behaviour, however, it is considered to
be useful (if
people ever need it).

"Moved the DAV:workspace property from version-controlled resources to any
resource,
since resources other than version-controlled resources can be in a
workspace (Tim)."
Agreed.

"Changed the return status of VERSION-CONTROL on an existing resource to be
200
(Greg)."
Agreed

"Added the impact of DELETE on properties that refer to the deleted
resource (Greg)."
Agreed that any references to the deleted resource should be removed from
DAV
properties.

It was pointed out that for all computed properties (e.g., 'successor set'
defined as the

list
of resources who have this resource as a predecessor) the protocol document
should
mention that any method that affects the resources it is computed from
affects the value
of the property.

"Changed the DTD of all top level request and response nodes to be ANY
(Yaron)."
Defer to a later XML discussion.

"Have version CHECKOUT example use version URL (Chuck)."
Agreed

"Renamed version selector to be version-controlled resource (Geoff)."
Agreed.

"Renamed Target-Selector header to be Label header (Geoff)."
Agreed, and that there would be other headers created if required (i.e.
baseline:, activity:
...).

"Divided optional section into one section per option (Juergen)."
The group liked the idea of splitting the document, however, should the
optional
behaviour document duplicate the information contained in core (so that it
is a stand-
alone document) or should it reference the core document?  Agreed to ask
the mailing list
since there was no consensus reached.

Agreed that we need to add some model description, esp. illustrating the
use of client-
based vs. server-based workspaces.  Will add a section at the end of the
document that
brings the concepts together, with a forward reference to this section
since some people
may prefer to read this section before the terms etc. are introduced.

Various changes to the document were discussed:

2.1.4 Auto-versioning
It was noted that non-versioning clients may receive errors related to
versioning
operations, however, since we are not introducing new status codes, the
clients will
understand the status code as an error, but they won't understand the
extended status
XML body.

2.2 Common property values
Some of these are duplications of RFC2518 and some are new/modified
definitions.
Agreed that this duplication was ok.

Discussed that fact that version controlled resources (VCRs) have different
properties
depending upon whether they are checked in / checked out.  Suggested having
a DAV:is-
checked-in (Boolean) property and reusing the DAV:target property.  Some
people felt
strongly that individual properties (e.g., DAV:target) should not have
different meanings
depending upon resource state.  Agreed to leave it alone.

Discussion of DAV:predecessor-set : why it cannot be used to denote the
checked out
version (e.g., by putting the checked out version URL as the first in the
list).  Clients

can
modify the DAV:predecessor-set because it represents the logical successor
not the
checked out resource.  Clients may remove the checked out version URL from
the
predecessor set and add other URLs (from the same version history).
An example of where this is useful is a server that only supports linear
history, and
clients have branched by checking out the same version.  The second client
to checkin
can do a merge (with the first to checkin) and fix-up the predecessor set
to maintain linear
history.

2.4.3 predecessor set should have a DTD fragment to be consistent with
other definitions.

DAV:version-name property is generally useful for clients, but is not used
in the
protocol.  It is envisaged that it would be used in a PROPFIND type request
rather than
used to 'directly' access the resource (such as with a VersionName:
header).

The overwrite header description may need rewriting to improve its clarity
-- Jim A.
agreed to draft a rewrite.

The body of section 2.8 OPTIONS should explain what the request body is
used for.
Correct "If a request body is included, it MUST be a DAV:options-response
XML
element." to read "if a response body ...".

2.8 supported live properties.  Would like to modify the XML to allow
passing metadata
about the property (e.g., type, whether protected, etc.) by adding another
level of element
<DAV:property-name> around the existing name data.  Agreed.

2.10 PROPPATCH semantics
It was recognised that a versioning aware client may set versioning
properties on a non-
versioning server, and the server would accept the properties (as dead
properties).  It
behoves clients to check the capabilities of a server (using OPTIONS).

DELETE vs. UNCHECKOUT
For a version controlled resource(VCR) DELETE means 'go away' whereas
UNCHECKOUT means 'revert to checked-in (version) state'; for a working
resource
DELETE means 'go away' and there is no equivalent for revert to checked in
state.

2.12 COPY semantics needs similar semantics description to PUT & PROPPATCH
where the destination is a VCR.  (No such change to be made to 2.13).

2.14 REPORT method -- why not just use POST?  REPORT is defined to have
read-only
semantics and so is more likely to be acceptable to proxies/servers who
have security
concerns.  In addition it does not require extending/redefining the
semantics of POST.

2.16 postconditions of CHECKOUT does not describe the effect on the checked
out set
(this is another example of a 'inverse property' that is defined as a
function of other
properties) the effect should be called out explicitly.
Editorial change: now that the document is split there is no need to say
"If a version-
controlled resource was checked out ...".

2.18 UNCHECKOUT also requires the effect on the checkout-set.

2.20 version tree report also should remove "If the report is applied to a
checked-in
version-controlled resource ..."

XML DTD -- we will create a valid DTD for delta-v, and we will strive to
get rid of the
ANYs (retaining them in places where extensibility is explicitly
predicted).  We need to
allow servers to add proprietary extensions to the XML.  Recognised that a
DTD is a
poor-man's solution, and that an XML schema would be more meaningful and
extendable and would allow clients and servers to validate messages.  Could
be added to
an appendix, but we won't hold up the progress of the document waiting for
this.

Ordering of successor list / version tree report
Agreed that there is no need for the server to assure any ordering or
repeatability of
ordering across subsequent request/responses; it is left to the client to
applying any
temporal ordering if this is required.

Brief discussion of activities.  They are used for branching and change
sets by clients,
and are indistinguishable as resource on the server.  Activities can be
used to model
either--interoperably.

Meeting closed at 3:00pm.

Regards,

Tim Ellison
Java Technology Centre, MP146
IBM UK Laboratory, Hursley Park, Winchester, UK.
tel: +44 (0)1962 819872  internal: 249872  MOBx: 270452
Received on Thursday, 14 December 2000 08:31:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT