RE: Renditions Proposal

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

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

However I do not want the DAV group to try to define the link value
syntax because it is a deep pit. Just look at the hell TCN has gone
through. It has been worked on for years at this point and the best it
could do is get to "experimental" status.

If someone wants to do variants, more power to them, let them build them
on top of the DAV architecture. 

			Yaron

> -----Original Message-----
> From:	Judith Slein [SMTP:slein@wrc.xerox.com]
> Sent:	Wednesday, August 27, 1997 2:28 PM
> To:	w3c-dist-auth@w3.org
> Subject:	Renditions Proposal
> 
> What if we tried just to do something along these lines (details of
> syntax
> aren't important to me) -- Would this be too painful for server
> vendors to
> consider? Would it meet the needs of those of us who build
> applications?
> 
> (The section numbers look weird because I took this from a longer
> paper I've
> been working on.)
> 
> --Judy
> 
> ---------------
> 
> 3 General Principles
> 
> 3.1 Do not dictate any algorithm for choice of rendition
> 
> 3.2 Do not assume anything about the naming scheme the server uses for
> renditions, or even that it uses a naming scheme to track rendition
> relationships
> 
> 3.3 Support both persistent and dynamically generated renditions in a
> consistent way
> 
> 4 Requirements and Solutions
> 
> 4.1 Clients must be able to find out what renditions of a resource are
> available
> 
> HTTP 1.1 discusses only in vague terms (in 12.2 and 19.6.2.1) how a
> server
> would describe what variants it has available.  It reserves the header
> name
> "Alternates" for this purpose, but does not define that header.  The
> Transparent Content Negotiation (TCN) draft
> Draft-ietf-http-negotiation-03.txt proposes a definition (in 10.1).
> This
> section treads on some ground being addressed by the TCN draft, but
> gives us
> a way of getting a rendition list without tampering with the semantics
> of
> HTTP 1.1 GET.
> 
> Request:
> 
> RENDITIONLIST /~slein/Book/ HTTP/1.1
> Host: www.xerox.com
> 
> Response:
> 
> HTTP/1.1 200 OK
> Alternates: {"http://www.xerox.com/~slein/Book/french.html" 0.9 
>         {type text/html} {language fr}},
>         {"http://www.xerox.com/~slein/Book/english.html" 1.0 
>         {type text/html} {language en}}
> 
> 4.2 Clients must be able to submit renditions of a resource to a
> server
> 
> Make a RENDITION request, with the request URI being the URL of the
> parent
> resource, and with headers describing the renditions.  A suggested URL
> for
> the rendition may be included, but the server is not required to use
> it.
> The response must include the URLs where the server actually put the
> renditions.  If the parent resource does not exist, the server should
> create
> it.  Quality here is the user agent's estimate of the quality of the
> rendition being provided.
> 
> If a rendition matching a variant description (URL and quality are not
> used
> in determining a match?) already exists, it will be replaced.
> 
> Request:
> 
> RENDITION /~slein/Book/ HTTP/1.1
> Host: www.xerox.com
> Content-type: multipart/alternate
> Alternates: {"./french.html/" 0.9 {type text/html} {language fr}},
>         {"./english.html/" 1.0 {type text/html} {language en}}
> 
> <entity body>
> 
> Response:
> 
> HTTP/1.1 200 OK
> Content-type: application/xml
> 
> <XML>
> <XML:Namespace><Ref>http://www.ietf.org/standards/dav/</>As>D</></>
> <D:MultiResponse>
> <Response>
> <XML:Ref>http://www.xerox.com/~slein/Book/</>
> <Status>HTTP/1.1 200 OK</>
> </>
> <Response>
> <XML:Ref>http://www.xerox.com/~slein/Book/french.html/</>
> <Status>HTTP/1.1 200 OK</>
> </>
> <Response>
> <XML:Ref>http://www.xerox.com/~slein/Book/english.html/</>
> <Status>HTTP/1.1 200 OK</>
> </>
> </>
> </>
> 
> 4.3 Clients must be able to get a particular rendition of a resource
> 
> HTTP takes care of this, up to a point.  For renditions that are
> resources,
> a client can simply GET the resource.  For renditions that are not
> resources, content negotiation can be used - the client specifies
> which
> renditions it can accept.  What is not defined is a way for the client
> to
> discover what renditions are available.  See 4.1 for the proposed
> solution
> to this part of the problem.
> 
> 4.4 Dynamic generation of renditions 
> 
> One rendition may be designated "master", or a "generated from" link
> may be
> defined, or both.
> 
> The master rendition is the one from which all others get generated.
> In
> some environments this may be a server-maintained property.  If there
> is a
> master rendition, it is the only one users are allowed to edit, and
> other
> renditions are generated as needed based on changes to the master.
> Values
> "true", "false".  This property should only be present on renditions
> that
> are source or output for dynamic generation.
> 
> The generated from link . . .
> 
> The GENRENDITION method provides a way to request generation of
> derived
> renditions. (In many cases generation of renditions may happen
> automatically, without the need for a request.  But there will be
> occasions
> when a request is needed - say, automatic generation happens at 2:00
> AM, but
> the author needs to make new generations available immediately.)  The
> request URL is the URL of the parent resource.  If no list of
> alternates is
> provided, all renditions will be regenerated from the master resource.
> If a
> list is provided, only the renditions on the list will be regenerated.
> 
> 4.5 Interoperability with HTTP content negotiation
> 
> Provide enough information in a RENDITION request to support HTTP 1.1
> content negotiation - at least media type, language, charset, and
> encoding.
> What about Transparent Content Negotiation?  Let's not add anything
> else (no
> features).
> 
> 
> Name:			Judith A. Slein
> E-Mail:			slein@wrc.xerox.com
> Internal Phone:  	8*222-5169
> External Phone:		(716) 422-5169
> Fax:			(716) 265-7133
> MailStop:		105-50C

Received on Wednesday, 27 August 1997 18:36:34 UTC