Re: version management and relative links

David G. Durand (dgd@cs.bu.edu)
Sun, 9 Jun 1996 23:16:54 -0400 

In message <199606091834.OAA00880@anansi.w3.org>, "Daniel W. Connolly" writes:
>In message <v02130504ade09d56f002@[128.148.157.46]>, "David G. Durand" writes:
>>
>>   This discussion has highlighted an important requirement:
>>
>>    **** Versions should be extractable from the URL ****
>
>Just Say No!
>
>I'll read the rest in detail later, but I'll just say now that I think
>this is a fatal flaw.
>
>Compare with:
>
>       "MIME types should be extractable from the URL"
>
>The web as it exists today is proof that this is not necessary.
>There are plenty of ways to ship the appropriate metainformation
>around so that this can be avoided.

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.

    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.

    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.

>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.

>Another way to put it: web clients have a standard way to construct
>query URLs from the address of the search service and the search
>terms. On the other hand, there is no standard way to do the
>reverse: look at a URL and determine what it means to the origin
>server.

   After I read your earlier attempt to kill the discussion of version
identification in the URL, I read the Genericity notes by TimBL. I was not
convinced by the notion of equating genericity of representation (the
examples were mime-type and language), and genericity of time (which seems
that it should properly include version). For one thing, a translation of a
resource from one language or data format to another is an <am>attempt</em>
to create a set of equivalent resources. However, it is _not_ the case that
different revisions of a document are intended to be equivalent, but rather
that they are hostorically related. It is the complexity of the relation
that actually obtains between revisions that makes versioning systems
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,
there are only examples of genericity given, and no explicit definition or
criterion, so I can't say that for sure. Here's a definition that I think
makes sense:

    A is generically related to B iff A and B are intended by an
information provider, to be equivalent for differing users or user-agents.

    If genericity is to be an absolute requirement of the W3C for any URL
proposals, perhaps it should be defined.

    I don't want to founder on a religious issue: if the W3C will rule URL
version information right out, I'm willing to accept extra mandatory use of
HTTP operations to find out any version information. I assume that others
would, too. But I think that the justification for that (if there is to be
one) is not yet clear.

   -- David

----------------------------------------------+----------------------------
  David Durand                 dgd@cs.bu.edu  | david@dynamicDiagrams.com
  Boston University Computer Science          | Dynamic Diagrams
  http://cs-www.bu.edu:80/students/grads/dgd/ | http://dynamicDiagrams.com/