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 17:24:28 UTC