Next message: Tim Ellison/OTT/OTI: "Re: Stable URLs"
Date: Wed, 5 Apr 2000 16:17:18 -0400 (EDT)
Message-Id: <200004052017.QAA02407@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Stable URLs
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
Here's my proposal for stable URLs.
Assumptions:
(1) A URL that is not "stable", is "dynamic".
(2) Stable URLs are server specific, and cannot be meaningfully parsed
by the client (i.e., reverse engineered into component parts). They can be
thought of as opaque tokens that conform to URL rules so that they can be
passed as request URIs.
So they do not form a WebDAV "consistent namespace"? So there are no
collections? I don't see how this can be compatible with your later
"acts the same in either dynamic or static namespace" requirement.
(3) Stable URLs are indistinguishable from dynamic URLs. That is,
there is no mangling of URLs to indicate its stability.
(4) There is no visible 'meta' area of a server URL namespace. The
stable URL space is the exclusive domain of the server.
Adding a header that says "switch to a completely different namespace"
is pretty drastic. In particular, why not just use existing namespace
functionality, namely, let the server allocate a meta area of the
server URL namespace, or let the server introduce a "metadata virtual
host"? What does the separate namespace buy you that makes up for the
cost of needing these "stable" flags in the Workspace and
Revision-Selector headers.
Axioms:
- The stable URl forms the equivalent of a server specific unique identity
of a resource.
- All resources, (revisions, non-versioned resources, working resources,
...) have a stable URL.
- A resource may be reached by zero or more dynamic URLs.
- There is a 1:1 mapping from resource to stable URL.
- Clients can determine the stable URL of any resource they can 'reach' by
stable or dynamic URL.
- Methods have the same effect if applied to a resource via its dynamic or
stable URL.
I don't agree with the last axiom. There will be some methods (such as
MOVE) which will fail for a stable URL but succeed for a dynamic URL.
There are other methods (such as depth:infinity PROPFIND) that will have
a different effect in stable and dynamic URL space.
Usage:
Since URLs can be dynamic or stable for any request to the server, there
must be some indication of its stability in the request. The stability of
URLs in the response is defined in the protocol specification. For
example, some properties are defined as containing stable URLs. Any
request that uses a stable request URI must contains <href> elements that
are themselves stable URLs.
I'm not sure what the last sentence is saying. Can you clarify?
The general form of a request is as follows:
METHOD <request-uri> HTTP/1.1
Workspace: [stable] <workspace-url>
Target-Selector: <keyword> [<param>]
where <keyword> <param> pairs may be one of:
_Unspecified_
The request-uri is a dynamic URL. Select the resource reached
by resolving the request-uri in the context of the request workspace.
If the selected resource is a versioned resource, select a revision
of the versioned resource in the context of the request workspace.
label "my label"
The request-uri is a dynamic URL. Select the revision of the
versioned resource labelled "my label". Select nothing if there
is no such labelled revision. Ignore this header if the target
resource is unversioned.
revid "rev12"
The request-uri is a dynamic URL. Select the revision of the
versioned resource with revision id "rev12". Select nothing if
there is no such revision id. Ignore this header if the target
resource
is unversioned.
metadata
The request-uri is a dynamic URL. Select the versioned
resource itself rather than any revision of it. Return a bad
request if the target resource is unversioned.
stable
The request-uri is a stable URL. Select the revision of the
versioned resource at the request-uri.
stable metadata
The request-uri is a stable URL. Select the
versioned resource itself rather than any revision of it.
Return a bad request if the target resource is unversioned.
Problems: Since discovering the members of a resource is a
'side-effect' of doing a PROPFIND depth one query, there is no way
to find the members of a collection given a stable URL to that
collection, since a PROPFIND using a stable URL woud return the
stable URLs of the members (which cannot be parsed to reveal their
names).
If you make the stable namespace a consistent WebDAV namespace, then
PROPFIND will return reasonable member names which will give you the
information you want ... why didn't you want the stable namespace to
be a consistent WebDAV namespace?
Cheers,
Geoff