Re: defining a versioned resource to be a "collection"
Chris Kaler (ckaler@microsoft.com)
Mon, 30 Nov 1998 11:54:05 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A757937@RED-MSG-52>
From: Chris Kaler <ckaler@microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>
Cc: ietf-dav-versioning@w3.org
Date: Mon, 30 Nov 1998 11:54:05 -0800
Subject: RE: defining a versioned resource to be a "collection"
I don't this approach works for one of my canonical cases. I have a Web
site that I update using DAV. We now have a DAV server that supports
versioning. Some of my clients are using non-versioning DAV clients, some
are using versioning-aware DAV clients. Both clients should be able to see
and operate on the structure of the Web.
I think getting this right adds more complexity to the clients which is
where I think we should be simplifying. I guess I don't understand why
passing a version token is bad. You will likely be holding a lock token
anyway, so why is this so much of a burden?
Possibly a disconnect here is they way I think of versioned resources.
Personally, I like the idea that the URI namespace refers to versioned
resources and that you specify the revision-id header to refer to a specific
revision, otherwise the request is against the versioned resource (or the
default revision). Of course you can always obtain a URI for a specific
revision. I think this approach makes clients much easier to build and
makes the protocol transition from non-versioning to versioning easier. As
well, I prefer not to define server-side structure whenever possible as it
ties the hands of the server writer.
Chris
-----Original Message-----
From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
Sent: Monday, November 09, 1998 9:29 AM
To: Chris Kaler
Cc: ietf-dav-versioning@w3.org
Subject: Re: defining a versioned resource to be a
"collection"
Chris raises several good questions. In order to answer
them, I will
in several cases refer to a proposal for handling versioned
collections
that I posted earlier today to this mailing list (it's
subject was
"versioned collections: a proposal".
From: Chris Kaler <ckaler@microsoft.com>
From: Geoffrey M. Clemm [gclemm@tantalum.atria.com]
...
Since a collection is
a canonical way of specifying a resource as some base
resource
extended by some unique (wrt that base resource)
identifier, why don't
we just define a versioned-resource to be a
collection, and each
revision to be a member of that collection identified
by what we have
been calling the revision-id?
...
... I think your approach has some problems. First, I
don't understand how you would handle the versioning of a
collection
resource itself. Does it become a collection of
collections?
Yes. (See the "versioned collections" article for details).
As for complexity, I'd argue it is a wash. You trade the
complexity of the
pair of information for the complexity of inserting extra
collections into
the namespace.
Inserting extra collections into the namespace does not
increase the
complexity of the protocol, while requiring a pair of
identifiers to
identify a revision resource does (e.g. the new header
needed to specify
the revision id, and extending the method semantics to use
or ignore
the new header). This is certainly something we could cope
with if we
had to, but I'd need to see some real benefit before paying
the price.
We would also have to add the notion of a "default"
member to a collection.
That is, if I do a GET on the versioned resource, which
is just a
collection, which resource within the collection do I
return (this is the
PIN method, but the semantics are a little broader now --
not that this is
bad).
I don't see why we would have to define in general the
notion of a
"default" member of a collection. We define the notion for
versioned
resources, and that isn't affected by whether the versioned
resource happens
to be a collection (of revisions).
I also think the collections approach assumes a basic
linear history.
Why? A standard collection is just a set with identifiers
for the members.
This implies nothing about the linear nature of the history
(this is determined
from the predecessor/successor properties of the revisions).
Once
you get into resource-level branching, do we represent
the branch as another
collection?
One could, but I wouldn't recommend doing so. I'd just make
the branch
be a property of the revision. In particular, this
branch-as-property
approach allows you to support the "change-set" approach
with no change
to the protocol.
If so, the collections of collections are going to get
very
complex, very fast.
Another reason not to do so.
When building Web sites, the inter-page links are very
important. I believe
people want to be able to version their sites without
requiring a lot of
link updating to occur. That is, I should be able to
create different
branches and have my links still work by passing in
headers to qualify the
URI. By introducing namespace changes to refer to the
branches and versions
(or even configurations), you force the links to have to
change.
I assume that you are referring to the problems of handling
absolute
inter-page links in the presence of namespace versioning?
(Relative
inter-page links require no additional headers).
I agree that this is an important problem, but I do not
believe it can
be effectively solved by passing around a "revision-id". To
solve
this problem, you need to pass around a "version-selection"
header
that indicates what revision should be selected from each of
the
versioned collections back to the root of the URI space. In
addition,
you need to indicate when you want a revision, and when you
want a
working resource.
In my proposal for handling versioned collections, this
problem would
be addressed by passing around a "workspace" header, and
then
upgrading all methods to treat absolute URI's in a document
as
relative URI's wrt the specified workspace URI.
Cheers,
Geoff