Fwd: Clarification of zero-duration intervals

Folks,
I did some investigating into the following message that came in  
yesterday. I hope someone better aware of the intricacies of the  
timing module (Sjoerd?) can check that my findings are correct (or,  
more likely, refute them:-) and suggest a course of action.

- E14 from the referenced errata is in SMIL 2.0 second edition, and  
carries forward to today.

- E15 was inadvertently applied to getFirstInterval() in stead of  
getNextInterval() for SMIL 2.0 second edition. This incorrect fix was  
not noticed, and happily carried over to SMIL 2.1 and SMIL 3.0.

- I checked the Ambulant scheduler, and it contains the fixes as  
stated in the errata, not the incorrect pseudocode that is in SMIL  
2.0SE, SMIL 2.1 and SMIL 3.0.

- I checked the discussion on the original errata (october-november  
2001 in the mailing list archive), and I couldn't find any mention of  
what our intention was for multiple zero-duration intervals. I think  
we've simply overlooked the possibility (but maybe someone with better  
memory remembers?).

Begin forwarded message:

> Resent-From: www-smil@w3.org
> From: Brian Birtles <birtles@gmail.com>
> Date: January 22, 2009 02:35:57  GMT+01:00
> To: www-smil@w3.org
> Subject: Clarification of zero-duration intervals
>
> Dear all,
>
> I would like to request a review of the pseudocode for  
> getFirstInterval and getNextInterval in all versions of the SMIL  
> specification, including SMIL3. It would be most helpful if this  
> pseudocode was also accompanied by a prose description of the  
> behaviour of zero-duration intervals.
>
> In my previous message I referred to the following piece of  
> pseudocode:
>
>    If (currentInterval.end > currentInterval.begin)
>        Set tempBegin = the first value in the begin list that is >=  
> beginAfter.
>    Else
>        Set tempBegin = the first value in the begin list that is >  
> beginAfter.
>
> I believe that this belongs in getNextInterval as indicated in the  
> SMIL2 errata.[1]
>
> Assuming that this is correct, and noting that beginAfter =  
> currentInterval.end, it would appear that this condition disallows  
> non-zero-duration intervals after zero-duration intervals. That is,  
> suppose currentInterval.end == currentInterval.begin (and therefore  
> == beginAfter). In such a case tempBegin = the first value in the  
> begin list that is > currentInterval.end.
>
> So if we have:
>
> begin=1s; 1s
> end=1s; 3s
> dur=1s
>
> We would make an interval from 1s-1s initially, then when we come to  
> get the next interval we would note that for the previous interval  
> currentInterval.end == currentInterval.begin and so we would search  
> for the first value in the begin list that is > 1s, which doesn't  
> exist and so we would fail and the result being that we would yield  
> only one interval and not two. Therefore it is not possible to have  
> a non-zero-duration interval after a zero-duration interval  
> according to the pseudocode quoted above.
>
> It should also be clarified what the expected results are for the  
> following:
>
> begin=1s
> end=1s; 3s
>
> Is it one interval, 1s-1s? Or two: 1s-1s, 1s-3s. i.e. can we re-use  
> a begin time? The pseudocode suggests we re-use begin times and I  
> this makes implementation easier.
>
> Whatever the result, something analogous should happen in  
> getFirstInterval for the following case:
>
> begin=-0.5s
> end=-0.5s; 1s
>
> Perhaps the rules is that we cannot have more than one zero-duration  
> interval with the same begin time?
>
> Such that
>
> begin=1s
> end=1s; 1s; 1s; 3s;
>
> produces two intervals
>
> I have tested many of these scenarios with various implementations  
> and they produce different results so I hope this issue can be  
> clarified.
>
> Thank you.
>
> Best regards,
>
> Brian Birtles
>
> [1] http://www.w3.org/2001/07/REC-SMIL20-20010731-errata#E14

--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman