RE: Renditions Proposal

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

I prefer to think of variants as independent URIs which can be manipulated through commands on the "master" URI i.e. allow for variants to be discovered with commands like "give me the list of variants on this URI" or "Add this resource as a German translation variant for this URI". These commands could then be performed on the result of previous discovery commands which would then allow a client to discover as many levels of the variant tree from a master URI as it requires and manipulate them in any way required.

The server would be responsible for the URI construction.

This should be flexible enough to be used for all sorts of variants (eg master document is a Word97 English document with HTML and PDF renditions and a German Word97 translation. The German translation could then also have HTML and PDF renditions which would be manipulated via the discovered German URI)

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

I think this is the only way to deal with the problem properly

Cheers
Dylan

Received on Friday, 29 August 1997 10:56:50 UTC