Re: frozen value for discrete animation

I understand the problem of discrete animations with a keyTimes value of
1 and a freeze and/or repeat in combination with the exclusive end time
model.  I think your solution to disallow a value of 1 for keyTimes in
discrete animations has merit.  However, I am a bit uncomfortable with
it.  My main issue is, how to determine whether an animation is
discrete.  If the playback engine does not support interpolated
animations on some value, it treats the animation as discrete, thereby
causing the same problem again.

Another solution might be to specify that in the case of a discrete
animation and a keyTime of 1, the time should be understood to be the
smallest possible fraction *before* the full duration.  In that case,
the final value is reached before the end, and all problems are also
resolved.  Or am I missing something here?

Dr. Olaf Hoffmann wrote:
>> 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
>>
> 
> 


-- 
Sjoerd Mullender