RE: Renditions Proposal

Since we are agreed that variant support can be handled via DAV, as it
exists today, it would seem to make the sense to allow the standard to
move forward and have a separate specification just addressing variants.
Everyone with interest in the topic can then discuss matters there,
while the base, which everyone needs, moves forward.
	Yaron

> -----Original Message-----
> From:	Martin J. Dürst [SMTP:mduerst@ifi.unizh.ch]
> Sent:	Thursday, August 28, 1997 3:47 AM
> To:	Yaron Goland
> Cc:	'Judith Slein'; w3c-dist-auth@w3.org
> Subject:	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 13:20:43 UTC