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.

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.

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 rendering of the same content can be improved automatically as
devices get more powerful.

All SMIL 3.0 documents can share a document type, a schema, and a set
of defined namespaces, and the required default xmlns declaration.

Any future SMIL 3.0 extensions can easily be incorporated into SMIL
documents and user agents.

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.

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.

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.

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.

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

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

A SMIL 3.0 document is a conformant SMIL 3.0 document if it
adheres fully to the following criteria:

The SMIL 3.0 Conformant document MUST be well-formed XML.

The SMIL 3.0 Conformant document MUST conform to the following W3C
Recommendations:

The XML 1.1 specification (Extensible Markup Language (XML) 1.1)
[XML11].Note: SMIL 3.0 conforms to both
XML 1.1 [XML11] and XML 1.0 [XML10], with XML 1.1 being the
definitive reference because it is newer. SMIL 3.0 itself uses no
features that are in XML 1.1 other than for character processing in
IRI's and xml:id's, but new development should use an XML 1.1 parser
to make sure documents that use XML 1.1 extensions are handled
correctly.

The SMIL 3.0 Conformant document MUST be based on a SMIL 3.0 Conformant
profile.

The SMIL 3.0 Conformant document MUST use the root element defined by
the profile specification.

The SMIL 3.0 Conformant document MUST reference the following
namespace, either as the default namespace or as an additional
prefix-qualified namespace):

xmlns="http://www.w3.org/ns/SMIL"

The SMIL 3.0 Conformant document MAY use a DOCTYPE, as defined in the
profile specification. If a document contains a DOCTYPE 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 specified, documents
must be valid per the normative DTD identified by that
profile

When the document uses the functionality of a particular SMIL 3.0
module through SMIL 3.0 elements and attributes and the semantics
associated with these elements and attributes, it must do so in ways
consistent with the SMIL 3.0 specification.

The SMIL 3.0 Conformant document MUST adhere to any additional
conformance rules for the profile, as defined in the SMIL 3.0 Conformant
profile specification.

The SMIL 3.0 Integration-Set Conformant document MUST be based on a
SMIL 3.0 Conformant profile.

The SMIL 3.0 Integration-Set Conformant document MUST use the root
element defined by the profile specification.

The SMIL 3.0 Integration-Set Conformant document MUST reference the
following namespace, either as the default namespace or as an additional
prefix-qualified namespace):

xmlns="http://www.w3.org/ns/SMIL"

The SMIL 3.0 Integration-Set Conformant document MAY use a DOCTYPE, as
defined in the profile specification. If a document contains a DOCTYPE
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
specified, documents must be valid per the normative DTD
identified by that profile

When the document uses the functionality of a particular SMIL 3.0
module through SMIL 3.0 elements and attributes and the semantics
associated with these elements and attributes, it must do so in ways
consistent with the SMIL 3.0 specification.

The SMIL 3.0 Integration-Set Conformant document MUST adhere to any
additional conformance rules for the profile, as defined in a SMIL 3.0
Integration-Set Conformant profile specification.

The SMIL 3.0 Integration-Set Conformant document MUST be based on a
SMIL 3.0 Conformant profile.

The root element of the SMIL 3.0 Host-Language Conformant document MUST
be the smil element.

The SMIL 3.0 Host-Language Conformant document MUST reference the
following default namespace:

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.

A SMIL 3.0 Host-Language Conformant document MAY contain a DOCTYPE
declaration, as defined by the relevant profile specification. The DTD
referenced in the DOCTYPE declaration will, among other things, define
default values for the language version number and the base profile name
associated with the DTD. If a document contains a DOCTYPE declaration, it
must be a valid XML document. Note that this implies that extensions to
the syntax defined in the DTD are not allowed. As 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 the URI defined by the profile. The
SYMM WG also publishes a non-normative SMIL 3.0 DTD
identified by:

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.
The SYMM WG plans to make changes to the non-normative DTD over time to
correct errata. If you choose to refer to the non-normative 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 the normative or non-normative URIs as the system identifier in
the SMIL 3.0 profile's DOCTYPE, according to the desired level of
stability.

A SMIL 3.0 Host-Language Conformant document MAY declare a version
number and base profile by using the version and baseProfile attributes on the
smil root element. If a DOCTYPE
declaration is present, the version and base profiles defined must match
those in the profile DTD. If a DOCTYPE declaration containing a valid
SMIL profile DTD is not given and if no version attribute is specified,
version 3.0 will be used. If a DOCTYPE declaration containing a valid
SMIL profile DTD is not given and if no baseProfile attribute is defined,
the Language base profile will be used.

Given that, as of this writing, DTDs have no way to describe the
allowability of namespace-qualified extensions, and that extensions to
SMIL 3.0 host-language conformant documents must be namespace-qualified,
here is the algorithm to be used to validate documents with extensions:

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

The SMIL 3.0 Host-Language Conformant document MUST adhere to any
additional conformance rules for the profile, as defined in a SMIL 3.0
Host-Language Conformant profile specification.

SMIL 3.0 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.

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 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:

In order to be consistent with the XML 1.1 Recommendation [XML11],
(see Note), the user agent MUST parse and evaluate a
SMIL 3.0 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].

When the user agent claims to support the functionality of a particular
SMIL 3.0 profile through SMIL 3.0 elements and attributes and the
semantics associated with these elements and attributes, it must do so in
ways consistent with the SMIL 3.0 specification.

The user agent must be able to successfully parse any host-language
conforming SMIL 3.0 document as specified by the relevant profile
document, and to process, support and correctly implement the semantics
of all features of the relevant SMIL 3.0 profile UNLESS a particular
feature has been explicitly removed from the user agent implementation
according to the rules set forth under Extending/Restricting SMIL
3.0 Profiles.

The XML parser of the user agent must be able to parse and process XML
constructs defined in [XML11] and [XML-NS].

Processing the default namespace on the smil element will fall into one of three
cases:

The default namespace on the smil root element is recognized by
the user agent. The user agent should process the document as
the version identified by the recognized namespace (and, starting in
SMIL 3.0, the values of the version and baseProfile attributes). Any
elements, attributes, or other syntax not defined by the default
namespace on the smil root
element must be fully namespace qualified using standard XML
mechanisms for declaring namespaces for elements and attributes
described in [XML-NS], as further described in the section on Expanding/Restricting
SMIL Profiles. Unqualified elements not part of the default
namespace are illegal and must result in an error.

Complete support for inclusion of non-SMIL 3.0 namespaces within
SMIL 3.0 content via Namespaces in XML [XML-NS]. A xmlns declaration or xmlns prefix declaration may be used
on any element in the SMIL 3.0 document.

The user agent MUST ignore 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.

The user agent MUST ignore 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.

The user agent MUST issue an error for an attribute value which does
not conform to the syntax specified for that attribute.

The detection of a syntax error in a SMIL 3.0 document MUST result in
the user agent issuing an error and not playing the document.

When the hyphenated (deprecated) and the camelCase version of an
attribute syntax are used in the same element, SMIL 3.0 user agents
should take into account the camelCase version only.

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.

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:

All elements introduced in extensions must have a skip-content
attribute if it should be possible that their content is processed by
SMIL 3.0 user agents.

Private extensions must be introduced by defining a new XML
namespace.

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

16.4.6 Rules for
Constructing Scalable Profiles

A scalable profile is specified by using the content control facilities
via a namespace mechanism as follows:

The xmlns mechanism is used to
identify a module prefix that is used by the scalability framework. The
xmlns mechanism is used only to
define a prefix, and NOT to declare a module-based namespace. The prefix
may only be used as a value of the systemRequired attribute.

The systemRequired
attribute MUST be supported by all conformant SMIL 3.0 profiles.

The systemRequired
attribute is used to specify a set of modules that are necessary to
support the extended profile. The effective profile used by the document
is defined as the union of the modules defined for the relevant SMIL 3.0
profile and those specified in the systemRequired attribute.

The systemRequired
attribute may always be specified on the root smil element. SMIL 3.0 profiles may also
allow the systemRequired
attribute to be specified on elements other than the root element. When
used on the smil element, if the
value of the systemRequired attribute
resolves to FALSE, the document should not be played. When used on any
interior element, if the value of the systemRequired attribute
resolves to FALSE, the containing element should be ignored.

16.5 SMIL 3.0 Document Scalability
Guidelines

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:

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:

A document that explicitly requires support for the HostLanguage
module collection. Note that all SMIL profiles are required to be Host
Language conformant, so listing this requirement explicitly is not
strictly necessary:

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:

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:

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.