Re: Version identifier in URL

Daniel W. Connolly (connolly@beach.w3.org)
Wed, 29 May 1996 18:30:10 -0400 

In message <2.2.32.19960529070838.00710f78@pop-server.austin.sar.slb.com>, "Rob
ert C. Pettengill" writes:
>
>It isn't clear to me that it is necessary to standardize the syntax of
>version identifiers across all servers.

Not necessary, and terribly ill-advised.

>The proposal in http://www.w3.org/pub/WWW/MarkUp/Resource/Specification
>seems to be pretty heavy weight.

Fair criticism. Shorthand syntaxes can be developed.

>  I can't simply have a URL to a specific
>document in the "version space", I need to define a resource and then
>provide a URL to that resource which seems more than a little awkward.

No? I think you can.

The point is: you can't tell the relationship between address A1
and address A2 just by looking at their syntax: you need explicit
information that says one is a version of the other. The Resource
element is one such syntax.

>Why not allow link attributes to be specified in the anchor, e.g.
><A HREF="mumble/foo" VERSION="x">?

That might be a reasonable short-hand, as long as we're clear on
how it expands into a full <resource> description; i.e. if
the above markup is found in a document at A1, then we have:

        link(A1, mumble/foo, version-specific)
and
        meta(mumble/foo, version, x)

i.e.
        <resource href="mumble/foo">
                <meta name=version content=x>
                <link rev=version-specific href="A1">
        </resource>


>It might be worthwhile discussing the requirements for versioned links
>before discussing the syntax.  Some questions that occur to me are:
>
>Is the versioning model constrained to be single threaded?  (i.e. unique
>answers to the queries below)
>
>Fetch the version previous to URL(x).
>Fetch the version subsequent to URL(x).

These are a matter of finding the address p and s such that:
        link(x, p, preceeds)
        link(s, x, preceeds)

Then GET p and s. A convention for finding those addresses might
be handy. But the convention can't be just a syntactic manipulation.

>Fetch the version of URL(x) current at time t.

That's trickier. It's a matter of finding c such that:

        meta(c, last-modified, t1)
        link(c, r1, preceeds)
        meta(r1, last-modified, t2)
        link(c, r2, preceeds)
                ...
        link(c, rn, preceeds)
        link(rn, x, preceeds)


such that t1 <= t <= t2.

>Fetch the version of URL(x) current as of the creation time of URL(y)
>Fetch the most recent version of URL(y)

One way to this sort of thing in general is:
        * Each response regarding a versioned resource has a
        link to its full version history in an HTTP header:

                Link: rel=revision-history href=/foo/bar/history

        * To find a certain revision of x, Client does GET (or HEAD)
        for x, and follows revision-history link

        * content of target revision-history gives links to each
        revision, along with information about last-modified dates.

        * client searches revision history to satisfy query

Another approach is to move some of the processing to the server.
Then it's a question of what queries to support, and how to
express them. URL forms syntax? Hmmm...


Dan