Next message: Tim Ellison/OTT/OTI: "MERGE failure"
To: ietf-dav-versioning@w3.org
Message-ID: <OF5C362743.7F7910D0-ON852568EE.007162B7@ott.oti.com>
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
Date: Mon, 29 May 2000 16:40:01 -0400
Subject: Re: stable URL's
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.
Tim
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
Sent by: ietf-dav-versioning-request@w3.org
26-05-00 10:36 PM
To: ietf-dav-versioning@w3.org
cc:
Subject: stable URL's
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