- From: Gregory J. Woodhouse <gjw@wnetc.com>
- Date: Mon, 28 Oct 1996 11:08:06 -0800 (PST)
- To: hallam@ai.mit.edu
- cc: w3c-dist-auth@w3.org
On Mon, 28 Oct 1996 hallam@ai.mit.edu wrote: > > >Since HTTP/1.1 allows GET with a body, why not use something like > > >GET <URI> HTTP/1.1 > >[...] > >Document-Author: <ID> > >Want-Source: yes > >Authors-Credentials: <whatever> > >Version-Number: 4 > >[...] > > Because it completely destroys the idea of being able to link to an > arbitrary document from an arbitrary HTML page using a single > URI. > I guess this depends on the role you expect document versioning to play in the first place. If you intend that versions 1 and 2 of the same document should co-exisxt and poth should potentially be available to end users, then you are right: each should ahve its own URI. On the other hand, if only one version should be available to to end users and old versions exist primarily for contnent developers, then I am not convinced. [...] > If information is an accessor for a document it bellongs in the URI, > otherwise it does not. > I guess I have not bewen viewing multiple versions of a document as separate resources, and have therefore seen the version slection process to be essentially analogous to content negotiation. This may be a faulty assumption. But consider tht if a resource has variants, those variants MAY have their own URIs. It is not required. > The most that could be done with URIs at a lexical level would be to > provide an assertion that the URI conformed to a lexical convention > concerning version numbers. > > If we are going to support collaborative authoring it better support > divergent versions and at least a hierarchical organisation of the > version resources. > I like this idea. If version numbers are totally ordered then it is not possible to have parallel development of separate versions. Of course, unless parallel development paths are ordered then there is no concept of current version. > > Another point, we need to consider the definition of "set" objects, > analogous to the old CMS classes and Groups. a CMS group > was a collection of resource entities. A Class was a collection of > particular variants of a resource. To make a release one would > create a class with the versions of the resources used to make > that release. the groups were used simply to collect resources together > into handy units. > > We should be prepared to think beyond "files" however. As anyone > who has coded LISP will know files are not a usefull grouping > for program objects. Indeed there is no single such grouping. > > > Phill > --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/ resource page: http://www.wnetc.com/resource/
Received on Monday, 28 October 1996 14:08:35 UTC