Next message: Tim Ellison OTT: "Re: Labels"
From: Tim_Ellison@oti.com (Tim Ellison OTT)
To: esedlar@us.oracle.com (Eric Sedlar), ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <2000Feb17.102930.1250.1478988@otismtp.ott.oti.com>
Date: Thu, 17 Feb 2000 10:30:57 -0500
Subject: RE: Localized baselines
I see no problem in relaxing the definition of baseline as you suggested.
It will mean that we have to write the spec to state what creating a
baseline means, and that may be difficult to do while maintaining the
generality you need.
I would only want to see the full transitive case written into the delta-v
spec., while leaving the door open for the conditional types you gave.
Tim
----------
>From: Eric Sedlar
>To: ietf-dav-versioning
>Subject: Localized baselines
>Date: Wednesday, February 16, 2000 11:48PM
>
>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