Re: Versioning TeleConf Agenda, 12/1/00 (Friday) 12-1pm EST

Minutes:

   - Moving branching support from core to optional (Geoff)

We agreed that since version-checkout and version-selector-checkout
is currently optional, it would expose a client to no more optionality
than is in the current protocol (but rather would make the current
optionality more evident).  Hopefully there will be further discussion
of this topic in the email thread that was started yesterday  (i.e.
"Simplifying CHECKOUT behavior for core clients").

   - Working collections (Greg)

We agreed that the latest working collection proposal was technically
consistent (i.e. where the members are version histories and
unversioned resources that are put under version control when the
working collection is checked in).  But it is still not clear that the
benefits of supporting a working collection construct are worth the
interoperability costs of having two ways of versioning collections.

   - CHECKIN of an activity (Greg)

This just provides a shorthand for checking in all the checked out
resources associated with that activity.  It appears that the only
benefit is in decreasing the number of round trips.  If anyone
believes there is a semantic benefit to this operation, please
explain it to the list.

   - Nested workspaces (Tim)

The motivation for nested workspaces is the desire to allow one to
version the root of the URL space on a host, and also support
multiple workspaces on that host.  We agreed that this is reasonable,
as long as a resource behaves as if it is a member of exactly one
resource.

And that's as far as we got.

   - Replacing DAV:must-support attribute with If tokens (Yaron)

   - Moving DAV:supported-xxx and DAV:collection/workspace-collection-set
     properties to be OPTION request/response items (Yaron).

   - Replace F and T with false and true (to allign with XML schema) (Yaron).

   - Move DAV:checkin-fork and DAV:checkout-fork to core (Yaron).

Cheers,
Geoff

Received on Friday, 1 December 2000 15:11:46 UTC