Re: Revision names
Chris Kaler (ckaler@Exchange.Microsoft.com)
Tue, 12 Oct 1999 16:49:14 -0700
Message-ID: <FD7A762E588AD211A7BC00805FFEA54B041DD98E@HYDRANT>
From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>
To: "'jamsden@us.ibm.com'" <jamsden@us.ibm.com>, ietf-dav-versioning@w3.org
Date: Tue, 12 Oct 1999 16:49:14 -0700
Subject: RE: Revision names
1) I would like these to be separate namespaces. My
argument has been that the server needs to be able
to determine if X is an 'id' or a 'label'. We need
a way to differentiate them -- context is fine if
it works.
<jra>
The server is free to store the id in a separate member. This doens't need
to be
exposed to the user, client, or protocol.
</jra>
<ck2/> My point is that this forces the server to (a) always
map the data, and (b) not present its own URL formatting
which might be more conducive to their store.
2) Headers are a good thing. I should be able to alter
the behavior of GET by including a header that indicates
which version I want. This has a lot of advantages in
that I can separate URL from version (revision). Also,
I can have separate headers, or special syntax in the
header to address #1.
<jra>
Agreed, but you don't need the special syntax if id's and labels aren't in
different namespaces.
</jra>
<ck2/> Only if there is a clear distinction -- for example a separate
header. I can say they are different namespaces, but given 'X',
how do I know which it is?
3) As stated below, I'm against requiring this, unless
the server has said that they support property collections
in which case the server has signed up to some additional
requirements.
<jra>
WebDAV already has "property collections", see the DAV:link element. The
additional requirement in the versioning spec is to treat these property
resources like references where the property value can either be the URL
of the
resource, or the contents of the referenced resource depending on the
presence
of the DAV:property-resource-URL element. I would like to see if we can
resolve
this issue so that there aren't two ways of representing the same
information in
the protocol. XML documents is one way, property collections (which allow
other
WebDAV methods to be applied to the "property") is another. This is one of
the
left over issues from Concord that we can address in Washington.
</jra>
<ck2/> WebDAV doesn't use "property collections" as Geoff has proposed.
Although two approaches can be sub-optimal, they are addressing
different problems. I do not believe it is viable to require servers
to support the semantics that 2.2 proposes for property collections.
I also don't think Geoff's request for an interoperable solution
that doesn't require transferring XML documents is unreasonable.
Just my two cents... :-)
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Tuesday, October 12, 1999 10:20 AM
To: ietf-dav-versioning@w3.org
Subject: RE: Revision names
If the revision name (id or label) is provided in a separate header, then
would
we still need to construct these URLs? I think we should avoid this if we
can.
"Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com> on 10/12/99
01:00:35 PM
To: Jim Amsden/Raleigh/IBM@IBMUS, ietf-dav-versioning@w3.org
cc:
Subject: RE: Revision names
I am strongly opposed to the specification describing what a
revision id must look like. I know Jim only said that they
should be valid path segments, but, in retrospect, I think
that is too severe. If my sever wants to use a URI to refer
to a revision, then I should be allowed to. However, this
may not be a "valid" URL segment.
As well, the specification shouldn't require the ability for
a client to be able to "glue" these with other information and
expect to have a URL that works. Now if a server supports
property resource collections, then they better conform to this.
But a server that doesn't, shouldn't have to.
This approach will limit servers from providing ids that are
optimized to their store's.
Chris
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Tuesday, October 12, 1999 7:53 AM
To: ietf-dav-versioning@w3.org
Subject: Re: Revision names
We can think of the server as another collaborator in distributed authoring
systems, one that provides a set of services. In particular, there can be
little
distinction between a revision name (something that distinguishes one
revision
from another in this context) specified by some other client and one
specified
by the server. In both cases there is the possibility for collisions, and in
both cases, there is the desire to use the revision name to select a
revision.
As Tim points out below, there is also a desire for the syntax of label
names to
be consistent with URLs, and to be able to marshall revision names in
request
and response entity bodies (in XML) as well as in headers. The only
difference I
can see is that the server's revision name, the revision id, can't be moved
or
reused - its an immutable or fixed label that ensures revisions can always
be
distinguished. Any attempt to move or reuse the label id results in an
error.
This makes potential client/server collisions even safer than client/client
collisions as there is no possibility of some other client getting an
unexpected
revision because some other client or the server moved the label id.
The only reason to separate id and label name spaces seemed to be to avoid
client/server label name collisions. But it is clear that client/client name
collisions are much more likely to happen, and have greater consequences (as
measured by the principle of least astonishment). I continue to find it hard
to
justify the complexity separate label namespaces adds to the protocol vs.
the
problems it solves. Does anyone else see other issues that separate
namespaces
would avoid?
Tim_Ellison@oti.com (Tim Ellison OTT) on 10/12/99 10:26:17 AM
To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
cc:
Subject: Revision names
As mentioned by both Jeff (by phone) and Geoff (in an earlier positing),
revision id's must be legal URI path segments if we envisage the ability to
refer to a revision by a URL (i.e. DAV:history's revisions collection "/"
DAV:revision-id).
Maybe we will also want to refer to a particular labelled resource by a URL
in a similar fashion.
If we choose to differentiate labels and revision id's by extra syntax
surrounding the value this would lead to bizzare looking URLs.
Having listened to the discussions, I think that the argument for avoiding
collisions between labels & revision ids has been largely debunked; and the
protocol would undoubtably be simpler if there was not requirement to
separate namespaces. However, labels and revision ids have different
characteristics from the client's perspective and it would be immensely
reassuring to know which you are dealing with at all times. I just don't
see yet how this would fit into the protocol.
Tim