RE: Renditions Proposal

On Thu, 28 Aug 1997, Judith Slein wrote:

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

I don't think that would be too much of a problem. It's the authoring
tool that would take care of this.


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

Yes, this is indeed a problem. It may be the only point where we need
an addition to the base protocol to be able to take care of variants
later.

Anyway, I would prefer modeling variants as collections instead of using
links (it's not yet clear to me whether all variants of a resource
would be linked to each other, or whether there would only be links
between the parent and the variants).


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

I think that for variants for various displays,... that might be okay.
But it would still be on the edge. But in particular for languages,
it's too restrictive. For a translation of a certain version of
a certain base document, you can easily go through several versions.
For other versions of the base document, you might not have time
and money for an update to the translation.


> So I was going to suggest that when you check out a resource, all
> of its renditions get checked out;

That would be very problematic for language versions. It's rarely
the case that a single translator will do French, German, Italian,
Greek, Finnish,... :-). And it will often be the case that these
translations have to be done in parallel.


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

That would be fine with me, too.

Regards,	Martin.

Received on Friday, 29 August 1997 10:02:47 UTC