Re: Prelim. DAV spec.

Gregory J. Woodhouse wrote:
> 
> 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.

This is a matter for access control, surely? Why invent a new scheme when we
already have a perfectly good one? Don't forget that content developers are
just end users with extra privilege.

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

But if they don't have their own URIs you may not be able to determine how to
select them. Certainly not without new headers.

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

To expand the URL/parallel version model, you could do things like:

http://some.where.com/some/path/somefile

	the file a "user" gets

http://some.where.com/some/path/somefile/!versions/1.2.3.4

	version 1.2.3.4 of somefile (possibly including tagging information
	for version tracking)

http://some.where.com/some/path/somefile/!versions/

	a list of versions

http://some.where.com/some/path/somefile/!versions/latest

	the latest version of somefile with version tagging

Of course, these can be protected with various levels of access control.

I'm sure I had some more to say but I'm being more than a little distracted by
the gale force winds currently blowing in London ;-)

Cheers,

Ben.

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

-- 
Ben Laurie                Phone: +44 (181) 994 6435  Email: ben@algroup.co.uk
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd,         Apache Group member (http://www.apache.org)
London, England.          Apache-SSL author

Received on Monday, 28 October 1996 14:39:04 UTC