Re: Prelim. DAV spec.

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