Re: Clarification of reset behaviour

First of all, it seems you understood the spec correctly.  See below for
more detailed answers.

Brian Birtles wrote:
> Dear all,
> 
> I believe some clarification of restart and reset behaviour in SMIL is
> required. Specifically, it is not clear to me at what point in the
> element life-cycle the restart (and corresponding reset) actually
> occurs. Please allow me to illustrate.
> 
> Consider an animation with begin="indefinite", restart="always" and
> where the following sequence of calls are made by script at time t=0s:
> 
>   beginElementAt(1)
>   endElementAt(2)
>   beginElementAt(3)
>   endElementAt(4)
>   beginElementAt(5)
>   endElementAt(6)
> 
> This should generate an interval: 1s-2s. After that I believe the
> behaviour is somewhat unclear and perhaps contradictory for the
> following reasons:
> 
> 1) It is not clear when restart and particularly reset behaviour should apply

[1] states: "When a time container repeats or restarts, ...".  This
should be interpreted as "At the time a time container repeats or
restart".  In other words, the reset in your case happens at t=3.

> SMIL 3.0 describes the behaviour for resetting element state which
> includes clearing all instance times generated by DOM calls and events
> in the past with the exception of the instance time defining the
> beginning of the current interval.[1]
> 
> However it is not obvious to me at which point this behaviour is
> effected. I believe the most natural reading of the spec is that the
> reset occurs at t=3s as that is when the animation "restarts".
> 
> Thus, in the example, after the interval 1s-2s plays to completion
> another interval will be constructed from 3s-4s. At t=3s the animation
> becomes active again, the animation restarts, and the instance times
> are reset.
> 
> Whether this reset occurs at t=2s or t=3s will produce different
> results if further instance times are generated between t=2s and t=3s,
> that is, whilst the animation is waiting to begin.
> 
> More significant however is the next issue:
> 
> 2) Some end instances must be preserved
> 
> In the example, if a reset is performed at t=3s, all instance times
> generated by DOM calls made in the past will be cleared except the
> instance time defining the beginning of the current interval, i.e. the
> begin instance time at 3s. Since all the DOM calls occurred at t=0s,
> they will all be cleared leaving only the one begin instance time of
> t=3s.

Correctly analyzed.

> (ASSUMPTION: SMIL 3.0 refers to, "Any instance times associated with
> past Event-values, Repeat-values, Accesskey-values or added via DOM
> method calls..." I understand this to mean instance times generated by
> a DOM call where the DOM call occured in the past, NOT instance times
> that are "in the past" according to their position in the document
> timeline relative to the current time. I believe this is consistent
> with the other prose describing reset behaviour.)
> 
> This behaviour is problematic because, in the example, we have an
> active interval from 3s-4s but after resetting the end instance of 4s
> will have been cleared. Thus any action that causes us to reevaluate
> the current interval will result in us noticing that our end instance
> has disappeared and causing the interval to unexpectedly change or
> even be deleted.

The behavior may indeed be problematic, but it is the defined behavior.
 You could (in this example) get around it by having end="beginEvent+1s"
or dur="1s" on the element.  I realize this may not always be possible.

It might be a good idea if a new SYMM working group is to start and
consider a new version of SMIL, to provide this issue as input.  Jack
and I were thinking of changing [2] to only clear the intervals on child
elements of the element being restarted/repeated and not clearing the
intervals of the element itself.  This is, however, a change in behavior
and can therefore not be considered as an erratum to the current spec.

> 3) It is not implemented (in SVG implementations)
> 
> In my tests of Batik 1.7, Opera 10.10, and WebKit nightly (10 Dec 09),
> all three show three intervals (although all differ in their actual
> results: Batik seems to ignore the end constraints, WebKit seems to
> use the final fill value). That is to say that it does not appear that
> the instance times are cleared upon a restart or else we would have
> only 1 or 2 intervals (depending on some of the issues discussed
> above).
> 
> This is perhaps the least significant issue but I mention it because
> it suggests I have entirely misunderstood this behaviour, or that
> implementors have taken issue with it/overlooked it/misunderstood it,
> or both.

I think you understood this correctly.  These implementations are wrong.

> 4) It is not consistent
> 
> This ties in with (1) and I will not elaborate on it here except to
> note that if my understanding is correct, that in the example the
> reset occurs at t=3s, then this will produce different results
> depending on whether we are beginning the first interval or the second
> interval (as we do not reset instance times at t=1s). It would be more
> consistent if we perform reset behaviour upon ending an interval (i.e.
> at t=2s) and in that case it must be specified whether the instance
> times are reset before or after establishing the next interval
> (presumably it is after since otherwise it would be meaningless to
> talk about keeping the instance time that defines the beginning of the
> current interval).

We cannot change this now, but if we take the approach as outlined
above, we could probably also get the effect you want.  A new SYMM group
would have to study the matter carefully.

> 5) The analogue with backwards seeking is not obvious
> 
> The description of backwards seeking behaviour in relation to
> hyperlinking provides the following:
> 
>   Resolved begin times (e.g. a begin associated with an event) are not
>   cleared or lost by seeking to an earlier time. Resolved end times
>   associated with events, Repeat-values, Accesskey-values or added via
>   DOM method calls are cleared when seeking to time earlier than the
>   resolved end time. This follows the semantics for resetting element
>   state.[2]
> 
> I cannot see an obvious analogue here between this behaviour which
> makes such a sharp distinction between begin and end instance times
> and the behaviour for resetting element state where the distinction is
> more subtle.

The analogue is that in both cases the element begins and the event or
DOM time that was added for the end of the interval is removed.  In that
sense, the behavior is consistent.

> (Furthermore, the behaviour is problematic because, as with (2), if we
> clear end instances in this manner we may in fact cause an historical
> interval to be deleted altogether since there is now no longer any
> matching end instance with which to construct an interval. This, to
> me, seems contrary to the intent of the spec here. Rather, as with
> (2), certain end instances must be preserved.)

Elements may begin without there being an end in sight.  This is
equivalent to having end="indefinite".  For animations this may be
problematic, however, since they often need some fixed duration over
which to change a value.

> 
> Thank you for any help you can offer! I apologise for such a long
> message. I hope we can clarify some of these matters because, as I
> have noted in (3), current implementations all differ on these matters
> from one another and, I suspect, from the specification.
> 
> Best regards,
> 
> Brian Birtles
> 
> [1] http://www.w3.org/TR/SMIL/smil-timing.html#q44
> [2] http://www.w3.org/TR/SMIL/smil-timing.html#q114
> 

I hope this helps.

[1] http://www.w3.org/TR/SMIL3/smil-timing.html#Timing-ResettingElementState
[2] http://www.w3.org/TR/SMIL3/smil-timing.html#q44

-- 
Sjoerd Mullender