Re: version management and relative links
David J. Fiander (davidf@worf.mks.com)
Mon, 10 Jun 1996 09:26:28 -0400
> Sure, we could use HTTP headers -- but I think that we should have a way to
> GET a _particular_ version of an object. As I say later, I think that it's
> not unreasonable to expect that one should be able to inspect URLs to
> determine that they are different versions of the same document.
Why? We can't even inspect vanilla URLs to determine if they are
the _same_ document.
> Given the fact that resource versions affect referential integrity,
> while MIME types, modification dates, and other meta-data do not, it seems
> that there is evidence that a version is part of the identification of a
> resource, and not just information about it.
This is almost the same argument that I've made. Revision 1.2
and revision 1.3 of foo.html are different resources. For
something like the Economist pages, something like the normal,
computerish, incremental version control system is probably
pointless; the June 1 version of the page has absolutely nothing
in common with the June 8 version of the page. On the other
hand, HTTP://www.w3.org/pub/WWW/ probably does change in an
incremental fashion, so the June 1 version is probably "weakly"
equivalent to the June 8 version.
> I don't want to question the feasibility of using HTTP headers and
> additional specialized requests to accomplish version identification, but I
> don't see the need to require an extra set of HTTP transactions that must
> be done in order for a version-aware browser to decide how to follow a
> link.
Following a link will always work. The client may discover that
the link was a versioned link when the server returns a
"Content-Version" header with the requested page, however.
>
> >As Larry M said, the flip side is "given a URL A and a version V,
> >there should be a standard way to combine them into a new URL A'
> >such that GETting A' yields version V of A."
> >
> >This flip side is reasonable.
>
> I'm not so sure. I don't see why we need to create _more_ URL aliasing to
> handle versions. Also what happens if I use the recipe on a URL A that
> already specifies version V' of A (in the server's private notation)? If
> the URL's version information is completely opaque, this cannot be
> prevented. I was going to ask what happens if we apply the recipe to A',
> but we can define the syntax to prevent that.
Client's will (probably) only be combining URLs with version
information provided by a human, so it's the human's problem to
make sure that the version information is a) correct and b) being
applied to the correct link. If you tried to attach version
information to a link that already contained version information,
the server would be fully justified in sending back an error
indication.
> useful. Obviously, I don't set design strategy for the WWW, but I'm not
> sure that version really meets the criteria for genericity. Of course,
I agree that version (that is, revision) information probably
isn't a "genericity" kind of thing, but that doesn't stop me from
saying that URLs <em/that a client receives/ are, in general,
opaque. Special purpose clients, that have been told a lot about
the site policies and the VCS being used might be able to decode
URLs, but that's an extension that's not supported by the basic
web functionality.
- David