RE: Renditions Proposal

I do like the idea of formally defining a "variant" link as part of the DAV
specification, as one possible approach to supporting variants.  This would
be like the "Alternate" link type in HTML 4.0.

There are 2 arguments against this approach, however:  

1.  The process of setting up and maintaining the variant links is pretty
onerous for the client.  Since we haven't provided a way to set property
values in the same request that creates a resource, an author would have to
create the resource, then do a PROPPATCH to create the variant link, and do
PROPPATCHs on all the other variants to update their variant links.
(Possibly doing a GETPROPS to retrieve the current value of the variant link
on each of them so as not to wreck the current value of the link when adding
the new variant to it.) For the HTTP model of variants to continue to work,
there also has to be a resource that is the "parent" of a group of variants,
on which content negotiation can take place.  So the author would have to
create the parent, too, and set up the links on it. 

2. If the server does want to use some naming scheme to manage variants of
the same resource, it's not OK for the client to choose the URL for the
variant resource, particularly since the server can't tell that it is going
to be a variant till after the PROPPATCH request.

Interactions between versioning and variants will require some thought.  I
believe it will be the hardest part of adding support for variants.  There
are two basic models: you can version each rendition independently of all
the others, or you can version the parent resource that a group of variants
represents. Or you can have a mixed model, where authors or applications can
version sometimes one, sometimes the other.  Supporting a mixed model could
get pretty hairy.  I was actually going to propose that we NOT allow
individual renditions to be versioned.  Letting different renditions of the
same resource be versioned independently is contrary to what renditions are
all about:  they are supposed to be different representations of the same
content.  So I was going to suggest that when you check out a resource, all
of its renditions get checked out; when you check it back in, all of its
renditions get checked in.  You can't force the author to keep the
renditions synchronized, but you can at least encourage it.  (On the other
hand, if you version the parent resource rather than the individual
renditions, you have to provide some way to add a new rendition after the
version graph has been started.)

I would have no problem with separating out variants, as we are separating
out recursion, for treatment in a separate draft, provided that it is
considered part of the work of the WEBDAV group and has a schedule for
completion that doesn't lag too far behind the core WEBDAV spec.

--Judy

At 03:36 PM 8/27/97 PDT, Yaron Goland wrote:
>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
>
>
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 Thursday, 28 August 1997 16:56:48 UTC