- From: Martin J. Dürst <mduerst@ifi.unizh.ch>
- Date: Fri, 29 Aug 1997 15:58:13 +0200 (MET DST)
- To: Judith Slein <slein@wrc.xerox.com>
- cc: Yaron Goland <yarong@microsoft.com>, w3c-dist-auth@w3.org
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