Table of contents

• 18.1 Overview and Summary of Changes for SMIL 3.0
• 18.2 Abstract
• 18.3 Introduction to the SMIL 3.0 UnifiedMobile Profile
  • 18.3.1 Relationship with the 3GPP2 SMIL Language Profile
• 18.4 Normative Definition of the UnifiedMobile Profile
  • 18.4.1 SMIL 3.0 UnifiedMobile Profile Conformance
  • 18.4.2 SMIL 3.0 UnifiedMobile Profile User Agent Conformance
  • 18.4.3 The SMIL 3.0 UnifiedMobile Profile
  • 18.4.4 Animation Module
  • 18.4.5 Content Control Modules
  • 18.4.6 Layout Modules
  • 18.4.7 Linking Modules
  • 18.4.8 Media Object Modules
  • 18.4.9 Required MIME Types
    • Media Object Integration Requirements
  • 18.4.10 Metainformation Module
  • 18.4.11 Structure Module
  • 18.4.12 Timing and Synchronization Modules
    • Supported Event Symbols
    • Event semantics
    • Order of raising of simultaneous events:
    • Extending the set of supported events
    • Integration definitions
  • 18.4.13 Transition Effects Modules
• 18.5 Appendix A: SMIL 3.0 Document Type Definition

This section is informative.

The SMIL 3.0 UnifiedMobile profile integrates the functionalities of theSMIL 2.1 Mobile[SMIL21-mobile-profile] and SMIL 2.1 Extended Mobile[SMIL21-extended-mobile-profile] profiles, and aligns the specificationwith newly structured existing functionality, plus extends thefunctionalities available in SMIL 2.1 with modules introduced in SMIL 3.0.

The following modules used in earlier mobile profiles were changed forSMIL 3.0:

• BasicContentControl
• BasicLayout Module
• MediaParam Module
• Metainformation Module

Restructuring of existing SMIL 2.1 functionality in SMIL 3.0 has resultedin the inclusion of the following new modules:

• RequiredContentControl Module
• StructureLayout Module
• MediaRenderAttributes Module
• Identity Module

The following modules contain new or expanded functionality in theUnifiedMobile profile in SMIL 3.0:

• BasicText Module
• TextStyling Module
• TextMotion Module
• SMIL DOM Module
• MediaPanZoom Module

In addition to new and changed modules, this version of SMIL also has anew requirement about the media formats that are to be supported by useragents.

This section is normative.

The SMIL 3.0 UnifiedMobile profile is a collection of SMIL 3.0 modulesthat provide extensive support for the SMIL 3.0 Language within the contextof a representative (for 2008) mobile device. Such a device is expected tohave a high-resolution display and sufficient memory and processor capacityto render nontrival SMIL documents. Although not as complete as the fullSMIL 3.0 Language Profile, the SMIL 3.0UnifiedMobile profile is rich enough to meet the needs of a wide range ofinteractive presentations.

The functionality of the SMIL 3.0 UnifiedMobile profile may be extended orreduced by using theSMIL 3.0Scalability Framework.

The W3C Synchronized Multimedia Working Group (SYMM) recognizes that manymobile handsets will be configured according to the specifications of otherindustry standards organizations. The UnifiedMobile profile has beendeveloped in part to give these organizations guidance on the functionalitywithin SMIL that the SYMM working groups feels appropriate for considerationin specifications that are based (in part) on this document.

This section is informative.

The SMIL 3.0 UnifiedMobile profile is defined as a markup language. Thesyntax of this language is formally described with a document type definition(DTD) or an XML Schema which is based on the SMIL modules as defined in "The SMIL 3.0 Modules".

The UnifiedMobile profile design requirements are:

1. Ensure that the profile is backward compatible with the SMIL 2.1 Mobile and Extended Mobile Profiles.
2. Ensure that the profile is a proper subset of theSMIL 3.0 Language Profile.

18.3.1 Relationship with the 3GPP2 SMILLanguage Profile

The Third Generation Partnership Project 2 (3GPP2)[3GPP2] defines itsown SMIL language profile. The revision A of the 3GPP2 SMIL File Formats forMultimedia Services, defines the SMIL profile including some additionalmodules compared to the 3GPP SMIL profile[3GPP26.234R5];AccessKeyTiming Module,MultiArcTiming Module,BasicAnimationModule andAudioLayout Module. Afuture revision of it may incorporate SMIL 3.0.

The UnifiedMobile profile includes all modules of 3GPP2 revision A SMIL,plus:BasicExclTimeContainersModule,SubRegionLayoutModule,BackgroundTilingLayoutModule,AlignmentLayoutModule,OverrideLayoutModule,FullScreenTransitionsModule,BasicTextModule,TextStylingModule,TextMotionModule,SMIL DOM Module,MediaPanZoomModule and theBrushMediaModule.

Note: because of the repartitioning of some SMIL modules (such asBasicContentControlandBasicLayout),3GPP and SMIL 3.0 are no longer aligned with respect to module definition,but the collection of elements and attributes have not changed.

This section is normative.

In the text in this profile specification, the termUnifiedMobileProfile will be considered to refer exclusively to the SMIL 3.0UnifiedMobile profile as defined in this document.

18.4.1SMIL 3.0 UnifiedMobile ProfileConformance

The definition of conformance for a SMIL 3.0 profile is given in theDefinitionssection of theSMIL 3.0 ScalabilityFramework. Based on these definitions, the UnifiedMobile profile is aStrictHost-Language Conformant SMIL 3.0 Profile.

Within the referenced sections of the Scalability Framework, the followingdefinitions should be used:

1. The profile identification string for the UnifiedMobile profile is:http://www.w3.org/2008/SMIL30/UnifiedMobile.
2. Documents written for the UnifiedMobile profile must declare the default SMIL namespace with thexmlns attribute on thesmil root element. For SMIL 3.0, this is:

   xmlns="http://www.w3.org/ns/SMIL"

3. The SMIL 3.0 UnifiedMobile profile DOCTYPE is:

   <!DOCTYPE smil PUBLIC "-//W3C//DTD SMIL 3.0 UnifiedMobile//EN""http://www.w3.org/2008/SMIL30/SMIL30UnifiedMobile.dtd">

   If a document contains this declaration, it must be a valid XML document. Note that this implies that extensions to the syntax defined in the DTD (or in the corresponding XML or RelaxNG schemas) are not allowed. If the document is invalid, the user agent should issue an error.
4. The identification string for the non-normative DTD used for integration of errata is:

   http://www.w3.org/2008/SMIL30/informative-DTD/SMIL30UnifiedMobile.dtd

5. Documents written for the UnifiedMobile Profile must declare (explicitly or implicitly via the DTD) the following values for theversion andbaseProfile attributes:

   version="3.0" baseProfile="UnifiedMobile"

   As a consequence of the two requirements above, the effective root element declaration for a UnifiedMobile profile document must be:

   <smil xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="UnifiedMobile">     ...</smil>

   The root element may be extended as required with additional atttributes.

This version of SMIL provides a definition of strict host-languageconformant SMIL 3.0 documents, which are restricted to tags and attributesfrom the SMIL 3.0 namespace. The Section "Extending/Restrictinga SMIL 3.0 Profile" provides information on using the SMIL 3.0UnifiedMobile profile with other namespaces, for instance, on including newtags within SMIL 3.0 documents.

Language designers and implementors wishing to extend the UnifiedMobileprofile must consider the implications of the use of namespace extensionsyntax. Please consult the section onScalable Profiles for restrictionsand recommendations for best practice when extending SMIL.

18.4.2SMIL 3.0 UnifiedMobile Profile User AgentConformance

The definition of user agent conformance for SMIL 3.0 UnifiedMobileprofile documents is given in theConformingSMIL 3.0 User Agents section of theSMIL 3.0 Scalability Framework.Conforming UnifiedMobile profile user agents must adhere completely to thissection.

18.4.3 The SMIL 3.0 UnifiedMobile Profile

The UnifiedMobile profile supports the multimedia document featuresappropriate for mobile platforms. It uses only modules from the SMIL 3.0recommendation. This profile includes the following SMIL 3.0 modules:

• Structure functionality
  • Structure Module
  • Identity Module
• Metainformation functionality
  • Metainformation Module
• Timing functionality
  • BasicInlineTiming Module
  • EventTiming Module
  • RepeatTiming Module
  • MultiArcTiming Module
  • AccessKeyTiming Module
  • BasicTimeContainers Module
  • BasicExclTimeContainers Module
• Animation functionality
  • BasicAnimation Module
• Content Control functionality
  • BasicContentControl Module
  • PrefetchControl Module
  • RequiredContentControl Module
  • SkipContentControl Module
• Layout functionality
  • BasicLayout Module
  • StructureLayout Module
  • AudioLayout Module
  • SubRegionLayout Module
  • BackgroundTilingLayout Module
  • AlignmentLayout Module
  • OverrideLayout Module
• Linking functionality
  • BasicLinking Module
  • LinkingAttributes Module
• Transition Effects functionality
  • BasicTransitions Module
  • FullScreenTransitions Module
• Media functionality
  • BasicMedia Module
  • MediaClipping Module
  • MediaDescription Module
  • MediaPanZoom Module
  • MediaParam Module
  • MediaRenderAttributes Module
  • BrushMedia Module
  • MediaAccessibility Module
• SmilText functionality
  • BasicText Module
  • TextStyling Module
  • TextMotion Module
• DOM Integration functionality
  • SMIL DOM Module

The collection names contained in the following table define theUnifiedMobile profile vocabulary.

In the following sections, we define the set of elements and attributesused in each of the modules included in the UnifiedMobile profile. Thecontent model for each element is described. The content model of an elementis a description of elements which may appear as its direct children. Thespecial content model "EMPTY" means that a given element may not havechildren.

Thexml:id andid attribute are used in the UnifiedMobileProfile to assign a unique XML identifier to every element in a SMILdocument. Thexml:id andid attributes are equivalent and must not bothbe used on an element. Thexml:idshould be used in preference to theidattribute.
When the document uses the SMIL 3.0 UnifiedMobile Profile DOCTYPE, onlyxml:id must be used.

Thexml:id, [id],classandtitle attributes in thecollectionCore are defined for all the elementsof the SMIL3.0 UnifiedMobile profile.

In this document, equivalent but deprecated attributes and elements are insquare brakets.

A conforming UnifiedMobile profile document should not use the SMIL 1.0attributes that have been depreciated in SMIL 2.0. UnifiedMobile profileimplementations are not required to support these attributes. This would beconsidered an unjustified burden for the targeted constraint devices. Theunsupported depreciated SMIL 1.0 attributes are the following: anchor,background-color, clip-begin, clip-end, repeat; and the additionaldepreciated test attributes of Content Control: system-bitrate,system-captions, system-language, system-required, system-screen-size, and,system-screen-depth.

18.4.4 Animation Module

TheAnimation Module provides aframework for incorporating animation into a timing framework, and amechanism for composing the effects of multiple animations. The AnimationModule uses the timing modules included in this profile for the underlyingmodel of time. The UnifiedMobile profile includes the Animation functionalityof theBasicAnimation module. TheBasicAnimation Module defines the semanticsfor theanimate,set,animateMotion andanimateColor elements.

In the UnifiedMobile profile, Animation elements may have the followingattributes and content model :

This profile adds theanimate,set,animateMotion andanimateColor elements to the contentmodel of thepar,seq, andexcl elements of theTiming and Synchronization Modules. It also addsthese elements to the content model of thebody element of theStructure Module.

Specifying the target element of the animation

The animation target elements supported in the UnifiedMobile profile aretheregion element defined in theLayout Modules, thearea [anchor] element defined in theLinking Modules and thetext,img,audio,animation,video,ref,textstream and thebrush elements defined in theMedia Objects modules.

The SMIL UnifiedMobile profile uses thetargetElement attribute to identifythe element to be affected by animation elements. As recommended in theBasicAnimation Module when thetargetElement attribute issupported, this profile excludes the XLink attributeshref,type,actuate andshow from theanimate,set,animateMotion andanimateColor elements.

Specifying the target attribute of the animation

The target attributes of the animations are a subset of those of theregion,area [anchor], and media elements. The animatableattributes of theregion,area [anchor], and media elements are listed inthe table below.

Thearea [anchor] element has thecoords attribute which may be subject toanimation. The attributecoords isconsidered of type string in this profile. This means that only discretenon-additive animation is supported on this attribute.

Media elements have the following region attributes which may be subjectto animation:left,right,top,bottom,width,height,z-indexandbackgroundColor [background-color].

Integration definitions

The UnifiedMobile profile defines a set of integration definitions asrequired by the Animation modules. These definitions are:

• Animation values in the UnifiedMobile profile are subject to the same syntax requirements as the attribute values on the animated elements.
• Percentage values on the attributes have the same semantics as they do on the attribute. If percentage values are not supported on an attribute then percentage values are not supported for animation in the SMIL 3.0 UnifiedMobile profile.
• The UnifiedMobile profile supports CSS2[CSS2] color names. The lower clamping bound color value is the black color or rgb(0%, 0%, 0%) and the higher clamping color value is the white color or rgb(100%, 100%, 100%). Values on an animated color lower than the lower clamping bound are clamped to the black color; values greater than the higher clamping color are clamped to the white color.
• The semantics of clamping values for attributes should be performed in floating point with a precision of at least that given by a 4-byte IEEE-format real number[IEEE-Arithmetic]. Cumulative and additive presentation values should be computed without regard to the range of the target attribute. Prior to display, the presentation value should be reduced or increased to the nearest value which is within the range of the target attribute. For integer attributes the computed value should then be rounded to the nearest integer (coerced-integer-value). The mathematical definition of rounding is:

  coerced-integer-value = Math.floor( interpolated-value + 0.5 )

• The position of the region element to which theanimateMotion element applies is the top left corner, in the coordinate system within which the 'top' and 'left' attributes are defined in the Layout modules.
• The origin for theanimateMotion when applied to the sub-region on media elements is the top left of the containing region as defined in theLayout modules.

18.4.5 Content Control Modules

TheContent Control Modules provide aframework for selecting content based on a set of test attributes. TheContent Control Modules define semantics for theswitch andprefetch elements. The UnifiedMobileprofile includes the Content Control functionality of theBasicContentControl,RequiredContentControlModule,PrefetchControlandSkipContentControlmodules.

In the UnifiedMobile profile, Content Control elements may have thefollowing attributes and content model :

This profile adds theswitchelement to the content model of thepar,seq andexcl elements of theTiming and Synchronization Modules, of thebody and thehead elements of theStructure Module, of the content model of thea element of theLinking Modules.

Content Control functionality is used to define the attribute setTest:

The Test attributes collection is added to all the elements defined in theUnifiedMobile profile. An UnifiedMobile user agent must support all of thevalues for thesystemOperatingSystem andsystemCPUattributes listed in theContent Control Modules. In addition, the user agent should accept namespacedvalues as future extensions, and not declare a syntax error. The user agentshould return false for unrecognized values of thesystemOperatingSystem andsystemCPUattributes.

18.4.6 Layout Modules

TheLayout Modules provide a framework forspatial layout of visual components. TheLayoutModules define semantics for theregion,root-layout,layout and theregPoint elements. The UnifiedMobileProfile includes the Layout functionality of theBasicLayout,StructureLayoutModule,AudioLayout,SubRegionLayout,BackgroundTilingLayout,AlignmentLayout,OverrideLayoutmodules.

In the UnifiedMobile profile, Layout elements may have the followingattributes and content model :

The attribute collection SubregionAttributes is defined as follows:

This profile adds thelayoutelement to the content model of thehead element of theStructure Module. It also adds this element tothe content model of theswitchelement of theContent Control Modules, whentheswitch element is a child of thehead element.

18.4.7 Linking Modules

TheLinking Modules provide aframework for relating documents to content, documents and documentfragments. TheLinking Modulesdefine semantics for thea andarea [anchor] elements. They define also thesemantics of a set of attributes defined for these elements. The SMIL 3.0UnifiedMobile profile includes the Linking functionality of theBasicLinkingandLinkingAttributesmodules.

Both thea andarea [anchor] elements have anhref attribute, whose value must be a validURI.

Support for URIs with XPointer fragment identifier syntax is notrequired.

In the UnifiedMobile profile, Linking elements may have the followingattributes and content model :

This profile adds thea element to thecontent model of thepar,seq, andexcl elements of theTiming and Synchronization Modules. It also addsthese elements to the content model of thebody element of theStructure Module.

In the UnifiedMobile profile, a value ofonLoad set on the attributeactuate indicates that the link isautomatically traversed when the linking element becomes active. For linkingelements containing SMIL timing, this is when the active duration of thelinking element begins.

Linking behavior in the UnifiedMobile profile may be used to navigatewithin a document or to link across documents. When linking to destinationsoutside the current document, implementations may ignore the values"play" and"pause" of thesourcePlaystate attribute,and the values"new" and"pause" of theshow attribute; in these cases, the semanticsof the"stop" attribute (forsourcePlaystate) and the"replace" attribute (forshow) should be used. If an implementationignores the values of thesourcePlaystate andshow attributes, it may also ignore thesourceLevel attribute.

The attributetabindex specifiesthe position of the element in the tabbing order at a particular instant forthe current document. The tabbing order defines the order in which elementswill receive focus when navigated by the user via an input device such as akeyboard. At any particular point in time, only active elements are takeninto account for the tabbing order; inactive elements are ignored.

When a media object element has atabindex attribute and becomes active,then its ordered tab index is inserted in the SMIL tab index at the locationspecified by the media object'stabindex attribute value. This assumesthat the media object itself has tab indices, such as embedded HTML withtabindex attributes. This enablesall link starting points in a SMIL presentation to have a place on theordered list to be tab-keyed through, including those in embeddedpresentations.

The UnifiedMobile profile does not define four-way navigation in the SMIL3.0 release. A definition for four-way navigation is expected in the futureversion of SMIL.

18.4.8 Media Object Modules

TheMedia Object Modules providea framework for declaring media. TheMedia Object Modules define semanticsfor theref,animation,audio,img,video,text,textstream,param,paramGroup andbrush elements. The UnifiedMobile Profileincludes the Media Object functionality of theBasicMedia,MediaClipping,MediaParam,BrushMediaandMediaAccessibilitymodules.

In the UnifiedMobile profile, media elements may have the followingattributes and content model:

The attribute collection MediaDescriptionAttributes is defined asfollows:

This profile adds theref,animation,audio,img,video,text,textstream andbrush elements to the content model of thepar,seq, andexcl elements of theTiming and Synchronization Modules and also addsthese elements to the content model of thebody element of theStructure Module. It also adds these elementsto the content model of thea element oftheLinking Modules. Lastly, thisprofile adds theparamGroupelement to theregion element of theLayout Modules.

The following elements are allowed as children of a media objectreference:anchor,area [anchor],param,animate,set,animateColor,animateMotion. Thea element isnot included in this list.Theswitch element is allowed, withthe restriction that in this case the content of the switch may only be fromthe same set of elements as is listed above.

18.4.9 Required MIME Types

The SMIL 3.0 UnifiedMobile profile recommends the use of the followingroyalty-free media formats. Refer to the list ofrecommended MIMETypes.

The following licensed media formats are recommended to be supported:

• For plain text: plain text with US-ASCII ([ASCII]) or UTF-8 ([UTF8]) encoding, MIME type is text/plain.
• for still image: ISO/IEC JPEG ([JPEG]) together with JFIF ([JFIF]), baseline DCT, non-differential, Huffman coding, as defined in table B.1, symbol 'SOF0' in[JPEG], MIME type is image/jpeg.
• For bitmap graphics: PNG, MIME type is image/png ([PNG-MIME],[PNG-REC]).
• For 2D vector graphics: SVG 1.1 Tiny Profile ([SVG-Mobile]), MIME type is image/svg+xml.
• For video: ITU-T Recommendation H.263[H263] profile 0 level 10, part of 3GP file format or H.264[H264].
• For audio: MPEG-4 AAC Low Complexity object type[AAC], part of 3GP file format.
• The file format for audio and for video: the 3GP file format as defined in[3GPP26.234R5].

<switch>  <audio src="non-baseline-format-object" />  <audio src="baseline-format-object" /></switch>

Media Object IntegrationRequirements

The MediaParam module defines theeraseattribute, and defers definition of the "display area" to the languageprofile. "Display area" for the purposes of the UnifiedMobile profilecorresponds to a SMIL BasicLayoutregion. The effects oferase="never"apply after the active duration of the media object and any fill period(defined by SMIL Timing and Synchronization), and only until other mediaplays to the region targeted by the media object, or until the same mediaobject restarts.

18.4.10 Metainformation Module

TheMetainformation Module provides aframework for describing a document, either to inform the human user or toassist in automation. TheMetainformationModule defines semantics for themeta andmetadata elements. The UnifiedMobileProfile includes the Metainformation functionality of theMetainformation module.

In the UnifiedMobile profile, Metainformation elements may have thefollowing attributes and content model :

This profile adds themeta elementto the content model of theheadelement of theStructure Module.

The content model of metadata is empty. Profiles that extend the UnifiedMobile profile may define the RDF (Resource Description Framework) schema tobe used in extending the content model of the metadata element. The ResourceDescription Framework is defined in the W3C RDF Recommendation[RDFsyntax].

18.4.11 Structure Module

The Structure Module provides a framework for structuring a SMIL document.The Structure Module defines semantics for thesmil,head, andbody elements. The UnifiedMobile profileincludes the Structure functionality of theStructure module.

In the UnifiedMobile profile, the Structure elements may have thefollowing attributes and content model :

Thebody element acts as the rootelement to span the timing tree. The body element has the behavior of aseq element. Timing on thebody element is supported. The syncbase ofthebody element is the applicationbegin time, which is implementation dependent, as is the application endtime. Note that the effect offillonthebodyelement is between the end ofthe presentation and the application end time, and therefore the effect offill is implementation dependent.

18.4.12 Timing and Synchronization Modules

TheTiming and Synchronization Modulesprovide a framework for describing timing structure, timing controlproperties and temporal relationships between elements. TheTiming and Synchronization Modules definesemantics forpar,seq andexcl elements. In addition, these modulesdefine semantics for attributes includingbegin,dur,end,repeat (deprecated),repeatCount,repeatDur,min,max.TheUnifiedMobile profile includes the Timing and Synchronization functionalityof theBasicInlineTiming,EventTiming, RepeatTiming, MultiArcTiming, AccessKeyTiming,BasicTimeContainers, BasicExclTimeContainers modules.

In the UnifiedMobile profile, Timing and Synchronization elements can havethe following attributes and content model :

The Attribute collection Timing is defined as follows:

This profile adds thepar,seq, andexcl elements to the content model of thebody element of theStructure Module and adds these elements tothe content model of thea element of theLinking Modules.

Elements of theMedia ObjectModules have the attributes describing timing and properties ofcontents.

Supported Event Symbols

The UnifiedMobile profile specifies which types of events may be used aspart of thebegin andend attribute values. The supported events aredescribed as Event-symbols according to thesyntax introduced in theSMIL Timing and Synchronization module.

The supported event symbols in the UnifiedMobile profile are:

As defined by theSMILsyncbase timing semantics, any event timing attributes that reference aninvalid time-value description will be treated as if "indefinite" werespecified.

Event semantics

focusInEvent:

Raised when a media element gets the keyboard focus in its rendering space, i.e., when it becomes the media element to which all subsequent keystroke-event information is passed. Once an element has the keyboard focus, it continues to have it until a user action or DOM method call either removes the focus from it or gives the focus to another media element, or until its rendering space is removed. Only one media element may have the focus at any particular time. The focusInEvent is delivered to media elements only, and does not bubble.

focusOutEvent:

Raised when a media element loses the keyboard focus from its rendering space, i.e., when it stops being the media element to which all subsequent keystroke-event information is passed. The focusOutEvent is delivered to media elements only, and does not bubble.

activateEvent:

Raised when a media element is activated by user input such as by a mouse click within its visible rendering space or by specific keystrokes when the element has the keyboard focus. The activateEvent is delivered to media elements only, and does not bubble.

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 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.

endEvent:

Raised when an element actually ends playback; this is when its active duration is reached or whenever a playing element is stopped. In the following example,

<ref xml:id="x" end="30s" src="15s.mpg" /><ref xml:id="y" end="10s" src="20s.mpg" /><ref xml:id="z" repeatCount="4" src="5s.mpg" />

x.endEvent occurs at roughly 30s when the active duration is reached, y.endEvent occurs at roughly 10s when the playback of the continuous media is ended early by the active duration being reached, and z.endEvent occurs at roughly 20s when the fourth and final repeat has completed, thus reaching the end of its active duration. The endEvent is delivered to elements which support timing, such as media elements and time containers, and does not bubble.

repeatEvent:

Raised when the second and subsequent iterations of a repeated element begin playback. An element that has norepeatDur,repeatCount, orrepeat attribute but that plays two or more times due to multiple begin times will not raise a repeatEvent when it restarts. Also, children of a time container that repeats will not raise their own repeatEvents when their parent repeats and they begin playing again. The repeatEvent is delivered to elements which support timing, such as media elements and time containers, and does not bubble.

inBoundsEvent:

Raised when one of the following happens:

• by any input from the mouse or other input device that brings the mouse cursor from outside to within the bounds of a media element's rendering space, regardless of what part, if any, of that rendering space is visible at the time, i.e., z-order is not a factor.
• by any other action that moves the "cursor" or "pointer", as defined by the implementation, from outside to within the bounds of a media element's rendering space, regardless of what part, if any, of that rendering space is visible at the time, i.e., z-order is not a factor. An implementation may decide, for instance, to raise an inBoundsEvent on an element whenever it gets the focus, including when keystrokes give it the focus.

A media element's bounds are restrained by the bounds of the region in which it is contained., i.e., a media element's bounds do not extend beyond its region's bounds. The inBoundsEvent is delivered to media elements only, and does not bubble.

Note that, unlike with keyboard focus which may only be active on one object at a time, the state of being within an object's bounds can be true for multiple objects simultaneously. For instance, if one object is on top of another and the cursor is placed on top of both objects, both would have raised an inBoundsEvent more recently than the raising of any respective outOfBoundsEvent. If a player does not support a pointer cursor, then these players will typically not generate the inBoundsEvent and outOfBoundEvent events.

outOfBoundsEvent:

Raised when one of the following happens:

• by any input from the mouse or other input device that brings the mouse cursor from within to outside the bounds of a media element's rendering space, regardless of what part, if any, of that rendering space is visible at the time,
• by any other action that moves the "cursor" or "pointer", as defined by the implementation, from within to outside the bounds of a media element's rendering space, regardless of what part, if any, of that rendering space is visible at the time.

A media element's bounds are restrained by its region's bounds, i.e., a media element's bounds do not extend beyond its region's bounds. The outOfBoundsEvent is delivered to media elements only, and does not bubble.

Order of raising ofsimultaneous events:

There will be cases where events occur simultaneously. To ensure that eachUnifiedMobile implementation handles them in the same order, the followingorder must be used to resolve ties:

1. InBoundsEvent
2. focusInEvent (should follow 1)
3. activateEvent (should follow 2)
4. OutOfBoundsEvent
5. focusOutEvent (should follow 4)
6. endEvent
7. beginEvent (must follow 6)
8. repeatEvent

Events are listed in order of precedence, e.g., if event #6 in this listoccurs at the same time as event #7, then #6 must be raised prior to #7.

The InBoundsEvent, focusInEvent, OutOfBoundsEvent, activateEvent, andfocusOutEvent events do not bubble and are delivered to the target mediaelement.

The beginEvent, endEvent and repeatEvent events do not bubble and aredelivered to the timed element on which the event occurs.

Extending the set ofsupported events

The UnifiedMobile profile supports an extensible set of events. In orderto resolve possible name conflicts with the events that are supported in thisprofile qualified event names are supported. Namespace prefixes are used toqualify the event names. As a result, the colon is reserved in begin and endattributes for qualifying event names.

For example:

<smil ... xmlns:example="http://www.example.com">   <img xml:id="foo" .../>    <audio begin="foo.example:focusInEvent".../>    ... </smil>

Integrationdefinitions

A SMIL document's begin time is defined as the moment a user agent beginsthe timeline for the overall document. A SMIL document's end time is definedas equal to the end time of thebodyelement.

18.4.13 Transition Effects Modules

TheTransition Effects Modules providea framework for describing transitions such as fades and wipes. TheTransition Modules define semantics for thetransition element. The UnifiedMobile Profile includes the functionality of theBasicTransitions andFullScreenTransitionsmodules.

In the UnifiedMobile profile, Transition Effects elements have thefollowing attributes and content model :

This profile adds thetransition element to the content modelof thehead element of theStructure Module.

TheTransition Effects Modules addtransIn andtransOut attributes toref,animation,audio,img,video,text,textstream andbrush elements of theMedia Object Modules.

TheTransition Effects Modules add thetransition value to thefill attribute for all elements on which thisvalue of thefill attribute issupported.

This section is normative.

TheUnifiedMobile profile Document TypeDefinition is defined as a set of SMIL 3.0 modules. All SMIL 3.0 modulesare integrated according to the guidelines in the W3C Note "SynchronizedMultimedia Modules based upon SMIL 1.0"[SMIL-MOD], and defined withintheir respective module sections.