W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

RE: Core versioning issues and nits

From: Lisa Dusseault <lisa@xythos.com>
Date: Fri, 2 Feb 2001 12:19:54 -0800
To: <Tim_Ellison@uk.ibm.com>, <ietf-dav-versioning@w3.org>
> > 7) How do you distinguish between:
> >  - A versionable resource
> >  - A non-versionable resource
> >  - A version-controlled resource
> >
> > Let's say the client wishes to present a simple UI which
> > lists all the resources in a collection, and can tell
> > what each resource is, allowing operations like "show me
> > the version history" or "turn versioning on" to be
> > available only when appropriate.  How, exactly, is this
> > accomplished?  What property is retrieved?
> Good question.
> A versionable resource will answer with (at least) Allow:
> to an OPTIONS request, a non-versionable resource will not.  A
> version-controlled resource is the only resource with a
> DAV:checked-in or
> DAV:checked-out property.
> There was some debate a while ago about making the resource
> types explicit,
> with various methods sugested.  I have to say that
> determining type by the
> presence or absence of properties is sub-optimal since, among
> other things,
> it makes for careful consideration when defining new resources with
> overlapping property names.

I agree that determining type by the absence of properties is
sub-optimal; I'd say it's not very reliable.  I'd point out another
problem:  in order to create the kind of GUI I described, the client
would have to:
 - Issue a depth:1 PROPFIND request to find all the resources that have
a DAV:checked-in (or checked-out) property.  If they do, consider them
 - Issue an OPTIONS request to every non-VCR, to find out whether it can
be versioned or not.

This is an order(N) operation, just to show a decent directory listing.
Depth is not supported on OPTIONS requests, according to RFC2518: "The
Depth header is only supported if a method's definition explicitly
provides for such support."

This is a serious client issue.  Please address...

Received on Friday, 2 February 2001 15:20:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC