Should the profile define a minimal list/recommended of media types?
see: Baseline formats.
Should we allow subsetting/splitting of modules (basic/Boston layout module)?
Does the profile require support for some or all features of SMIL Boston? If it requires some, what features are not required If it requires all, is it realistic to expect that someone will really implement the full Boston Language Profile in the near future (including DOM, transitions, animation)
Should we define:
See in-line for more remarks.
The SMIL Boston profile describes the SMIL modules that are included and details how this modules are integrated. It contains all of the SMIL Boston features including animation, content control, layout, linking, media object, meta-information, structure, timing and transition effects modules. It is designed for Web clients that support direct SMIL Boston markup such as standalone multimedia players.
This section is informative.
The SMIL Boston Profile is defined as a markup language. The syntax of this language is formally described with a document type definition or Schema which are based on SMIL modules as defined in "Modularization of SMIL" [SMIL-MOD]
The SMIL Boston Profile design requirements are:
This section is normative.
A conforming SMIL Boston document is a document that requires only the facilities described as mandatory in this specification. Such a document must meet all of the following criteria:
<smil>.
http://www.w3.org/2000/smil
<!DOCTYPE SMIL-Boston PUBLIC "-//W3C//DTD SMIL Boston //EN"
"smil-boston.dtd">
The user agent must conform to the following user agent rules :
@fill in here requirements.
The SMIL-Boston Profile supports the timeline-centric multimedia features found in SMIL language. This profile includes the following SMIL modules:
Is it realistic to expect that someone will really implement this in the near future (including full transitions, animation, DOM)? Check this with implementers. Chairman: Yes, we should require what people will actually implement. If the group wants to make certain features option, that is up for discussion.
The Animation Module provides a framework for incorporating animation onto
a timeline (a timing model) and a mechanism for composing the effects of
multiple animations (a composition model). The Animation Module defines semantics
for the animate, set,
animateMotion, and
animateColor elements:
| Elements | Attributes | Minimal Content Model |
|---|---|---|
| animate | TBD | TBD |
| set | TBD | TBD |
| animateMotion | TBD | TBD |
| animateColor | TBD | TBD |
This module adds the animate, set, animateMotion, and animateColor elements to the content model of the par, seq, and excl elements of the Timing and Synchronization Module. It also adds these elements to the content model of the body element of the Structure Module.
Integration issues with animation
We need to think about how animation applies to SMIL. It should be possible to animate regions, and so animation will apply to the elements of layout. Animating the time containers is interesting, but likely beyond what we want to do here. What properties of media elements are interesting to animate? How about the URL's of media objects? There is much up for discussion here.
The Content Control Module provides a framework for selecting content based
on a set of test attributes. The Content Control Module defines semantics
for the switch element.
| Elements | Attributes | Minimal Content Model |
|---|---|---|
| switch | Common, Timing | TBD |
This module adds the switch, element to the content model of the par, seq, and excl elements of the Timing and Synchronization Module. It also adds this element to the content model of the body element of the Structure Module. It also adds this element to the content model of the a element of the Linking Module. It also adds this element to the content model of the head element of the Structure Module.
The Content Control Module defines the Attribute set "Test".
| Collection Name | Attributes in Collection |
|---|---|
| Test | systemBitrate (Number), systemCaption (on|off), systemLanguage (CDATA), systemOverdubOrCaption (caption|overdub), systemRequired (URI), systemScreenSize (CDATA), systemScreenDepth (CDATA), systemOverdubOrSubtitle (overdub|subtitle), systemAudioDesc (on|off), systemComponent (CDATA), |
We also want to include the test-attributes, which can be on elements within or outside of a switch, the usergroups, and the prefetch element.
The Layout Module provides a framework for spatial layout of visual components. The Layout Module defines semantics for the layout, root-layout, and region elements.
We may want to split layout up, but this will not be done for this draft. This shouldn't affect this profile, since all of the layout will likely be included in the full profile (as opposed to the Basic profile).
| Elements | Attributes | Minimal Content Model |
|---|---|---|
| region | backgroundColor,bottom, fit (fill | hidden | meet | scroll | slice), width, height, left, right, title, top, volume, z-index, | TBD |
| root-layout | backgroundColor, width, height, skip-content, title | None |
| top-layout(*) | backgroundColor, width, height, skip-content, title | region, None |
| layout | TBD** | root-layout, region, top-layout |
(*) If the type attribute of the "layout" element has the value "text/smil-basic-layout", it can contain the "region" and the "root-layout" elements. If the type attribute of the layout element has the value "text/smil-extended-layout", in addition to the "layout" and "root-layout" elements it can contain the "top-layout" element.
(**) The "background-color" attribute of SMIL1.0 is deprecated in favor of "backgroundColor".
This module adds the layout element to the content model of the head element of the Structure Module. It also adds this element to the content model of the switch element of the Content Control Module.
Probably need more explanation here as to how modules add to each other through the integration profile. Any suggestions for a good format? Maybe define in both sections: briefly note in the section adding functionality, and fully describe in the section having functionality added.
The Linking Module provides a framework for relating documents to content, documents and document fragments. The Linking Module defines semantics for the a and area elements.
Both the a and area elements have an "href" attribute, whose value should be a valid URI. Support for URI's using http:// and file:/ access protocols is required. Support for other protocols is optional.
Make support for RT(S)P required? Chairman: How about if RTP/RTSP is supported by the implementation, then the markup must be supported. If not, then the rtsp attributes/elements are ignored. This is the kind of thing that the profile has to nail down).
Support for URI's with XPointer fragment identifier syntax is not required.
| Elements | Attributes | Minimal Content Model |
|---|---|---|
| a | href, sourceVolume, destinationVolume, sourcePlaystate (play | pause | stop), destinationPlaystate, show (new | replace), accesskey, tabindex , target, actuate, Common, Timing, Test | Media Objects, Time Container Elements, |
| area | coords, sourceVolume , destinationVolume, sourcePlaystate, destinationPlaystate, show, accesskey, tabindex, target, Common, Timing,Test | Empty |
This module adds the area and a elements to the content model of the par, seq, and excl elements of the Timing and Synchronization Module. It also adds these elements to the content model of the body element of the Structure Module.
SMIL 1: The <anchor> element is deprecated in favor of <area>.
SMIL 1: The show attribute value "pause" is deprecated in favor of setting the the "show" attribute to "new" and the "sourcePlaystate" attribute to "pause".
Chairman: need to define what "adding to the content model" means. This is not fully descriptive, since the time containers can be children of media elements, etc.
The Media Object Module provides a framework for declaring media. The Media Object Module defines semantics for the ref, animation, audio, img, video, text, and textstream elements.
Should the profile define a minimal list/recommended of media types?
see: Baseline formats.
In the SMIL Boston Language Profile, media object elements can have the following attributes, in addition to the attributes defined in the SMIL Media Object Module:
In the SMIL Boston Language Profile, media object elements can contain the following elements:
Can this be moved to an appendix?
SMIL 1.0 only allowed "anchor" as a child element of a media element. In addition to "anchor", the following elements are now allowed as children of a SMIL media object:
| Elements | Attributes | Minimal Content Model |
|---|---|---|
| ref | TBD | TBD |
| img, text | TBD | TBD |
| audio, video, animation, textstream | TBD | TBD |
This module adds the ref, animation, audio, img, video, text, and textstream elements to the content model of the par, seq, and excl elements of the Timing and Synchronization Module. It also adds these elements to the content model of the body element of the Structure Module. It also adds these elements to the content model of the a element of the Linking 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.
| Elements | Attributes | Minimal Content Model |
|---|---|---|
| meta (TBD) | base, pics-label (or PICS-Label), title, xml:lang, http-equiv, scheme | None |
| metadata | RDF |
This module adds the meta element to the content model of the head element of the 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.
| Elements | Attributes | Minimal Content Model |
|---|---|---|
| smil | Core, Accessibility, xmlns | head?, body?, metadata? |
| head | Core, Accessibility, profile | meta*, ( switch | layout )? |
| body | Core, Accessibility | ( Schedule | MediaContent | MediaControl | LinkAnchor )* |
The Attribute collections in this table are defined as follows
class (NMTOKEN)
title (CDATA)
The collections in the table from the Content Model of the body element are defined as follows
The body element acts as the root element to span the timing tree. The body element has the schedule semantics of a time container equal to that of the "seq" element from the timing and synchronization module. This module is a mandatory part in any profile family labeled "SMIL".
The Timing and Synchronization Module provides a framework for describing timing structure, timing control properties, and temporal relationships between elements. The Timing and Synchronization Module defines semantics for par, seq, and excl elements. In addition, this module defines semantics for attributes including begin, dur, end, repeatCount, repeatDur, etc.
| Elements | Attributes | Minimal Content Model |
|---|---|---|
| par, seq, excl | TBD | TBD |
| begin, end, dur, repeatCount, repeatDur, TBD | TBD |
This module is mandatory in any profile incorporating SMIL modules.
| Elements | Attributes | Minimal Content Model |
|---|---|---|
| TBD | TBD | TBD |
@TBD This module is used, and it adds the TBD element to the content model of the layout element of the Layout Module.
This section is normative.
The SMIL Boston document type is defined as a set of SMIL Boston modules. All SMIL Boston modules are integrated according to the guidelines in the "Modularization of SMIL Boston" specification [SMIL-MOD], and defined within their respective module sections.
This section is normative.
TBD. May instead be an XML Schema.