This section provides some clear rules including the following:
"2. Do not change any interval time that is in the past. Do not prune
an interval that has already begun. Note that this refers to intervals
and not instance times.
"3. When building an interval from a set of instance times, if the
duration is resolved and negative, reject the interval; do not
propagate the interval to time dependents.
A. When the current interval has not yet begun, if the interval
times change such that the duration is negative, prune the interval."
However, whilst the behaviour for an interval that has not yet begun
is clearly specified, the only rule provided for an interval that HAS
already begun is simply: do not prune.
Consider the following example. At t=4s, an interval with begin=3s,
end=5s is playing. Then some chain of syncbase dependencies is fired
causing the end time to be updated to 2s. We now have an active
interval from 3s to 2s which is invalid since it is negative. What
should be the behaviour in this case?
We can't prune the interval. But can we say the interval is trimmed?
I think the following areas of behaviour need to be specified:
* Animation function: this is probably the easiest--can we assume that
from the moment the active interval becomes invalid it is no longer
applied? But then do fill effects apply as in the case of a normal
* Syncbase behaviour: if there are instance times dependent on the end
of our active interval what time to they get? 2s? 3s? 4s? or 5s?
* Events: is an end event fired? Presumably yes. And if so, what is
the timestamp associated with the event?
-- Furthermore, should this end event be acted on by dependencies?
(On this last point, I am under the impression that some end events
should be ignored. The section of "Hyperlinks and timing" under
section 5.4.5 talks about raising end events and yet says "This action
does not resolve any times in the instance times list for end times."
I take this to mean that end events generated under such circumstances
should be ignored by animations that would otherwise be dependent on
end events. )
It is possible that this behaviour is specific elsewhere in SMIL but
as yet I haven't found it. In either case I'd greatly appreciate your