Responses to SMIL 2.0 Last Call Comments

These are the collected Last Call comments on SMIL 2.0 Last Call WD that were sent to the SMIL mailing list (, and responses to those comments. Comments include:

  1. The XML Namespace Identifier for the SMIL 2.0
  2. Add the "viewportClosedEvent"
  3. Adding the value "tile" to the fit attribute
  4. Why does SMIL Basic have its own XML namespace name?
  5. The content model for override is shown in the DTD
  6. Content Control DTD - ENTITY
  7. DOM comments on the SMIL 2.0 Last Call draft
  8. Oratrix Last Call Layout comments
  9. RealNetworks "Last Call" comments
  10. WAI/SMIL issues
  11. XML Linking WG review of SMIL Last Call Working Draft
  12. How to control content loading dynamically with Timing Attributes
  13. Layout is shown as an EMPTY element in the Layout Module DTD
  14. The transitions draft currently specifies no method that allows to avoid nameclashes for "private" transitions
  15. Synthesized-speech auditory descriptions
  16. Scheduling needs that do not appear to be covered in SMIL 2.0

Issue 1: The XML Namespace Identifier for the SMIL 2.0

Subject: The XML Namespace Identifier for the SMIL 2.0
Modules in 2.3.2 is given to be
but the examples in 13.3.2 make use of .
Which one of these does the SYMM Working Group intends to follow?
Thanks. Pankaj Kamthan

SYMM WG Response:

The "LC" is just to distinguish the last call draft from the final, because the W3C requires that we use different normative URL's for each public released document. The Candidate Rec version will use "CR". The final recommendation will use the URL's without an "LC" or "CR" suffix. []
The discussion and resolution is archived at:

Issue 2: Add the "viewportClosedEvent"

Subject: Currently, there is no way for a SMIL 2.0 player to react to the end user closing a viewport window prior to the media playing within the window finishing its active duration. The layout spec says that the closing of a viewport has no effect on the timing of the presentation. Therefore, if a viewport window is closed early, a means of reacting to this within the SMIL is needed. A solution would be to add the "viewportClosedEvent" that gets raised by the window when it closes, regardless of why it closes.

SYMM WG Response:

We have discussed this and determined that this is indeed an omission, and have added 'viewportOpenEvent' and viewportClosedEvent' to the layout module so that authors can take into account this behavior in their presentations. These event will be added to the SMIL 2.0 language profile as well.
The discussion and resolution is archived at:

Issue 3: Adding the value "tile" to the fit attribute

Subject: If for no better reason than to test the sensitivity of everyone's "no new features" trigger, here's a modest proposal: adding the value "tile" to the fit attribute. This applies when an image is smaller its region in one or both dimensions. When this occurs, a copies of the image are place next to or around it, repeatedly if necessary, in a "tiled" fashion, until the region is filed. This should be easy to implement. It would enable the use of background patterns that are common in HTML documents, but for which there is currently no easy way to encode in SMIL.

SYMM WG Response:

The WG put significant time into this request to define and size its complexity.
The final proposal is archived at:

It was decided that the feature is useful, but it is not of high enough priority and the user demand has not been high enough to add to SMIL 2.0 at this late date. We will definitely consider it for a future version of SMIL.
The discussion and resolution is archived at:

Issue 4: Why does SMIL Basic have its own XML namespace name?

Subject: XHTML Basic[XHTMB] use the XHTML namespace name, but has its own DTD.
Should not a valid SMIL Basic document also be a valid SMIL 2.0 document?
With the solution in the working draft it will not.

SYMM WG Response:

This is an excellent question. Originally we thought that SMIL Basic would have it's own DTD and Schema, and that this would be a starting point for others to define there own profiles. Several people have remarked that SMIL Basic documents should be legal SMIL 2.0 language documents. Some have stated that SMIL Basic is too simple and others said that it is too complex. After discussing this within the group, we agree that it makes the sense to both enable re-purposing of content, and to allow a wide variety of complexity in client implementations. Therefore we have redesigned SMIL Basic to be not a specific language but instead a means of authoring scalable SMIL that will work on user agents with a wide variety of capabilities. SMIL Basic is now an authoring guide describing how to use content control functionality to enable playback scalability, and a set of  conformance guidelines for user agents that implement a subset of smil 2.0 functionality. 

The discussion and resolution is archived at:

Issue 5: The content model for override is shown in the DTD

Subject: The content model for override is shown in the DTD as (allowed |not-allowed) 'not-allowed'.
Shouldn't it be (allowed | not-allowed | uid-only) 'not-allowed', per the text of 4.3.2?

SYMM WG Response:

Your comment is correct. This will be fixed in the next version.

Issue 6: Content Control DTD - ENTITY

Subject: Content Control DTD - ENTITY %customAttributes.content

In the Content Control DTD, the content model for ENTITY
%customAttributes.content is "EMPTY".
Shouldn't it be "(customTest)+" instead?

SYMM WG Response:

Yes, the only content in <customAttributes> are <customTest> elements.
In fact, the SMIL language profile DTD defines the content model correctly, but I agree with you that it makes more sense to do this in the Content Control DTD.
This too will be fixed in the next version.

Issue 7: DOM comments on the SMIL 2.0 Last Call draft

Subject: Two reviewers reviewed this draft on behalf of the DOM WG and we have no comments on it.

SYMM WG Response:

Thank you for your review.

Issue 8: Oratrix Last Call Layout comments

Subject: Based on discussions with designers, we would like:

1- to allow the use of 'height' and 'width' attributes on in-line sub-region positioning (in addition to "bottom" and 'right'). Justification: in placing media objects, people often know the media dimensions of the object being placed. Forcing them to use 'bottom/right' specifications make things unnecessarily complex.

2-  In order to facilitate layout needs, the user should also be able to specify the z-index attribute on in-line sub-region positioning.

In both cases, we feel that leaving these attributes out of the current draft was simply an editorial omission.

SYMM WG Response:

items 1 and 2: These are indeed oversights and do not require any additional semantics or implementation complexity. We will add these in the next public version of the draft. The working group discussion is archived at:

Issue 9:RealNetworks "Last Call" comments

Subject: comments on the SMIL 2.0 Language Profile and one comment on Timing.

SMIL 2.0 Language Profile:

1. "Conforming SMIL 2.0 Documents" vs. "User Agent Conformance"
- The names of these two sections are potentially confusing.
- Suggested titles: "Conforming SMIL 2.0 Documents" and "Conforming SMIL

2.0 User Agents". It may be useful to put these in a single list called "SMIL 2.0 Language Conformance", with these two as major top-level divisions.
- Recommendation: unify outline/numbering of sections

2. "SMIL player" vs. "user agent"
- Both terms are used. We should pick one and use it.

3. "Namespaces in XML [[XML-NS]], we require at least the support for the default namespace declaration. "
- implies that <smil xmlns:foo="" ... > can be rejected by an implementation
- Recommendation: we should remove this clause, and state that full namespace support is required.
- See thread:

4. "Default namespace prefix recognized. If the default namespace is not recognized in its entirety by the player but it includes the prefix "" the document will be processed as if the default namespace declaration were "". This means that the document will be processed as a SMIL 1.0 document, and handle fully namespace qualified extension elements either by recognizing the elements or applying the skip-content rules to the unknown extension elements. Unqualified elements not part of the SMIL 1.0 namespace are illegal and will result in an error."
- Forces an implementation to treat documents as SMIL 1.0 when an error should be issued or the document should be played as some future version of SMIL
- Either strike or change "the document will be" to "the document may be"
- If kept, this item belongs in "User Agent Conformance" section

5. "For an attribute with an unknown attribute value, the player substitutes the default attribute value if any, or ignores the attribute if the attribute has no default value."
- Need to modify to be in line with Resolution 6 from NYC f2f:

"6. RESOLUTION: Add note to profile saying that SMIL language profile errors are strict. This is an action item for SMIL language profile editors."
- Need to replace "unknown attribute value" with "syntactically invalid"

7. " The animation target elements supported in the SMIL 2.0 Profile are the region element defined in the Layout Modules, the area element defined in the Linking Modules and the ref, img, video, text, and textstream defined in the Media Objects modules."
- Typo: animation should be in list of media elements

8. In the Specifying the target attribute of the animation table.
- we should consider adding regionName to the list of Target Attributes for animate and set
- this could be both interesting and useful to authors

9. In Supported Event Symbols, an event to detect when/if buffering occurs during playback would be useful:
- bufferingInEvent, bufferingOutEvent or bufferingStartedEvent, bufferingEndedEvent


10. "Times are expressed in UTC (Coordinated Universal Time)."

- We should add UTC to the glossary: "Universal Time" (abbreviated UT) which is sometimes referred to, now colloquially, as "Greenwich Mean Time" (abbreviated GMT). The two terms are often used loosely to refer to time kept on the Greenwich meridian (longitude zero), five hours ahead of Eastern Standard Time. Times given in UT are almost always given in terms of a 24-hour clock. Thus, 14:42 (often written simply 1442) is 2:42 p.m., and 21:17 (2117) is 9:17 p.m. Sometimes a Z is appended to a time to indicate UT, as in 0935Z.
- or how to convert from timezones

SYMM WG Response:

item 1: Good suggestion. We have incorporated this into the draft.

item 2: Good suggestion. We have chosen to use the term "user agent". Thank you.

item 3: Agreed, full namespace support is now required in the SMIL 2.0 Language.

items 4, 5, and 6: At the November 2000 face2face, the group examined these points and we have revised the smil 2.0 document and user agent conformance sections of the smil 2.0 language profile. The discussion is archived at: . The next draft will incorporate these changes.

item 7: Thanks for catching this typo.

item 8: We discussed animating regionName at the November 2000 face2face and agreed that this should be included. The discussion is archived at: . The next draft will incorporate these changes.

item 9: We discussed buffering events at length during the November 2000 face2face. The group resolution was that this is a worthwhile feature, but the semantics are not obvious and it will take some time and effort to define. The feature is simply too new to put in at this time. We would like to consider adding buffering events to a future version of smil.

item 10: Good suggestion. We have incorporated explanatory text on UTC  into the draft.

Issue 10: WAI/SMIL issues

Subject: a page where I have tried to list all the known WAI/SMIL issues -

Some of them I believe are resolved already, But I haven't yet put in the solution information. I will try to do that over the weekend.

for example I don't think there are outstanding issues with layout beyond the possiblity to describe it (which is part of the general description issue,and in any case seems like a very low priority thing since it could be presented direct by a user agent based on teh layout markup and the titles of things as identifiers for people to read)

SYMM WG Response:

We have reviewed the issues listed on the symm-liaison page during SYMM telecons, at the November 2000 face2face, and during two WAI/SYMM telecons. SYMM and WAI have agreed on resolutions covering the outstanding issues:

We have reviewed the available system test attributes. They do cover the necessary use cases.  See Geoff Freed's email:

SMIL supports multiple simultaneous system languages. The user agent can provide an interface allowing the user to specify this. SYMM requests feedback from WAI for suggestions on how a user agent should implement this.

SYMM and WAI have worked together to produce language stating the implemention requirements for the accesskey feature. See:

SYMM has agreed to include alt/longdesc on every element in the SMIL 2.0 language to improve accessibility. The suggestion was made that SMIL 2.0 include title and desc elements, like in SVG, but it was mutually agreed that the interactions between the attributes and the rest of SMIL 2.0 is too complex to add at this late date. SYMM will closely consider adding accessibility elements to the next version of smil.

The SMIL 2.0 specification defers most user agent accessibility issues to the WAI guidelines. The need to review and pay close attention to the WAI User Agent guidelines now in last call has been established.

Issue 11: XML Linking WG review of SMIL Last Call Working Draft

The XML Linking WG recently reviewed the Last Call version of the SMIL 2.0 specification at ( version was also checked).

Due to the size of the specification, only the parts likely to be related to linking were reviewed, more specifically the Linking Module, the Language Profile and the Basic Language Profile.

First we would like to report our appreciation for your making the namespace declaration required in the Profile. There are, however, three points which would have to be checked or modified in the process of going to Candidate Recommendation and further:

1 - SMIL is not requiring XPointer and is making heavy use of fragment identifiers in URI References to parts of SMIL documents. Hence it must register its own MimeType and not be delivered as text/xml nor application/xml.
It seems that, since this registration is a work in progress, it must be made sure that it has attained a sufficient standard level at the IETF before asking for PR.

2 - The Linking module suffers (as I reported back in March) some namespaces deficiencies:

3 - The status of the use of XML Base is unclear. As explained in the XML Base specification, the deployment strategy for XML Base is by reuse in other XML specifications. Though there is a reference to   it in the Appendix B, it is unclear if it is normative.
There is also no reference to it in the Linking module. We hope you intent to use XML Base and make it clear in the Linking Module.
We thank you in advance for the clarification those changes would make.

SYMM WG Response:

item 1: The SYMM and XML Linking WG members have discussed this issue at length. We agree that restricting the types of XPointers supported to fragments is correct for SMIL user agents processing application/smil content. This restriction does not apply to the processing of other media or to other applications of XML.

item 2 : We have added language to make clear that the linking attributes are part of the SMIL namespace, and not a general xml or xlink namespace. 
a- Changed the line as you suggest to clarify the situation
"These attributes can be applied to linking elements from other namespaces if allowed by the language profile." by
"These attributes pertains to the SMIL namespace but can be applied to linking elements from other namespaces if allowed by the language profile."

b-We will also also fix the examples so that the smil20 namespace is made explicit and obvious.

item 3: We have modified the language to state that the SMIL 2.0 language supports XML Base, and have added supportive text in the linking draft as well.

Issue 12: How to control content loading dynamically with Timing Attributes

Subject: me and my colleague have been reading the latest smil draft version very enthusiastic and are beginning to understand it's full potential. Especially we have evaluated it in couple of real-life usage scenarios to see more clearly, whether it could be usable in our future projects. One thing, however, doesn't come out from the document:

How to control content loading dynamically with Timing Attributes without scripting of any kind (without programming against DOM)? And all of this during playback?

All the examples in the draft are dealing only with static content.
By static content we mean, that the SMIL presentation is always loaded as a whole and then played. There's no "reloading" of anykind during playback.

It seems, that this kind of functionality is not "built-in" in SMIL?
Even though, SMIL is designed to be reusable in the module level (you can create your own markups using these modules), this kind of functionality must definitely be in the SMIL itself.
Here is a couple of examples where we could utilize this kind of behaviour:

1. "Real-time" view of stock exchange (textual or graphical view)
Let's say I want to have a window open on my desktop, which shows the values of the stocks I own. As we all know, "real-time" view for stock value is essential. It should be obvious that I don't want to "refresh" the view myself - it should executed automatically (updating itself while I work).
One solution could be that you add an element called <fetch> (to the Content Control Module), which could be used for "timed loading" of SMIL content.
Something like the following:

<fetch dur="10s" repeatDur="indefinite">
<text id="text1" src="stockvalues.txt"...>

In here a text file "stockvalues.txt" is assumed to be created on the server side. The fetch module reloads it's contents on every 10 seconds.

2. "Real-time" view of Vote Counts in presidential election
This is much like the first example, but now I want to follow some presidential election process in "real-time".

<fetch dur="60s" repeatDur="09:00pm">
<img id="image1" src="progressbar_candidate1.jpg"...>
<img id="image2" src="progressbar_candidate2.jpg"...>

Again, in here we are assuming that the progressbar images are updated regularly on the server side. The fetch module reloads it's contents on every 60 seconds and stops reloading after 9 pm.

Is there some way to do this, that we are not able to see? Is there a way to do this without scripting? If not, we think that this kind of functionality must definitely be supported in the SMIL 2.0. If we want to minimize the need for scripting why not minimize it even further?
Note, that the examples above are just to demonstrate the problem we have been encountering. We are sure that you can come up with much more finer solution.

SYMM WG Response:

These are more authoring questions than comments about the specification. However, we thank you for the opportunity to describe how smil 2.0 supports these use cases. The short answer is that to use the HTTP protocol and cache management to send updated media. See the reply at:

Issue 13: Layout is shown as an EMPTY element in the Layout Module DTD

Subject: Layout is shown as an EMPTY element in the Layout Module DTD, which contradicts the examples in the spec itself.

SYMM WG Response:

Most elements are defined as EMPTY in their module DTDs.
These are just simple default values which are used to keep the module DTDs independent from one another. The actual content model of elements like layout depends on the profile that is in use. For the SMIL language profile this is defined in the file smil-model-1.mod. There the content model of layout is defined as:

<!ENTITY % layout.content "(region|viewport|root-layout|regPoint)*">

The SMIL Basic profile's layout content model, however, is defined in smilbasic-model-1.mod as:

<!ENTITY % layout.content "(root-layout?,(region)*)">

Issue 14: The transitions draft currently specifies no method that allows to avoid nameclashes for "private" transistions

Subject: The transitions draft currently specifies no method  that allows to avoid nameclashes for "private" transistions:

In other words, two implementations can use the same name for a new transition, but they would result in completely different transitions.
This can be resolved by using a namespace-based solution, which is already used for events

SYMM WG Response:

The SYMM WG discussed this at the November 200 face2face and agreed. We will avoid nameclashes on extension transitions using the name namespace prefix qualification mechanism as we have already specified for events. See the minutes in the face2face discussion at This will appear in the next version of the draft.

Issue 15: Synthesized-speech auditory descriptions

Subject: My questions concern the use of SMIL for developing auditory descriptions for multimedia presentations.

The Web Content Accessibility Guidelines (WCAG) version 1.0 of W3C/WAI indicates the possibility of using speech synthesis for providing auditory descriptions for multimedia presentations. Specifically, checkpoint 1.3 of WCAG 1.0 reads:

"1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. [Priority 1] Synchronize the auditory description with the audio track as per checkpoint

1.4. Refer to checkpoint 1.1 for information about textual equivalents for visual information." (WCAG 1.0, checkpoint 1.3).

In the same document in the definition of "Equivalent", we read:

"One example of a non-text equivalent is an auditory description of the key visual elements of a presentation. The description is either a prerecorded human voice or a synthesized voice (recorded or generated on the fly). The auditory description is synchronized with the audio track of the presentation, usually during natural pauses in the audio track. Auditory descriptions include information about actions, body language, graphics, and scene changes."

My questions are as follows:

1. Does SMIL 2.0 support the development of synthesized speech auditory descriptions?

2. If the answer to question #1 is "Yes", then briefly describe the support that is provided.

3. If the answer to question #1 is "No", then please describe any plans for providing such support in the future.

Thanks very much for your consideration.

SYMM WG Response:

We had a detailed discussion of this on the mailing list. In summary, SMIL 2.0 supports synthesized speech as media, and it also allows a user agent to provide synthesized speech for rendering including rendering of the accessibility attributes such as alt/longdesc. The smil 2.0 test attributes support selecting content based on the standard accessibility preference and also based on author specified selection criteria. 

The point was made however, that there is a need for a standard location for synthesized speech text to provide maximum accessibility at minimal author effort. It was agreed that this is a general topic of interest for XML languages and is not specific to smil, and that the WAI group will consider what  feature would be of general utility and provide feature requests to SYMM for a future version of smil.

It was agreed that the support in SMIL 2.0 is the current state of the art, and that future work will need to be done to specify what more support is needed.

A detailed email thread discussing this issue can be found at:

Issue 16: 2 scheduling needs that do not appear to be covered in SMIL 2.0

Subject: We have 2 scheduling needs that do not appear to be covered in SMIL 2.0

Can anyone explain how to accomplish these requirements within the SMIL 2.0 specification?

1) Our Scheduling Module creates many different SMIL schedule documents for our "Player" that are active throughout a month. Due to a high volume and complex business requirements, it is not feasible to combine all of the different SMIL schedules created for a month into one SMIL schedule.

How can we indicate the active date range and timeframe of each SMIL document?

For example, SMIL schedule document #1 is active from 11/1 - 11/30, with a daily active timeframe

of 8:00 AM - 10:00 AM. Schedule #2 is active from 11/1 - 11/15, with a daily active timeframe of 5:00 PM - 10:00 PM. Schedule #3 is active from 11/5 - 11/5, with a daily active timeframe of   10:00 AM - 12:00 PM.

2) Our Scheduling Module needs the ability to schedule a sequence of media elements and indicate the active timeframe of each element. Is this possible in SMIL?

For example, in the element sequence below, we need the ability to indicate that sm5v.jpg should only be played during 11/5 - 11/6.

<img id="Logo" region="Image-1" src="Assets/euro/euro52x51.gif" dur="5s"/>
<img id="Five" region="Image-1" src="Assets/euro/sm5v.jpg" dur="10s"/>
<img id="Ten" region="Image-3" src="Assets/euro/sm10v.jpg" dur="10s"/>

SYMM WG Response:

Thank you for a very interesting question!  SMIL 2.0 supports wallclock begin times that provide support for this kind of thing. However, getting the expected behavior is more complicated and involves use of other language features such as beginEvent and max to provide the correct sync and additional constraints. The working group produced an example that implements the requested behavior, see:

We agree that this may not be intuitive to new smil authors. We suggest that you gain experience with wallclock and other supporting features and then provide SYMM  with feature requests for additional desired support.

By: Aaron COHEN ( ) and Thierry MICHEL (