Re: SMIL21: Duplicated event definitions

Bjoern,

I do not think this is a bug.
The Timing and Synchronization Module defines defines a set of events 
that may be included by a host language, and each Profile specifies 
which types of events can be used .

Therefore:

1- The beginEvent event is defined in the The SMIL 2.1 Timing and 
Synchronization Module
http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil-timing.html#Timing-DOMEvents

*beginEvent*
    This event is raised when the element local timeline begins to play.
    It will be raised each time the element begins the active duration
    (i.e. when it restarts, but not when it repeats). It may be raised
    both in the course of normal (i.e. scheduled or interactive)
    timeline play, as well as in the case that the element was begun
    with a DOM method.

2-It is also defined in the following available Profiles

- Language Profile
http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil21-profile.html

- Mobile Profile
http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil21-mobile-profile.html#q20

-Extended Mobile Profile
http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil21-extended-mobile-profile.html#q20


beginEvent:
    Raised when the element actually begins playback of its active
    duration. If an element does not ever begin playing, this event is
    never raised. If an element has a repeat count, beginEvent only is
    raised at the beginning of the first iteration. The beginEvent is
    delivered to elements which support timing, such as media elements
    and time containers, and does not bubble.


Thierry.



Bjoern Hoehrmann a écrit :

>Dear Synchronized Multimedia Working Group,
>
>  http://www.w3.org/TR/2005/PR-SMIL2-20050927/ duplicates some text, one
>example is the definition of the beginEvent event
>
>  This event is raised when the element local timeline begins to play.
>  It will be raised each time the element begins the active duration
>  (i.e. when it restarts, but not when it repeats). It may be raised
>  both in the course of normal (i.e. scheduled or interactive) timeline
>  play, as well as in the case that the element was begun with a DOM
>  method. 
>
>and
>
>  Raised when the element actually begins playback of its active
>  duration. If an element does not ever begin playing, this event is
>  never raised. If an element has a repeat count, beginEvent only is
>  raised at the beginning of the first iteration. The beginEvent is
>  delivered to elements which support timing, such as media elements and
>  time containers, and does not bubble. 
>
>and
>
>  Raised when the element actually begins playback of its active
>  duration. If an element does not ever begin playing, this event is
>  never raised. If an element has a repeat count, beginEvent is only
>  raised at the beginning of the first iteration. The beginEvent is
>  delivered to elements that support timing, such as media elements and
>  time containers, and does not bubble. 
>
>and
>
>  Raised when the element actually begins playback of its active
>  duration. If an element does not ever begin playing, this event is
>  never raised. If an element has a repeat count, beginEvent is only
>  raised at the beginning of the first iteration. The beginEvent is
>  delivered to elements that support timing, such as media elements and
>  time containers, and does not bubble. 
>
>I am not sure why it does that (it seems like this is duplicated for
>each profile), but these are 3 slightly different definitions and can
>easily be confused; there are also problems like that the first
>definition does not define the intrinsic bubbling behavior of the event.
>
>I think these events should be defined just once; if there are profile-
>specific considerations these should be called out explicitly for the
>profiles.
>  
>

Received on Monday, 12 December 2005 11:10:23 UTC