Next message: Eric Sedlar: "Re: Localized baselines"
Message-ID: <65B141FB11CCD211825700A0C9D609BC0205B4AD@chef.lex.rational.com>
From: "Clemm, Geoff" <gclemm@Rational.Com>
To: "'ietf-dav-versioning@w3.org'" <ietf-dav-versioning@w3.org>
Date: Sun, 27 Feb 2000 09:16:21 -0500
Subject: RE: Localized baselines
For something like this, I'd be inclined to just use the general
configuration resource, rather than making the baseline resource
more general.
Cheers,
Geoff
-----Original Message-----
From: ietf-dav-versioning-request@w3.org
[mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Eric Sedlar
Sent: Wednesday, February 16, 2000 11:43 PM
To: ietf-dav-versioning@w3.org
Subject: Localized baselines
It seems like we might want to create baselines that don't recurse
indefinitely, but that have a "bottom". I might create bindings from
objects in one release area (managed as a group) to another release areas
(managed separately) solely for the purposes of ensuring persistence, but
that aren't really "under" the first release area from the organizational
perspective usually associated with hierarchies (like URLs & filesystems).
It would be useful to allow servers to implement functionality where
external properties other than bindings (like the presence (or lack thereof)
or a label or membership in a configuration) could be used when recursing
through the heirarchy to create a baseline (snapshot), to indicate when to
stop recursing. (The SQL way might be "CREATE BASELINE START WITH '/foo'
WHERE labels IN ['bar', 'werf']" or something). Does anyone see any harm in
loosening the definition of baseline to only require that it contain a
subtree of resources contiguous in URL namespace (e.g. for all resources
other than the baseline root, a parent collection is in the baseline),
rather than being an infinite recursion?
--Eric