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 and profiling use the extensibility properties of XML, and
related technology like XML namespaces and XML Schema [XML10], [XML-NS], [XSCHEMA].

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

The modularization approach used in this specification derives from that
set forth in XHTML Modularization [XMOD]. The framework on which SMIL
modularization and profiling is based, is informally described here.

A Module is a collection of
semantically-related XML elements, attributes, and attribute values that
represents a unit of functionality. Modules are defined in coherent sets.
This coherency is expressed in that the elements of these modules are
associated with the same namespace.

A Language Profile
is a combination of modules. Modules are atomic, i.e. they cannot be
subset when included in a language profile. Furthermore, a module
specification may include a set of integration requirements, to which
language profiles that include the module must comply.

Commonly, there is a main language profile that incorporates nearly all
the modules associated with a single namespace. For example, the
SMIL 2.0 language profile uses most of the SMIL 2.0 modules.
Usually, the same name is used to loosely reference both - "SMIL 2.0" in
the example. Also, the name "profile" is used to mean "language profile".

Other language profiles can be specified that are subsets of the larger
one, or that incorporate a mixture of modules associated with different
namespaces. SMIL 2.0 Basic is an example of the first, XHTML+SMIL of the
latter.

A special module in a language profile is the so-called Structure Module, in that it
contains the root element of the language profile, e.g. <smil> or
<html>. Any language profile that incorporates modules associated with
a single namespace will include the Structure module associated with that
namespace.

Other modules that require special mention are those that characterize the
core of the functionality provided by the namespace. This is expressed by the
notions of host
language and integration set.
Both of them relate to a set of conformance requirements for language
profiles, which includes the requirement to incorporate at least the core set
of modules. The set may be different for a host language and an integration
set. A host language must incorporate the Structure module; an integration
set need not. There may be other differences as well.

The main purpose of language profile conformance is to enhance
interoperability. Preferably, the mandatory modules for host language
conformance are defined in such a way that any document interchanged in a
conforming language profile will yield a reasonable presentation when the
document renderer, while supporting the associated 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. To
achieve the latter, a negotiation would have to be conducted to agree on the
specific language profile to be used for the document interchange.

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.

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

Table 1 presents the SMIL 2.0 modules and the modules they
dependent on.

SMIL is an XML-based language and conforms to the (XML) DOM Core [DOM1], [DOM2]. In the
future, a SMIL-specific DOM recommendation may specify support for timing and
synchronization, media integration, and other synchronized multimedia
functionality.

A language profile may include DOM support. The granularity of DOM being
supported corresponds to the modules being selected in that language profile.
As with all modules, required support for the DOM is an option of the
language profile.

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.

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.0 module is necessary.

Table 2 summarizes the identifiers for SMIL 2.0 modules.

Table 2: The SMIL 2.0 Module Identifiers.

Module name

Identifier

AccessKeyTiming

http://www.w3.org/2001/SMIL20/AccessKeyTiming

AudioLayout

http://www.w3.org/2001/SMIL20/AudioLayout

BasicAnimation

http://www.w3.org/2001/SMIL20/BasicAnimation

BasicContentControl

http://www.w3.org/2001/SMIL20/BasicContentControl

BasicInlineTiming

http://www.w3.org/2001/SMIL20/BasicInlineTiming

BasicLayout

http://www.w3.org/2001/SMIL20/BasicLayout

BasicLinking

http://www.w3.org/2001/SMIL20/BasicLinking

BasicMedia

http://www.w3.org/2001/SMIL20/BasicMedia

BasicTimeContainers

http://www.w3.org/2001/SMIL20/BasicTimeContainers

BasicTransitions

http://www.w3.org/2001/SMIL20/BasicTransitions

BrushMedia

http://www.w3.org/2001/SMIL20/BrushMedia

CustomTestAttributes

http://www.w3.org/2001/SMIL20/CustomTestAttributes

EventTiming

http://www.w3.org/2001/SMIL20/EventTiming

ExclTimeContainers

http://www.w3.org/2001/SMIL20/ExclTimeContainers

FillDefault

http://www.w3.org/2001/SMIL20/FillDefault

HierarchicalLayout

http://www.w3.org/2001/SMIL20/HierarchicalLayout

InlineTransitions

http://www.w3.org/2001/SMIL20/InlineTransitions

LinkingAttributes

http://www.w3.org/2001/SMIL20/LinkingAttributes

MediaAccessibility

http://www.w3.org/2001/SMIL20/MediaAccessibility

MediaClipMarkers

http://www.w3.org/2001/SMIL20/MediaClipMarkers

MediaClipping

http://www.w3.org/2001/SMIL20/MediaClipping

MediaDescription

http://www.w3.org/2001/SMIL20/MediaDescription

MediaMarkerTiming

http://www.w3.org/2001/SMIL20/MediaMarkerTiming

MediaParam

http://www.w3.org/2001/SMIL20/MediaParam

Metainformation

http://www.w3.org/2001/SMIL20/Metainformation

MinMaxTiming

http://www.w3.org/2001/SMIL20/MinMaxTiming

MultiArcTiming

http://www.w3.org/2001/SMIL20/MultiArcTiming

MultiWindowLayout

http://www.w3.org/2001/SMIL20/MultiWindowLayout

ObjectLinking

http://www.w3.org/2001/SMIL20/ObjectLinking

PrefetchControl

http://www.w3.org/2001/SMIL20/PrefetchControl

RepeatTiming

http://www.w3.org/2001/SMIL20/RepeatTiming

RepeatValueTiming

http://www.w3.org/2001/SMIL20/RepeatValueTiming

RestartDefault

http://www.w3.org/2001/SMIL20/RestartDefault

RestartTiming

http://www.w3.org/2001/SMIL20/RestartTiming

SkipContentControl

http://www.w3.org/2001/SMIL20/SkipContentControl

SplineAnimation

http://www.w3.org/2001/SMIL20/SplineAnimation

Structure

http://www.w3.org/2001/SMIL20/Structure

SyncbaseTiming

http://www.w3.org/2001/SMIL20/SyncbaseTiming

SyncBehavior

http://www.w3.org/2001/SMIL20/SyncBehavior

SyncBehaviorDefault

http://www.w3.org/2001/SMIL20/SyncBehaviorDefault

SyncMaster

http://www.w3.org/2001/SMIL20/SyncMaster

TimeContainerAttributes

http://www.w3.org/2001/SMIL20/TimeContainerAttributes

TimeManipulations

http://www.w3.org/2001/SMIL20/TimeManipulations

TransitionModifiers

http://www.w3.org/2001/SMIL20/TransitionModifiers

WallclockTiming

http://www.w3.org/2001/SMIL20/WallclockTiming

In addition to the module identifiers above, there may be different
features and variances from one language profile to another that may not be
expressed as the support or non-support of a particular module. These
features may be expressed using the following identifiers:

Implementations that support the SMIL BasicContentControl module must
allow these as identifiers for use with the XML namespace mechanism, and must
allow the associated namespace identifier to be used with the systemRequired
test attribute. Profiles must identify those attributes for which an
implementation must return "true" (this is an integration requirement).
Implementations must return "false" for modules or features which are not
fully supported.

Modules can also be identified collectively. The following four module
collections are defined:

The following two tables list names used to collectively reference certain
sets of SMIL 2.0 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.

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 2.0
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 required for
SMIL 2.0 host language conformance for all modules the given language
supports. For example, if a SMIL 2.0 host language supports the
MultiArcTiming module, it must support the deprecated syntax defined in the
MultiArcTiming module.

Since the SMIL 2.0 Structure module may only be used in a profile that is
SMIL host language conformant, this implies that the SMIL 2.0 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.

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

BasicContentControl

BasicInlineTiming

BasicMedia

BasicTimeContainers

MinMaxTiming

RepeatTiming

SyncbaseTiming

In addition, the following requirements must be satisfied:

The language profile defines what modules it collects.

The language profile includes all elements, attributes, and attribute
values specified by the collected SMIL 2.0 modules.

The language profile fulfills the "minimum support" requirements for
elements and attributes as listed in Table 6 below.

The language profile complies with the integration requirements set
forth by the SMIL 2.0 modules it collects.

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.0 Language, XHTML+SMIL [XHTML+SMIL], 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.0 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.

A language profile is specified through its DTD or XML Schema. The
identifier of these can be used to identify the language profile.
SMIL 1.0 has specified the default namespace declaration on its root
element, smil, as the decisive identifier for
distinguishing it from other language profiles [SMIL10]. For that purpose SMIL 1.0
has specified

http://www.w3.org/TR/REC-smil

as the namespace identifier for SMIL 1.0.

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:

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:

The URI is constructed conformant to the requirements set forth by
the W3C [W3C-NSURI].

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.

Syntax errors in a SMIL Host Language conformant document are handled
according to the XML rules for well-formed or valid XML [XML10].

Semantic errors can arise at various levels. One is where the declared
attribute values are of unknown value. Another is where the assembled
presentation is (possibly) conflicting, as in a case where media objects are
competing for display space or where they are synchronized ambiguously. These
latter types, although maybe an error according to the author's intentions,
are not considered an error and the user agent will present according to the
resolution rules defined in this specification.

Errors in attribute values might remain undetectable to the parser,
because the value type is declared as CDATA, or because the value range is
open ended, as in the case of events, for example. However, errors in
attribute values can be detected within a given language profile, where that
language profile specifies the supported value set. Specifications of
language profiles are required to specify the error handling that is required
when such an attribute value error occurs.

This section describes how language profiles could be defined using the
SMIL 2.0 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.0
modular DTDs use the same mechanisms as the XHTML modular DTDs use.
Exceptions to this are:

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

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.0 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.0
specification places the XML element declarations (e.g. <!ELEMENT...>)
and attribute list declarations (e.g. <!ATTLIST...>) of all
SMIL 2.0 elements in separate files, the SMIL module files. A SMIL
module file is provided for each functional area in the SMIL 2.0
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.0 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.0 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.0 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:

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

Table 7: Formal public identifiers and system identifiers of
all files used in the SMIL 2.0 modular DTDs.

Driver files for the predefined
profiles

-//W3C//DTD SMIL 2.0//EN

http://www.w3.org/2001/SMIL20/SMIL20.dtd

Document model files for the
predefined profiles

-//W3C//ENTITIES SMIL 2.0 Document Model 1.0//EN

http://www.w3.org/2001/SMIL20/smil-model-1.mod

SMIL 2.0 module files

-//W3C//ELEMENTS SMIL 2.0 Animation//EN

http://www.w3.org/2001/SMIL20/SMIL-anim.mod

-//W3C//ELEMENTS SMIL 2.0 Content Control//EN

http://www.w3.org/2001/SMIL20/SMIL-control.mod

-//W3C//ELEMENTS SMIL 2.0 Layout//EN

http://www.w3.org/2001/SMIL20/SMIL-layout.mod

-//W3C//ELEMENTS SMIL 2.0 Linking//EN

http://www.w3.org/2001/SMIL20/SMIL-link.mod

-//W3C//ELEMENTS SMIL 2.0 Media Objects//EN

http://www.w3.org/2001/SMIL20/SMIL-media.mod

-//W3C//ELEMENTS SMIL 2.0 Document Metainformation//EN

http://www.w3.org/2001/SMIL20/SMIL-metainformation.mod

-//W3C//ELEMENTS SMIL 2.0 Document Structure//EN

http://www.w3.org/2001/SMIL20/SMIL-struct.mod

-//W3C//ELEMENTS SMIL 2.0 Timing//EN

http://www.w3.org/2001/SMIL20/SMIL-timing.mod

-//W3C//ELEMENTS SMIL 2.0 Transition//EN

http://www.w3.org/2001/SMIL20/SMIL-transition.mod

Other utilities: data types, common
attributes, qname and frame work files