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