Next message: Vasta, John: "RE: Questions on activities"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568BE.004C219F.00@d54mta03.raleigh.ibm.com>
Date: Tue, 11 Apr 2000 09:51:29 -0400
Subject: Unversioned members of versioned collections
<geoff>
The semantics of an unversioned resource is that a PUT to that
resource is seen by the next GET to that resource. This means that
two workspaces cannot have their own copies of that resource, but must
share a common resource. In contrast, each workspace can have its own
copy of a revision, since it is immutable.
</geoff>
<jra>
OK, I think I'm getting there. Say you have a versioned collection
http://domaing/401k/images. Now say that versioned collection has a member
arrow.ico. The collection has a member arrow.ico which is a binding to
something somewhere. Workspaces that select collection 401k have a "copy"
of that collection with a member that contains the binding. Not say
arrow.ico is an unversioned resource. Workspace selection is involved in
selecting a revision of collection 401k containing member arrow.ico which
is a binding to an unversioned resource. It doesn't do anything to select a
revision of the bound to resource as it is not versioned. This would be
true of all workspaces that select any revision of 401k that contained a
member referencing the same unversioned resource. So I don't see the
problem. The two workspaces don't contain copies of arrow.ico, but rather
401k which contains bindings to arrow.ico.
</jra>