Re: FWD: Questions on the 02 versioning
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Tue, 17 Aug 1999 14:44:42 -0400
Date: Tue, 17 Aug 1999 14:44:42 -0400
Message-Id: <9908171844.AA27815@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: Jeff_McAffer@oti.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <1999Aug13.183400.1250.1288432@otismtp.ott.oti.com>
Subject: Re: FWD: Questions on the 02 versioning
From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
[On the topic of REPORT'ing conflicts]
<gmc> If we keep the restriction in the current spec that
"versioned collection members must be versioned resources"
(something I advocate), then this case does not arise. </gmc>
<jm> If / is not a versioned collection then to find ALL conflicts (i.e.,
every conflict in my workspace) I need to specify / in my REPORT request.
We then need to spec what happens when you hit non-versioned
resources.</jm>
<gmc> You are of course correct. I was being a meathead.
I agree with your original proposal that we explicitly state that
a non-versioned resource never has a conflict.
[On the topic of REPORT'ing differences]
> <gmc>
> An activity being in a configuration is a report on whether the
> products of that revisions in that activity are "included" in that
> configuration. More formally: "An activity is in a configuration if
> at least one revision that is a product of that activity is on a line
> of descent to the revision selected by the configuration." It can be
> the case that only part of an activity is in a given configuration.
> This is how an activity can have "changed" from one configuration to
> another, as indicated by the "DAV:changed" element. Unlike a
> workspace,
> there are never any "conflicts" in configuration revision selections.
> </gmc>
<jm>I don't see the value add in this. What is the use-case for why we
need/want this? If I read your (gmc) description right, the activity
list for a config will/could be huge. Every activity involved in the
line of descent of the selected revision of every resource in the
configuration will be technically "in" the configuration!! What did I
miss? </jm>
<gmc>
A very common question is "what changed between these two
configurations". One could say "these new revisions are in and these
revisions are out", but it is usually much more useful to respond
"these are the activities that were performed to change the new
configuration".
So the activity list is huge only if there have been a huge number of
activities to produce the new configuration (remember that this is for
the "difference" REPORT for configurations).
A server is of course free to not support the activity-based
difference report, if it can't, or if it doesn't think clients will
want this information.
</gmc>
<jm>
Also, does one explicitly add an activity to a configuration?
<gmc/> No.
How? Are
activities implicitly added by virtue of adding a revision who's line of
descent goes through the activity to the configuration?
</jm>
<gmc/> Yes.
> 5) how does one create a configuration?
<jm>Alternatively, MKRESOURCE "config" at / would put it in the server
defined place and return the URL for where it put it. This is the
"default". <jm/>
<gmc/> I don't think we can count on playing games with /. Often /
will not even be in dav space, so the dav-enabled server will not see
requests that go to /.
<jm/> Users can spec a different Request-URI (other than /) if they
are really keen. BTW, do we have any use-cases in which users really
want their configs mixed with their domain resources?
<gmc/> I don't, but the issue is that we can't/shouldn't be defining
in the protocol what the legal URL's are for configurations, but rather
should provide a way for the server to expose this information.
Currently in the 2.2 draft, we are proposing to use OPTIONS to do this.
<jm>
BTW, where do baselines go? These are effectively config constructed by
the system when you do a deep CHECKIN. Presumably they have a URL as
well? <jm/>
<gmc/> That again is up to the server. You can find out the URL for
the baselines for a particular collection by looking at the
DAV:baselines property of that collection.
<jm>
I'm very uneasy about all of this. Configurations really are metadata.
They are not content or structure. They are configuration management
info. If we start mixing metadata resources with domain resources, it
significantly muddies the user view? There should be a "meta" area of
the URL namespace where one can escape the domain and access configs,
workspaces, activities, ... <jm/>
<gmc/> That's a very reasonable server design choice, but I don't think we
can mandate the actual name of that "meta" area of the namespace.
<jm> We can do better than the filesystem. </jm>
<gmc/> URL's have the same slash separated namespace as a filesystem does.
> 7) What are the semantics of the DAV:needed-configurations
> property of configuraions?
<jm>To be clear. If the needed-configs are actually added to the RSR
then I can edit the RSR and remove one of the needed-configs. How does
this affect the config which needed config I just removed? It may be
better to say that the needed-configs of a config in an RSR are
*implicitly* added to the RSR.</jm>
<gmc/> The semantics of DAV:needed-configurations is currently
specified in section 5.1.2 (the section that describes the
DAV:rsr-activity-latest semantics). I think the current wording
avoids any suggestion that the DAV:needed-configurations actually
change the value of the workspace RSR in any way, but if it is not
clear, we need to reword it so that it becomes unambiguous. In
particular, adding or deleting DAV:needed-configurations has no effect
on the contents of the workspace DAV:revision-selection-rule property.
> <gmc> ... A baseline of a versioned collection must
> contain all the members of that collection (to an arbitrary depth).
> So creating a baseline of a collection creates sub-baselines of any
> sub-collections that are baselined. Something I would support would
> be a property on a versioned collection revision that says whether a
> baseline of a parent collection should contain a baseline of
> that versioned
> collection or a revision of that versioned collection (and
> its members).
<jm>If I read gmc right, we want to autocreate "sub-baselines" and add
them as needed-configurations on the parent baseline? If so, I agree.
If not, I missed something</jm>
<gmc/> Yes. I'll add some words to this effect to the CHECKIN section
(which is currently how baselines are created), and then we can merge
this into whatever changes you have made to this section.
> 9) What resource types can be created with MKRESOURCE?
DAV:collection (e.g. MKCOL)
DAV:workspace, DAV:activity, DAV:history, DAV:configuration
Cheers,
Geoff