Re: Prelim. DAV spec.

At 02:31 PM 10/31/96 PST, Henrik Frystyk Nielsen wrote:
>At 12:34 PM 10/31/96 PST, Larry Masinter wrote:
>># If there are cases where variants are NOT computed on the fly, what should
>># happen when someone creates a new version of the resource (by editing
>one of
>># the variants)?  I assume the user would normally prefer for the other
>># variants to be brought into synch automatically -- for new versions of them
>># to be generated from the one he submitted.  Do we want to do anything to
>># support this?
>>
>>It depends on how the variants are computed. If they can be
>>automatically generated, you might want to update them automatically,
>>but the state of language translation software, for example, isn't
>>really up to automatically regenerating the French page from a new
>>version of the English page, for example.
>>
>>Since there's not a general solution, the question is whether we need
>>or want to do anything in the protocol. I don't think so.
>
>Yes indeed. Whether representations are generated on the fly or not is an
>implementation detail - not subject for protocol definition. The same is
>the case for CGI-script outputs - you can't see on a URL what it produces
>when you poke it (except from the cases where you peek into the URL and
>find tokens like "cgi-bin" or "htbin" :-))
>

I didn't want to place any constraints on whether variants are persistent or
not.  I just wanted to suggest that we provide a way for a user who creates
a new version of a resource to say "Please generate for this new version all
the variants that existed for the previous version" or "Please generate the
following variants for this version".  If it turned out that variants for
the resource were always created on the fly, nothing would have to be done
for this request.  If the server could not satisfy the request, ... well,
we'd have to decide whether it should create the new version anyway or just
fail.

--Judy
Name:		Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Phone:  	8*222-5169
Fax:		(716) 265-7133
MailStop:	128-29E

Received on Thursday, 31 October 1996 17:54:39 UTC