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, profiles. Examples of specifications intended for such integration are MathML and XForms [MathML], [XFORMS10].
This part of the SMIL 3.0 specification describes the framework on which SMIL modularization and profiling is based, and specifies the SMIL 3.0 Modules, their identifiers, and the requirements for conformance within this framework.
This section is informative.
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.
A Profile is a combination of modules. Modules are atomic, i.e. they may not be subset when included in a profile. Furthermore, a module specification may include a set of integration requirements, to which profiles that include the module must comply.
Commonly, there is a main profile that incorporates nearly all the modules associated with a single namespace. For this version of SMIL, this is the SMIL 3.0 Language profile.
Other profiles may be specified that are subsets of the larger one, or that incorporate a mixture of modules associated with different namespaces. SMIL 3.0 Tiny is an example of the first, XHTML+SMIL of the latter.
Several of SMIL's modules define features that that characterize the core of the functionality provided by SMIL. 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 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 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 profile to be used for the document interchange.
This section is informative.
SMIL 3.0 specification provides three classes of changes to the SMIL 2.1 Recommendation, among the functional areas;
The following functional areas are affected by SMIL 3.0:
Content ControlThis functional area is currently unchanged, apart from repartitioning of the content control module structure in order to support the SMIL Tiny profile. In a future version the content control mechanisms specified will be modified to better align with the expression and test logic being developed within the SMIL 3.0 State modules.
SMIL 3.0 extends the Layout capabilities as follows:
SMIL 3.0 linking integrates the general features of the XHTML-2 access and role attributes as an extension and replacement for the accessKey attribute. This is expected to result in the deprecation or removal of the accesskey attribute and the accesskey event from the SMIL 2.1 language.
This new smilText functionality provides a new media type for use in SMIL presentations. The smilText modules provide a text container element with an explicit content model for defining in-line text, and a set of additional elements and attributes to control explicit in-line text rendering.
The following 3 modules are introduced in the new Text functional area allowing use of in-line text content:
In addition, SMIL 3.0 also defines the smilText profile, which allows timed text markup to be placed in a light-weight external container.
Metainformation mechanisms in SMIL 3.0 provide a general purpose approach to attaching metainformation to any element within the presentation.
The new Identity module identifies the SMIL version and the SMIL profile. This replaces the former SMIL approach of defining separate namespaces for individual modules and profiles.
The SMIL 3.0 specification leaves the basic syntax and semantics of the SMIL 2.1 timing model [SMIL21-timing] unchanged apart from the following changes:
The new modules in this section provide a mechanism whereby the document author may create more complex controlflow than what SMIL provides through the timing and content control modules, without having to go all the way of using a scripting language. One way to provide this is to allow a document to have some explicit state (think: variables) along with ways to modify, use and save this state.
The following 4 modules are introduced in the State functional areas:
This section is normative.
SMIL functionality is partitioned into 12 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 SMIL 3.0. Modules marked with (*) are revised modules from SMIL 2.1.
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 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 3.0 modules and the modules they depend on.
|FillDefault||BasicTimeContainers, and/or BasicExclTimeContainers, BasicPriorityClassContainers, and/or TimeContainerAttributes|
|MultiArcTiming||AccessKeyTiming, and/or BasicInlineTiming, and/or EventTiming,
MediaMarkerTiming, and/or RepeatValueTiming, and/or
SyncbaseTiming, and/or WallclockTiming
|Structure||BasicContentControl, and BasicInlineTiming, and BasicLayout, and
BasicLinking, and BasicMedia, and BasicTimeContainers, and
SkipContentControl, and SyncbaseTiming
BasicExclTimeContainers, BasicPriorityClassContainers, and/or
|TransitionModifiers||BasicTransitions, and/or InlineTransitions|
This section is normative.
This section specifies the identifiers for the SMIL 3.0 MIME Type and the SMIL 3.0 modules. The identifiers for SMIL 3.0 profiles are defined as part of the profile specification.
Documents authored in host-language conformant profiles may be associated
with the "
application/smil+xml" mime type:
application/smil+xml" mime type are required to be host
language conformant. The "
application/smil" mime type as
specified in SMIL 2.0 [SMIL20] is obsolete.
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 3.0 module is necessary. These identifiers are to be used with the systemRequired attribute from the RequiredContentControl module.
Table 2 summarizes the identifiers for SMIL 3.0 modules.
In addition to the module identifiers above, there are different sets of features that may be expressed using the following identifiers:
Modules may also be identified collectively. When grouped into SMIL 3.0 profiles, the module identification string is placed in the profile specification. Profiles will also provide an identification string for their DTD specification. In addition, the following general module collections are defined:
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.
This section is normative.
The rules for host-language and SMIL 3.0 document conformance, as well as the rules for SMIL 3.0 User Agent conformance are provided as part of the SMIL Scalability Framework.
This section is informative.
This section describes how profiles could be defined using the SMIL 3.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 3.0 modular DTDs use the same mechanisms as the XHTML modular DTDs use. Exceptions to this are:
Below, we give a short description of the files that are used to define the SMIL 3.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 3.0 specification places the XML element declarations (e.g. <!ELEMENT...>) and attribute list declarations (e.g. <!ATTLIST...>) of all SMIL 3.0 elements in separate files, the SMIL module files. A SMIL module file is provided for each functional area in the SMIL 3.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 3.0 Language profile. Usage of the same module files for defining other SMIL profiles is recommended, but not required. The requirements that SMIL profiles must follow are stated in the SMIL 3.0 specification, not in the DTD code.
To make the SMIL module files independent of each other, and independent of the 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 3.0 Language profile provides examples of how the SMIL module files may 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 file that is different for each profile is the driver file, and possibly the document model file. To define a new 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. A new profile that merely reuses SMIL 3.0 modules may not need a new document model file. 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 the modules and features that are included in the DTD. The file contains the following parts.
If the SMIL element names are to be prefixed, this can be done by adding something like the following 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.
The default value of the baseProfile should be defined. If not
defined, the value defaults to
#IMPLIED. For example:
<!ENTITY % SMIL.baseProfile.default "#FIXED 'Language'">
The modules to be included in the DTD need to be specified using entity definitions such as this, one for each included module:
<!ENTITY % SMIL.Structure.module "INCLUDE" >
The entity names are all of the form
SMIL.ModuleName.module. The default for all modules is
that they are not included.
For each of the optional features and variants that are to be
included, an entity needs to be defined as
Here is a list of all possible entities:
The default for these optional features is that they are not included.
The document model file that is to be used needs to be defined:
<!ENTITY % smil-model.mod
PUBLIC "-//W3C//ENTITIES SMIL 3.0 Document Model 1.0//EN"
All standard SMIL DTDs use the same document model file.
The framework file needs to be included. The framework file will subsequently include the data type, common attributes, qname and document model file.
The SMIL module files that are used by this profile need to be included.
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 may be defined in the document model file. The (dummy) default content model as defined in the SMIL module files is "EMPTY" for all SMIL 3.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 3.0 core attributes and the attributes that are defined in the same SMIL module file. All other attributes may 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.
|Driver files for the predefined profiles|
|-//W3C//DTD SMIL 3.0 Language//EN||
|-//W3C//DTD SMIL 3.0 Unified Mobile//EN||
|-//W3C//DTD SMIL 3.0 Daisy//EN||
|-//W3C//DTD SMIL 3.0 Tiny//EN||
|-//W3C//DTD SMIL 3.0 smilText//EN||
|Document model files for the predefined profiles|
|-//W3C//ENTITIES SMIL 3.0 Document Model 1.0//EN||
|SMIL 3.0 module files|
|-//W3C//ELEMENTS SMIL 3.0 Animation//EN||
|-//W3C//ELEMENTS SMIL 3.0 Content Control//EN||
|-//W3C//ELEMENTS SMIL 3.0 Layout//EN||
|-//W3C//ELEMENTS SMIL 3.0 Linking//EN||
|-//W3C//ELEMENTS SMIL 3.0 Media Objects//EN||
|-//W3C//ELEMENTS SMIL 3.0 Document Metainformation//EN||
|-//W3C//ELEMENTS SMIL 3.0 SMILtext//EN||
|-//W3C//ELEMENTS SMIL 3.0 State//EN||
|-//W3C//ELEMENTS SMIL 3.0 Document Structure//EN||
|-//W3C//ELEMENTS SMIL 3.0 Timesheet//EN||
|-//W3C//ELEMENTS SMIL 3.0 Timing//EN||
|-//W3C//ELEMENTS SMIL 3.0 Transition//EN||
|Other utilities: data types, common attributes, qname and frame work files|
|-//W3C//ENTITIES SMIL 3.0 Common Attributes 1.0//EN||
|-//W3C//ENTITIES SMIL 3.0 Datatypes 1.0//EN||
|-//W3C//ENTITIES SMIL 3.0 Modular Framework 1.0//EN||
|-//W3C//ENTITIES SMIL 3.0 Qualified Names 1.0//EN||