22. SMIL 3.0 Server Playlist Profile

This section is normative.

22.5.1 Document Conformance

This version of SMIL provides a definition of strictly conforming Server Playlist Profile documents, which are restricted to tags and attributes from the SMIL 3.0 namespace. In the future, the language described in this 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 Server Playlist Profile user agents.
• Private extensions must be introduced by defining a new XML namespace.

Conformant Server Playlist Profile user agents are expected to handle documents containing extensions that obey these two rules.

22.5.2 Server Playlist Profile Conformance

The Server Playlist Profile is a conforming SMIL 3.0 specification. The rules for defining conformant documents are provided in the SMIL in the SMIL document. Note that while the section is written for the SMIL 3.0 Language profile, all of the rules apply to the Server Playlist Profile as well, with the exception that the Server Playlist Profile's namespace should be used instead of the SMIL 3.0 Language Profile's namespace and the Server Playlist Profile's DOCTYPE declaration should be used instead of the SMIL 3.0 Language Profile DOCTYPE declaration.

Server Playlist Profile Namespace

Documents written for the Server Playlist Profile must declare a default namespace for its elements with an xmlns attribute on the smil root element with its identifier URI:

<smil xmlns="http://www.w3.org/2006/SMIL30/WD/ServerPlaylist">
   ...
</smil>  

The default namespace declaration must be

xmlns="http://www.w3.org/2006/SMIL30/WD/ServerPlaylist"

Language designers and implementors wishing to extend the Server Playlist Profile must consider the implications of the use of namespace extension syntax. Please consult the section on Scalable Profiles for restrictions and recommendations for best practice when extending SMIL.

Server Playlist Profile DOCTYPE declaration

A SMIL 3.0 document can contain the following DOCTYPE declaration:

The SMIL 3.0 Mobile Profile DOCTYPE is:

<!DOCTYPE smil PUBLIC "-//W3C//DTD SMIL 3.0 Mobile//EN"
"http://www.w3.org/2006/SMIL30/WD/SMIL30Mobile.dtd">

If a document contains this 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 the document is invalid, the user agent should issue an error.

Conforming SMIL Server Playlist Profile User Agents

Since the Server Playlist Profile defines a conforming SMIL document, the rules for defining conformant user agents are the same as provided in the Conforming SMIL 3.0 Language User Agents in the SMIL 3.0 Language Profile document, with the exception that the conforming user agent must support the Server Playlist Profile's namespace instead of the SMIL Language Profile's namespace.

22.5.3 The SMIL 3.0 Server Playlist Profile

The Server Playlist Profile supports the SMIL features for basic multimedia presentations. It uses only modules from the SMIL 3.0 Recommendation. As the language profile includes the mandatory modules, it is a SMIL Host Language conforming language profile. This language profile includes the following SMIL 3.0 modules:

• Structure functionality
  • Structure Module
• Metainformation functionality
  • Metainformation Module
• Timing functionality
  • BasicInlineTiming Module
  • MinMaxTiming Module
  • RepeatTiming Module
  • BasicTimeContainers Module
  • WallClockTiming Module
• Layout functionality
  • BasicLayout Module
  • AudioLayout Module
  • BackgroundTilingLayout Module
  • AlignmentLayout Module
• Transition Effects functionality
  • BasicTransitions Module
  • FullScreenTransitions Module
• Media functionality
  • BasicMedia Module
  • MediaClipping Module
  • MediaDescription Module

The collection names contained in the following table define the Server Playlist Profile vocabulary.

SMIL 3.0 Server Playlist Profile
Collection Name	Elements in Collection
ContentControl	switch
Layout	region, root-layout, layout, regPoint
MediaContent	text, img, audio, video, ref, textstream
Metainformation	meta, metadata
Structure	smil, head, body
Schedule	par, seq
Transition	transition

In the following sections, we define the set of elements and attributes used in each of the modules included in the Server Playlist Profile. The content model for each element is described. The content model of an element is a description of elements which can appear as its direct children. The special content model "EMPTY" means that a given element may not have children.

Collection Name	Attributes in Collection
Core	id (ID), class (NMTOKEN), title (CDATA), alt (CDATA), longdesc (CDATA), xml:base (CDATA)
I18n	xml:lang (NMTOKEN)

The id, class and title attributes in the collection Core are defined for all the elements of the Server Playlist Profile. The id attribute is used in the Server Playlist Profile to assign a unique XML identifier to every element in a SMIL document.

A conforming Server Playlist Profile document should not use the SMIL 1.0 attributes that have been depreciated in SMIL 2.0. Server Playlist Profile implementations are not required to support these attributes. This would be considered an unjustified burden for the targeted constraint devices. The unsupported depreciated SMIL 1.0 attributes are the following: anchor, background-color, clip-begin, clip-end, repeat; and the additional depreciated test attributes of Content Control: system-bitrate, system-captions, system-language, system-required, system-screen-size, and, system-screen-depth.

22.5.4 Layout Modules

The Layout Modules provide a framework for spatial layout of visual components. The Layout Modules define semantics for the region, root-layout, layout and the regPoint elements. The Server Playlist Profile includes the Layout functionality of the BasicLayout, AudioLayout, BackgroundTilingLayout, and AlignmentLayout modules.

In the Server Playlist Profile, Layout elements can have the following attributes and content model :

Layout Module
Elements	Attributes	Content model
region	Core, I18n, Test, backgroundColor, showBackground (always | whenActive), bottom, fit (fill | hidden | meet | scroll | slice), width, height, left, right, top, soundLevel, z-index, skip-content, regionName	EMPTY
root-layout	Core, I18n, Test, backgroundColor , width, height, skip-content	EMPTY
layout	Core, I18n, Test, type	(root-layout | region | regPoint)*
regPoint	Core, I18n, Test, top, bottom, left, right, regAlign ( topLeft|topMid | topRight | midLeft | center | midRight | bottomLeft | bottomMid | bottomRight ), skip-content	EMPTY

This profile adds the layout element to the content model of the head element of the Structure Module.

22.5.5 Media Object Modules

The Media Object Modules provide a framework for declaring media. The Media Object Modules define semantics for the ref, audio, img, video, text, and textstream elements. The Server Playlist Profile includes the Media Object functionality of the BasicMedia and MediaClipping modules.

In the Mobile Profile, media elements can have the following attributes and content model:

Media Object Module
Elements	Attributes	Content model
text, img, audio, video, ref, textstream	Core, I18n, Timing, Test, region, fill (freeze | remove | hold | transition | auto | default), author, copyright, abstract, src, type, erase, mediaRepeat, paramGroup, sensitivity, transIn, transOut, clipBegin, clipEnd, endsync, mediaAlign, regPoint, regAlign, soundAlign, soundLevel.	(param | area | switch)*

22.5.6 Metainformation Module

The Metainformation Module provides a framework for describing a document, either to inform the human user or to assist in automation. The Metainformation Module defines semantics for the meta and metadata elements. The Server Playlist Profile includes the Metainformation functionality of the Metainformation module.

In the Server Playlist Profile, Metainformation elements can have the following attributes and content model :

Metainformation Module
Elements	Attributes	Content model
meta	Core, I18n, skip-content, content (CDATA), name (CDATA)	EMPTY
metadata	Core, I18n, skip-content	EMPTY

This profile adds the meta element to the content model of the head element of the Structure Module.

The content model of metadata is empty. Profiles that extend the Server Playlist Profile may define their own content model of the metadata element.

22.5.7 Structure Module

The Structure Module provides a framework for structuring a SMIL document. The Structure Module defines semantics for the smil, head, and body elements. The Server Playlist Profile includes the Structure functionality of the Structure module.

In the Server Playlist Profile, the Structure elements can have the following attributes and content model :

Structure Module
Elements	Attributes	Content model
smil	Core, I18n, Test, xmlns	(head?,body?)
head	Core, I18n	(meta*,(metadata,meta*)?,((layout|switch),meta*)?, (transition+,meta*)?, (paramGroup+,meta*)?)
body	Core, I18n, Timing, fill, abstract, author, copyright	(Schedule | MediaContent | ContentControl | a )*

The body element acts as the root element to span the timing tree. The body element has the behavior of a seq element. Timing on the body element is supported. The syncbase of the body element is the application begin time, which is implementation dependent, as is the application end time. Note that the effect of fill on the body element is between the end of the presentation and the application end time, and therefore the effect of fill is implementation dependent.

22.5.8 Timing and Synchronization Modules

The Timing and Synchronization Modules provide a framework for describing timing structure, timing control properties and temporal relationships between elements. The Timing and Synchronization Modules define semantics for par and seq elements. In addition, these modules define semantics for attributes including begin, dur, end, repeatCount, repeatDur, min, max. The Server Playlist Profile includes the Timing and Synchronization functionality of the BasicInlineTiming, EventTiming, MinMaxTiming, RepeatTiming, BasicTimeContainers modules.

In the Server Playlist Profile, Timing and Synchronization elements can have the following attributes and content model :

Timing and Synchronization Module
Elements	Attributes	Content model
par	Core, I18n, Timing, Test, endsync, fill (freeze | remove | hold | auto | default), abstract, author, copyright, region	(Schedule | MediaContent | ContentControl | a)*
seq	Core, I18n, Timing, Test, fill (freeze | remove | hold | auto | default), abstract, author, copyright, region	(Schedule | MediaContent | ContentControl | a) *

The Attribute collection Timing is defined as follows:

Collection Name	Attributes in Collection
Timing	begin, dur, end, repeatCount, repeatDur, min, max

This profile adds the par and seq elements to the content model of the body element of the Structure Module.

Elements of the Media Object Modules have the attributes describing timing and properties of contents.

Supported Event Symbols

The Mobile Profile specifies which types of events can be used as part of the begin and end attribute values. The supported events are described as Event-symbols according to the syntax introduced in the SMIL Timing and Synchronization module.

The supported event symbols in the Mobile Profile are:

Event	example
focusInEvent (In DOM Level 2: "DOMFocusIn")	end="foo.focusInEvent"
focusOutEvent (In DOM Level 2: "DOMFocusOut")	begin="foo.focusOutEvent"
activateEvent (In DOM Level 2: "DOMActivate")	begin="foo.activateEvent"
beginEvent	begin="foo.beginEvent"
endEvent	end="foo.endEvent"
repeatEvent	end="foo.repeatEvent"
inBoundsEvent	end="foo.inBoundsEvent"
outOfBoundsEvent	begin="foo.outOfBoundsEvent"

As defined by the SMIL syncbase timing semantics, any event timing attributes that reference an invalid time-value description will be treated as if "indefinite" were specified.

Event semantics

focusInEvent:

Raised when a media element gets the keyboard focus in its rendering space, i.e., when it becomes the media element to which all subsequent keystroke-event information is passed. Once an element has the keyboard focus, it continues to have it until a user action or DOM method call either removes the focus from it or gives the focus to another media element, or until its rendering space is removed. Only one media element can have the focus at any particular time. The focusInEvent is delivered to media elements only, and does not bubble.

focusOutEvent:

Raised when a media element loses the keyboard focus from its rendering space, i.e., when it stops being the media element to which all subsequent keystroke-event information is passed. The focusOutEvent is delivered to media elements only, and does not bubble.

activateEvent:

Raised when a media element is activated by user input such as by a mouse click within its visible rendering space or by specific keystrokes when the element has the keyboard focus. The activateEvent is delivered to media elements only, and does not bubble.

beginEvent:

Raised when the element actually begins playback of its active duration. If an element does not ever begin playing, this event is never raised. If an element has a repeat count, beginEvent is only raised at the beginning of the first iteration. The beginEvent is delivered to elements that support timing, such as media elements and time containers, and does not bubble.

endEvent:

Raised when an element actually ends playback; this is when its active duration is reached or whenever a playing element is stopped. In the following example,

<ref id="x" end="30s" src="15s.mpg" />
<ref id="y" end="10s" src="20s.mpg" />
<ref id="z" repeatCount="4" src="5s.mpg" />

x.endEvent occurs at roughly 30s when the active duration is reached, y.endEvent occurs at roughly 10s when the playback of the continuous media is ended early by the active duration being reached, and z.endEvent occurs at roughly 20s when the fourth and final repeat has completed, thus reaching the end of its active duration. The endEvent is delivered to elements which support timing, such as media elements and time containers, and does not bubble.

repeatEvent:

Raised when the second and subsequent iterations of a repeated element begin playback. An element that has no repeatDur, repeatCount, or repeat attribute but that plays two or more times due to multiple begin times will not raise a repeatEvent when it restarts. Also, children of a time container that repeats will not raise their own repeatEvents when their parent repeats and they begin playing again. The repeatEvent is delivered to elements which support timing, such as media elements and time containers, and does not bubble.

inBoundsEvent:

Raised when one of the following happens:

• by any input from the mouse or other input device that brings the mouse cursor from outside to within the bounds of a media element's rendering space, regardless of what part, if any, of that rendering space is visible at the time, i.e., z-order is not a factor.
• by any other action that moves the "cursor" or "pointer", as defined by the implementation, from outside to within the bounds of a media element's rendering space, regardless of what part, if any, of that rendering space is visible at the time, i.e., z-order is not a factor. An implementation may decide, for instance, to raise an inBoundsEvent on an element whenever it gets the focus, including when keystrokes give it the focus.

A media element's bounds are restrained by the bounds of the region in which it is contained., i.e., a media element's bounds do not extend beyond its region's bounds. The inBoundsEvent is delivered to media elements only, and does not bubble.

Note that, unlike with keyboard focus which can only be active on one object at a time, the state of being within an object's bounds can be true for multiple objects simultaneously. For instance, if one object is on top of another and the cursor is placed on top of both objects, both would have raised an inBoundsEvent more recently than the raising of any respective outOfBoundsEvent. If a player does not support a pointer cursor, then these players will typically not generate the inBoundsEvent and outOfBoundEvent events.

outOfBoundsEvent:

Raised when one of the following happens:

• by any input from the mouse or other input device that brings the mouse cursor from within to outside the bounds of a media element's rendering space, regardless of what part, if any, of that rendering space is visible at the time,
• by any other action that moves the "cursor" or "pointer", as defined by the implementation, from within to outside the bounds of a media element's rendering space, regardless of what part, if any, of that rendering space is visible at the time.

A media element's bounds are restrained by its region's bounds, i.e., a media element's bounds do not extend beyond its region's bounds. The outOfBoundsEvent is delivered to media elements only, and does not bubble.

Order of raising of simultaneous events:

There will be cases where events occur simultaneously. To ensure that each Mobile implementation handles them in the same order, the following order must be used to resolve ties:

1. InBoundsEvent
2. focusInEvent (should follow 1)
3. activateEvent (should follow 2)
4. OutOfBoundsEvent
5. focusOutEvent (should follow 4)
6. endEvent
7. beginEvent (must follow 6)
8. repeatEvent

Events are listed in order of precedence, e.g., if event #6 in this list occurs at the same time as event #7, then #6 must be raised prior to #7.

The InBoundsEvent, focusInEvent, OutOfBoundsEvent, activateEvent, and focusOutEvent events do not bubble and are delivered to the target media element.

The beginEvent, endEvent and repeatEvent events do not bubble and are delivered to the timed element on which the event occurs.

Extending the set of supported events

The Mobile Profile supports an extensible set of events. In order to resolve possible name conflicts with the events that are supported in this profile qualified event names are supported. Namespace prefixes are used to qualify the event names. As a result, the colon is reserved in begin and end attributes for qualifying event names.

For example:

<smil ... xmlns:example="http://www.example.com">
   <img id="foo" .../> 
   <audio begin="foo.example:focusInEvent".../>
    ... 
</smil>

Integration definitions

A SMIL document's begin time is defined as the moment a user agent begins the timeline for the overall document. A SMIL document's end time is defined as equal to the end time of the body element.

22.5.9 Transition Effects Modules

The Transition Effects Modules provide a framework for describing transitions such as fades and wipes. The Transition Modules define semantics for the transition element. The Server Playlist Profile includes the functionality of the BasicTransitions and FullScreenTransitions modules.

In the Server Playlist Profile, Transition Effects elements have the following attributes and content model :

Transition Effects Module
Elements	Attributes	Content model
transition	Core, I18n, Test, dur, type, subtype, startProgress, endProgress, direction, fadeColor, scope, skip-content	EMPTY

This profile adds the transition element to the content model of the head element of the Structure Module.

The Transition Effects Modules add transIn and transOut attributes to ref, audio, img, video, text and textstream elements of the Media Object Modules.

The Transition Effects Modules add the transition value to the fill attribute for all elements on which this value of the fill attribute is supported.

This section is normative.

The Server Playlist Profile Document Type Definition is defined as a set of SMIL