Synchronized Multimedia Integration Language (SMIL) Boston Specification

W3C Working Draft 22 June 2000

This version:: http://www.w3.org/TR/2000/WD-smil-boston-20000622
(Other formats: single HTML file, zip archive)
Latest version:: http://www.w3.org/TR/smil-boston
Previous version:: http://www.w3.org/TR/2000/WD-smil-boston-20000225
Editors:: Jeff Ayars (RealNetworks), Dick Bulterman (Oratrix), Aaron Cohen (Intel), Erik Hodge (RealNetworks), Philipp Hoschka (W3C), Eric Hyche (RealNetworks), Ken Day (Macromedia), Kenichi Kubota (Panasonic), Rob Lanphier (RealNetworks), Nabil Layaïda (INRIA), Philippe Le Hégaret (W3C), Thierry Michel (W3C), Muriel Jourdan (INRIA), Jacco van Ossenbruggen (CWI), Lloyd Rutledge (CWI), Bridie Saccocio (RealNetworks), Patrick Schmitz (Microsoft), Warner ten Kate (Philips), Ted Wugofski (Gateway).

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

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

Many parts of the document are still preliminary, and do not constitute full consensus within the Working Group. Also, some of the functionality planned for SMIL Boston is not contained in this draft. Many parts are not yet detailed enough for implementation, and other parts are only suitable for highly experimental implementation work.

At this point, the W3C SYMM WG seeks input by the public on the concepts and directions described in this specification. Please send your comments to www-smil@w3.org. Since it is difficult to anticipate the number of comments that come in, the WG cannot guarantee an individual response to all comments. However, we will study each comment carefully, and try to be as responsive as time permits.

This working draft may be updated, replaced or rendered obsolete by other W3C documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". This document is work in progress and does not imply endorsement by the W3C membership.

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.

Quick Table of Contents

1. About SMIL Boston
2. Synchronized Multimedia Integration Language (SMIL) Modules
3. The SMIL Animation Module
4. The SMIL Content Control
5. SMIL Layout Module
6. The SMIL Linking Module
7. The SMIL Media Object Module
8. The SMIL Streaming Media Object Module
9. The SMIL Metadata Module
10. SMIL Structure Module
11. The SMIL Timing and Synchronization Module
12. The SMIL Transition Effects Module
13. The SMIL Document Object Model Module
14. SMIL Boston Language Profile
15. HTML+SMIL Language Profile
16. SMIL Basic Language Profile
17. Baseline Media Formats
Appendix A. References

Full Table of Contents

1. About SMIL Boston
- 1.1 Introduction
- 1.2 Acknowledgements
2. Synchronized Multimedia Integration Language (SMIL) Modules
3. The SMIL Animation Module
4. The SMIL Content Control
5. SMIL Layout Module
6. The SMIL Linking Module
7. The SMIL Media Object Module
8. The SMIL Streaming Media Object Module
- 8.1 Introduction
- 8.2 SMIL Streaming Media Object Document Type Definition (DTD)
9. The SMIL Metadata Module
10. SMIL Structure Module
11. The SMIL Timing and Synchronization Module
12. The SMIL Transition Effects Module
13. The SMIL Document Object Model Module
- 13.1 Abstract
14. SMIL Boston Language Profile
15. HTML+SMIL Language Profile
16. SMIL Basic Language Profile
17. Baseline Media Formats
Appendix A. References

1. About SMIL Boston

1.1 Introduction

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

SMIL Boston is defined as a set of markup modules, which define the semantics and an XML syntax for certain areas of SMIL functionality. All modules have an associated Document Object Model (DOM).

SMIL Boston deprecates a small amount of SMIL 1.0 syntax in favor of more DOM friendly syntax. Most notable is the change from hyphenated attribute names to mixed case (camel case) attribute names, e.g., clipBegin is introduced in favor of clip-begin. The SMIL Boston modules do not require support for these SMIL 1.0 attributes so that integration applications are not burdened with them. SMIL document players, those applications that support playback of "application/smil" documents (or however we denote SMIL documents vs. integration documents) must support the deprecated SMIL 1.0 attribute names as well as the new SMIL Boston names.

This specification also defines three profiles that are built using the above SMIL modules:

Finally, this specification defines a number of baseline media formats to be widely supported by SMIL players:

1.2 Acknowledgements

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

2. Synchronized Multimedia Integration Language (SMIL) Modules

2.1 Introduction

Since the publication of SMIL 1.0 [SMIL10], interest in the integration of SMIL concepts with the HTML, the Hypertext Markup Language [HTML40], and other XML languages, has grown. Likewise, the W3C HTML Working Group is specifying how XHTML, the Extensible Hypertext Markup Language [XHTML10], can be subset, be extended, or be integrated with other languages. The strategy considered for integrating respective functionality with other XML languages is based on the concepts of modularization and profiling [MODMOD], [SMIL-MOD], [XMOD], [XPROF].

Modularization is a solution in which a language's functionality is partitioned into sets of semantically-related elements and attributes. Profiling is the combination of these feature sets to provide support for the functionality required within a particular application domain. The re-use of modules across profiles should enhance the interoperability between the various application domains.

This specification complies with the XHTML modularization conformance requirements as set forth in the XHTML Modularization specification [XMOD]. For the purposes of this specification we further define:

The main purpose of the notion of language profile family is to enhance interoperability. Language profiles within the same language profile family share the same MIME type(s). Preferably, the mandatory modules of a language profile family should be defined in such a way that any offered document conforming to a language profile in that language profile family will yield a reasonable presentation when the renderer, while supporting that language profile family's mandatory module set, would ignore all other (unknown) elements and attributes. Here, "reasonable presentation" is to be understood as something intelligible, which is not necessarily a close reflection of the author's original intentions. For that purpose a language profile negotiation would have to be conducted.

There is an important difference between the concepts of module family and language profile family. The first indicates the functionality space, and the second has to do with the document type (and MIME type). A language profile associates with one doctype, which is called the "host language". Therefore, the "Structure Module", containing the doctype's root element, is an essential module in any language profile family.

@@ In respect of decreasing document size: should the remainder of this section stay?

SMIL functionality is partitioned into modules based on the following design requirements:

The first requirement specifies that a collection of modules can be "recombined" in such a way as to be backwardly compatible with SMIL 1.0 (it will properly play SMIL 1.0 conforming content).

The second requirement specifies that the semantics of SMIL must not change when they are embodied in a module. Fundamentally, this ensures the integrity of the SMIL content and timing models. This is particularly relevant when a different syntax is required to integrate SMIL functionality with other languages.

The third requirement states that modules be of reasonable granularity. This requirement reflects the core purpose of modularization and profiling. On the one hand, the modularization should lead to separation of functionality, such that language profile designs can optimize for performance and complexity. On the other hand, the range of modules should be limited, such that interoperability is promoted.

The fourth requirement specifies that, where functionality overlaps, modules be isomorphic with other modules from other W3C recommendations. This will assist designers when sharing modules across language profiles.

The fifth requirement states that specific attention be paid to providing multimedia functionality to the XHTML language. XHTML is the reformulation of HTML in XML.

The sixth requirement ensures that modules have integrated support for the document object model. This facilitates additional control through scripting and user agents.

These requirements led to a partitioning of SMIL functionality into twenty five modules.

2.2 SMIL Modules

SMIL functionality is partitioned into nine functional areas. Within each functional area a further partitioning is applied into modules. The modules are complementary. For example, the Timing Level 2 Module adds syncBehavior to the timing in the Timing Level 0 and Level 1 Modules.

@@ This is a Normative statement !! When a language profile includes a module of a higher level, the modules of the lower levels MUST be included. Some elements or attributes are labeled as Profile Specific. This means that those elements or attributes are optional to the language profile, as long as the module from which they stem is the top level module.

Each of these modules introduces a set of semantically-related elements, properties, and attributes.

All these modules, and only these modules, are members of the SMIL module family. @@ This is a Normative statement ??

The Structure Level 0 Module, Timing Level 0 Module, and Media Object Level 0 Module are mandatory modules in any language profile in the SMIL language profile family. This implies that the SMIL Structure Level 0 Module must at least be accompanied with the two other modules. Those modules themselves can still be used in other, non-SMIL family, language profiles.

@@ The names for the script to generate hyperlinks to the element and attribute definitions need check on being identical.

2.3 Timing functionality

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, and excl elements. In addition, the modules define semantics for attributes including begin, dur, end, repeatCount, repeatDur, and others.

2.3.1 Timing Level 0 Module

The Timing Level 0 Module is a mandatory module in any language profile in the SMIL language profile family.

Note that upon building a language profile which integrates SMIL timing with other, non-SMIL, modules, that the elements from this Timing Level 0 Module may appear as attributes to the elements from the other XML language, rather than as these elements themselves. In that case, the element's functionality is declared using the timeContainer attribute.

@@ To be moved to corresponding module
The timing attributes are used by the elements in this Timing Level 0 Module and in the other Timing Modules, and by the elements in the Media Modules, in the Linking Modules, and in the Content Control Modules. As upon integration with non-SMIL modules, the elements from this module may appear as attributes instead of elements, the referenced timing attributes are also used by those non-SMIL elements.

2.3.2 Timing Level 1 Module

Usage of the Timing Level 1 Module requires inclusion of the Timing Level 0 Module. (@@ Therefore, should we design the modules as inclusive, rather than complementary?) Consequently, the same usage rules apply.

This means that upon integrating with a non-SMIL language, the excl element may appear as an attribute using the timeContainer construct. Another implication is that the added attributes (restart etc.) are adopted by the same elements who have adopted the attributes in the Timing Level 0 Module.

When this module is used it adds the 'multiple time conditions' and 'events' semantics to the begin and end attributes.

2.3.3 Timing Level 2 Module

@@ To be moved to corresponding module
When this module is used it adds the 'media marker' semantics to the begin and end attributes.

2.4 Time Manipulations functionality

2.4.1 Time Manipulations Module

2.5 Animation functionality

The Animation Modules provide a framework for incorporating animation onto a timeline (a timing model) and a mechanism for composing the effects of multiple animations (a composition model). The Animation Modules define semantics for the animate, set, animateMotion, and animateColor elements.

2.5.1 Animation Level 0 Module

@@ To be moved to corresponding module
When this module is used, it adds the animate, set, animateMotion, and animateColor elements to the content model of the ref, animation, audio, img, video, text, and textstream elements of the Media Object Modules (if those are present in the language profile). It also adds these elements to the content model of the par, seq, and excl elements of the Timing Modules, and to the content model of the body element of the Structure Level 0 Module (if those are present in the language profile).

2.5.2 Animation Level 1 Module

Usage of the Animation Level 1 Module requires inclusion of the Animation Level 0 Module. Consequently, the same usage rules apply.

@@ To be moved to corresponding module
When this module is used it adds the keyTimes and keySplines attributes to the animate element.

2.6 Transition Effects functionality

The Transition Effects Modules define a taxonomy of transition effects as well as semantics and syntax for integrating these effects into XML documents.

2.6.1 Transition Effects Level 0 Module

@@ To be moved to corresponding module
When this module is used, it adds the transition element to the content model of the layout element of the Layout Level 0 Module (if present in the language profile). The transition attribute is added to the elements in the Media Object Level 0 Module (if present in the language profile).

2.6.2 Transition Effects Level 1 Module

Usage of the Transition Effects Level 1 Module requires inclusion of the Transition Effects Level 0 Module. Consequently, the same usage rules apply.
In addition, the usage of the Transition Effects Level 1 Module requires support for hierarchical layout, such as supported by the Layout Level 1 Module.

@@ To be moved to corresponding module
When this module is used it adds transition effects functionality for transitions over multiple regions.

2.7 Media functionality

The Media Object Modules provide a framework for declaring media. The Media Object Modules define semantics for the ref, animation, audio, img, video, text, and textstream elements.

2.7.1 Media Object Level 0 Module

The Media Object Level 0 Module is a mandatory module in any language profile in the SMIL language profile family.

@@ To be moved to corresponding module
When this module is used, it adds the ref, animation, audio, img, video, text, and textstream elements to the content model of the par, seq, and excl elements of the Timing Modules (if those are present in the language profile). It also adds these elements to the content model of the body element of the Structure Level 0 Module (if those are present in the language profile). It also adds these elements to the content model of the a element of the Linking Modules (if those are present in the language profile).