Re: frozen value for discrete animation

> I thought we had something in there somewhere to make the fill value take
> the exclusive endpoint value (as all authors would want, if not expect, and
> even if they understand the interval timing model as we do).

No, if one understands this interval timing model and maybe the
mathematical concept of a limes, it would be surprising to have an
additional specific rule to get the exclusive endpoint. There is no
need for a specific rule. Some more of such exceptions and the 
interval timing model with exclusive end is not useful for anything ;o)

The main reason to discuss the situation of the exclusive end for
a continuous (linear, paced or spline) animation seems to be to
avoid that implementors have to identify this themselves as the 
correct limes in the interval timing model with exclusive end.
In a perfect world for those continuous animations there is no 
need for a specific rule, but I can understand this as a simplification 
for implementors. But for discrete animation these rules do not
create the correct result related to the mathematical limes
for the time interval model, therefore for the discrete animation 
the result from the simplifying formulars in SMIL2 gets 
counterintuitive using the exclusive endpoint as a frozen value.

With interactive begin or end the probabilty that it happens is
very low and the main application doing this with offset values is
to test, if the time interval model is implemented correctly in a viewer.
Else I cannot imagine any other expectation for this relatively
exotic situation for authors as the mathematical correct limes
within the interval timing model ;o)

Using the interval timing model and having a discrete animation,
we identified in another discussion a problem with the value 1
for keyTimes. According to the definition of keyTimes for 
discrete animation, 1 is allowed, but it creates always an
empty or invalid interval at the end. For this, there can be
some wording interpreted as specific rule to take this as the
frozen value (if there is no cut off simple duration). But
this creates some more curious effects concerning accumulative
animations, because within the active duration the empty
interval related to keyTimes 1 is always ignored. But freezing
the animation at a multipe  of the simple duration results
in a multiple of the value for the keyTimes 1, creating a
surprising big jump at the end.

Therefore keyTimes 1 for discrete animation is a surprising
thing too, surprising that it is allowed together with the interval
timing model, not useful at all and creating maybe minor 
specific implementation trouble to get it right with accumulative
animation ;o)

>
> I forget where this was, but I remember discussing it. Will hunt around
> when I get back online (writing from the train).
>
> Patrick
>

Received on Tuesday, 29 May 2007 12:20:12 UTC