Synchronized Multimedia Integration Language (SMIL 2.1)

W3C Candidate Recommendation 13 May 2005

This version:

http://www.w3.org/TR/2005/CR-SMIL2-20050513/

Latest SMIL 2 version:

http://www.w3.org/TR/SMIL2/

Latest SMIL Recommendation:

http://www.w3.org/TR/SMIL/

Previous version:

http://www.w3.org/TR/2005/WD-SMIL2-20050201/

Editors:

Dick Bulterman, CWI - Guido Grassel, Nokia - Jack Jansen, CWI - Antti Koivisto, Nokia - Nabil Layaïda, INRIA - Thierry Michel, W3C - Sjoerd Mullender, CWI - Daniel Zucker, Access Co., Ltd.

This document is also available in these non-normative formats: single HTML file, zip archive.

Copyright ©2005 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

---

Abstract

This document specifies the second version of the Synchronized Multimedia Integration Language (SMIL, pronounced "smile"). SMIL 2.1 has the following design goals:

• Define an XML-based language that allows authors to write interactive multimedia presentations. Using SMIL, an author can describe the temporal behaviour of a multimedia presentation, associate hyperlinks with media objects and describe the layout of the presentation on a screen.
• Allow reusing of SMIL syntax and semantics in other XML-based languages, in particular those who need to represent timing and synchronization. For example, SMIL components are used for integrating timing into XHTML [XHTML10] and into SVG [SVG].
• Extend the functionalities contained in the SMIL 2.0 [SMIL20] into new or revised SMIL 2.1 modules.
• Define new SMIL 2.1 Mobile Profiles incorporating features useful within the mobile industry.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a W3C Candidate Recommendation of the Synchronized Multimedia Integration Language (SMIL) 2.1.
This document is based upon the SMIL 2.1 Last Call Working Draft published on 01 February 2005. The current draft contains editorial improvements, and minor bug fixes in response to Last Call comments. The significant changes in this draft are:

• Added an Appendix for Patent Policy clarification.
• Updated the SMIL 21 DTDs Appendix (added the new SMIL 2.1 semantics).
• Updated SMIL 2.1 references Appendix (split Normative and Informative references, reviewed outdated references).
• Fixed bugs:
  • soundAlign : The BALANCE functionality implied by the original text has now been made explicit in the attribute definition.
  • paramGroup attribute: The type of the attribute has been changed for IDREF to NMTOKEN and the text definition has been clarified.
  • Interaction of mediaAlign with regPoint/regAlign: The fact the regPoint/regAlign override mediaAlign has been added to the definition of mediaAlign and has been integrated into an example.
  • Animation of soundAlign: the soundAlign attribute has been added to the 'set' table for animation in the SMIL 2.1 Language profile and SMIL2.1 Extended Mobile Profile.
  • Changed the text of the backgroundTiling introduction to remove an incorrect statement about backgroundTiling and scaling; images used with backgroundTiling are never scale.

Please send review comments about this Candidate Recommendation to the public mailing list www-smil@w3.org [archives], including the prefix'[SMIL21 CR comment]' in the subject line. We expect that sufficient feedback to determine its future will have been received by 15 June 2005.

The SYMM Working Group will advance the specification to Proposed Recommendation when the following exit criteria have been met:

• All features in the SMIL 2.1 specification have been implemented at least twice in an interoperable way. This defines as :
  - the implementations have been developed independently,
  - each test in the SMIL 2.1 test suite has at least two passing implementations.
• The Working Group releases a public test suite for SMIL 2.1 along with an implementation report.
  The SMIL 2.1 test suite will provide at least one test case for any new element or new attribute or new attribute value introduced in SMIL 2.1 and sufficient tests also for any SMIL 2.0 functionality that might be impacted by new features of SMIL 2.1.

  The Implementation results are publicly released and are intended solely to be used as proof of SMIL 2.1 implementability. It is only a snap shot of the actual implementation behaviors at one moment of time, as these implementations may not be immediately available to the public. The interoperability data is not intended to be used for assessing or grading the performance of any individual implementation.

Any feedback on implementation and use of this specification would be very welcome. To the extent possible, please provide a separate email message for each distinct comment.

This document has been produced by the SYMM Working Group as part of the W3C Synchronized Multimedia Activity, following the procedures set out for the W3C Process. The goals of the SYMM Working Group are discussed in the SYMM Working Group Charter.

In line with its charter the SYMM WG has organized this specification as a collection of changes-only documents for Candidate Recommendation. The SYMM WG will publish a full SMIL 2.1 document (including SMIL 2.0 former modules and SMIL 2.1 new modules) for Proposed Recommendation.

The patent policy for this document is the 5 February 2004 W3C Patent Policy. Patent disclosures relevant to this specification may be found on the SYMM Working Group's patent disclosure page. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.

The authors of this document are the SYMM Working Group members. Different parts of the document have different editors.

Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

1. About SMIL 2.1

Editor

Thierry Michel, W3C.

1.1 Introduction

This document specifies the extended 2.1 version of the Synchronized Multimedia Integration Language (SMIL, pronounced "smile"). SMIL 2.1 has the following design goals:

• Define an XML-based language that allows authors to write interactive multimedia presentations. Using SMIL 2.1, an author can describe the temporal behavior of a multimedia presentation, associate hyperlinks with media objects and describe the layout of the presentation on a screen.
• Allow reusing of SMIL 2.1 syntax and semantics in other XML-based languages, in particular those who need to represent timing and synchronization. For example, SMIL 2.1 components are used for integrating timing into XHTML [XHTML10] and into SVG [SVG].
• Extend the functionalities contained in the SMIL 2.0 [SMIL20] into new or revised SMIL 2.1 modules.
• Define new SMIL 2.1 Mobile Profiles incorporating features useful within the mobile industry.

SMIL 2.1 is defined as a set of markup modules, which define the semantics and an XML syntax for certain areas of SMIL functionality.

1.2 Content of this Recommendation

This specification is structured as a set of sections, each defining one or more modules:

• Section 2 is an overview of SMIL 2.1 modularization and the individual modules, and presents conformance criteria.
• Section 3 defines the SMIL 2.1 Animation Modules.
• Section 4 defines the SMIL 2.1 Content Control Modules.
• Section 5 defines the SMIL 2.1 Layout Modules Updates.
• Section 6 defines the SMIL 2.1  Linking Modules.
• Section 7 defines the SMIL 2.1  Media Object Modules Updates.
• Section 8 defines the SMIL 2.1  Metainformation Module.
• Section 9 defines the SMIL 2.1 Structure Module.
• Section 10 defines the SMIL 2.1 Timing and Synchronization Modules Updates.
• Section 11 defines the SMIL 2.1 Time Manipulations Module.
• Section 12 defines the SMIL 2.1 Transition effects Modules Updates.

This specification also defines four Profiles that are built using the above SMIL 2.1 modules.

• Section 13 defines the SMIL 2.1 Language Profile.
• Section 14 defines the SMIL 2.1 Mobile Profile.
• Section 15 defines the SMIL 2.1 Extented Mobile Profile.
• Section 16 defines the SMIL 2.1 Basic Profile and Scalability Framework.

1.3 Relation to SMIL 2.0

SMIL 2.1 is a new version. It is build on top of SMIL 2.0.
A large number of SMIL 2.0 Modules [SMIL20-modules] remain the same in SMIL2.1.
SMIL 2.1 deprecates only a small number of SMIL 2.0 Modules.
SMIL 2.1 introduces new SMIL 2.1 Modules with extented functionalities.

SMIL 2.1 also defines new profiles that are built using the SMIL 2.0 modules [SMIL20] and SMIL 2.1 modules specified in this specification.

If this specification is approved as a W3C Recommendation, it will supersede the 07 January 2005 version of the SMIL 2.0 Recommendation (Second Edition) [SMIL20].

Note: SMIL document players, those applications that support playback of "application/smil" documents, and host language conformant document profiles must support the deprecated SMIL 2.0 functionalities as well as the new SMIL 2.1 functionalities.

1.4 Summary of Changes for SMIL 2.1

1- The following sections remain unchanged from SMIL 2.0 [SMIL20].

The modules, elements and attributes semantics in the following sections remain the same as in SMIL2.0.
Therefore each of these sections link to the equivalent section of the SMIL 2.0 Recommendation [SMIL20].

• Section 3 : SMIL 2.1 Animation Modules.
• Section 4 : SMIL 2.1 Content Control Modules.
• Section 6 : SMIL 2.1  Linking Modules.
• Section 8 : SMIL 2.1  Metainformation Module.
• Section 9 : SMIL 2.1 Structure Module.
• Section 11 : SMIL 2.1 Time Manipulations Module.

2- The following sections are updated from SMIL 2.0.

In these sections, only the updated or new modules, the new and updated elements or attributes semantics are specified. The following two profiles have also been updated:

• Section 2 : SMIL 2.1 modularization and conformance criteria.
• Section 5 : SMIL 2.1 Layout Modules Updates.
• Section 7 : SMIL 2.1  Media Object Modules Updates.
• Section 10 : SMIL 2.1 Timing and Synchronization Modules Updates.
• Section 12 : SMIL 2.1 Transition effects Modules Updates.
• Section 13 : SMIL 2.1 Language Profile.
• Section 16 : SMIL 2.1 Basic Profile and Scalability Framework.
• Appendix A : SMIL 2.1 DTDs.
• Appendix B : SMIL 2.1 Schemas.

3- The following sections introduce new Mobile Profiles.

• Section 14 : SMIL 2.1 Mobile Profile.
• Section 15 : SMIL 2.1 Extented Mobile Profile.

1.5 Acknowledgements

This document has been prepared by the Synchronized Multimedia Working Group (SYMM-WG) of the World Wide Web Consortium.
The SYMM WG which specified SMIL 2.1 included the following individuals:

Dick Bulterman, CW - Marisa DeMeglio, DAISY Consortium - Yoshihisa Gonno, Sony Corporation - Guido Grassel, Nokia - Markku Hakkinen, DAISY Consortium - Erik Hodge, RealNetworks - Eric Hyche, RealNetworks - Jack Jansen, CWI - Hiroshi Kawamura, NRCD - Antti Koivisto, Nokia - Nabil Layaïda, INRIA - Vincent Mahe, France Telecom - Thierry Michel, W3C - Sjoerd Mullender, CWI - Xabiel García Pañeda, Universidad de Oviedo - Andrei Popescu, Nokia - Masaru Sugano, KDDI Corporation - Daniel Zucker, Access Co., Ltd.

The former SYMM WG which specified SMIL 2.0 included the following individuals:

Hanan Rosenthal, Canon - Jin Yu, Compaq - Pietro Marchisio, CSELT - Lynda Hardman, CWI - Jacco van Ossenbruggen, CWI - Lloyd Rutledge, CWI - Olivier Avaro, France Telecom - Ted Wugofski, Gateway (Invited Expert) - Masayuki Hiyama, Glocomm - Keisuke Kamimura, Glocomm - Michelle Y. Kim, IBM - Steve Wood, IBM - Jeff Boston, IBM - Nabil Layaïda, INRIA - Muriel Jourdan, INRIA - Aaron Cohen, Intel - Wayne Carr, Intel - Marcel Wong, Ericsson - Ken Day, Macromedia - Daniel Weber, Panasonic - Patrick Schmitz, Microsoft - Debbie Newman, Microsoft - Pablo Fernicola, Microsoft - Aaron Patterson, Microsoft - Kevin Gallo, Microsoft - Paul David, Microsoft - Don Cone, Netscape/AOL - Wo Chang, NIST - Didier Chanut, Nokia - Antti Koivisto, Nokia - Roberto Castagno, Nokia - Jack Jansen, Oratrix - Sjoerd Mullender, Oratrix - Dick Bulterman, Oratrix - Kenichi Kubota, Panasonic - Warner ten Kate, Philips - Ramon Clout, Philips - Jeff Ayars, RealNetworks - Erik Hodge, RealNetworks - Rob Lanphier, RealNetworks - Bridie Saccocio, RealNetworks - Eric Hyche, RealNetworks - Robin Haglund, RealNetworks - Geoff Freed, WGBH - Philipp Hoschka, W3C - Philippe Le Hégaret, W3C - Thierry Michel, W3C.

2. The SMIL 2.1 Modules Updates

Editor:

Thierry MICHEL, W3C.

2.1 Introduction

This section is informative.

Since the publication of SMIL 1.0 [SMIL10], interest in the integration of SMIL concepts with the HTML, the HyperText Markup Language [HTML4], and other XML languages, has grown. Likewise, the W3C HTML Working Group has specified XHTML, the Extensible HyperText Markup Language [XHTML10], in preparation to subset, extend, and integrate it with other languages. The strategy considered for integrating respective functionality with other XML-based languages is based on the concepts of modularization and profiling [SMIL-MOD], [XMOD].

Modularization is an approach in which markup functionality is specified as a set of modules that contain semantically-related XML elements, attributes, and attribute values. Profiling is the creation of an XML-based language through combining these modules, in order to provide the functionality required by a particular application.

Profiling introduces the ability to tailor an XML-based language to specific needs, e.g. to optimize presentation and interaction for the client's capabilities. Profiling also adds the ability for integrating functionality from other markup languages, releasing the language designer from specifying that functionality. Moreover, it provides for consistency in markup through the use of the same model to incorporate a function. Identical constructs ease authoring, while at the user agent side there is a potential for re-use of code. For example, a scheduler supporting SMIL timing and synchronization functionality could be used for SMIL documents, XHTML+SMIL documents, and SVG documents.

Modularization enables language designers to specify dedicated markup intended for integration with other, existing, language profiles. Examples of specifications intended for such integration are MathML and XForms [MathML], [XFORMS].

Modularization and profiling use the extensibility properties of XML, and related technology like XML namespaces and XML Schema [XML11], [XML-NS], [XSCHEMA].

This part of the SMIL 2.1 specification describes the framework on which SMIL modularization and profiling is based, and specifies the SMIL 2.1 Modules, their identifiers, and the requirements for conformance within this framework.

2.1.1 Modularization and Profiling

This section is informative.

This section is unchanged from SMIL Modules section [SMIL20-modules].

SMIL 2.1 reuses the modularization approach as used in SMIL.

Also refer to SMIL Modules section [SMIL20-modules] for host language conformance, integration set conformance and modules notions.

2.2 Summary of Changes for SMIL 2.1

This section is informative.

SMIL 2.1 specification provides three classes of changes to the SMIL Recommendation, among the ten functional areas;

1. New Modules are introduced (e.g. BackgroundTilingLayout, FullScreenTransitionEffects)
2. Former SMIL Modules are deprecated and replaced by new ones to allow differentiated features to be implemented in profiles without necessarily requiring support for all of the functionality of the former SMIL module. (This is the case for the HierarchicalLayout module and ExclTimeContainers module).
3. Former SMIL Modules are revised allowing extented functionalities (example are AudioLayout, MultiWindowLayout)

The following functional areas are affected by SMIL2.1.

Timing

• ExclTimeContainers module is deprecated and replaced with two new modules: the BasicExclTimeContainers and BasicPriorityClassContainers modules.

Layout

• SMIL HierarchicalLayout module has been replaced by the SubRegionLayout, AlignmentLayout and OverrideLayout modules
• BackgroundTilingLayout is a new module
• Revised: BasicLayout and MultiWindowLayout modules.

Media Object

• MediaParam module is revised with added functionalities.

Transitions

• FullScreenTransitionEffects is a new module.
• BasicTransitions is revised with added functionalities.

2.3 SMIL 2.1 Modules

This section is normative.

SMIL functionality is partitioned into ten functional areas. Within each functional area a further partitioning is applied into modules. All of these modules, and only these modules, are associated with the SMIL namespace.

The functional areas and their corresponding modules are:

Note: Modules marked with (**) are new Modules added in SMIL2.1. Modules marked with (*) are revised modules from SMIL

1. Timing
   1. AccessKeyTiming
   2. BasicInlineTiming
   3. BasicTimeContainers
   4. BasicExclTimeContainers (**)
   5. BasicPriorityClassContainers (**)
   6. EventTiming
   7. FillDefault
   8. MediaMarkerTiming
   9. MinMaxTiming
   10. MultiArcTiming
   11. RepeatTiming
   12. RepeatValueTiming
   13. RestartDefault
   14. RestartTiming
   15. SyncbaseTiming
   16. SyncBehavior
   17. SyncBehaviorDefault
   18. SyncMaster
   19. TimeContainerAttributes
   20. WallclockTiming
2. Time Manipulations
   1. TimeManipulations
3. Animation
   1. BasicAnimation
   2. SplineAnimation
4. Content Control
   1. BasicContentControl
   2. CustomTestAttributes
   3. PrefetchControl
   4. SkipContentControl
5. Layout
   1. AlignmentLayout (**)
   2. AudioLayout
   3. BackgroundTilingLayout (**)
   4. BasicLayout (*)
   5. MultiWindowLayout (*)
   6. OverrideLayout (**)
   7. SubRegionLayout (**)
6. Linking
   1. BasicLinking
   2. LinkingAttributes
   3. ObjectLinking
7. Media Objects
   1. BasicMedia
   2. BrushMedia
   3. MediaAccessibility
   4. MediaClipping
   5. MediaClipMarkers
   6. MediaDescription
   7. MediaParam (*)
8. Metainformation
   1. Metainformation
9. Structure
   1. Structure
10. Transitions
    1. BasicTransitions (*)
    2. InlineTransitions
    3. TransitionModifiers
    4. FullScreenTransitionEffects (**)

This section is informative.

Each of these modules introduces a set of semantically-related elements, properties, and attributes. Each functional area has a corresponding section in this specification document. Further details on each of the modules is specified within those sections.

The modules may be independent or complementary. For example, the SyncMaster module requires and builds upon the SyncBehavior module, but the PrefetchControl and SkipContentControl modules are independent from each other. In addition, some modules require modules from other functional areas.

Modules specify their integration requirements. When one module requires another module for basic features and as a prerequisite for integration, a language profile must include the second module in order to include the first. The first module is said to be a dependent of the second module. Dependency may be nested, in that a module may be dependent on a module that is a dependent itself.

Table 1 presents the SMIL 2.1 modules and the modules they depend on.

2.3.1 SMIL DOM

This section is informative.

This section is unchanged from SMIL Recommendation [SMIL20-modules]

2.4 Identifiers for SMIL 2.1 Modules and Language Profiles

This section is informative.

This section specifies the identifiers for the SMIL 2.1 namespace and the SMIL 2.1 modules. Each SMIL host language conformant language profile is requested to explicitly state the namespace URI that is to be used to identify it. That namespace URI must comply with the "Requirements on Identifiers for SMIL Host Language Conformant Language Profiles", defined below.

2.4.1 The SMIL Mime Type

This section is normative.

Documents authored in language profiles that include the SMIL Structure module can be associated with the "application/smil" mime type. Documents using the "application/smil" mime type are required to be host language conformant.

2.4.2 XML Namespace Identifier for the SMIL 2.1 Modules

This section is normative.

The XML namespace identifier for the complete set of SMIL 2.1 modules, elements and attributes, are contained within the following namespace:

http://www.w3.org/2005/SMIL21/CR/

2.4.3 Identifiers for SMIL 2.1 Modules

This section is normative.

Each module in this specification has a unique identifier associated with it. They are intended to uniquely and consistently identify each of them. They should be used as values in a test for whether an implementation includes a specific module, as well as in other circumstances where a need to refer to a specific SMIL 2.1 module is necessary.

Table 2 summarizes the identifiers for SMIL 2.1 modules.

2.4.4 Identifiers for SMIL 2.1 Profiles and Features

This section is normative.

This section is informative.

2.5 SMIL Conformance

This section is informative.

In this section we specify the rules for SMIL host language and SMIL integration set conformance. First, the conformance requirements for host language conformance and integration set conformance are given. The requirements are similar to those set forth for XHTML host language document type conformance and XHTML integration set document type conformance [XMOD]. In a final section the requirements on identifiers for host language conformant language profiles are given.

Currently, there exist four language profiles using SMIL 2.1 Modules. They are the SMIL 2.1 Language Profile, the SMIL 2.1 Extended Mobile Profile, the SMIL 2.1 Mobile Profile and the SMIL 2.1 Basic Language Profile. All four profiles are SMIL host language conformant.

This section is normative.

The following two tables list names used to collectively reference certain sets of SMIL 2.1 elements and attributes. These are used in the definitions of the minimum support in the two sections below on SMIL host language conformance and SMIL integration set conformance. The term "minimum support" is used to refer to the minimum set of elements that an element can contain, and the minimum set of attributes that can be used on an element.

2.5.1 SMIL Host Language Conformance

This section is normative.

A language profile is said to be SMIL 2.1 host language conformant if it includes the following modules:

1. Structure
2. BasicContentControl
3. BasicInlineTiming
4. BasicLayout
5. BasicLinking
6. BasicMedia
7. BasicTimeContainers
8. MinMaxTiming
9. RepeatTiming
10. SkipContentControl
11. SyncbaseTiming

In addition, the following requirements must be satisfied:

1. The language profile defines what modules it collects.
2. The language profile includes all elements, attributes, and attribute values specified by the collected modules.
3. The language profile fulfills the "minimum support" requirements for elements and attributes as listed in Table 5 below.
4. The language profile complies with the integration requirements set forth by the modules it collects.
5. The language profile specifies the semantics related to the integration of the modules.
6. The language profile defines its DTD or XML Schema.
7. The language profile defines a unique identifier conforming to the requirements set forth in Requirements on Identifiers for SMIL Host Language Conformant Language Profiles.
8. The SyncbaseTiming module should be included in Host Language conformant profiles, although it is not strictly required. We strongly recommend inclusion of this module in Host Language conformant profiles to maintain a high level of consistency and interoperability with other languages that have integrated SMIL modules including the SMIL Language, XHTML+SMIL, and SVG. Only profiles designed to operate on severely constrained devices may omit the SyncbaseTiming module.

Support of deprecated elements and attributes is no longer required for SMIL 2.1 host language conformance but it is highly recommended for all modules the given language supports. Support of deprecated elements and attributes can only be left out in cases where interoperability with SMIL 1.0 implementations is not an issue. For example, if a SMIL 2.1 host language supports the MultiArcTiming module, it is highly recommended that it support the deprecated syntax defined in the MultiArcTiming module.

Since the SMIL 2.1 Structure module may only be used in a profile that is SMIL host language conformant, this implies that the SMIL 2.1 Structure module must at least be accompanied with the nine other modules required for host language conformance that were named above. Those modules themselves can still be used in other, non SMIL host language conformant, language profiles.

2.5.2 SMIL Integration Set Conformance

This section is normative.

A language profile is said to be SMIL 2.1 integration set conformant if it includes the following modules:

1. BasicContentControl
2. BasicInlineTiming
3. BasicMedia
4. BasicTimeContainers
5. MinMaxTiming
6. RepeatTiming
7. SyncbaseTiming

In addition, the following requirements must be satisfied:

1. The language profile defines what modules it collects.
2. The language profile includes all elements, attributes, and attribute values specified by the collected SMIL 2.1 modules.
3. The language profile fulfills the "minimum support" requirements for elements and attributes as listed in Table 6 below.
4. The language profile complies with the integration requirements set forth by the SMIL 2.1 modules it collects.
5. The SyncbaseTiming module should be included in Integration Set conformant profiles, although it is not strictly required. We strongly recommend inclusion of this module in Integration Set conformant profiles to maintain a high level of consistency and interoperability with other languages that have integrated SMIL modules including the SMIL 2.1 Language, XHTML+SMIL [XHTMLplusSMIL], and SVG [SVG]. Only profiles designed to operate on severely constrained devices may omit the SyncbaseTiming module.

Support of deprecated elements and attributes is not required for SMIL 2.1 integration set conformance. However, when included, the above requirements also apply to these elements and attributes. Also, when supported, it is required that all the deprecated elements and attributes from all the included modules are supported as a whole.

2.5.3 Requirements on Identifiers for SMIL Host Language Conformant Language Profiles

This section is informative.

This section is unchanged from SMIL 2.0 Recommendation [SMIL20-modules]

This section is normative.

For the purpose of identifying the version and the language profile used, SMIL host language conformant documents must satisfy the following requirements:

1. The document should declare a default namespace [XML-NS].
2. The default namespace must be declared on the smil root element.
3. In case the SMIL host language conformant language profile has been issued as a W3C Recommendation, the default namespace identifier must satisfy the following requirements:
   1. The URI is constructed conformant to the requirements set forth by the W3C [W3C-NSURI].
   2. The default namespace identifier should identify the language profile.
      In case the language profile is a subset of a larger one, the default namespace identifier may also identify that larger language profile. The module collection that is required to be supported in the subset language profile may be indicated through the systemRequired attribute on the smil element.
      See the SMIL Basic Language Profile specification for an example.

2.5.4 Error Handling in SMIL Host Language Conformant Documents

This section is normative.

This section is unchanged from SMIL Recommendation [SMIL20-modules].

2.5.5 Handling of Syntax errors in Attribute Values

This section is normative.

This section is unchanged from SMIL Recommendation [SMIL20-modules]

2.6 Creating a DTD for a Language Profile

This section is informative.

This section describes how language profiles could be defined using the SMIL 2.1 modular DTDs. The reader is assumed to be familiar with the mechanisms defined in "Modularization of XHTML" [XMOD], in particular Appendix D [XMOD-APPD] and Appendix E [XMOD-APPE]. In general, the SMIL 2.1 modular DTDs use the same mechanisms as the XHTML modular DTDs use. Exceptions to this are:

1. SMIL supports qualified attribute names for SMIL attributes that can appear on non-SMIL elements. This enables these attributes to use prefixes to indicate that they belong to the SMIL 2.1 namespace.
2. SMIL supports module level INCLUDE/IGNORE instead of XHTML's element/attlist level. Similar to XHTML Modularization, this prohibits profiles from importing only part of a module -- they have to support either all the elements and attributes or none.

Below, we give a short description of the files that are used to define the SMIL 2.1 modular DTDs. See the table and the end of the section for a complete list of the filenames involved.

Following the same mechanisms as the XHTML modular DTDs, the SMIL 2.1 specification places the XML element declarations (e.g. <!ELEMENT...>) and attribute list declarations (e.g. <!ATTLIST...>) of all SMIL 2.1 elements in separate files, the SMIL module files. A SMIL module file is provided for each functional area in the SMIL 2.1 specification (that is, there is a SMIL module file for animation, layout, timing, etc).

The SMIL module files are used in the normative definitions of the specification of the SMIL 2.1 Language Profile. Usage of the same module files for defining other SMIL profiles is recommended, but not required. The requirements that SMIL language profiles must follow are stated in the SMIL 2.1 specification, not in the DTD code.

To make the SMIL module files independent of each other, and independent of the language profiles, the element and attribute declarations make heavy use of XML entities. This provides profiles with the necessary hooks to define the actual content models and attributes of the SMIL elements.

The SMIL 2.1 Language Profile provides examples of how the SMIL module files can be used. Most of the DTD files are reused across the different profiles. Reused are the SMIL module files, the files that define the data types and the common attributes, the "qname" file that takes care of adding namespace prefixes if necessary, and the framework file, which takes care of including files in the appropriate order.

The files that are different for each profile are the driver file and document model file. This would, in general, also apply to new profiles: to define a new language profile, one has to write the extension module(s), the driver file that defines which modules are used, and a document model file that defines the extended document model. The driver file and document model file are described in more detail below.

The driver file.

This is the file that would be referenced by a document's DOCTYPE declaration. Its main job is to define which document model file and which of the SMIL module files the profile is using. It may also define an optional namespace to be used in all namespace prefixes. For example, to prefix all SMIL element names with "foobar", the following can be added to the start of the profile:

<!ENTITY % SMIL.prefixed "INCLUDE" >
<!ENTITY % SMIL.prefix "foobar" >

Elements defined in their modules as, for example, <video> will become parsed as <foobar:video>. This also applies for SMIL attributes that appear on other elements, so, for example, "begin" becomes "foobar:begin". The default is that the qname prefix is empty -- that is, it is effectively turned off by default.

After these definitions, the driver file includes the framework file (which will subsequently include the data type, common attributes, qname and document model file), after which the SMIL module files are included that are used by this profile.

The document model file.

The document model file contains the XML entities that are used by the SMIL module files to define the content models and attribute lists of the elements in that profile.

Content models generally differ from profile to profile, or contain elements from other modules. To avoid these dependencies in the SMIL module files, content models need to be defined in the document model file. The (dummy) default content model as defined in the SMIL module files is "EMPTY" for all SMIL 2.1 elements.

For the same reasons, the SMIL module files only define a default attribute list for their elements. This default list only contains the SMIL 2.1 core attributes and the attributes that are defined in the same SMIL module file. All other attributes need to be added to this default list by defining the appropriate XML entities. For example, the Media Objects Module file only adds the core and media related attributes on the media objects; other attributes, such as the timing attributes, are added to this list by the document model file.

3. The SMIL 2.1 Animation Modules

Editor for SMIL 2.1:

Thierry MICHEL, W3C

Editors for SMIL 2.0

Patrick Schmitz , Microsoft

Aaron Cohen, Intel

Ken Day, Macromedia.

3.1 Introduction

This section defines the SMIL 2.1 Animation Modules, which are composed of a BasicAnimation module and a SplineAnimation module. These modules contain elements and attributes for incorporating animation onto a time line, and a mechanism for composing the effects of multiple animations. Since these elements and attributes are defined in modules, designers of other markup languages can choose whether or not to include this functionality in their languages. Language designers incorporating other SMIL modules do not need to include the animation modules if animation functionality is not needed.

The examples in this document that include syntax for a host language use [SMIL10], [SVG], [HTML4] and [CSS2]. These are provided as an indication of possible integrations with various host languages.

While this document defines a base set of animation capabilities, it is assumed that host languages may build upon the support to define additional or more specialized animation elements.  Animation only manipulates attributes and properties of the target elements, and so does not require any knowledge of the target element semantics beyond basic type information.

This module depends on the SMIL 2.1 BasicInlineTiming module, using elements and attributes from the Timing module for its time line. The BasicInlineTiming module is a prerequisite for any profile using SMIL Animation. The reader is presumed to have read and be familiar with the SMIL 2.1 Timing modules. 

This section first presents the underlying principals of animation in SMIL 2.1, then the elements and attributes of the BasicAnimation module and of the SplineAnimation module.

3.2 Relation to SMIL 2.0

The SMIL 2.1 specification leaves the SMIL 2.0 Animation Modules unchanged.

Please refer to the former SMIL 2.0 Animation Modules [SMIL20-animation] for definition of animation semantics, elements and attributes allowing animation features into SMIL presentation.

Note: A SMIL 2.0 errata was raised which affects SMIL 2.1 Animation Modules . Please refer to the SMIL 2.0 [Second Edition] Errata page for details. This errata should be incorporated in the next SMIL 2.1 Proposed Recommendation full version.

4. The SMIL 2.1 Content Control Modules

Editor for SMIL 2.1

Dick Bulterman, CWI

Editors for SMIL 2.0

Dick Bulterman, Oratrix

Jeffrey Ayars, RealNetworks.

4.1 Introduction

This section defines the SMIL 2.1 content control modules. These modules contain elements and attributes which provide for runtime content choices and optimized content delivery. SMIL content control functionality is partitioned across four modules:

• BasicContentControl, containing content selection elements and predefined system test attributes;
• CustomTestAttributes, containing author-defined custom test elements and attributes;
• PrefetchControl, containing presentation optimization elements and attributes; and
• SkipContentControl, containing attributes that support selective attribute evaluation.

Since all of the content control elements and attributes are defined in modules, designers of other markup languages can reuse this functionality on a module by module basis when they need to include media content control in their language.

The functionality in the CustomTestAttributes module builds on the functionality of the BasicContentControl module; profiles implementing the CustomTestAttributes module must also implement the BasicContentControl module. The PrefetchControl and SkipContentControl modules have no prerequisites.

In some of the module descriptions for content control, the concept of "user preference" may be present. User preferences are usually set by the playback engine using a preferences dialog box, but this specification does not place any restrictions on how such preferences are communicated from the user to the SMIL player.

It is implementation dependent when content control attributes are evaluated. Attributes may be evaluated multiple times. Dynamic reevaluation is allowed but not required.

The SMIL 2.1 specification leaves the SMIL 2.0 Content Control Modules unchanged.
Please refer to the former SMIL 2.0 Content Control Modules [SMIL20-content-control] for information about semantics, elements and attributes allowing content choices and optimized content delivery of SMIL documents.

5. The SMIL 2.1 Layout Modules

Editor for SMIL 2.1

Dick C.A. Bulterman, CWI/Amsterdam

Editors for SMIL 2.0

Aaron Cohen, Intel

Dick Bulterman, Oratrix

Erik Hodge, RealNetworks.

5.1 Overview and Summary of Changes for SMIL 2.1

This section is informative.

SMIL 2.1 Layout provides two classes of changes to SMIL 2.0 layout. First, the SMIL 2.0 HierarchicalLayout module has been replaced by the SubRegionLayout, AlignmentLayout, and OverrideLayout modules; this allows differentiated features to be implemented in profiles without necessarily requiring support for all of the functionality in the HierarchicalLayout module. Second, several new elements and attributes have been added to SMIL 2.1 Layout to provide expression for common functions in an authoring-efficient manner; these functions include the short-cut notations for media positioning now available in the AlignmentLayout module and support for background image tiling in the BackgroundTilingLayout. In addition, new support for simple audio positioning has been added that allows audio placement to be supported by those players that allow audio 2-D imaging. The new OverrideLayout module groups existing support for per-media-object overrides of BasicLayout attributes.

Although the additions made to layout functionality are relatively minor, the restructuring of the layout modules means that the use of a diffs-style update chapter the layout modules would place a substantial burden on readers and implementors. As a result, an entire new Layout section has been produced containing all layout functionality that is included by various SMIL 2.1 profiles.

5.2 Introduction

This section is informative.

This section defines the SMIL 2.1 Layout Modules, which contain elements and attributes that allow positioning of media elements on visual and audio rendering surfaces and to control of audio volume. Since these elements and attributes are defined in modules, designers of other markup languages can choose the appropriate level of functionality to be included in their languages. Language designers incorporating other SMIL modules may include all, some or none of the modules described in this section.

5.2.1 Module Overview

This section is normative.

SMIL 2.1 Layout functionality is partitioned across the following seven modules:

BasicLayout

The BasicLayout module defines the core SMIL layout elements and their attributes. Using these attributes, basic positioning can be achieved for simple presentations.

AudioLayout

The AudioLayout module extends the BasicLayout module with a single attribute to control audio output sound levels.

MultiWindowLayout

The MultiWindowLayout module extends the BasicLayout module by defining an alternative to the root-layout element for defining the outer containing rendering space for a presentation. This module also defines functionality for supporting multiple top-level windows simultaneously.

SubRegionLayout

The SubRegionLayout module extends the BasicLayout module by defining a facility for creating logically nested regions. These regions can be created statically within the layout section or dynamically on a media object reference.

AlignmentLayout

The AlignmentLayout module extends the BasicLayout module by defining attributes to position content within a region based on a set of registration points and alignment algorithms. Several convenience attribute values are also provided to simply common authoring cases.

BackgroundTilingLayout

The BackgroundTilingLayout module extends the BasicLayout module by defining a facility to fill a region background with a tiled image instead of simply a background color.

OverrideLayout

The OverrideLayout model extends the BasicLayout module by defining a mechanism to specify per-media-object overrides of various layout attribute values.

The SMIL 2.0 HierarchicalLayout module has been deprecated and is not longer part of SMIL 2.1 Layout.

5.2.2 Support for Multiple Layout Models

This section is informative.

The SMIL 2.1 layout architecture allows support for multiple layout models within a presentation. Media layout may be described using the SMIL layout syntax described in this chapter or by using another layout mechanism, such as CSS2 syntax [CSS2]. Other layout types are possible as well.

Support for multiple layout models is implementation profile dependent. A given profile may support multiple layout models simultaneously (with selection performed using the SMIL switch element), or it may dictate that only a single layout model is supported (such as the use of CSS2 layout within the XHTML+SMIL candidate profile[XHTMLplusSMIL].

The remainder of this chapter will focus solely on the use of SMIL 2.1 layout semantics.

5.3 The SMIL 2.1 BasicLayout Module

5.3.1 Changes for SMIL 2.1

This section is informative.

The functionality in this module is essentially identical to the layout functionality in [SMIL20], which in turn was essentially identical to the layout functionality of [SMIL10]. The only exception is that SMIL 2.1 BasicLayout defines a new meetBest value for the fit attribute which limits the amount of upward scaling applied to a media object to 100%.

5.3.2 Overview

This section is informative.

SMIL 2.1 BasicLayout module includes a layout model for organizing media elements into regions on the visual rendering surface. The layout element is used in the document head to declare a set of regions on which media elements are rendered. Media elements declare which region they are to be rendered into with the region attribute.

Each region has a set of CSS2 compatible properties such as top, left, height, width, and backgroundColor. These properties can be declared using a syntax defined by the type attribute of the layout element. In this way, media layout can be described using the either SMIL basic layout syntax or CSS2 syntax (note that these are not functionally identical). Other layout types are possible as well.

For example, to describe a region with the id "r" at location 15,20 that is 100 pixels wide by 50 pixels tall using the SMIL BasicLayout module:

    <layout>
      <region id="r" top="15px" left="20px" width="100px" height="50px"/>
    </layout>   

To display a media element in the region declared above, specify the region's id as the region attribute of the media element:

    <ref region="r" src="http://..." />

5.3.3 Elements and Attributes

This section is normative.

This section defines the elements and attributes that make up the functionality in the SMIL BasicLayout module.

The layout element

The layout element defines a collection of rendering regions that determine how the elements in the document's body are positioned on an abstract rendering surface (either visual or acoustic).

The layout element must appear before any of the declared layout is used in the document. If present, the layout element must appear in the head section of the document. Default layout values can be assigned to all renderable elements by selecting the empty layout element <layout></layout>. If a document contains no layout element, the positioning of the body elements is implementation-dependent.

Element content

If the type attribute of the layout element has the value "text/smil-basic-layout", it may contain the following elements:

region

root-layout

Profiles incorporating the BasicLayout module need to define what additional elements are allowed as children. If the type attribute of the layout element has another value, the element contains character data.

The region element

The region element controls the position, size and scaling of media object elements that are placed within it rendering space.

The position of a region, as specified by its top, bottom, left, and right attributes, is always relative to the parent geometry, which is defined by the parent element. For the SMIL BasicLayout module, all region elements must have as their immediate parent a layout element, and the region position is defined relative to the root window declared in the sibling root-layout element. The intrinsic size of a region is equal to the size of the parent geometry.

When region sizes, as specified by width and height attributes are declared relative with the "%" notation, the size of a region is relative to the size of the parent geometry. Sizes declared as absolute pixel values maintain those absolute values.

Conflicts between the region size and position attributes width, height, bottom, left, right, and top are resolved according to the rules for placeholder elements as detailed below. The default values of region position and size attributes is specified as auto. This attribute value has the same meaning here that it does in [CSS2], when there is no distinction drawn between replaced and non-replaced element.

A placeholder element is one which has no intrinsic width or height, but does have a bounding-box which has a width and height. SMIL BasicLayout regions are placeholder elements. Placeholder elements are clipped to the bounding box.

The governing equation for the horizontal dimension is:

bbw (bounding-box-width) = left + width + right

Given that each of these three parameters can have either a value of "auto" or a defined value not "auto", then there are 8 possibilities:

The vertical attributes height, bottom, and top are resolved similarly. The governing equation for the vertical dimension is:

bbh (bounding-box-height) = top + height + bottom

Given that each of these three parameters can have either a value of "auto" or a defined value not "auto", then there are 8 possibilities:

Element examples

In the following example fragment, the position of a text element is set to a 5 pixel distance from the top border of the rendering window:

<smil xmlns="...">
  <head>
     ...
    <layout>
        ...
        <region id="a" top="5" />
        ...
    </layout>
  </head>
  <body>
    ...
    <text region="a" src="text.html" dur="10s" />
    ...
  </body>
</smil>

The root-layout element

The root-layout element determines the value of the layout properties of the root element, which in turn determines the size of the window in which the SMIL presentation is rendered.

If more than one root-layout element is parsed within a single layout element, this is an error, and the document should not be displayed. This does not include root-layout elements skipped by the user agent (e.g. because the enclosing layout element was skipped due to an unrecognized type or a test attribute evaluated to false).

The semantics of the root-layout element are as in SMIL 1.0: the attributes of the root-layout element determine the size of the top level presentation window, and the declared sibling regions are arranged within this top level window. If either the height or width of the root-layout element is not specified, the value of the attribute is implementation-dependent.

Element content

The root-layout element is an empty element. This element supports the SMIL 1.0 syntax where the root-layout element is an empty sibling of the top level region elements.

Element examples

The following example extends the fragment above with a specification of the root-layout element:

<smil xmlns="...">
  <head>
    <layout>
      <root-layout width="320" height="480" />
      <region id="a" top="5" />
    </layout>
  </head>
  <body>
    <text region="a" src="text.html" dur="10s" />
  </body>
</smil>

Note that the root-layout element is placed at a peer-level within the layout section. SMIL Layout also supports a nested containment model using the topLayout element defined in the MultiWindowLayout module.

The region attribute

The region attribute is added to the ref element (and its synonyms). The target of this attribute will be one or more regions with a regionName delared that matches the value of this attribute, or a single region element with a region attribute that matches this value. For processing rules, see the section Implementation details.

5.3.4 SMIL BasicLayout Implementation and Integration

Implementation Details

SMIL 2.1 BasicLayout module is consistent with the visual rendering model defined in CSS2, it reuses the formatting properties defined by the CSS2 specification, and newly introduces the fit attribute [CSS2]. The reader is expected to be familiar with the concepts and terms defined in CSS2.

SMIL 2.1 layout regions influence the propagation of user interface events (such as a mouse click, or hyperlink activation) to underlying visible elements. When the location of an event corresponds to the background of a region rather than the media that is displayed in that region, a region background color of transparent allows user interface events to pass through to elements lower in the display stacking order. Conversely, regions with non-transparent background colors will capture user interface events, not allowing the event to pass through to elements lower in the display stacking order. This behavior is separate from that of a language profile's ability to make use of user interface events captured by region elements.

An element that does not refer to a valid region element will display in the default region. If not otherwise specified by the profile, the default region is defined as filling and aligned to the upper-left corner of the presentation window. This default region takes on default values for all other region attributes.

The region attribute is applied to an element in order to specify which rendering region is assigned to the element. The attribute refers to the abstract rendering region (either visual or acoustic) defined within the layout section of the document. The referenced abstract rendering region is determined by applying the following rules, in order:

1. Find all elements in the layout section with regionName attributes that are assigned the same value as that of the region attribute.
2. Remove the elements from this collection that are removed from the rendered presentation due to the processing of switch elements and test attributes.
3. If any elements remain, the media should be rendered in all of the referred to regions. If the application cannot render the media simultaneously in multiple regions, then the media should be rendered using the lexically first remaining element.
4. If no elements have a regionName attribute that is assigned the same value as that of the region attribute, then select the element in the layout section whose unique identifier is the value of the region attribute.

If this process selects no rendering surface defined in the layout section, the values of the formatting properties of this element are defined by the default layout values, which is described in the section on integration requirements for this module.

Integration Requirements

A profile integrating the SMIL 2.1 BasicLayout module must define the content models for the layout element if any elements beyond those specified here are to be allowed as children.

A profile integrating the SMIL 2.1 BasicLayout module must provide a means of declaring an XML identifier on region elements if the profile intends on referring to region elements by XML identifier. This value is used as the argument value to the region attribute. This is not required if the profile will only use the regionName method of referring to a region element.

A profile integrating the SMIL 2.1 BasicLayout module must specify which elements have a region attribute and any inheritance of the attribute.

If not otherwise defined by the profile, the default values of the layout attributes listed in the SMIL 2.1 layout modules will apply to presented elements not otherwise specifying layout semantics.

5.3.5 Document Type Definition (DTD) for the BasicLayout Module

See the full DTD for the SMIL Layout modules.

5.4 The SMIL 2.1 AudioLayout Module

5.4.1 Changes for SMIL 2.1

This section is informative.

The functionality in this module is identical to the layout functionality in the [SMIL20] SMIL 2.0 AudioLayout module. The SMIL 2.1 text contains minor editorial changes.

5.4.2 Overview

This section is informative.

In SMIL 2.1 AudioLayout, one attribute is supported that allows the sound intensity of an audio object to be specified via the soundLevel attribute.

The following region defines an audio sound level that is set to 50% of its normal recorded value:

  <layout>
    ...
    <region id="a" soundLevel="50%"/>
    ...
  </layout>

When used in conjuction with SMIL 2.1 Animation (and if supported by the profile), the value of the attribute may be varied over time.

5.4.3 Audio Volume Control

This section is normative.

SMIL 2.1 AudioLayout module supports control of aural media volumes via a new property on the region element, soundLevel. Multimedia assigned to a region with an explicit soundLevel attribute will have its audio rendered at the given relative sound intensity.

5.4.4 Elements and Attributes

This section is normative.

This section defines the soundLevel attribute that makes up the SMIL 2.1 AudioLayout module.

The region element

The region element defined in the BasicLayout module is extended with the addition of the soundLevel attribute.

5.4.5 Integration Requirements for the AudioLayout Module

This section is normative.

The functionality in this module builds on top of the functionality in the BasicLayout module, which is a required prerequisite for inclusion of the AudioLayout module.

5.4.6 Document Type Definition (DTD) for the AudioLayout Module

See the full DTD for the SMIL Layout modules.

5.5 The SMIL 2.1 MultiWindowLayout Module

5.5.1 Changes for SMIL 2.1

This section is informative.

The functionality in this module is identical to the layout functionality in the [SMIL20] SMIL 2.0 MultiWindowLayout module. The SMIL 2.1 text contains minor editorial changes to descriptions and examples.

5.5.2 Overview

This section is informative.

This section defines the functionality in the SMIL 2.1 MultiWindowLayout module. This level contains elements and attributes providing for creation and control of multiple top level windows on the rendering device.

In the architecture of the SMIL 2.1 BasicLayout module, each presentation is rendered into a single root window of a specific size/shape. The root window contains all of the regions used to manage the rendering of specific media objects and is defined by a peer-level root-layout element.

The SMIL 2.1 Layout specification extends the root container level with the notion of a top-level rendering window, called a topLayout window. A SMIL 2.1 layout section may support one or more topLayout windows. The assignment of the regions to individual top level windows allows independent placement and resizing of each top-level window, if supported by the including profile and implementation. The initial placement of the top level windows on the display device and any available means of relocating the top level windows is implementation-dependent.

The top-level windows function as rendering containers only, that is, they do not carry temporal significance. In other words, each window does not define a separate timeline or any other time-container properties. There is still a single master timeline for the SMIL presentation, no matter how many top-level windows have been created. This is important to allow synchronization between media displayed in separate top-level windows.

The display of top level windows can be controlled automatically by the player, or manually by the user of the application. If a window is closed (by the user) while any of the elements displayed in that window are active, there is no effect on the timeline (if any) of those elements. However, a player may choose not to decode content as a performance improvement. The means provided to a user to close top level windows is implementation-dependent.

For SMIL 1.0 compatibility, the root-layout element will continue to support SMIL 1.0 layout semantics. The new topLayout element will support the extension semantics and the improved, nested syntax.

Note also that any one region may belong to at most one top-level (or root-level) window. Regions not declared as children of a topLayout element belong to the root-layout window. If no root-layout element has been declared, the region is assigned to an additional window according to the semantics in the BasicLayout module.

5.5.3 Elements and Attributes

This section is normative.

This section defines the elements and attributes that make up the SMIL 2.1 MultiWindowLayout module.

The topLayout element

The topLayout element determines the size of the a window in which the SMIL presentation is rendered, as well as serving as a top level window in which to place child region elements.

Multiple topLayout elements may appear within a single layout element, each declaring an independent top-level window.

Each instance of a topLayout element determines the size of a separate top-level presentation window, and the descendant regions are arranged within this top-level window and relative to the coordinate system of this window.

This module also provides control over when topLayout windows open and close in a presentation. Note that the precise mapping of topLayout windows on to the host environment is implementation-dependent. It is expected that implementations will "pop up" independent desktop windows if they can, but other means of supporting multiple topLayouts, such as by using frames, are allowed. When automatically opening and closing windows, applications should try to comply with the WAI User Agent Guidelines [UAAG] and allow the user to choose whether to be warned that windows are being opened and closed, and give a method for disabling automatic opening and closing of windows.

Element content

The topLayout element may contain any number of region elements, or be empty.

Element examples

The following example provides a restatement of the root-layout example:

<smil xmlns="...">
  <head>
    <layout>
      <topLayout width="320" height="480" />
        <region id="a" top="5" />
      </topLayout/>
    </layout>
  </head>
  <body>
    <text region="a" src="text.html" dur="10s" />
  </body>
</smil>

Multiple instances of the topLayout element may occur within a single layout element:

  <layout>
    <topLayout id="WinV" title="Video" width="320" height="240"/>
      <region id="pictures" title="pictures" height="100%" fit="meet"/>
    </topLayout>
    <topLayout id="WinC" title="Captions" width="320" height="60">
      <region id="captions" title="caption text" top="90%" fit="meet"/>
    </topLayout>
  </layout>

In this example, two top-level windows are defined ("WinV" and "WinC"), and two regions are defined with one region ("pictures") assigned to WinV and the other ("captions") to WinC. These windows may be opened and closed independently by the presentation or by a user.

The layout element

The MultiWindowLayout module does not redefine the BasicLayout layout element. Instead, it simply extends the content model for that element, as described in the following subsection.

Element content

This section is normative.

The layout element defined in the SMIL BasicLayout module is extended by adding topLayout element to the content model of the layout element if the type attribute of the layout element has the value "text/smil-basic-layout".

5.5.4 MultiWindowLayout Module Events

This section is normative.

This module includes two events that may be included in the integrating language profile.

topLayoutOpenEvent

Raised when a topLayout window opens. This event is delivered to the associated topLayout element. If a topLayout closes and then reopens when additional media becomes active in any of its regions, this event will be raised again, and will be raised every subsequent time it reopens.

topLayoutCloseEvent

Raised when a topLayout closes for any reason. This event is delivered to the associated topLayout element. If a topLayout reopens when additional media becomes active in any of its regions, this event will be raised again if and when the topLayout closes again, and will be raised every subsequent time it closes.

5.5.5 Implementation and Integration Requirements for the MultiWindowLayout Module

Implementation details

Allowing multiple topLayout elements within a single layout element implies support for multiple top level windows. If an implementation does not support multiple top level windows (because of device or processing restrictions), only content in the first top-level window defined in the layout will be rendered. Non-rendered objects will still participate in all SMIL timing and scheduling operations.

If used together with the root-layout element, any direct peer-level regions to the root-layout will be contained within the extents of the root-layout.

5.5.6 Integration Requirements for the MultiWindowLayout Module

This section is normative.

The functionality in this module builds on top of the functionality in the BasicLayout module, which is a required prerequisite for inclusion of the MultiWindowLayout module.

The language profile must specify the declarative names for binding the topLayoutOpenEvent and topLayoutCloseEvent events described in the MultiWindowLayout Module Events section, as well as the bubbling behavior of the events.

5.5.7 Document Type Definition (DTD) for the MultiWindowLayout Module

See the full DTD for the SMIL Layout modules.

5.6 The SMIL 2.1 SubRegionLayout Module

5.6.1 Changes for SMIL 2.1

This section is informative.

The functionality in this module is a subset of the layout functionality in the [SMIL20] HierarchicalLayout module. The SubRegionLayout module for SMIL 2.1 does not introduce any new elements, attributes or attribute values beyond those available in SMIL 2.0. Unlike SMIL 2.0 HierarchicalLayout, SMIL 2.1 SubRegionLayout no longer defines elements and attributes for the registration element or the registration attributes. These are now defined in the AlginmentLayout module. Also unlike SMIL 2.0 HierarchicalLayout, the SMIL 2.1 SubRegionLayout module no longer provides support for an object in a (sub-)region to alter various non-positioning region attributes. This facility is now supported in the OverrideLayout module. Note that all functionality provided by the SMIL 2.0 HierarchicalLayout module is still supported in the SMIL2.1 Layout modules; only the organization of the modules has changed.

The descriptions of sub-regions in this section is included as a convenience to the reader or implementor. It contains only editorial changes to the text in the relevant portions of the SMIL 2.0 specification.

5.6.2 Overview

In SMIL 2.1, the SubRegionLayout module defines two mechanisms for defining regions that are logically contained within a parent region (these are SMIL's sub-regions). First, the SubRegionLayout module extends the definition of the region element to allow for the specification of sub-regions within the layout section as hierarchical content of regions. Second, the SubRegionLayout module extends the attributes allowed on (media) object references to allow a dynamic sub-region to be defined in-line by that object instance only. All values given for placement within sub-regions are defined in terms of the parent region's placement attributes. The ability to define sub-regions can be exploited for authoring convenience or when changing the location of a group of related regions using SMIL 2.1 Animation.

In the following fragment, a parent region (CaptionedVideo) is defined that contains two hierarchical sub-regions: image and captions. The placement of the image and caption content is specified as relative to the dimensions of the parent region. This is an example of a statically-defined hierarchy of sub-regions.

  <layout>
     ...
     <region id="CaptionedVideo" top="10px" left="20px" width="320" height="300">
       <region id="image" title="image content" width="100%" height="240px" fit="meet"/>
       <region id="captions" title="caption text" top="240px" height="60px" fit="meet"/>
     </region>
     ...
  </layout>

A presentation using the above layout specification could also create a dynamic sub-region that is defined for use by this single object:

  <body>
      ...
     <img id="Title" region="image" top="5%" left="3" bottom="10%" right="15%"  src="TitleImage.png"/>
     ...
  </body>

This statement creates a sub-region with the named region "image" with the given extents. In the example above, the effective boundaries of the sub-region for the placement of this object are defined by declaring the top, bottom, left and right edges of the region to the values shown, and then filling the resulting sub-region with the specified image as directed by the fit attribute. If the size of the media object being displayed is smaller than that of the resulting sub-region, the display will be similar to:

The use of in-line sub-region placement is intended as a light-weight alternative to defining a large number of single-use regions. Often, the dimensions used for the sub-region will match the dimensions of the media object being placed, but in all cases the values of the fit attribute will govern rendering of the object in the sub-region. The other attributes on the media element that would have been applied to a referenced region are applied to the sub-region instead. Note that the default values for the sub-region attributes are all 'auto', meaning that, by default, a sub-region is created having the same size and position as the parent region.

The use of sub-region positioning leads to authoring convenience and SMIL file compactness, since many separate regions do not need to be defined to handle incidental layout needs. The support for a hierarchy of sub-regions also allows multiple layout objects to be animated in concert by moving the parent region using SMIL 2.1 Animation facilities.

5.6.3 Elements and attributes

This section defines extension to the region and ref elements to support sub-region functionality.

The region element

This module extends the definition of the region element to include the definition of hierarchical sub-regions.

Element content

The SMIL 2.1 SubRegionLayout module extends the region element content model to include region elements.

The ref element (and its synonyms)

The SubRegionLayout module extends the ref element to allow a separate, unnamed sub-region to be defined for the media object reference containing the sub-region positioning attributes.

Element attributes

The ref element defined in the MediaObject module and its synonyms are extended to include the following positioning attributes.

top

This value uniquely identifies the position or the distance (using CSS2 pixel or non-negative percentage values) of the top edge of the sub-region relative to the top of the region. The default value of top is auto.

bottom

This value uniquely identifies the position or the distance (using CSS2 pixel or non-negative percentage values) of the bottom edge of the sub-region relative to the bottom of the region. The default value of bottom is auto.

height

This value uniquely identifies the position or the distance (using CSS2 pixel or non-negative percentage values) of the bottom edge of the sub-region relative to the top side of the sub-region. The default value of height is auto.

left

This value uniquely identifies the position or the distance (using CSS2 pixel or non-negative percentage values) of the left edge of the sub-region relative to the left of the region. The default value of left is auto.

right

This value uniquely identifies the position or the distance (using CSS2 pixel or non-negative percentage values) of the right edge of the sub-region relative to the right side of the region. The default value of right is auto.

width

This value uniquely identifies the position or the distance (using CSS2 pixel or non-negative percentage values) of the right edge of the sub-region relative to the left side of the sub-region. The default value of width is auto.

Conflicts between the region size attributes  bottom, height, left, right, top, and width are resolved according to the rules for placeholder elements described in the section on the region element.

The sub-region positioning attributes will be ignored if they are used on an element without a region attribute (or, if supported, the regionName attribute) that resolves to a region element in the layout section.

5.6.4 SubRegionLayout Module Events

This module does not define any SMIL 2.1 events.

5.6.5 SubRegionLayout Implementation and Integration

Implementation Details

This section is normative.

The position of a region, as specified by its top and left attributes, is always relative to the parent geometry, which is defined by the parent element. For the SMIL 2.1 SubRegionLayout module, all hierarchical region elements must have as their immediate parent a region or topLayout element. The position of the hierarchical region is defined relative to that parent element. The intrinsic size of a region is equal to the size of the parent geometry.

When region sizes, as specified by width and height attributes are declared relative with the "%" notation, the size of the hierarchical region is relative to the size of the parent region. Sizes declared as absolute pixel values are absolute values even when used with a child region.

Note that a (hierarchical) region may be defined in such a way as to extend beyond the limits of its parent. In this case the child region must be clipped to the parent boundaries.

If a z-index attribute is defined on the hierarchical region, it is evaluated as a local index within that of the parent.

If the fit attribute and alignment attributes regPoint and regAlign are relevant to the placement of a particular media object, the interaction is the same as described in the definition of regPoint. If sub-region positioning attributes are used on a media object along with fit or the alignment attributes regPoint and regAlign, these attributes apply to the sub-region. In this case the fit setting on the referenced region element does not apply to the sub-region.

For both sub-region positioning and registration point use (as defined in the module), the value of the z-index attribute on the associated region is used. If media objects overlap spatially, existing rules for resolving z-index conflicts are applied.

Note that placement within the region may be defined in such a way as to extend the media object beyond the limits of the region. In this case the media object must be clipped to the region boundaries.

If two hierarchical regions with the same z-index attribute value overlap, the existing rules for z-index processing defined in the BasicLayout module are applied. Specifically, the rule concerning time priority is maintained, meaning that in the case of a z-index conflict, the media visible in the overlap will be determined by the region that is rendering the media that has most recently begun in time. If the conflicting media began at the same time, then the rule using the textual order of the media elements in the SMIL document is applied.

For example:

<layout>
   <root-layout width="640px" height="480px" />
   <region id="whole" top="0px" left="0px" width="640px" 
                                height="480px" z-index="5"/>
   <region id="right" top="0px" left="320px" width="320px"
                                height="480px" z-index="4">
       <region id="inset" top="140px" left="80" width="160px" 
                                height="200px" z-index="6"/>
       <region id="inset2" top="140px" left="80" width="160px" 
                                height="200px" z-index="6"/>
       <region id="inset3" top="140px" left="80" width="160px" 
                                height="200px" z-index="7"/>
   </region>
</layout>
...
<par>
        <img id="A" region="whole" src="imageA.jpg" dur="10s"/>
        <img id="B" region="inset" src="imageB.jpg" dur="10s"/>
</par>
<par>
        <img id="D" region="inset2" src="imageD.jpg" begin="1s" dur="10s"/>
        <img id="C" region="inset" src="imageC.jpg" begin="0s" dur="10s"/>
</par>
<par>
        <img id="E" region="inset2" src="imageE.jpg" dur="10s"/>
        <img id="F" region="inset3" src="imageF.jpg" dur="10s"/>
</par>

1. In the first "par", image "A" and image "B" begin at the same time. Image A will obscure image "B", even though the z-index of "inset" is greater than that of "whole". This is because the z-index of "right", which is the region containing "inset" is less than that of "whole". 
2. In the second "par", images "C" and "D" are rendered into regions occupying the same area of the rendering surface. Image "C" will be shown for one second and then obscured by Image "D", since "D" begins after image "C". Note that lexical order is irrelevant here. 
3. In the third "par", the z-index of region "inset" is considered when computing stacking between siblings, and therefore image "F" will be shown, but image "E" will be obscured for the entire 10 seconds that they are both active.

Integration Requirements for the SubRegionLayout Module

This section is normative.

The functionality in this module builds on top of the functionality in the BasicLayout module and the MediaObject module, which are required prerequisites for inclusion of the SubRegionLayout module. If the functionality in this module is to be used with the topLayout construct, the MultiWindowLayout module is a prerequisite.

5.6.6 Document Type Definition (DTD) for the SubRegionLayout Module

See the full DTD for the SMIL Layout modules.

5.7 AlignmentLayout Module

5.7.1 Changes for SMIL 2.1

This section is informative.

This is a new module for SMIL 2.1. It contains the alignment functionality from [SMIL20] and adds the mediaAlign attribute to simplify the specification of object alignment and the soundAlign attribute to support audio 2-D placement.

Minor changes have been made to the definition of the layout element because of the restructuring of SMIL 2.1 layout modules.

5.7.2 Overview

A registration element is an element defined within this module that is used to define a point within a region and a default object alignment algorithm about that point. The element can be used in a media object element, where it is associated with a region and an optional override alignment algorithm. The placement values within registration elements can be either percentages or pixels.

The use of registration points allows for consistent relative placement across regions. As such, registration points are defined outside of any single region.

For example, the following code describes two registration points (with id values "midPoint" and "topMargin"), one of which is defined as a relative location and one at a fixed pixel location, using the SMIL 2.1 AlignmentLayout syntax:

    <layout>
      <regPoint id="midPoint" top="50%" left="50%" regAlign="center" />
      <regPoint id="topMargin" top="10" left="15" regAlign="topLeft" />
      <region id="a" ... />
      <region id="b" ... />
    </layout> 

In this example, the registration point with the id value "midPoint" has a default alignment algorithm that centers the media object about the defined point, while the registration point with the id value "topMargin" has a default alignment algorithm that places the top-left point of the media object at the registration point.

Various media elements could be displayed in the regions using the alignment points as follows:

  
    <ref region="a" src="rtsp://..." dur="2s" regPoint="midPoint" /> 
    <ref region="b" src="http://..." dur="2s" 
                         regPoint="midPoint" regAlign="bottomRight"/>
    <ref region="a" src="http://..." dur="2s" regPoint="topMargin" />
    <ref region="b" src="http://..." dur="2s" 
                         regPoint="topMargin" regAlign="center"/>

In the first example, a media object is centered in the middle of region a. In the second example, a media object has its bottom right corner centered in the middle of region b. Similarly, in the third example, a media object has its top left corner placed at a point 10,15 within region a, and in the fourth example, an object is centered around the point 10,15 in region b.

Registration points can be used to coordinate the placement of a set of media objects that do not share the same sizes. (For example, a set of images can be aligned to the center of a region.) They can also be used to coordinate the display of images about a particular point in a region, as in:

   <layout>
      <regPoint id="middle" top="50%" left="50%" regAlign="center" />
      <region id="a" ... />
   </layout> 
   ...
   <seq>   
    <ref region="a" src="rtsp://..." dur="2s" regPoint="middle" 
                                        regAlign="bottomRight"/> 
    <ref region="a" src="http://..." dur="2s" regPoint="middle" 
                                        regAlign="bottomLeft"/>
    <ref region="a" src="http://..." dur="2s" regPoint="middle" 
                                        regAlign="topLeft"/>
    <ref region="a" src="http://..." dur="2s" regPoint="middle" 
                                        regAlign="topRight"/>
  </seq>

In this example, four objects are aligned over time to the middle of region. If any media element extends outside the bounds of a region, it will be clipped to the region.

Note that registration points are global within the context of a layout, and are not tied to a particular region, but can be reused across regions. As such, pixel-based offsets should be used with care.

For authoring convenience, SMIL AlignmentLayout module provides several pre-defined region registration points including topLeft, topMid, topRight, midLeft, center, midRight, bottomLeft, bottomMid, and bottomRight.

For example, media objects can be centered in any region like this:

    <ref ... regPoint="center" regAlign="center" />

As a further convenience, SMIL AlignmentLayout module provides the mediaAlign attribute, which defines a combination of regAlign and regPoint attributes. For example, media objects can be centered in any region using mediaAlign as follows:

    <ref ... mediaAlign="center" />

If the mediaAlign attribute and either (or both) of the regPoint and regAlign attributes are used together, the regPoint and/or regAlign value(s) will override the corresponding effective regPoint/regAlign value(s) defined by the mediaAlign value.

The default value of regAlign for a region is topLeft. If the regAlign attribute is used without a regPoint attribute, the alignment operation is relative to the upper left point of the region containing this object, that is, the behavior is the same as if the regPoint were to be specified as topLeft.

Rules for handling clipping of objects within regions based on the regPoint and regAlign attributes are defined below.

5.7.3 Elements and Attributes for the AlignmentLayout Module

This section defines the elements and attributes that make up the SMIL 2.1 AlignmentLayout module.

The layout element

This element extends the content model of the layout element to support the registration point functionality described in this section.

Element content

If the type attribute of the layout element has the value "text/smil-basic-layout", it is extended to contain the following elements:

region

root-layout

regPoint

The regPoint element

The regPoint element determines the (x, y) coordinates of a point relative to a region upper-left corner for use in aligning elements in the document's body on regions within a visual rendering surface. A regPoint may be defined using absolute (pixel) or relative (percentage) based values. The regPoint functionality is not defined and may not be used for media without intrinsic size.

For the purposes of regPoint functionality, media and regions are defined to be rectangular, with perpendicular sides, with the sides ordered clockwise top, right, bottom, and left. The top side is the edge closest to the point or edge of the display device considered "up". 

Element content

None.

The region element

This module extends the definition of the region element to include the definition of default alignment policies for content in that region.

Element content

SMIL 2.1 AlignmentLayout module does not extend the region element content model.

The ref element (and its synonyms)

The AlignmentLayout module extends the ref element to allow the positioning of media content within a region based on the an alignment registration point and an alignment policy.

Element content

SMIL 2.1 AlignmentLayout module does not extend the ref element content model.

5.7.4 AlignmentLayout Module Events

This module does not define any SMIL 2.1 events.

5.7.5 SMIL AlignmentLayout Implementation and Integration

Implementation Details

If an implementation cannot support the soundLevel attribute, it may be ignored. Even when processing is ignored, the attribute must be correctly parsed.

The regPoint element may only appear as an immediate child of a layout element.

If the registration point functionality is used on a media object that also uses sub-region positioning, the registration point applies to the subregion.

For registration point use, the value of the z-index attribute on the associated region is used. If media objects overlap spatially, existing rules for resolving z-index conflicts are applied.

Note that placement within the region may be defined in such a way as to extend the media object beyond the limits of the region. In this case the media object must be clipped to the region boundaries.

The default value of regAlign for a region is topLeft. If the regAlign attribute is used without a regPoint attribute, the alignment operation is relative to the upper left point of the region containing this object, that is, the behavior is the same as if the regPoint were to be specified as topLeft.

If the registration point or alignment functionality is used on a media object, the interaction between the regPoint attribute value, the regAlign attribute value, and the fit attribute value of the region in which the media object is displayed is as follows:

fill fit value:

This depends on the value of the regAlign attribute. (Note: in all cases, the media must maintain proper alignment over the regPoint):

topLeft regAlign value:

Scale the object's height and width independently so that the content just touches the bottom and right edges of the box.

topMid regAlign value:

Scale the object's height and width independently so that the content just touches the bottom edge of the box, and the nearest (to the regPoint) of the left or right edges of the box.

topRight regAlign value:

Scale the object's height and width independently so that the content just touches the bottom and left edges of the box.

midLeft regAlign value:

Scale the object's height and width independently so that the content just touches the nearest (to the regPoint) of the top or bottom edges of the box, and touches the right edge of the box.

center regAlign value:

Scale the object's height and width independently so that the content just touches the nearest (to the regPoint) of the top or bottom edges of the box, and touches the nearest (to the regPoint) of the left or right edges of the box.

midRight regAlign value:

Scale the object's height and width independently so that the content just touches the nearest (to the regPoint) of the top or bottom edges of the box, and touches the left edge of the box.

bottomLeft regAlign value:

Scale the object's height and width independently so that the content just touches the top and right edges of the box.

bottomMid regAlign value:

Scale the object's height and width independently so that the content just touches the top edge of the box, and the nearest (to the regPoint) of the left or right edges of the box.

bottomRight regAlign value:

Scale the object's height and width independently so that the content just touches the top and left edges of the box.

hidden fit value:

Align the media over the given regPoint per the regAlign attribute. If the media so positioned extends past the bounds of the region, clip the excess media. If the media so positioned doesn't meet the bounds of the region, fill the remaining space with the background color of the region.

meet fit value:

This depends on the value of the regAlign attribute. Any part of the region that is not covered by the media is then filled with the region's background color. (Note: in all cases, the media must maintain proper alignment over the regPoint):

topLeft regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches the right or bottom edge of the box while none of the content is clipped.

topMid regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches at least one of the left, right, or bottom edges while none of the content is clipped.

topRight regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches the left or bottom edge of the box while none of the content is clipped.

midLeft regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches at least one of the top, right, or bottom edges while none of the content is clipped.

center regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches at least one of the top, left, right, or bottom edges while none of the content is clipped.

midRight regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches at least one of the top, left, or bottom edges while none of the content is clipped.

bottomLeft regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches the top or right edge of the box while none of the content is clipped.

bottomMid regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches at least one of the top, left, or right edges while none of the content is clipped.

bottomRight regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches the top or left edge of the box while none of the content is clipped.

scroll fit value:

Align the media over the given regPoint per the regAlign attribute. If any part of the media extends beyond the bounds of the region, a scrolling mechanism should be invoked that allows viewing of the media that is clipped beyond the bounds of the region.

slice fit value:

This depends on the value of the regAlign attribute. (Note: in all cases, the media must maintain proper alignment over the regPoint):

topLeft regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches the right or bottom edge of the box, whichever requires the largest scale factor. Any content that extends beyond the bounds of the region is clipped.

topMid regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches the left, right, or bottom edge of the box, whichever requires the largest scale factor. Any content that extends beyond the bounds of the region is clipped. Clipping will occur on up to two sides of the region.

topRight regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches the left or bottom edge of the box, whichever requires the largest scale factor. Any content that extends beyond the bounds of the region is clipped.

midLeft regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches the top, right, or bottom edge of the box, whichever requires the largest scale factor. Any content that extends beyond the bounds of the region is clipped. Clipping will occur on up to two sides of the region.

center regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches the top, left, right, or bottom edge of the box, whichever requires the largest scale factor. Any content that extends beyond the bounds of the region is clipped. Clipping will occur on up to three sides of the region.

midRight regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches the top, left, or bottom edge of the box, whichever requires the largest scale factor. Any content that extends beyond the bounds of the region is clipped. Clipping will occur on up to two sides of the region.

bottomLeft regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches the top or right edge of the box, whichever requires the largest scale factor. Any content that extends beyond the bounds of the region is clipped.

bottomMidregAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches the top, left, or right edge of the box, whichever requires the largest scale factor. Any content that extends beyond the bounds of the region is clipped. Clipping will occur on up to two sides of the region.

bottomRight regAlign value:

Scale the visual media object's height and width while maintaining its aspect ratio so that the content just touches the top or left edge of the box, whichever requires the largest scale factor. Any content that extends beyond the bounds of the region is clipped.

For example, a wide-screen video can be made to play in "letterbox" mode in a region, whose width-to-height ratio is smaller, by using regPoint ="center" and regAlign="center" and setting the region's fit value to "meet". The result is the video will touch the left and right edges of the region and will be centered vertically with the gaps above and below filled in with the region's background color.

Integration Requirements

This section is normative.

The functionality in this module builds on top of the functionality in the BasicLayout module and the MediaObject module, which are required prerequisites for inclusion of the AlignmentLayout module.

5.7.6 Document Type Definition (DTD) for the AlignmentLayout Module

See the full DTD for the SMIL Layout modules.

5.8 BackgroundTilingLayout Module

5.8.1 Changes for SMIL 2.1

This section is informative.

This Layout module is new for SMIL 2.1. It provides functionality that was not supported in previous versions of the SMIL language or its profiles.

5.8.2 Overview

This section is informative.

The SMIL 2.1 BackgroundTilingLayout module defines a backgroundImage attribute that allows an image to be placed onto the background of a layout region. It also provides the same capability for the root-layout and any of the topLayout element(s), if supported by the language profile. This module also defines the backgroundRepeat attribute to control tiling of the background image. These facilities are provided as a convenience extension to SMIL's use of a background color in a region. Although similar functionality can be defined by using a combination of the image media object, the z-index attribute and subregions positioning, this would require substantially more authoring effort.

The BackgroundTilingLayout module allows simple convenience tiling support in a manner that is consistent with CSS-3. For more complex background image operations (such as support for animated images or non-image background content, users are expected to use the standard media placement and alignment facilities available in SMIL 2.1 Layout.

5.8.3 Elements and Attributes for the BackgroundTilingLayout Module

This section is normative.

This section defines the backgroundImage and backgroundRepeat attributes that make up the SMIL 2.1 BackgroundTilingLayout module.

The region

The root-layout

The topLayout

This module extends the attribute set for the region, root-layout and topLayout elements.

Element content

The SMIL 2.1 BackgrondFillLayout module does not extend the content model for elements integrating these attributes.

5.8.4 BackgroundTilingLayout Module Events

This module does not define any SMIL 2.1 events.

5.8.5 SMIL BackgroundTilingLayout Implementation and Integration

Implementation details

This section is normative.

For purposes of establishing an inheritance default value, the root-layout element defined in SMIL 2.1 BasicLayout is considered the root of the background image inheritance tree. In this case, both backgroundImage and backgroundRepeat may be used with the root-layout and region elements.

For profiles implementing the SMIL 2.1 MultiWindowLayout module, each top-level layout element is considered to define a separate root of the background image inheritance tree. In this case, both backgroundImage and backgroundRepeat may be used with any topLayout elements.

Integration Requirements

This section is normative.

The functionality in this module builds on top of the functionality in the BasicLayout module, which is a required prerequisite for inclusion of the BackgroundTilingLayout module. If this functionality is to be applied to multiple top-level windows, the MultiWindowLayout module must be included.

5.8.6 Document Type Definition (DTD) for the BackgroundTilingLayout Module

See the full DTD for the SMIL Layout modules.

5.9 OverrideLayout Module

This section is normative.

5.9.1 Changes for SMIL 2.1

The OverrideLayout module contains attributes which were defined as part of the SMIL 2.0 HierarchicalLayout module for allowing placement values in regions to be overridden by attributes on media object references. While the OverrideLayout module is new, the functionality it describes was also available in SMIL 2.0.

5.9.2 Overview

This section is informative.

The SMIL 2.1 OverrideLayout module includes the ability to use the fit, z-index, and backgroundColor attributes on objects displayed in a region in order to declare different behavior from that on the region element.

5.9.3 Elements and Attributes for the OverrideLayout Module

This module does not define any new elements. It provides extensions to the ref element (and its synonyms).

The Ref Element

The fit, z-index, and backgroundColor attributes are added to media object references.

Element content

The SMIL 2.1 OverrideLayout module does not extend the content model for the ref element integrating these attributes.

5.9.4 OverrideLayout Module Events

This module does not define any SMIL 2.1 events.

5.9.5 SMIL OverrideLayout Implementation and Integration

Implementation Details

This section is normative.

The OverrideLayout module allows individual media object references to override the default values for certain attributes. In all cases, the attributes will apply only to the (sub-)region referenced by the media object. Changes will not propagate to child sub-regions or to parent regions.

Integration Requirements

This section is normative.

The functionality in this module builds on top of the functionality in the BasicLayout module, which is a required prerequisite for inclusion of the OverrideLayout module.

5.9.6 Document Type Definition (DTD) for the OverrideLayout Module

See the full DTD for the SMIL Layout modules.

6. The SMIL 2.1 Linking Modules

Editor for SMIL 2.1:

Thierry MICHEL, W3C

Editors for SMIL 2.0

Lloyd Rutledge, CWI

Aaron Cohen, Intel.

6.1 Introduction

The SMIL 2.1 Linking Modules define the SMIL 2.1 document attributes and elements for navigational hyperlinking. These are navigations through the SMIL presentation that can be triggered by user interaction or other triggering events, such as temporal events. SMIL 2.1 provides only for in-line link elements. Links are limited to uni-directional single-headed links (i.e. all links have exactly one source and one destination resource).

The SMIL 2.1 Linking Modules are named LinkingAttributes, BasicLinking and ObjectLinking. The LinkingAttributes module includes a set of attributes used to provide SMIL linking semantics to linking elements. The BasicLinking module includes the SMIL 2.1 linking elements themselves. The ObjectLinking module includes additional optional linking features that a language profile may wish to include. Note that the BasicLinking module explicitly includes the attributes from the LinkingAttributes module on its elements.

The SMIL 2.1 specification leaves the SMIL 2.0 Linking Modules unchanged.

Please refer to the former SMIL 2.0 Linking Modules [SMIL20-linking] for definition of navigation semantics, elements and attributes allowing navigational hyperlinking through SMIL presentations.

7. SMIL 2.1 Media Object Modules Updates

Editor for SMIL 2.1

Dick C.A. Bulterman, CWI/Amsterdam

Editor for SMIL 2.0

Rob Lanphier, RealNetworks

7.1 Overview and Summary of Changes for SMIL 2.1

The only change for to the Media Object Modules for SMIL 2.1 is the introduction of the paramGroup element to predefine sets of common param element values in the document head section and a facility to refer to these definitions from media object references within the body section. This change is made to reduce the size of a SMIL document containing many similar parameter definitions and to ease the authoring and maintenance of SMIL 2.1 documents that use the elements and attributes in the MediaParam Module.

This change has resulted in an expanded definition of the MediaParam module. No other changes have been made to the other media object modules for the SMIL 2.1 release.

The following sections will highlight any text changes to the media object modules specification. Where no changes have been made, this is explicitly noted.

7.2 Definitions

This entire section remains unchanged.

7.3 Definitions

This entire section remains unchanged.

7.4 SMIL BasicMedia Module

This entire section remains unchanged.

7.5 SMIL MediaParam Module

The introduction of this section remains unchanged.

SMIL 2.1 adds a new facility to predefine commonly-used parameters in the document head section. The new sections below define the new elements and attributes of the SMIL 2.1 MediaParam Module. Unless explicitly noted, all of the functionality of the SMIL 2.0 MediaParam Module remain unchanged.

7.5.1 The param element

This section expands the definition of the param element for SMIL 2.1 to include the integration of the paramGroup element.

The param element allows a general parameter value to be sent to a media object renderer as a name/value pair. This parameter is sent to the renderer at run-time. Any number of param elements may appear (in any order) in the content of a media object element or in a paramGroup element.

The syntax of names and values is assumed to be understood by the object's implementation. This document does not specify how user agents should retrieve name/value pairs nor how they should interpret parameter names that appear multiple times within the same paramGroup element or as children of a media object.

Example

<ref src="http://www.example.com/herbert.face">
  <param name="mood" value="surly" valuetype="data"/>
  <param name="accessories" value="baseball-cap,nose-ring" valuetype="data"/>

</ref>

7.5.2 The paramGroup element

The paramGroup element provides a convenience mechanism for defining a group of media parameters that may be used with several different media objects. If present, the paramGroup element must appear in the head section of the document. The content of the paramGroup element consists of zero or more param elements. The paramGroup element may not contain nested paramGroup element definitions.

Examples

<smil ... >
  <head>
    ...
    <paramGroup id="clown">
       <param name="mood" value="upBeat" valuetype="data"/>
       <param name="accessories" value="flowers,dunceCap"/>
    </paramGroup>
    ...
  </head>
  <body>
    ...
    <ref src="http://www.example.com/andy.face" paramGroup="clown"/>
    ...
    <ref src="http://www.example.com/sally.face" paramGroup="clown"/>
    ...
  </body>
</smil>

<smil ... >
  <head>
    ...
    <paramGroup id="clown">
       <param name="mood" value="upBeat" valuetype="data"/>
       <param name="accessories" value="flowers,dunceCap"/>
    </paramGroup>
    ...
  </head>
  <body>
    ...
    <ref src="http://www.example.com/andy.face" paramGroup="clown">
      <param name="gender" value="male"/>
    </ref>
    ...
  </body>
</smil>

<smil ... >
  <head>
    ...
    <paramGroup id="clown">
       <param name="mood" value="upBeat" valuetype="data"/>
       <param name="accessories" value="flowers,dunceCap"/>
    </paramGroup>
    ...
  </head>
  <body>
    ...
    <ref src="http://www.example.com/andy.face" paramGroup="clown">
      <param name="gender" value="male"/>
      <param name="mood" value="depressed" valuetype="data"/>
    </ref>
    ...
  </body>
</smil>

7.5.3 7.4.2 Element Attributes for All Media Objects

In addition to the element attributes defined in BasicMedia, media object elements may have the attributes and attribute extensions defined below. The inclusion or exclusion of these attributes is left as an option in the language profile.

SMIL 2.1 adds the paramGroup attribute to the list of attibutes available for media objects. For completeness, the entire set of attributes is reproduced here.

7.5.4 Integration Requirements

This section remains unchanged.

7.6 SMIL MediaClipping Module

This entire section remains unchanged.

7.7 SMIL MediaClipMarkers Module

This entire section remains unchanged.

7.8 SMIL BrushMedia Module

This entire section remains unchanged.

7.9 SMIL MediaAccessibility Module

This entire section remains unchanged.

7.10 SMIL MediaDescription Module

This entire section remains unchanged.

7.11 Appendices

7.11.1 Appendix A: Changes to SMIL 1.0 Media Object Attributes

This sub-section remains unchanged.

7.11.2 Appendix B: Changes to SMIL 1.0 Media Object Elements

New child elements for media objects

This entire section remains unchanged.

The param element

The text in this section is changed to highlight the media parameter definition facility in SMIL 2.1.

A new param element provides a generalized mechanism to attach media-specific attributes to media objects. A new paramGroup element provides a convenience grouping mechanism to collect commonly used param element definitions into a single unit that may be referenced by multiple media objects.

The brush element

This entire section remains unchanged.

8. The SMIL 2.1 Metainformation Module

Editor for SMIL 2.1:

Thierry MICHEL, W3C

Editor for SMIL 2.0

Thierry Michel, W3C.

8.1 Introduction

This section defines the SMIL 2.0 Metainformation Module composed of a single module. This module contains elements and attributes that allow description of SMIL documents.

Since these elements and attributes are defined in a module, designers of other markup languages can choose whether or not to include this functionality in their languages.

The World Wide Web was originally built for human consumption, and although everything on it is machine-readable, this data is not machine-understandable. It is very hard to automate anything on the Web, and because of the volume of information the Web contains, it is not possible to manage it manually. Metadata is "data about data" (for example, a library catalog is metadata, since it describes publications) or specifically in the context of this specification "data describing Web resources".

The solution proposed here is to use metadata information to describe SMIL documents published on the Web.

The earlier SMIL 1.0 specification allowed authors to describe documents with a very basic vocabulary using the meta element.

The SMIL 2.1 Metainformation module defined in this specification fully supports the use of this meta element from SMIL 1.0 but it also introduces new capabilities for describing metadata using the Resource Description Framework Model and Syntax [RDFsyntax], a powerful meta information language for providing information about resources.

The SMIL 2.1 specification leaves the SMIL 2.0 Metainformation Module unchanged.
Please refer to the former SMIL 2.0 Metainformation Module [SMIL20-meta] for information about metadata semantics, elements and attributes allowing description of SMIL documents.

9. The SMIL 2.1 Structure Module

Editor for SMIL 2.1

Thierry MICHEL, W3C

Editors for SMIL 2.0

Warner ten Kate, Philips Electronics

Aaron Cohen, Intel.

9.1 Introduction

This section is informative.

This Section defines the SMIL 2.1 Structure module. The Structure module provides the base elements for structuring SMIL content. These elements act as the root in the content model of all SMIL Host Language conformant language profiles. The Structure module is a mandatory module for SMIL Host Language conformant language profiles.

The SMIL Structure module is composed of the smil, head, and body elements, and is compatible with SMIL 1.0 [SMIL10]. The corresponding SMIL 1.0 elements form a subset of the Structure module, both in syntax and semantics, as their attributes and content model is also exposed by the Structure module. Thus, the Structure module is backwards compatible with SMIL 1.0.

The SMIL 2.1 specification leaves the SMIL 2.0 Structure Module unchanged.
Please refer to the former SMIL 2.0 Structure Module Module [SMIL20-structure] for information about semantics, elements and attributes for structuring SMIL content.

10. The SMIL 2.1 Timing and Synchronization Module Updates

Editor for SMIL 2.1

Dick Bulterman, CWI/Amsterdam

Editors for SMIL 2.0:

Patrick Schmitz, Microsoft

Jeff Ayars, RealNetworks

Bridie Saccocio, RealNetworks

Muriel Jourdan, INRIA.

10.1 Overview and Summary of Changes for SMIL 2.1

This section is informative

The SMIL 2.1 specification leaves the basic syntax and semantics of the SMIL 2.0 timing model unchanged [SMIL20-timing]. The only change for SMIL 2.1 that SMIL 2.0's ExclTimeContainers module is deprecated and replaced with two new modules: BasicExclTimeContainers and BasicPriorityClassContainers. This partitioning is done to reduce the implementation burden of the excl element on low-powered devices or in implementations in which the full functionality of the priority class mechanism of SMIL 2.0 is not required.

The following sections will highlight any text changes to the SMIL 2.0 timing and synchronization specification [SMIL20-timing]. Where no changes have been made, this is explicitly noted.

As a result of this change, SMIL 2.1 Timing and Synchronization support is broken down into 16 modules instead of the 15 modules used in SMIL 2.0. These modules are described in Appendix A: SMIL Timing and Synchronization modules.

Note: A SMIL 2.0 errata was raised which affects SMIL 2.1 Timing and Synchronization Module Update . Please refer to the SMIL 2.0 [Second Edition] Errata page, for details. This errata should be incorporated in the next SMIL 2.1 Proposed Recommendation full version.

10.2 Introduction

This section remains unchanged.

10.3 Overview of SMIL timing

This section remains unchanged.

10.4 Language definition

The majority of this section remains unchanged for SMIL 2.1 except for the description of the behavior of the excl element.

10.4.1 Attributes

This sub-section remains unchanged.

10.4.2 Elements

The definitions of the par, seq, and priorityClass elements in the SMIL 2.0 specification remain unchanged in SMIL 2.1. The only change made in this section is the definition of the excl element.

The excl element

SMIL 2.1 modifies the definition of the SMIL 2.0 exclusive container, excl. The modification provides default behavior for implementations that only support the exclusive element and not the priorityClass element.

This section provides all of the normative text of the exclusive element definition. For examples and use cases, please refer to the SMIL 2.0 specification [SMIL20-timing].

This section is normative

excl

This defines a time container with semantics based upon par, but with the additional constraint that only one child element may play at any given time. If any element begins playing while another is already playing, the element that was playing is stopped. If the priorityClass element is also supported by a profile, child elements in an excl container may be grouped into categories; the behavior of the element that was playing at the time a new element starts can be defined to have stop/pause/interruption behavior. The priorityClass can define several levels of interrupt behavior (one per class), each of which can be controlled explicitly.

Implicit duration of excl containers

This section is normative

• The implicit duration of an excl container is defined the same as for a par container, using the endsync="last" semantics. However, since the default timing for children of excl is interactive, the implicit duration for excl time containers with only default timing on the children will be 0.

The remainder of this section remains unchanged.

10.4.3 Semantics of the Timing Model

This sub-section remains unchanged.

10.4.4 Clarifications and surprising results

This sub-section remains unchanged.

10.5 Integrating SMIL Timing and Synchronization into a host language

This section remains unchanged.

10.6 Document object model support

This sub-section remains unchanged.

10.7 Glossary

This sub-section remains unchanged.

10.8 Appendix A: SMIL Timing and Synchronization modules

This section is normative.

All SMIL 2.0 timing and synchronization modules remain unchanged except as noted in this section.

ExclTimeContainers

This module is depreciated in SMIL 2.1.

BasicExclTimeContainers

This module is new to SMIL 2.1. It includes a time container that defines a mutually exclusive set of elements and describes the 'stop' interrupt semantic among these elements.

Module dependencies

None.

Included features

excl element, fill and endsync attributes.

Other module specific integration requirements

fill="transition" is only supported when BasicTransitions or InlineTransitions is included in the language profile. If FillDefault is not included in the profile, fill="default" is interpreted the same as fill="auto".

BasicPriorityClassContainers

This module is new to SMIL 2.1. It includes a child element for the excl that is used to describe interrupt semantics among group of children of the the exclusive element.

Module dependencies

The BasicExclTimeContiners module must be included in a profile containing the BasicPriorityClassContainers module

Included features

priorityClass element.

Other module specific integration requirements

None.

10.9 Appendix B: Annotated examples

This sub-section remains unchanged.

10.10 Appendix C: Differences from SMIL 1.0

This sub-section remains unchanged.

10.11 Appendix D: Unifying event based and scheduled timing

This sub-section remains unchanged.

11. The SMIL 2.1 Time Manipulations Module

Editor for SMIL 2.1:

Thierry MICHEL, W3C

Editor for SMIL 2.0:

Patrick Schmitz, Microsoft

11.1 Introduction

This module introduces new attributes for advanced manipulation of time behavior, such as controlling the speed or rate of time for an element. These time manipulations are especially suited to animation and non-linear or discrete media. Not all continuous media types will fully support time manipulations. For example, streaming MPEG 1 video will not generally support backwards play. A fallback mechanism is described for these kinds of media.

Four new attributes add support for time manipulations to SMIL timing modules, including control over the speed of an element, and support for acceleration and deceleration.  The impact on overall timing and synchronization is described. A definition is provided for reasonable fallback mechanisms for media players that cannot support the time manipulations.

An accessibility requirement for control of the playback speed is related to the speed control, but may also be controlled through some other mechanism such as DOM interfaces. 

The SMIL 2.1 specification leaves the Time Manipulations Module unchanged.
Please refer to the former SMIL 2.0 Time Manipulations Module [SMIL20-timemanipulations] for information about semantics, elements and attributes allowing advanced manipulation of time behavior in SMIL presentationss.

12. The SMIL 2.1 Transition Effects Modules Updates

Editors for SMIL 2.1:

Jack Jansen, CWI/Amsterdam

Antti Koivisto, Nokia

Guido Grassel, Nokia

Editors for SMIL 2.0:

Eric Hyche, RealNetworks

Debbie Newman, Microsoft

12.2 Changes to Transition Model

In case of SMIL language profile supporting FullScreenTransitions module the area to which the transition applies may be different and, hence, the effect perceived by the viewer is of multiple media items transitioning. However, all timing rules and other rules for applying transitions outlined in the SMIL 2.0 Transitions Model [SMIL20-transition] still treat the transition exactly the same as when applying it to a single media item.

12.3 Additions to the BasicTransitions Module

The only change from SMIL 2.0 BasicTransitions module [SMIL20-transition] is the inclusion of audio transitions. Audio transitions animate the audio component of the target media object. SMIL 2.1 specifies two audio transitions, "audioFade" and "audioVisualFade". They both adjust the audio volume of the target media. The latter one also animates the visual component of the media.

The "audioFade" transition fades an audio clip in or out by linearly adjusting the volume of the clip. As with the visual "fade" transition from SMIL 2.0, direction of the transition depends on whether it is used in transIn or transOut attribute. To achieve cross-fade effect between two audio clips, the clips must overlap in time and the "audioFade" transitions need to be applied simultaneously to both.

The "audioVisualFade" fade acts like a combination of the "audioFade" and the visual "fade" transitions from SMIL 2.0. It has the same subtypes as "fade" transition. Future versions of the specification may provide a general mechanism for combining transitions.

Since the fill attribute semantics dictate that audio is silent during the fill period, the fill value fill="transition" can't be used for transition effects between audio clips. To mix audio clips using transition effects the timeline of the clips must overlap.

Example:

The following example cross-fades between two audio clips. For cross-fade effect the clips must overlap in the presentation timeline. Since audio clips are not audible during the fill period, a sequence time container would not be suitable for achieving this effect.

<transition id="four_sec_fade" type="audioFade" subType=fade" dur="4s"/>
. . .
<par>
  <audio id="audio1" ... transOut="four_sec_fade" />
  <audio id="audio2" ... begin="audio1.end-4s" transIn="four_sec_fade" />
</par>

12.4 New FullScreenTransitions Module

The FullScreenTransitions module extends SMIL 2.1 BasicTransitions module with the option of doing full-screen transitions, while keeping the semantics of transitions the same. Logically, a transition is still applied to a single media item, through the transIn or transOut attribute, but the visual effect is that the whole screen or window is transitioned from one set of media items to another. In this section we refer to the media item with the transIn or transOut attribute as the master media item.

The exact meaning of whole window must be defined in the language profile including this module. In general, it will be the largest possible area encompassing the destination region, for instance the topLayout element of which the region is a descendant, or the whole screen for profiles without support for separate windows.

Consider the following presentation:

...
<head>
   <transition id="diagonalWipe" type="diagonalWipe" subtype="topRight" 
                  dur="1s" />
  ...
</head>
<body>
  <par dur="10s">
        <img  id="left1"   src="left1.jpg"  region="leftpane"   />
        <text id="right1"  src="right1.txt" region="rightpane"  />
  </par>
  <par dur="10s">
        <img  id="left2"  src="left2.jpg"  region="leftpane"  />
        <text id="right2" src="right2.txt" region="rightpane" />
  </par>
</body>
...

We can define parallel transitions on individual media objects using SMIL 2.0 BasicTransitions [SMIL20-transition]: For this purpose we add attribute transIn="diagonalWipe" to elements "left2" and "right2" identifiers and attribute fill="transition" to elements "left1" and "right1" identifiers.

Parallel transitions on individual media objects

It is common practice to apply transitions across several different media at once. Using FullScreenTransitions we can achieve a transition effect on the whole screen:

Full-screen transition

The SMIL 2.1 FullScreenTransitions module adds a single attribute to the transition element defined in SMIL2.0 [SMIL20-transition] :

Element attributes

The transition element is extented with the following attribute:

scope

This attribute designates the destination area of the transition. The allowable values are

region

In this case the transition behaves as specified in the BasicTransitions module. This is the default value.

screen

In this case the destination area encompasses a larger area, as defined in the language profile.

The media items that transition together with the master media item are all those media items that are rendering within the area defined by the scope attribute at the time the transition starts. In effect, a transIn transition transitions from the set of media items defined as "background" in the Transition Model to the set of media items that would have been visible at the start time if no transIn attribute had been present. A transOut transition is from a set of media items visible at the start time of the transition to the set of media items that should be visible just after the master media item finishes (note that this set does not depend on whether transOut is specified or not).

Media items that start or end during the transition are treated in the same way as the background media items (see the BasicTransitions module)

.

Using these definitions a full-screen transition can be added to above example as follows:

...
<head>
   <transition id="diagonalWipeFullScreenTransition" type="clockWipe" subtype="clockwiseTwelve" 
                  dur="1s" scope="screen" />
  ...
</head>
<body>
  <par dur="10s">
        <img  id="left1"   src="left1.jpg"  region="leftpane"  fill="transition"  />
        <text id="right1"  src="right1.txt" region="rightpane" fill="transition"  />
  </par>
  <par dur="10s">
        <img  id="left2"   src="left2.jpg"  region="leftpane"  />
        <text id="right2"  src="right2.txt" region="rightpane" transIn="diagonalWipeFullScreenTransition" />
  </par>
</body>
...

12.5 Additions to Appendix: Taxonomy Tables

SMIL 2.1 introduces the following two new transition types.

AudioTransitions
type	subType
audioFade audioVisualFade	fade (default) crossfade (default), fadeToColor, fadeFromColor

13. SMIL 2.1 Language Profile

Editor:

Nabil Layaïda, INRIA

13.1 Abstract

The SMIL 2.1 profile describes the SMIL 2.1 modules that are included in the SMIL 2.1 Language and details how these modules are integrated. It contains support for all of the major SMIL 2.1 features including animation, content control, layout, linking, media object, meta-information, structure, timing and transition effects. It is designed for Web clients that support direct playback from SMIL 2.1 markup. 

13.2 SMIL 2.1 Profile

This section is informative.

The SMIL 2.1 Profile is defined as a markup language. The syntax 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 2.1 Modules".

The SMIL 2.1 Profile design requirements are:

1. Ensure that the profile is completely backward compatible with SMIL 1.0.
2. Ensure that the profile is completely backward compatible with SMIL 2.0.
3. Ensure that all the modules' semantics maintain compatibility with SMIL semantics (this includes content and timing).
4. Adopt new W3C Recommendations when appropriate without conflicting with other requirements.

13.3 Normative Definition of the SMIL 2.1 Language Profile

This section is normative.

13.3.1 Document Conformance

This version of SMIL provides a definition of strictly conforming SMIL 2.1 documents, which are restricted to tags and attributes from the SMIL 2.1 namespace. The Section "Extending SMIL 2.1 Language" provides information on using SMIL 2.1 with other namespaces, for instance, on including new tags within SMIL 2.1 documents.

13.3.2 SMIL 2.1 Language Conformance

Conforming SMIL 2.1 Documents

A SMIL 2.1 document is a conforming SMIL 2.1 document if it adheres to the specification described in this document (Synchronized Multimedia Integration Language (SMIL) 2.1 Profile Specification) including SMIL 2.1's DTD (see Document Type Definition). A conforming SMIL 2.1 document must meet all of the following criteria:

1. The root element of the document must be the smil element.
2. The document must be well-formed XML.
3. It must conform to the following W3C Recommendations:
   • The XML 1.1 specification (Extensible Markup Language (XML) 1.1) [XML11].
   • Namespaces in XML [XML-NS]. Full XML Namespaces must be supported.
   • Any use of CSS styles and properties shall conform to Cascading Style Sheets, level 2 CSS2 Specification [CSS2].
4. A SMIL 2.1 document can contain the following DOCTYPE declaration:

   The SMIL 2.1 Language DOCTYPE is:

   <!DOCTYPE smil PUBLIC "-//W3C//DTD SMIL 2.1//EN"
                         "http://www.w3.org/2005/SMIL21/CR/SMIL21.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 are not allowed. If the document is invalid, the user agent should issue an error.
   

   A document is a conforming SMIL 2.1 document if it satisfies the requirements of this specification (Synchronized Multimedia Integration Language (SMIL) 2.1 Profile Specification) and is valid per the normative DTD identified by
   http://www.w3.org/TR/2005/REC-SMIL21-2005mmdd/smil21DTD/smil-DTD.dtd
   (Note: The SMIL 2.1 normative DTD will be identified and published at its final URI for Recommendation.)
   Per section 7.6 of the W3C Process Document, W3C will make every effort to make this normative DTD available, in its original form, at this URI.

   The SYMM WG also publishes a non-normative SMIL 2.1 DTD identified by http://www.w3.org/2005/WD/SMIL21/SMIL21.dtd
   The SYMM WG plans to make changes to this DTD over time to correct errata. If you choose to refer to this DTD, please note that it is subject to change without notice at any time. The SYMM WG MAY publish a normative "snapshot" of the corrected DTD at a new URI by following the W3C Process for modifying a Recommendation.

   Individuals are free to use either of the two URIs above as the system identifier in the SMIL 2.1 language DOCTYPE, according to the desired level of stability.

5. A document must declare a default namespace for its elements with an xmlns attribute on the smil root element with its identifier URI:

   <smil xmlns="http://www.w3.org/2005/SMIL21/CR/Language">
      ...
   </smil>  

   The default namespace declaration must be xmlns="http://www.w3.org/2005/SMIL21/CR/Language".

   This namespace URI will only be used to refer to this version of this specification: different URIs will be used for any and all new versions of the specification. This namespace name may be reused in any update of the specification which is made for the purpose of clarification or bug fixes. These changes will be minor in that they do not (a) change the meaning of existing documents written using the namespace, or (b) affect the operation of existing software written to process such documents. The SYMM WG may reuse this namespace URI in a future specification that revises the SMIL 2.1 DTD, thus affecting the validity of published documents.

6. A document may declare both an XML DOCTYPE declaration (as defined in [XML11]) and one or more XML namespace declarations (as defined in [XML-NS]). To be recognized as a SMIL 2.1 document by a conforming SMIL 2.1 user agent, the document must include the SMIL 2.1 namespace identifier as the default namespace on the <smil> tag. For example:

   Declare a SMIL 2.1 document with custom extensions conforming to a custom DTD:

   <!DOCTYPE smil SYSTEM "http://www.example.org/myveryownSMIL.dtd">
   <smil xmlns="http://www.w3.org/2005/SMIL21/CR/Language"
           xmlns:mysmil="http://www.example.org/2005/SMIL30/Language">
           <mysmil:foo>
           ...
           </mysmil:foo>
   </smil>

7. A document that declares neither a DOCTYPE nor a default namespace declaration will be processed as a SMIL 1.0 document. Extension elements or attributes not defined by the SMIL 1.0 namespace should be declared using the XML namespace mechanism.
8. Given that, as of this writing, DTDs have no way to describe the allowability of namespace-qualified extensions, and that extensions to SMIL 2.1 conformant documents must be namespace-qualified, here is the algorithm to be used to validate documents with extensions:

   If all non-SMIL 2.1 namespace elements and attributes and all xmlns attributes which refer to non-SMIL 2.1 namespace elements are removed from the given document and if the appropriate <!DOCTYPE ... > statement which points to the SMIL 2.1 DTD is included, the result is a valid XML document.

9. Many SMIL 2.1 attributes are associated with several SMIL 2.1 and SMIL 2.0 namespaces including the module namespaces, module collection namespaces, the SMIL 2.1 language namespace, and the overall SMIL 2.1 namespace. Attributes in the SMIL 2.1 namespaces having the same local part are considered the same attribute as far as SMIL 2.1 Language document syntax. It is illegal to use a SMIL 2.1 attribute several times on an element, even if each occurrence is qualified by a different SMIL 2.1 namespace, and SMIL user agents shall treat this as a syntax error. For example, the following document fragment is an error, because the begin attribute appears twice on the ref element:

   <smil xmlns="http://www.w3.org/2005/SMIL21/CR/Language"
           xmlns:BasicInlineTiming="http://www.w3.org/2005/SMIL21/CR/BasicInlineTiming">
   ...
   <ref begin="5s" BasicInlineTiming:begin="5s"/>
   ...
   </smil>

The SMIL 2.1 language or these conformance criteria provide no designated size limits on any aspect of SMIL 2.1 content. There are no maximum values on the number of elements, the amount of character data, or the number of characters in attribute values.

SMIL 2.1 deprecates base as a property value for the content attribute of the meta element of SMIL 1.0 in favor of the more general XML Base URI mechanisms.

The SMIL 2.1 Language profile supports the XML Base Recommendation [XMLBase]. XML Base is supported on all elements, and affects the interpretation of URIs as specified in the individual modules defining the URI attributes. Specifically, any applicable XML Base base URI must be applied to the interpretation of the href attribute of the link elements a, area and anchor, as well as the src attribute of the media elements audio, video, img, animation, textstream, text, and ref. XML Base must also be applied on longdesc attributes of all of the SMIL 2.1 Language elements.

The rules above should be revised once a normative XML Schema for SMIL 2.1 is available. This revision will take into account XML Schema validation.

Conforming SMIL 2.1 Language User Agents

A SMIL 2.1 user agent is a program which can parse and process a SMIL 2.1 document and render the contents of the document onto output mediums. A conforming SMIL 2.1 user agent must meet all of the following criteria:

1. In order to be consistent with the XML 1.1 Recommendation [XML11], the user agent must parse and evaluate a SMIL 2.1 document for well-formedness. If the user agent claims to be a validating user agent, it must also validate documents against their referenced DTDs according to [XML11].
2. When the user agent claims to support the functionality of SMIL 2.1 through SMIL 2.1 elements and attributes and the semantics associated with these elements and attributes, it must do so in ways consistent with this specification.
3. The user agent must be able to successfully parse and process any conforming SMIL 2.1 documents, and support and correctly implement the semantics of all SMIL 2.1 Language Profile features.
4. The XML parser of the user agent must be able to parse and process XML constructs defined in [XML11] and [XML-NS].
5. The default namespace on the smil root element recognized by the user agent will fall into one of three types:
   1. Default namespace on the smil root element recognized in its entirety by the user agent. The user agent should process the document as the version identified by the recognized namespace. Any elements, attributes, or other syntax not defined by the default namespace on the smil root element must be fully namespace qualified using the standard XML mechanisms for declaring namespaces for elements and attributes described in [XML-NS]. The "skip-content" mechanism (defined in the SkipContent module) will be applied to extension elements unrecognized by the user agent. Unqualified elements not part of the default namespace are illegal and must result in an error.

      Examples:

      1) A pure SMIL 1.0 document:

      <smil xmlns="http://www.w3.org/TR/REC-smil">
       ...
      </smil>  

      2) A pure SMIL 2.1 document:

      <smil xmlns="http://www.w3.org/2005/SMIL21/CR/Language">
       ...
      </smil>  

      3) A SMIL 1.0 document that has been extended to use the excl element:

      <smil xmlns="http://www.w3.org/TR/REC-smil"
            xmlns:smil21="http://www.w3.org/2005/SMIL21/CR/" >
         <smil21:excl>
           ...
         </smil21:excl>
      </smil>  

      4) A SMIL 2.1 document that has been extended to use the 'foo' element from a fictitious SMIL 3.0 version of SMIL:

      <smil xmlns="http://www.w3.org/2005/SMIL21/CR/Language"         
            xmlns:smil30="http://www.example.org/2005/SMIL30/" >
        <smil30:foo>
         ...         
        </smil30:foo>
      </smil>

   2. No default namespace declaration is present on the smil root element in the document. The document will be processed as a SMIL 1.0 document.
   3. The namespace declaration is "http://www.w3.org/2001/SMIL20/Language". The document will be processed as a SMIL 2.0 document.
   4. Default namespace declaration on the smil root element unrecognized. A SMIL user agent will not recognize the document as any version of SMIL and must issue an error.
6. The user agent must support the following W3C Recommendations with regard to SMIL 2.1 content:
   • Complete support for the XML 1.1 specification (Extensible Markup Language (XML) 1.1) [XML11].
   • Complete support for inclusion of non-SMIL 2.1 namespaces within SMIL 2.1 content via Namespaces in XML [XML-NS]. A xmlns declaration or xmlns prefix declaration may be used on any element in the SMIL 2.1 language profile.
7. The user agent ignores namespace prefix qualified elements from unrecognized namespaces and must support the skip-content attributes. If no skip-content attributes are declared, the value of true is assumed.
8. The user agent ignores elements with unrecognized default namespace declarations and must support the skip-content attribute. If no skip-content attributes are declared, the value of true is assumed.
9. The user agent must issue an error for an attribute value which does not conform to the syntax specified for that attribute.
10. The detection of a syntax error in a SMIL 2.1 language profile document must result in the user agent issuing an error and not playing the document.
11. When the deprecated (hyphenated) and the new (camelCase) version of an attribute syntax are used in the same document, SMIL 2.1 user agents should take into account the camelCase version only.
12. Conforming SMIL 2.1 Language user agents must play SMIL 1.0 documents as specified in the SMIL 1.0 Recommendation [SMIL10] and SMIL 2.0 documents as specified in the SMIL 2.0 Recommendation [SMIL20].

The Web Accessibility Initiative is defining "User Agent Accessibility Guidelines 1.0" [UAAG]. Developers are encouraged to design user agents that satisfy at least the Level A requirements of that document. Should UAAG 1.0 become a W3C Recommendation, a future version of SMIL is likely to require Level A conformance to UAAG 1.0 as part of SMIL user agent conformance.

13.3.3 The SMIL 2.1 Language Profile

The SMIL 2.1 Language Profile supports the timeline-centric multimedia features found in the SMIL 2.1 modules. It uses only modules from the SMIL 2.1 recommendation. As the language profile includes the mandatory modules, it is a SMIL Host Language conforming language profile. This language profile includes the following SMIL 2.1 modules:

1. Structure functionality
   1. Structure Module
2. Metainformation functionality
   1. Metainformation Module
3. Timing functionality
   1. BasicInlineTiming Module
   2. BasicTimeContainers Module
   3. BasicExclTimeContainers Module
   4. BasicPriorityClassContainers Module
   5. EventTiming Module
   6. FillDefault Module Module
   7. MediaMarkerTiming Module
   8. MinMaxTiming Module
   9. MultiArcTiming Module
   10. RepeatTiming Module
   11. RepeatValueTiming Module
   12. RestartDefault Module
   13. RestartTiming Module
   14. SyncbaseTiming Module
   15. SyncBehavior Module
   16. SyncBehaviorDefault Module
   17. WallclockTiming Module
4. Animation functionality
   1. BasicAnimation Module
5. Content Control functionality
   1. BasicContentControl Module
   2. CustomTestAttributes Module
   3. PrefetchControl Module
   4. SkipContentControl Module
6. Layout functionality
   1. AlignmentLayout Module
   2. AudioLayout Module
   3. BackgroundTilingLayout Module
   4. BasicLayout Module
   5. MultiWindowLayout Module
   6. OverrideLayout Module
   7. SubRegionLayout Module
7. Linking functionality
   1. BasicLinking Module
   2. LinkingAttributes Module
   3. ObjectLinking Module
8. Transition Effects functionality
   1. BasicTransitions Module
   2. TransitionModifiers Module
   3. FullScreenTransitions Module
9. Media functionality
   1. BasicMedia Module
   2. BrushMedia Module
   3. MediaAccessibility Module
   4. MediaClipping Module
   5. MediaClipMarkers Module
   6. MediaDescription Module
   7. MediaParam Module

The collection names contained in the following table define the SMIL 2.1 Profile vocabulary.

In the following sections, we define the set of elements and attributes used in each of the modules included in the SMIL 2.1 Profile. The content model for each element is described. The content model of an element is a description of elements which can appear as its direct children. The special content model "EMPTY" means that a given element may not have children.

The id, classand titleattributes in the collection Core are defined for all the elements of the SMIL 2.1 Profile. The idattribute is used in the SMIL 2.1 Language Profile to assign a unique XML identifier to every element in a SMIL document. In this document, equivalent but deprecated attributes and elements are in parentheses.

13.3.4 Animation Module

The Animation Module provides a framework for incorporating animation into a timing framework, and a mechanism for composing the effects of multiple animations. The Animation Module uses the timing modules included in this profile for the underlying model of time. The SMIL 2.1 profile includes the animation functionality of the BasicAnimation module. The BasicAnimation Module defines the semantics for the animate, set, animateMotion and animateColor elements.

In the SMIL 2.1 Language Profile, Animation elements can have the following attributes and content model :

This profile adds the animate, set, animateMotion and animateColor elements to the content model of the par, seq, excl and priorityClass elements of the Timing and Synchronization Modules. It also adds these elements to the content model of the body element of the Structure Module.

Specifying the target element of the animation

The animation target elements supported in the SMIL 2.1 Profile are the region element defined in the Layout Modules, the area (anchor) element defined in the Linking Modules and the text, img, audio, animation, video, ref, textstream and the brush elements defined in the Media Objects modules.

The SMIL 2.1 Language Profile uses the targetElement attribute to identify the element to be affected by animation elements. As recommended in the BasicAnimation Module when the targetElement attribute is supported, this profile excludes the XLink attributes href, type, actuate and show from the animate, set, animateMotion and animateColor elements.

Specifying the target attribute of the animation

The target attributes of the animations are a subset of those of the region, area (anchor), and media elements. The animatable attributes of the region, area (anchor), and media elements are listed in the table below.

The area (anchor) element has the coords attribute which can be subject to animation. The attribute coords is considered of type string in this profile. This means that only discrete non-additive animation is supported on this attribute. 

The media elements have the following sub-region attributes which can be subject to animation: left, right, top, bottom, width, height, z-indexand backgroundColor.

Integration definitions

The SMIL 2.1 Language profile defines a set of integration definitions as required by the Animation modules. These definitions are:

• Animation values in the SMIL 2.1 Language 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 2.1 Language profile.
• The SMIL 2.1 Language profile supports CSS2 [CSS2] color names as described in the Layout modules. 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 the animateMotion 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 the animateMotion when applied to the sub-region on media elements is the top left of the containing region as defined in the Layout modules.

13.3.5 Content Control Modules

The Content Control Modules provide a framework for selecting content based on a set of test attributes. The Content Control Modules define semantics for the switch, prefetch, customAttributes and customTest elements. The SMIL 2.1 profile includes the Content Control functionality of the BasicContentControl, CustomTestAttributes, PrefetchControl and SkipContentControl modules.

In the SMIL 2.1 Language Profile, Content Control elements can have the following attributes and content model :

This profile adds the switch element to the content model of the par, seq and excl elements of the Timing and Synchronization Modules, of the body and the head elements of the Structure Module, of the content model of the a element of the Linking Modules. The profile adds the customAttributes element to the content model of the head and the customTest element to the content model of the customAttributes element.

The Content Control functionality is used to define the Attribute set "Test":

The collection of Attributes Test is added to all the elements defined in the SMIL 2.1 profile, except customTest and customAttributes. A SMIL 2.1 user agent must support all of the values for the systemOperatingSystem and systemCPUattributes listed in the Content Control Modules. In addition, the user agent should accept namespaced values as future extensions, and not declare a syntax error. The user agent should return false for unrecognized values of the systemOperatingSystem and systemCPUattributes. 

13.3.6 Layout Modules

The Layout Modules provide a framework for spatial layout of visual components. The Layout Modules define semantics for the region, root-layout, topLayout, layout and the regPoint elements. The SMIL 2.1 profile includes the Layout functionality of the AlignmentLayout Module, AudioLayout Module, BackgroundTilingLayout Module, BasicLayout Module, MultiWindowLayout Module, OverrideLayout Module, SubRegionLayout Module modules.

In the SMIL 2.1 Language Profile, Layout elements can have the following attributes and content model :

(**) The "background-color" attribute of SMIL1.0 is deprecated in favor of "backgroundColor", but both are supported.

The attribute collection SubregionAttributes is defined as follows:

This profile adds the layout element to the content model of the head element of the Structure Module. It also adds this element to the content model of the switch element of the Content Control Modules, when the switch element is a child of the head element.

13.3.7 Linking Modules

The Linking Modules provide a framework for relating documents to content, documents and document fragments. The Linking Modules define semantics for the a and area (anchor) elements. They define also the semantics of a set of attributes defined for these elements. The SMIL 2.1 profile includes the Linking functionality of the BasicLinking, LinkingAttributes and ObjectLinking modules.

Both the a and area elements have an href attribute, whose value must be a valid URI.

Support for URIs with XPointer fragment identifier syntax is not required.

In the SMIL 2.1 Language Profile, Linking elements can have the following attributes and content model :

This profile adds the a element to the content model of the par, seq, and excl elements of the Timing and Synchronization Modules. It also adds these elements to the content model of the body element of the Structure Module.

In the SMIL 2.1 language profile, a value of onLoad set on the attribute actuate indicates that the link is automatically traversed when the linking element becomes active. For linking elements containing SMIL timing, this is when the active duration of the linking element begins.

The attribute tabindex specifies the position of the element in the tabbing order at a particular instant for the current document. The tabbing order defines the order in which elements will receive focus when navigated by the user via an input device such as a keyboard. At any particular point in time, only active elements are taken into account for the tabbing order; inactive elements are ignored.

When a media object element has a tabindex attribute and becomes active, then its ordered tab index is inserted in the SMIL tab index at the location specified by the media object's tabindex attribute value. This assumes that the media object itself has tab indices, such as embedded HTML with tabindex attributes. This enables all link starting points in a SMIL presentation to have a place on the ordered list to be tab-keyed through, including those in embedded presentations.

For SMIL 1.0 backward compatibility, the anchorelement is available but deprecated in favor of area. The anchor element supports the same attributes as area, both the new SMIL 2.1 attributes and the SMIL 1.0 attributes as defined in [SMIL10].

SMIL 1.0 backward compatibility: The show attribute value pause is deprecated in favor of setting the show attribute to new and the sourcePlaystate attribute to pause.

13.3.8 Media Object Modules

The Media Object Modules provide a framework for declaring media. The Media Object Modules define semantics for the ref, animation, audio, img, video, text, textstream and brush elements. The SMIL 2.1 profile includes the Media functionality of the BasicMedia, MediaClipping, MediaClipMarkers, MediaParam, BrushMedia and MediaAccessibility modules.

In the SMIL 2.1 Language Profile, media elements can have the following attributes and content model:

Widely Supported MIME Types

This section is informative.

The members of the W3C SYMM Working Group believe that the following MIME types will be widely supported by SMIL user agents:

• audio/basic [MIME-2]
• image/png ([PNG-MIME], [PNG-REC])
• image/jpeg ([MIME-2], [JFIF])

Implementers of SMIL user agents should thus strive to provide support for each of these types. Note, however, that this section is non-normative, and that support for these MIME types is not a precondition for conformance to this specification.

Authors are encouraged to encode media objects using one of the widely supported MIME types whenever possible. This will ensure that their SMIL documents can be played back by a wide range of SMIL user agents.

If authors use a MIME type that is not in the list of widely supported types, they should provide an alternative version encoded using a baseline format. This can be achieved by using a switch element as shown in the following example:

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

In this example, a user agent that supports the non-baseline format will play the first audio media object, and a user agent that does not support the non-baseline format will play the second media object.

Media Object Integration Requirements

This section is normative.

The MediaParam module defines the eraseattribute, and defers definition of the "display area" to the language profile. "Display area" for the purposes of the SMIL 2.1 Language corresponds to a SMIL BasicLayout region. The effects of erase="never" apply after the active duration of the media object and any fill period (defined by SMIL Timing and Synchronization), and only until other media plays to the region targeted by the media object, or until the same media object restarts.

13.3.9 Metainformation Module

The Metainformation Module provides a framework for describing a document, either to inform the human user or to assist in automation. The Metainformation Module defines semantics for the meta and metadata elements. The SMIL 2.1 profile includes the Metainformation functionality of the Metainformation module.

In the SMIL 2.1 Language Profile, Metainformation elements can have the following attributes and content model :

This profile adds the meta element to the content model of the head element of the Structure Module.

The content model of metadata is empty. Profiles that extend the SMIL 2.1 language profile can define the RDF (Resource Description Framework) schema to be used in extending the content model of the metadata element. The Resource Description Framework is defined in the W3C RDF Recommendation [RDFsyntax].

13.3.10 Structure Module

The Structure Module provides a framework for structuring a SMIL document. The Structure Module defines semantics for the smil, head, and body elements. The SMIL 2.1 profile includes the Structure functionality of the Structure module.

In the SMIL 2.1 Language Profile, the Structure elements can have the following attributes and content model :

The body element acts as the root element to span the timing tree. The body element has the behavior of a seq element. Timing on the body element is supported. The syncbase of the body element is the application begin time, which is implementation dependent, as is the application end time. Note that the effect of fillon the bodyelement is between the end of the presentation and the application end time, and therefore the effect of fill is implementation dependent.

13.3.11 Timing and Synchronization Modules

The Timing and Synchronization Modules provide a framework for describing timing structure, timing control properties and temporal relationships between elements. The Timing and Synchronization Modules define semantics for par, seq, excl and priorityClass elements. In addition, these modules define semantics for attributes including begin, dur, end, repeat (deprecated), repeatCount, repeatDur, syncBehavior, syncTolerance, syncBehaviorDefault, syncToleranceDefault, restartDefault, fillDefault, restart, min, max.The SMIL 2.1 profile includes the Timing functionality of the AccessKeyTiming Module, BasicInlineTiming Module, BasicTimeContainers Module, BasicExclTimeContaine Module, BasicPriorityClassContainers Module, EventTiming Module, FillDefault Module Module, MediaMarkerTiming Module, MinMaxTiming Module, MultiArcTiming Module, RepeatTiming Module, RepeatValueTiming Module, RestartDefault Module, RestartTiming Module, SyncbaseTiming Module, SyncBehavior Module, SyncBehaviorDefault Module, WallclockTiming Module modules.

In the SMIL 2.1 Language Profile, Timing and Synchronization elements can have the following attributes and content model :

The Attribute collections Timing and basicTiming are defined as follows:

This profile adds the par, seq, and excl elements to the content model of the body element of the Structure Module and adds these elements to the content model of the a element of the Linking Modules.

Elements of the Media Object Modules have the attributes describing timing and properties of contents.

Supported Event Symbols

The SMIL 2.1 Language profile specifies which types of events can be used as part of the begin and end attribute values. The supported events are described as Event-symbols according to the syntax introduced in the SMIL Timing and Synchronization module.

The supported event symbols in the SMIL 2.1 Language Profile are:

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

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 id="x" end="30s" src="15s.mpg" />
<ref id="y" end="10s" src="20s.mpg" />
<ref 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 no repeatDur, repeatCount, or repeat 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 can 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.

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.

topLayoutCloseEvent

Raised when a topLayout closes for any reason. This event is delivered to that topLayout. If a topLayout reopens when additional media becomes active in its region(s), this event will be raised again if and when the topLayout closes again, and will be raised every subsequent time it closes. This event is delivered to topLayout elements only and does not bubble.

topLayoutOpenEvent

Raised when a topLayout window opens. This event is delivered to that topLayout. If a topLayout closes and then reopens when additional media becomes active in its region(s), this event will be raised again, and will be raised every subsequent time it reopens. This event is delivered to topLayout elements only and does not bubble.

Order of raising of simultaneous events: