This section is informative.
The SMIL 3.0 specification extends the functionality SMIL 2.1 ContentControl Modules[SMIL21-content-control] by introducing three newattributes:allowReorder,
This section is normative.
This section defines the SMIL 3.0 content control modules. These modulescontain elements and attributes which provide for runtime content choices andoptimized content delivery. SMIL content control functionality is partitionedacross five modules:
Since all of the content control elements and attributes are defined inmodules, designers of other markup languages may reuse this functionality ona module by module basis when they wish to include media content control intheir language.
The functionality in the CustomTestAttributes module builds on thefunctionality of the BasicContentControl module; profiles implementing theCustomTestAttributes module must also implement the BasicContentControl andRequiredContentControl modules. The PrefetchControl and SkipContentControlmodules have no prerequisites.
This section is informative.
In some of the module descriptions for content control, the concept of"user preference" may be present. User preferences are usually set by theplayback engine using a preferences dialog box, but this specification doesnot place any restrictions on how such preferences are communicated from theuser to the SMIL player.
It is implementation dependent when content control attributes areevaluated. Attributes may be evaluated multiple times. Dynamic reevaluationis allowed but not required. When dynamic reevaluationis supported bya user agent, it is expected that any system- or custom-test variable will beevaluated at the beginning of a node's execution (either at its initial begintime or each time a repeated element restarts). For situations in which moreexplicit control over reevaluation is required, the use of the SMIL 3.0 Statemodules is encouraged.
This section is normative.
SMIL 1.0 provides a "test-attribute" mechanism to process an element onlywhen certain conditions are true, for example when the language preferencespecified by the user matches that of a media object. One or more testattributes may appear on media object references or timing structureelements; if the attribute evaluates totrue, thecontaining element is played, and if the attribute evaluates to
The SMIL 3.0 BasicContent module includes the test attribute functionalityfrom SMIL 1.0 and extends it by supporting new system test attributes. Thissection will describe the use of the predefined system test attributes, theswitch element and test attributein-line placement. A mechanism for extending test attributes is presented intheCustomTestAttributesmodule.
This specification defines a list of test attributes that can be added tolanguage elements, as allowed by the language designer. In SMIL 1.0, theseelements are synchronization and media elements. Conceptually, theseattributes represent Boolean tests. When any of the test attributes specifiedfor an element evaluates tofalse, the elementcarrying this attribute is ignored.
SMIL 3.0 supports the full set of SMIL 2.1 system attributes. The SMIL 2.1compatible system test attributes are:
- systemBitrate
- systemCaptions
- systemLanguage
- system-overdub-or-caption (note: this attribute has been deprecated in favor ofsystemCaptions orsystemOverdubOrSubtitle)
- systemScreenDepth
- systemScreenSize
Note that, with the exception of
SMIL 3.0 also supports system test attributes that define additionalcharacteristics of the system environment. These are:
Finally, SMIL 3.0 supports system test attributes that definecharacteristics of the SMIL version (starting with version 3.0) and baseprofile supported by the system environment. These are:
The complete definition of each attribute is given in theattributes definitionsection.
Theswitch element allows anauthor to specify a set of alternative elements from which only the firstacceptable element is chosen.
This section is informative.
An example of the use of the
... <par> <video src="anchor.mpg" ... /> <switch> <audio src="dutchHQ.aiff" systemBitrate="56000" ... /> <audio src="dutchMQ.aiff" systemBitrate="28800" ... /> <audio src="dutchLQ.aiff" ... /> </switch> </par> ...
In this example, one audio object is selected to accompany the videoobject. If the system bitrate is 56000 or higher, the objectdutchHQ.aiff is selected. If the system bitrate is at least 28800 butless than 56000, the objectdutchMQ.aiff is selected. If no otherobjects are selected, the alternativedutchLQ.aiff is selected, sinceit has no test attribute (thus is always acceptable) and no other testattributes evaluated totrue.
Authors should order the alternatives from the most desirable to the leastdesirable. Furthermore, authors may wish to place a relatively fail-safealternative as the last item in the
Note that some network protocols, e.g. HTTP and RTSP, supportcontent-negotiation, which may be an alternative to using the
It is the responsibility of the SMIL user agent to determine the settingfor system test attribute values. Such settings may be determined staticallybased on configuration settings, or they may be determined (and re-evaluated)dynamically, depending on the player implementation. When dynamicreevaluationis supported by a user agent, it is expected that anysystem- or custom-test variable will be evaluated at the beginning of a nodesexecution (either at its initial begin time or each time a repeated elementrestarts). For situations in which more explicit control over reevaluation isrequired, the use of the SMIL 3.0 State modules is encouraged. Players maynot select members of aswitch atrandom.
To allow more flexibility in element selection, test attributes may alsobe used outside of theswitchelement.
This section is informative.
In the following example of in-line test attribute use, captions are shownonly if the user wants captionson.
... <par> <audio src="audio.rm"/> <video src="video.rm"/> <textstream src="stockticker.rt"/> <textstream src="closed-caps.rt" systemCaptions="on"/> </par> ...
The alternatives indicated by the in-line construct could be representedas a set ofswitch statements,although the resultingswitch couldbecome explosive in size. Use of an in-line test mechanism significantlysimplifies the specification of adaptive content, especially in those caseswhere many independent alternatives exist. Note, however, that there is nofail-safe alternative mechanism (such as defining an element without a testattribute inside of aswitch) whenusing test attributes in-line.
This section is informative.
In a common scenario, implementations may wish to allow for selection via asystemBitrate attribute on elements. The SMIL 3.0 player evaluates each of the elements within theswitch one at a time, looking for an acceptable bitrate value.
... <par> <text .../> <switch> <par systemBitrate="40000"> ... </par> <par systemBitrate="24000"> ... </par> <par systemBitrate="10000"> ... </par> </switch> </par> ...
In this example, if the system bitrate has been determined to be less than 10000 (in mobile telephone cases, for example), then none of thepar constructs would be included.
The elements within theswitch may be any combination of elements. For instance, one could specify an alternate audio track:
... <switch> <audio src="joe-audio-better-quality" systemBitrate="16000" /> <audio src="joe-audio" /> </switch> ...
If the system bitrate was less than 16000, the standard-quality audio would be presented by default.
In the following example, an audio resource is available both in Dutch and in English. Based on the user's preferred language, the player can choose one of these audio resources.
... <switch> <audio src="joe-audio-nederlands" systemLanguage="nl"/> <audio src="joe-audio-english" systemLanguage="en"/> </switch> ...
In this example, if the system language setting was anything other than Dutch or English, no audio would be presented. To make a choice the default, it should appear as the last item in the list and not contain a test attribute. In the following fragment, English is used as the default:
... <switch> <audio src="joe-audio-nederlands" systemLanguage="nl"/> <audio src="joe-audio-english" /> </switch> ...
If the alternatives are equivalent an author may specify this through theallowReorder attribute, which gives the user agent the freedom to select the second alternative for someone who speaks both German and Dutch but prefers German:
... <switch allowReorder="yes"> <audio src="joe-audio-nederlands" systemLanguage="nl"/> <audio src="joe-audio-deutsch" systemLanguage="de"/> <audio src="joe-audio-english" /> </switch> ...
Note that none of these examples show the full power of language tag matching, please refer to BCP47[BCP47] for more elaborate examples.
In the following example, the presentation contains alternative parts designed for screens with different resolutions and bit-depths. Depending on the particular characteristics of the screen, the player must use the first alternative in which all of the test attributes evaluate totrue.
... <par> <text .../> <switch> <par systemScreenSize="1024X1280" systemScreenDepth="16"> ... </par> <par systemScreenSize="480X640" systemScreenDepth="32"> ... </par> <par systemScreenSize="480X640" systemScreenDepth="16"> ... </par> </switch> </par> ...
This example shows a video that is accompanied by zero or more media objects. If the system language has been set to either Dutch or English, then the appropriate audio object will play. In addition, if the system language has been set to either Dutch or English andsystemCaptions has also been set toon, the appropriate text files will also be displayed.
... <par> <video src="anchor.mpg" ... /> <audio src="dutch.aiff" systemLanguage="nl" ... /> <audio src="english.aiff" systemLanguage="en" ... /> <text src="dutch.html" systemLanguage="nl" systemCaption="on"... /> <text src="english.html" systemLanguage="en" systemCaption="on"... /> </par> ...
If system language is set to something other than Dutch or English, no objects will be rendered (except the video). Note that there is no catch-all default mechanism when using test attributes for in-line evaluation.
In the following example, a French-language movie is available with English, German, and Dutch overdub and subtitle tracks. The following SMIL segment expresses this, and switches on the alternatives that the user prefers.
... <par> <switch> <audio src="movie-aud-en.rm" systemLanguage="en" systemOverdubOrSubtitle="overdub"/> <audio src="movie-aud-de.rm" systemLanguage="de" systemOverdubOrSubtitle="overdub"/> <audio src="movie-aud-nl.rm" systemLanguage="nl" systemOverdubOrSubtitle="overdub"/> <!-- French for everyone else --> <audio src="movie-aud-fr.rm"/> </switch> <video src="movie-vid.rm"/> <switch> <textstream src="movie-sub-en.rt" systemLanguage="en" systemOverdubOrSubtitle="subtitle"/> <textstream src="movie-sub-de.rt" systemLanguage="de" systemOverdubOrSubtitle="subtitle"/> <textstream src="movie-sub-nl.rt" systemLanguage="nl" systemOverdubOrSubtitle="subtitle"/> <!-- French captions for those that really want them --> <textstream src="movie-caps-fr.rt" systemCaptions="on"/> </switch> </par> ...
SMIL 3.0 BasicContentControl defines the
Theswitch element allows anauthor to specify a set of alternative elements. An element is selected asfollows: the player evaluates the elements in the order in which they occurin theswitch element. The firstacceptable element is selected at the exclusion of all other elements withintheswitch. Implementations must NOTarbitrarily pick an object within a
This element allows the
The content of the element is language implementation dependent.
In the SMIL 3.0 language profile, if the
TheallowReorder attributesignals whether a user agent may reorder the direct descendents of the
The possible values areno, the default,disallowing reordering andyes, allowingreordering.
This section is informative.
User agents are free to ignore the
Authors should add the
SMIL 3.0 defines the following system test attributes. When any of thetest attributes specified for an element evaluates to
Profile-name ::= "Language" | "UnifiedMobile" | "Daisy" | "Tiny" | "smilText" |User-defined-profile-name
User-defined-profile-name ::= "x-" NMTOKENThese values come from the _PR_SI_ARCHITECTURE constants defined by themozilla project.
The syntax of thesystemLanguage and the deprecatedsystem-language attributes are defined using EBNF notation (as defined in[XML11]) as list of XML namespace prefixes[XML-NS], separated by the ',' character:
SystemLanguageArgumentValue ::= (LanguageTag (S? "," S? LanguageTag)*)?
Where allowed white space is indicated as 'S', defined as follows (taken from the[XML11] definition for 'S'):
S ::= (#x20 | #x9 | #xD | #xA)+
This section is informative.
BCP47: This is actually an active document that can, over time, refer to newer RFCs as technology progresses. As of this writing BCP47 consists of RFC4646 for defining language tags and RFC4647 for defining the matching algorithm.
Implementation: When making the choice of linguistic preference available to the user, implementers should take into account the fact that most users are not familiar with the details of RFC4647 language matching, and should provide appropriate guidance. As an example, users may mistakenly assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. The user interface for setting user preferences should guide the user to add "en" to get the best matching behavior.
This section is informative.
These values come from the _PR_SI_SYSNAME constants defined by themozilla project.
It is the responsibility of the SMIL 3.0 Player to determine the settingsfor each predefined test variable. These values may be determined by staticconfiguration settings, or they may be evaluated dynamically during runtime.Such setting and (re)evaluation behavior is implementation dependent. Whendynamic reevaluationis supported by a user agent, it is expected thatany system- or custom-test variable will be evaluated at the beginning of anodes execution (either at its initial begin time or each time a repeatedelement restarts). For situations in which more explicit control overreevaluation is required, the use of the SMIL 3.0 State modules isencouraged.
For this version of SMIL elements with specified test attributes thatevaluate to false, or elements within a switch that are not selected, areconsidered to be ignored and will behave as though they were not specified inthe document. Any references to these elements will be as if the elementswere not in the document. In particular, any ID references to the elementwill act as if there was no element with that ID. Languages that integratethis module must specify any additional behavior related to these ignoredelements. In the SMIL 3.0 Language profile, timing attributes that referenceinvalid IDs are treated as being indefinite.
This section is informative.
Authors should be aware that this model for handling ignoredelements may be revised in a future version of SMIL, and the relatedsemantics may well change. These changes should not affect implementationsthat only support parse-time (or equivalent) evaluation of test attributesand/or the switch element. However, the semantics ofdynamicre-evaluation (i.e. re-evaluation during document presentation) of testattributes and/or switch elements are not defined in this version of SMIL;this will be addressed in a future version.
Authors should realize that if several alternative elementsare enclosed in aswitch, and none ofthem evaluate to true, this may lead to situations such as a media objectbeing shown without one or more companion objects. It is thus recommended toinclude a "catch-all" choice at the end of a
The functionality in this module does not build on functionality definedin other SMIL 3.0 modules.
See the fullDTD for theSMIL Content Control modules.
This section is normative.
The use of predefined system test attributes in the SMILBasicContentControl module provides a selection mechanism based on attributesthat are fixed within the module's definition. The CustomTestAttribute moduleextends this facility with the definition of author-defined custom testattributes. Custom test attributes allow presentation authors to define theirown test attributes for use in a specific document. Custom test attributesmay be shared among application documents using the
As with system test attributes, custom test attributes may be used withintiming structure and media object elements; if they evaluate to
Since custom test attributes are application/document specific, they needa mechanism to allow attribute definition and attribute setting. Attributedefinition is done via the
The state of the attribute can be changed in one of three ways:
The exact rules for setting and modifying the values associated withcustom test attributes are givenbelow.
An implementation may support either, both, or none of methods 2 and 3. Ifmethod 2 is supported, the URI value in
This section is informative.
The following example shows one way in which custom test attributes may beapplied within a SMIL 3.0 Language profile document:
<smil> <head> <layout> <!-- define projection regions --> </layout> <customAttributes> <customTest xml:id="west-coast" title="West Coast Edition" defaultState="false" override="visible" uid="http://defs.example.org/user-settings/west-coast" /> <customTest xml:id="east-coast" title="East Coast Edition" defaultState="false" override="visible" uid="http://defs.example.org/user-settings/east-coast" /> <customTest xml:id="far-north" title="Northern Edition" defaultState="false" override="visible" uid="http://defs.example.org/user-settings/far-north" /> <customTest xml:id="the-rest" title="National Edition" defaultState="true" override="hidden" /> </customAttributes> </head> <body> ... <par> <img src="background.png" region="a"/> <video src="story_1v.rm" region="b" /> <switch> <audio src="story_1w.rm" region="c" customTest="west-coast"/> <audio src="story_1e.rm" region="c" customTest="east-coast"/> <audio src="story_1n.rm" region="c" customTest="far-north"/> <audio src="story_1r.rm" region="c" customTest="the-rest"/> </switch> </par> ... </body></smil>
ThecustomAttributeselement in the header contains the definition of the available custom testattributes. Each custom test attribute, defined by the
The custom test variables named "west-coast", "east-coast" and "far-north"are defined with a default rendering state of
The custom test variable "the-rest" is defined with a default renderingsetting oftrue.
Inside thebody, a SMIL
While this example shows
The setting of the value associated with a custom test attribute proceedsas follows:
Note that a user setting of the custom test attribute will take precedenceover a URI setting. If the user has not specified a value for the attributethen the URI setting takes precedence. As with predefined system testattributes, this evaluation will occur in an implementation-defined manner.The value may be (re)evaluated dynamically, but this is not required. Whendynamic reevaluationis supported by a user agent, it is expected thatany system- or custom-test variable will be evaluated at the beginning of anodes execution (either at its initial begin time or each time a repeatedelement restarts). For situations in which more explicit control overreevaluation is required, the use of the SMIL 3.0 State modules isencouraged. Note also that not all implementations need support
This section defines the elements and attributes that make up thefunctionality in the SMIL CustomTestAttributes module. The
ThecustomAttributeselement contains definitions of each of the custom test attributes. Thecontained elements define a collection of author-specified test attributesthat may be used inswitch statementsor as in-line test attributes in the document.
This element does not have attributes beyond those required of allelements in the profile.
ThecustomAttributeselement may contain one or more
ThecustomTest element definesan author-specified name that will be used as the test argument in the
This section is informative.
The actual evaluation mechanism associated with the URI is implementation dependent. It may vary from a simple lookup in a local file or registry, to a secure reference via a capabilities database, and may be influenced by other configuration settings provided by the implementation.
None.
In addition to the
The syntax of thecustomTest is defined using EBNF notation (as defined in[XML11]) as list of customTest element identifier references, separated by the '+' character:
CustomTestArgumentValue ::= Idref (S? "+" S? Idref)*
Idref ::= Name
Where allowed white space is indicated as 'S', defined as follows (taken from the[XML11] definition for 'S'):
S ::= (#x20 | #x9 | #xD | #xA)+
andIdref is aName as defined in[XML11] is a reference to acustomTest element.
The functionality in this module builds on functionality defined in theBasicContentControl module, which is a required prerequisite for inclusion ofthe CustomTestAttribute module.
The profile implementing the custom test elements and attributes mustprovide a means of associating a unique XML identifier with a customTestelement, so that it can be used by the customTest attribute. And the profileshould provide a means of associating descriptive text with a customTestelement, which may be used in a GUI or other selection mechanism that may bepresented to the user. For the SMIL 3.0 Language Profile, the element's idand title attributes serve this purpose.
See the fullDTD for theSMIL Content Control modules.
This section is normative.
This module defines an element and attributes that may be used to controlthe fetching of content from a server in a manner that will improve therendering performance of the document.
This element will give a suggestion or hint to a user agent that a mediaresource will be used in the future and the author would like part or all ofthe resource fetched ahead of time to make the document playback smoother.User-agents may ignoreprefetchelements, though doing so may cause an interruption in the document playbackwhen the resource is needed. It gives authoring tools or savvy authors theability to schedule retrieval of resources when they think that there isavailable bandwidth or time to do it. A
This section is informative.
Prefetching data from a URL that changes the contentdynamically is potentially dangerous: if the entire resource isn'tprefetched, a subsequent request for the remaining data may yield data from anewer resource. A user agent should respect any appropriate cachingdirectives applied to the content, e.g. no-cache 822 headers in HTTP. Morespecifically, content marked as non-cacheable would have to be refetched eachtime it was played, where content that is cacheable could be prefetched once,with the results of the prefetch cached for future use.
<smil xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="Language"> <body> <seq> <par> <prefetch xml:id="endimage" src="http://www.example.org/logo.gif"/> <text xml:id="interlude" src="http://www.example.org/pleasewait.html" fill="freeze"/> </par> <video xml:id="main-event" src="rtsp://www.example.org/video.mpg"/> <img src="http://www.example.org/logo.gif" dur="5s"/> </seq> </body> </smil>
The example starts with a prefetch in parallel with the rendering of a text object. The text is discrete media so it ends immediately, the prefetch is defaulted to prefetch the entire image at full available bandwidth and the prefetch element ends when the image is downloaded. That ends the<par> and the video begins playing. When the video ends the image is shown.
<html> <body> <prefetch xml:id="upimage" src="http://www.example.org/up.gif"/> <prefetch xml:id="downimage" src="http://www.example.org/down.gif"/> .... <!-- script will change the graphic on rollover --> <img src="http://www.example.org/up.gif"/> </body> </html>
Theprefetch gives authors amechanism to influence the scheduling of media object transfers from a serverto the player.
Documents must still playback even when the
The intrinsic duration of a
If aprefetch element isrepeated, due to restart or repeat on a parent element the prefetch operationshould occur again. This insures appropriately "fresh" data is displayed if,for example, the prefetch is for a banner ad to a URL whose content changeswith each request.
Theprefetch element supportsthe following attributes:
Any attribute with a value of "0%" is ignored and treated as if theattribute wasn't specified.
If bothmediaSize and
If theclipBegin or
Bytes-value ::= DIGIT+ /* any positive number */
Percent-value ::= DIGIT+ "%" /* any positive number in the range 0 to 100 */
Clock-value ::= ( Hms-val | Smpte-val )Smpte-val ::= ( Smpte-type )? Hours ":" Minutes ":" Seconds( ":" Frames ( "." Subframes )? )?Smpte-type ::= "smpte" | "smpte-30-drop" | "smpte-25"Hms-val ::= ( "npt=" )? (Full-clock-val | Partial-clock-val| Timecount-val)Full-clock-val ::= Hours ":" Minutes ":" Seconds ("." Fraction)?Partial-clock-val ::= Minutes ":" Seconds ("." Fraction)?Timecount-val ::= Timecount ("." Fraction)? (Metric)?Metric ::= "h" | "min" | "s" | "ms"Hours ::= DIGIT+ /* any positive number */Minutes ::= 2DIGIT /* range from 00 to 59 */Seconds ::= 2DIGIT /* range from 00 to 59 */Frames ::= 2DIGIT /* smpte range = 00-29, smpte-30-drop range = 00-29, smpte-25 range = 00-24 */Subframes ::= 2DIGIT /* smpte range = 00-01, smpte-30-drop range = 00-01, smpte-25 range = 00-01 */Fraction ::= DIGIT+Timecount ::= DIGIT+2DIGIT ::= DIGIT DIGITDIGIT ::= [0-9]
For Timecount values, the default metric suffix is "s" (for seconds).
This note is informative
A value of three sets of colon-separated digits can be produced both by Hms-val and Smpte-val. This is however not aproblem since in both cases the values are interpreted as Hours, Minutes and Seconds.
Bitrate-value ::= DIGIT+ /* any positive number */
A profile integrating the PrefetchControl module must add the attributesnecessary to specify the media to be fetched. In general, these will be thesame resource specifying attributes as those on the media elementsthemselves. In addition, the profile must add any necessary attributes tocontrol the timing of theprefetchelement.
See the fullDTD for theSMIL Content Control modules.
This section is normative.
This module contains one attribute,
The SkipContentControl module does not contain any element definitions.
It is the responsibility of the language profile to specify which elementshaveskip-content attributes toenable this expansion mechanism.
This section is normative.
This module contains one attribute,
The RequiredContentControl module does not contain any elementdefinitions.
SystemRequiredArgumentValue := Nmtoken (S? "+" S? Nmtoken)*
Where allowed white space is indicated as 'S', defined as follows (taken from the[XML11] definition for 'S'):
S ::= (#x20 | #x9 | #xD | #xA)+
It is the responsibility of the language profile to specify which elementssupport thesystemRequiredattribute. In order to support the SMIL Scalability Framework, all profilesare expect to at least support this attribute on the top-level SMILelement.