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 [Status: Request approved]
  2. Add the "viewportClosedEvent" [Status: Request approved]
  3. Adding the value "tile" to the fit attribute [Status: Question answered/agreed by Requestor]
  4. Why does SMIL Basic have its own XML namespace name? [Status: Request approved]
  5. The content model for override is shown in the DTD [Status: Request approved/agreed by Requestor]
  6. Content Control DTD - ENTITY [Status: Request approved/agreed by Requestor]
  7. DOM comments on the SMIL 2.0 Last Call draft [Status: Request approved]
  8. Oratrix Last Call Layout comments [Status: Request approved]
  9. RealNetworks "Last Call" comments [Status: Request approved]
  10. WAI/SMIL issues [Status: Request approved]
  11. XML Linking WG review of SMIL Last Call Working Draft [Status: Request approved/agreed by Requestor]
  12. How to control content loading dynamically with Timing Attributes [Status: Question answered, no reaction from Requestor]
  13. Layout is shown as an EMPTY element in the Layout Module DTD [Status: Request approved/agreed by Requestor]
  14. The transitions draft currently specifies no method that allows to avoid nameclashes for "private" transitions [Status: Request approved]
  15. Synthesized-speech auditory descriptions [Status: Request approved]
  16. Scheduling needs that do not appear to be covered in SMIL 2.0 [Status: Request approved/agreed by Requestor]
  17. Last call comments HTML WG [Status: Request approved/agreed by Requestor]
  18. Viewport issues [Status: Request approved/agreed by Requestor]

Notification of these Last Call responses was sent to all of the commentors and the SYMM list:

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 (including Lloyd's acceptance of the 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. 

In short, suggestion accepted, now SMIL 2.0 and "SMIL Basic" have the same namespace.

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.

Michael found his comments adequately addressed:

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.

Michael found his comments adequately addressed:

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 (and Dick's agreement) 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 possibility 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 the 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.

Additionally, the SYMM Working Group has agreed to work with WAI on two topics of mutual interest, separate from the process of the SMIL 2.0 advancing forward to Recommendation. First, the SYMM WG will provide feedback to WAI on a method of WAI's design to enhance the functionality and flexibility of system test and custom test attributes using metadata. The SYMM WG also will work with them on finding implementers to produce trial implementations of this method.

Second, the SYMM Working Group will work in parallel with WAI to produce a combined set of multimedia authoring/presentation and accessibility requirements for a general and reusable timed text format. After assembling and discussing the requirements, we will mutually decide on appropriate next steps.

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.

These responses have been found acceptable by Eve and Daniel:

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: . We do not have record of a further response from Max.

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)*)">

Michael found his comments adequately addressed:

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.

However, the problem has been found to be sufficiently important that the SYMM and WAI groups have agreed to work together to further define the problem and to determine an appropriate course of action. Please see the response to the WAI comments listed as WAI/SMIL issues.

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.

Jeff agreed to pursue the solutions that we discussed on the mailing list:

Issue 17: Last call comments HTML WG

Subject: Last call comments HTML WG

Apologies for the slight delay in these notes.

1- Comment regarding Section 2.5 item 2; "SMIL supports module level INCLUDE/IGNORE instead of XHTML's element/attlist level. This prohibits profiles from importing only part of a module -- they have to support either all the elements and attributes or none."
Since XHTML also prohibits importing only part of a module, we think this comment is misleading and would like it removed.

2- Comment regarding media types: for interoperability we strongly urge a minimal list of required media types, with at least one per media type. We strongly urge the use of xhtml for text.

3- Comment regarding namespaces in attribute values: Xlink had this and dropped them after last call as a response to last call comments. The Namespaces REC does not mention this usage; please ensure community consensus in this usage before going to CR.

Best wishes, Steven Pemberton

SYMM WG Response:

First issue: You are right. I'll change the language to remove the mistaken implication.
How about: SMIL supports module level INCLUDE/IGNORE instead of XHTML's element/attlist level. Similar to XHTML, this prohibits profiles from importing only part of a module -- they have to support either all the elements and attributes or none.

Second issue: Philipp pointed out that I missed your comment on requiring XHTML as a supported media type (thanks Philipp). Philipp suggested this at our Grenoble face2face, and after some discussion, the group rejected the idea as too heavy a requirement, especially for "smil basic" type players. Also note that there is signifant interest in the W3C (WAI, SYMM) for a light weight timed text format. At some future date, it may make sense to require such a format in smil.
From the Grenoble face2face minutes at:
In general, agreeing on a required set of media types is difficult or impossible, as people have a very wide range of uses in mind. Even the few types that we have are only "should" not "must". AFAIK, XHTML does not have this either, and I suspect for the same reasons.

RESOLUTION: SMIL Boston language profile will include section on recommended baseline media formats including audio/basic, img/png, and img/jpeg. No text and no video formats.

Third issue: We've gone around this quite a bit. The use of namespaces in attribute values is confined to event names and transition names, and the colon is specifically reserved in these attribute values to be used to support an open extension mechanism using namespaces.
XML Schemas also uses namespace prefixed attribute values as a core part of the technology, so it seems that it's now okay.

I hope that this is sufficent to close these issues. Please let me know. -Aaron

Steven has accepted our comments, with one point where we agree that we'd both like something that we cannot have:

Issue 18:Viewport issues

Subject: Viewport issues

A. Discussed "placeholder" elements and viewports at UI-Tech telecon. CSS and XSL promise to spend some cycles on this and approve or suggest changes by next Monday's Hypertext Coordination Group meeting.

B. Viewport issues

1. Open/close may have conflicting semantics. We need to decide and make some language changes in the draft.

2. The term "viewport" was discussed at at UI-Tech telecon. It probably conflicts with some conceptual terms in XSL.

SYMM WG Response:

The SYMM WG discussed this and agreed to update the specification by changing:
1- the viewport open/close attribute values from open="always" to open="onStart" and close from "never" to "onRequest".
2- "viewport" to "topLayout" element.
Note that this resulted in also renaming the viewportOpenEvent to topLayoutOpenEvent and viewportCloseEvent to topLayoutCloseEvent.

By: Aaron COHEN ( ) and Thierry MICHEL (

Last Updated:$Date: 2001/01/24 14:17:21 $