Re: FWD: Questions on the 02 versioning
jamsden@us.ibm.com
Wed, 22 Sep 1999 16:16:21 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852567F4.006F865C.00@d54mta03.raleigh.ibm.com>
Date: Wed, 22 Sep 1999 16:16:21 -0400
Subject: RE: FWD: Questions on the 02 versioning
<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". 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?
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?
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, ... We can do better than the filesystem.
</jm>
<jra>
I still think configurations are user-data. A user creates a configuration which
represents a persistent set of revisions that taken together represent some
solution to some problem. A different revision of that configuration selects a
different set of member revisions which solve some functionally or
non-functional enchancment to that problem. This is all user information, not
system information, and so users should create and control them.
</jra>
<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>
<jra>
They are only implicitly added, so you can't remove one of them.
</jra>