Next message: Tim Ellison/OTT/OTI: "Re: Why do we need working resource ids ?"
To: ietf-dav-versioning@w3.org
Message-ID: <OFEBF629A3.6CE9B291-ON852568EF.00535AEB@ott.oti.com>
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
Date: Tue, 30 May 2000 11:12:13 -0400
Subject: Re: stable URL's
Ok, if you think that is sufficient.
Tim
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
Sent by: ietf-dav-versioning-request@w3.org
29-05-00 10:49 PM
To: ietf-dav-versioning@w3.org
cc:
Subject: Re: stable URL's
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
I don't think that the problem goes away -- describing these new URL
semantics is going to require a word to replace "stable" (as you have
shown below). If we find a good replacement it will be sufficient to
sue
that everywhere in preference to introducing numerous new terms.
I was using the word "stable" below to draw the connection between
the current terminology and the new terminology, not because the term
is needed to explain the new terminology.
You would just say:
A versioned resource URL identifies a resource whose previous states
can be remembered.
A revision URL identifies a particular state of a versioned resource.
A history URL identifies a resource describing all the states of a
particular versioned resoruce.
"A Target-Selector header only affects a versioned-resource URL".
In particular, it does not affect a revision URL, a working resource URL,
or a history URL."
No need for the term stable.
Cheers,
Geoff
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
At this weeks design meeting, it was proposed that we require that
the server provide a URL to all resources that currently require a
header. In particular, that would be working resources and the
metadata for versioned resources.
It was also proposed that we not use the term "stable", and in the
case of revisions, use the term "revision URL". That works fine
for working resources as well (i.e. use the term "working resource
URL").
So all we need is a term to distinguish a versioned resource URL
that is affected by a target selector header, and one that is not
(i.e. is a "stable URL for the versioned resource metadata").
I propose that we keep the term "versioned resource URL" for
the resource that is affected by the target selector header,
and that we use the term "history URL" for the one that exposes
the versioned resource metadata.
So that leaves us with 4 kinds of URL's:
- versioned resource URL's (affected by Target-Selector header)
- revision URL's (stable)
- working resource URL's (stable)
- history URL's (stable)
Any objections?
Cheers,
Geoff