RE: Renditions Proposal

Hello Yaron,

> One of the basic design principals of DAV is that everything is a
> resource and all resources have URLs. Therefore any variant based system
> must start with the principal that all variants have their own unique
> URLs.

The principle of HTTP is somewhat different. In some case, some
URL can result in the return of different resources depending
on other things in the HTTP protocol (accept headers and such).
The different resource that are being served usually also have
their own, unique URLs. You are true at saying that HTTP is
constraining us here in some way. But the constraints are
not too strong, and as we are doing something for HTTP,
we probably have to accept them.

A position that says: "We are working for HTTP, so we have
to accept HTTPs definitions, but for some reason we don't
like HTTP, so we work only on those areas that HTTP hasn't
defined and ignore those it already has defined." is
definitely not a good working base. [Not that I want to
say that the above is your oppinion, but it is the extreme
one could construct starting from some the statements
you have made in this discussion.]


In order to make the HTTP model and the DAV models compatible,
various things are possible, but one solution might look as
follows:

- Require that variants can be identified by an unique URL
	(in addition to generic URL +something) by a HTTP
	server that wants to do DAV. (I think this is
	currently optional???)

- For a variant with an unique URL, have a property that
	indicates the generic URLs it is associated with.

- For a generic URL, allow to query the variants with their
	names (this is already supported by HTTP, I think).

- For a generic URL and a set of properties, get back a
	specific URL (for creation of new variants).

A slightly different solution might look as follows:

- Define a special kind of collection that is a variant
	collection. The name of the collection is the
	generic URL, the components are the specific
	URLs.

- When a new resource is added to such a collection,
	allow the server to give it a name different
	from the name the user suggest.

Note that in all of this, the server has full control
over how it wants to organize various variants, and of
course it has full control as to how it wants to respond
to a generic request (within the limitations of the HTTP
procotol).


> This principal then results in variants being just another
> versioned resource. All we then do is create some sort of "variant" link
> that indicates the relationship between two resources, for example, one
> is the French HTML version suitable for printing at 600 DPI of the
> other, etc. 

With variant links between two resources, the fact that you can
easily have more than two resources cannot be captured very well,
unless your link is between the generic name of the resource and
each of the specific variants.


> One could implement this system with DAV, today. No additional changes
> or modifications are required.

One probably could. And one reason for putting the variants
requirement in, and for having this discussion, is to make
sure that this is feasible, so that we don't have bad surprises
later.

Also, we don't want 5 servers to implement this in five
different ways. Even if we don't need some additions to
the DAV core protocol, it would be very beneficial to have
the same interface on all implementations.



> However I do not want the DAV group to try to define the link value
> syntax because it is a deep pit.

I agree that in general, it is a deep pit. What is needed is
a) That we agree at least where to put the link (which PROPERTY,
	for examlpe). The value is probably just an URL, and
	that's fine.
b) That if we leave naming to the server, we have a way in the
	protocol for the server to tell us what names it
	chooses.

Regards,	Martin.

Received on Thursday, 28 August 1997 06:47:36 UTC