This section is informative.
The SMIL 3.0 Scalability Framework revises the SMIL 2.1 Basic Profile and Scalability Framework [SMIL21-basic-profile]. With the introduction of the SMIL 3.0 Tiny profile, the definition of the Scalability Framework has been migrated into a separate document. The text has been revised to conform to current SMIL practice and intent.
This section is normative.
SMIL 3.0 provides a scalability framework, where a family of scalable SMIL profiles can be defined using a sub- or superset of the SMIL 3.0 Language, DAISY, or UnifiedMobile profiles, or a superset of the SMIL 3.0 Tiny profile. A SMIL document can be authored conforming to the scalability framework such that it provides limited functionality on a resource-constrained device while allowing richer capabilities on a more capable device. This section defines the requirements for conforming SMIL documents and SMIL user agents. Moreover, it describes scalable SMIL profile architecture, guidelines for defining them, and their conformance requirements.
This section is informative.
The Synchronized Multimedia Integration Language (SMIL) includes powerful functionality for various multimedia services for platforms of various/differing complexities, ranging from desktops to ubiquitous information appliances such as minimum capability mobile phones, car navigation systems, television sets, and voice user agents. Each of these platforms has its specific capabilities and requirements. It is clear that not all of the SMIL 3.0 elements and attributes will be required on all platforms. SMIL 3.0 modularization groups semantically related SMIL elements, attributes, and attribute values into a disjoint set of SMIL modules. These modules can then be recombined to produce a SMIL profile that meets the needs of different communities. For example, a hand held device, digital talking book player, or a mobile phone may only support a small subset of SMIL 3.0 modules in its own profile.
The W3C SYMM working group has defined a scalability architecture that allows a SMIL user agent to implement only the sub- or superset of the SMIL 3.0 standard it needs, while maintaining document interoperability between device profiles built for different needs. A scalable profile enables user agents to support incremental extra collections of modules containing the baseline functionality needed for an implementation environment, or it allows certain modules to be removed from a more extensive profile in those situations where this extra functionality is not necessary.
At the same time, SMIL 3.0 provides an additional mechanism in which a document author is given the ability to specify which SMIL modules are required within a document.
Conformance to the scalable SMIL profile architecture provides a basis for interoperability guarantees. The advantages of scalable profiles include:
The SMIL 3.0 scalability framework allows inclusion or exclusion of functionality. SMIL user agent developers are also able to focus their implementations by specifically excluding support for individual SMIL elements or attributes, as is explained in the section on document conformance. Note that in these cases, a document containing unsupported elements or attributes should always parse correctly on any SMIL-compliant user agent.
This section is normative.
The SMIL Scalability Framework specifies the rules for SMIL 3.0 profile, document and user agent conformance, and the mechanism for creating dynamic, scalable profiles using the SMIL 3.0 extension mechanism. This section provides a normative definition of these three aspects.
All SMIL host-language conformant profiles must reference and adhere to the rules specified in this SMIL Scalability Framework. All such profiles must supply profile-specific information that is required by the SMIL Scalability Framework.
The SMIL 3.0 Scalability Framework makes use of a hierarchy of conformance definitions for profiles, documents and user agents that are based in whole or in part on SMIL 3.0 modules. The elements in this hierarchy (from least restrictive to most restrictive) are given in this section.
SMIL 3.0 defines a hierarchy of conforming profiles based on the following definitions:
SMIL 3.0 defines a conforming document to be a document that conforms to a SMIL 3.0 profile and is valid per the normative DTD identified by that profile. Documents may be:
A Conformant SMIL 3.0 User Agent is a user agent that renders a document in accordance with the functionality of the associated profile and which adheres to the rules set out in the section Rules for SMIL 3.0 Conformant User Agents.
The following sections detail the rules for profile, document and user agent conformance. These rules make use of the following definitions for collections of elements and attributes. In these tables, the term "minimum support" is used to refer to the minimum set of elements that an element may contain, and the minimum set of attributes that may be used on an element.
Element Set Name | Elements |
TIMING-ELMS | par, seq |
MEDIA-ELMS | ref, animation, audio, img, video, text, textstream |
EMPTY | no elements are required as a minimum |
Attribute Set Name | Attributes |
TIMING-ATTRS | begin, end, dur, repeatDur, repeatCount, fill, endsync |
CONTCTRL-ATTRS | systemRequired |
MEDIA-ATTRS | src, type |
COMMON-ATTRS | xml:id, id, class, xml:lang, title |
IDENTITY-ATTRS | version, baseProfile |
This section defines the rules for creating conformant SMIL 3.0 profiles. The rules are considered by conformant profile type, as defined in the section Definitions.
Neither the SMIL 3.0 definition nor these conformance criteria provide designated size limits on any aspect of SMIL 3.0 content. There are no maximum values on the number of elements, the amount of character data, or the number of characters in attribute values.
A SMIL 3.0 profile is a conformant SMIL 3.0 profile if it adheres fully to the following criteria:
There are no minimum set of required modules for a Conformant SMIL 3.0 Profile.
A SMIL 3.0 profile is an integration-set conformant SMIL 3.0 profile if it meets all of the requirements of a Conformant SMIL 3.0 Profile and if it also adheres fully to the following criteria:
A profile that is said to be SMIL 3.0 integration set conformant must include the following modules:
Element | Minimum Support | |
Content | Attributes | |
ref, animation, audio, img, video, text, textstream | EMPTY | CONTCTRL-ATTRS, IDENTITY-ATTRS, TIMING-ATTRS, MEDIA-ATTRS |
par, seq | TIMING-ELMS, MEDIA-ELMS | CONTCTRL-ATTRS, IDENTITY-ATTRS, TIMING-ATTRS |
Support of deprecated elements and attributes is not required for SMIL 3.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 SMIL 3.0 profile is an host-language conformant SMIL 3.0 profile if it meets all of the requirements of a Integration Set Conformant SMIL 3.0 Profile and if it also adheres fully to the following criteria:
A profile that is said to be SMIL 3.0 host-language conformant must include the following modules:
Element | Minimum Support | |
Content | Attributes | |
smil | head, body | COMMON-ATTRS, CONTCTRL-ATTRS, IDENTITY-ATTRS, xmlns |
head | layout, , | COMMON-ATTRS, IDENTITY-ATTRS |
body | TIMING-ELMS, MEDIA-ELMS, | COMMON-ATTRS, IDENTITY-ATTRS |
layout | EMPTY | COMMON-ATTRS, CONTCTRL-ATTRS, IDENTITY-ATTRS, type, skip-content |
ref, animation, audio, img, video, text, textstream | COMMON-ATTRS, CONTCTRL-ATTRS, IDENTITY-ATTRS, TIMING-ATTRS, MEDIA-ATTRS, skip-content | |
par, seq | TIMING-ELMS, MEDIA-ELMS, | COMMON-ATTRS, IDENTITY-ATTRS, CONTCTRL-ATTRS, TIMING-ATTRS |
EMPTY | COMMON-ATTRS, CONTCTRL-ATTRS, IDENTITY-ATTRS, skip-content | |
EMPTY | COMMON-ATTRS, CONTCTRL-ATTRS, IDENTITY-ATTRS, skip-content |
Support of deprecated elements and attributes is no longer required for SMIL 3.0 host language conformance but it is highly recommended for all modules the given language supports. Support of deprecated elements and attributes may only be left out in cases where interoperability with SMIL 1.0 implementations is not an issue.
Since the SMIL 3.0 Structure module may only be used in a profile that is SMIL host language conformant, this implies that the SMIL 3.0 Structure module must at least be accompanied with the other modules required for host language conformance that were named above. Those modules themselves may still be used in other non-SMIL host-language conformant profiles.
This section defines the rules for creating conformant SMIL 3.0 documents. The rules are considered by conformant profile type, as defined in the section Definitions.
A SMIL 3.0 document is a conformant SMIL 3.0 document if it adheres fully to the following criteria:
xmlns="http://www.w3.org/ns/SMIL"
A SMIL 3.0 document is a integration-set conformant SMIL 3.0 document if it adheres fully to the criteria specified by the host-language for that document, and it adheres to the following criteria:
xmlns="http://www.w3.org/ns/SMIL"
A SMIL 3.0 document is a host-language conformant SMIL 3.0 document if it adheres to the following criteria:
xmlns="http://www.w3.org/ns/SMIL"The SYMM working group MAY reuse this namespace URI in a future specification that revises the SMIL 3.0 DTD, thus affecting the validity of published documents.
This section is informative.
SMIL 3.0 no longer assigns individual namespace identifiers to SMIL 3.0 modules, as all elements and attributes are defined within the single SMIL 3.0 namespace. SMIL 3.0 does define a set of module identifier strings that may be used with as part of the SMIL extension mechanism.
http://www.w3.org/2008/SMIL30/informative-DTD/SMIL30XXX.dtd ,where the string SMIL30XXX is replaced by the name string defined in the relevant profile specification for the informative DTD.
SMIL 3.0 deprecates base as a property value for the content attribute of the element of SMIL 1.0 in favor of the more general XML Base URI mechanisms.
All SMIL 3.0 profile specifications support 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 and label attributes of all of the SMIL 3.0 elements.
A SMIL 3.0 document is a strict host-language conformant SMIL 3.0 document if it adheres to the criteria for Rules for SMIL 3.0 Host-Language Conformant Documents and it meets the following criteria:
A conforming SMIL 3.0 user agent is a program which can parse and process a SMIL 3.0 document and render the contents of the document onto output media. A conforming SMIL 3.0 user agent must meet all of the following criteria:
This section is informative.
Examples:
1) A pure SMIL 1.0 document:
<smil xmlns="http://www.w3.org/TR/REC-smil"> ... </smil>
2) A pure SMIL 3.0 Language profile document:
<smil xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="Language"> ... </smil>
The Web Accessibility Initiative has defined the "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.
If a particular SMIL 3.0 document requires a particular language feature to be supported for author-determined correct rendering of document content, the document may define the modules that support the required feature(s) as described in the section specifying required modules. User agents that do not support the required features MUST result in the user agent issuing an error and not playing the document.
Syntax errors in a SMIL Host Language conformant document are handled according to the XML rules for well-formed or valid XML [XML11], (see Note).
Semantic errors may 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 may be detected within a given profile, where that profile specifies the supported value set. Specifications of profiles are required to specify the error handling that is required when such an attribute value error occurs.
The rules for restricting and extending the functionality of any SMIL profile are defined in this section.
Individual user agents may opt-out of a particular language feature by explicitly ignoring it during document processing. In this way, both author and user-agent-development needs are supported for a wide community without having to define a large number of standard profiles.
Developers of user agents that explicitly support only a subset of a profile's functionality are encouraged to publish a list of these restrictions on a web site maintained by W3C and the Synchronized Multimedia working group.
A scalable profile is defined by extending any SMIL host language conforming profile using the content control facilities to support application/device specific features via a module identification mechanism, as described in the section specifying required modules.
A scalable profile is defined by extending its set of modules using the content control facilities to support application/device specific features. The scalable profile must include the description of the profile it extends, for example by including a declaration of the version and base profile attributes for the profile. A family of scalable SMIL profiles can be built using the SMIL 3.0 Tiny Profile plus additional sets of modules geared to the particular needs each profile addresses.
In the future, a SMIL 3.0 profile may be extended by other W3C Recommendations, or by private extensions. For these extensions, the following rules must be obeyed:
Conformant SMIL 3.0 user agents are prepared to handle documents containing extensions that obey these two rules. The SMIL 3.0 namespace may be used with other XML namespaces as per [XML-NS].
A scalable profile is specified by using the content control facilities via a namespace mechanism as follows:
This section is informative.
This section presents scalability guidelines for SMIL content authors that will enable their content to be played on the widest range of SMIL conformant devices.
A SMIL 3.0 document must declare a default namespace for its elements with its xmlns attribute at the smil root element with its identifier URI:
<smil xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="Language">
... </smil>
If no namespace is specified, the namespace will default to: xmlns="http://www.w3.org/TR/REC-smil", which is the SMIL 1.0 namespace.
The version and baseProfile attributes may be used to specify a particular profile for use when processing the document. If a DOCTYPE is used to define the profile, then the version and base profile will be defined by the DTD in the DOCTYPE. If both a DOCTYPE DTD is defined and the version and/or baseProfile attributes, both sets must refer to the same profile.
A SMIL 3.0 document with custom extensions conforming to a custom DTD may be declared as follows:
<!DOCTYPE smil SYSTEM "http://www.example.org/myCustomSMIL.dtd"> <smil xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="Language" xmlns:myStuff="http://www.example.org/2008/Custom"> <myStuff:foo> ... </myStuff:foo> </smil>
The systemRequired attribute is used to specify which components of SMIL 3.0 are required to render the document.
Examples:
<smil xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="Language" xmlns:smil30lang="http://www.w3.org/2008/SMIL30/Language" systemRequired="smil30lang" > ... </smil>
<smil xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="Language" xmlns:transition="http://www.w3.org/2008/SMIL30/BasicTransitions" xmlns:align="http://www.w3.org/2008/SMIL30/AlignmentLayout" xmlns:override="http://www.w3.org/2008/SMIL30/OverrideLayout" xmlns:subregion="http://www.w3.org/2008/SMIL30/SubRegionLayout" systemRequired="transition+align+override+subregion" > ... </smil>
<smil xmlns="http://www.w3.org/2008/SMIL30/Tiny" xmlns:HostLanguage="http://www.w3.org/2008/SMIL30/HostLanguage" systemRequired="HostLanguage" > ... </smil>
If supported by the profile used as the base for the scalable document, the author may choose to explicitly qualify blocks of content with the systemRequired attribute. The following example contains the systemRequired attribute on the seq container within a switch, allowing the inclusion of the brush element when the "BrushMedia" test succeeds, and providing an image based alternative when the BrushMedia module is not supported:
<smil xmlns="http://www.w3.org/2008/SMIL30/Mobile" xmlns:BrushMedia="http://www.w3.org/2008/SMIL30/BrushMedia" > <head> <layout> <region xml:id="colorbox" top="0px" left="0px" height="50px" width="50px" /> </layout> </head> <body> <switch> <seq systemRequired="BrushMedia"> <brush dur="5s" color="#0000FF" region="colorbox"/> <brush dur="5s" color="#00FF00" region="colorbox"/> <brush dur="5s" color="#FF0000" region="colorbox"/> </seq> <seq> <img dur="5s" src="blue.jpg" region="colorbox"/> <img dur="5s" src="green.jpg" region="colorbox"/> <img dur="5s" src="red.jpg" region="colorbox"/> </seq> </switch> </body> </smil>
Note that there is an difference between the systemRequired on the smil element and an "inline" systemRequired on the other SMIL elements (if supported by the base profile). The former is a hard requirement for rendering the document. For example, if the systemRequired on the smil element lists a module that the user agent does not support even though the module is not actually used in the document, the document is still prohibited from presentation by that user agent.
Conversely, the use of the systemRequired attribute on other elements only specifies a requirement for rendering a sub-tree of the document. If some of the content of a presentation requires support beyond that provided by the base profile and that specified on the systemRequired attribute on the smil element, the additional features should be wrapped with the switch element and system test attributes, which can then be evaluated by a user agent and be processed accordingly.
The SMIL 3.0 profiles are organized from the least capable to the most capable as follows:
When extending a particular profile with additional modules, the namespace used in the extended profile should be that of the SMIL profile that includes the smallest difference in modules needed to support the document. The systemRequired attribute should also be used and set to the original profile namespace together with the module(s) used in the extension. For example, suppose the SMIL 3.0 UnifiedMobile Profile is to be extended with the BasicPriorityClassContainers module. The version and base profile used in documents for the extension should be set to the SMIL 3.0 UnifiedMobile profile and the systemRequired attribute should be set to the SMIL 3.0 UnifiedMobile profile identifier and the BasicPriorityClassContainers module identifier:
<smil xmlns="http://www.w3.org/ns/SMIL" version="3.0"
baseProfile="UnifiedMobile"
xmlns:ump="http://www.w3.org/2008/SMIL30/UnifiedMobile"
xmlns:bpcc="http://www.w3.org/2008/SMIL30/BasicPriorityClassContainers"
systemRequired="ump+bpcc">
...
</smil>
Note that it is also possible to use the full SMIL 3.0 Language Profile identifier in the above example:
<smil xmlns="http://www.w3.org/ns/SMIL" version="3.0"
baseProfile="Language"
xmlns:lang="http://www.w3.org/2008/SMIL30/Language"
xmlns:bpcc="http://www.w3.org/2008/SMIL30/BasicPriorityClassContainers"
systemRequired="lang+bpcc">
...
</smil>
This practice is NOT recommended because the resulting document will only be able to be processed by implementations that support the full SMIL 3.0 Language profile, and not by implementations that support the more restricted SMIL 3.0 UnifiedMobile profile -- even though the UnifiedMobile Profile provides all of the functionality required in the document.