Localized baselines

From: Eric Sedlar (esedlar@us.oracle.com)
Date: Wed, Feb 16 2000

  • Next message: Tim Ellison OTT: "Labels"

    Message-ID: <011b01bf7901$81a314e0$ab171990@us.oracle.com>
    From: "Eric Sedlar" <esedlar@us.oracle.com>
    To: <ietf-dav-versioning@w3.org>
    Date: Wed, 16 Feb 2000 20:43:16 -0800
    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