Responses to SMIL 2.1 Last Call Comments

This is the Disposition of Comments document collecting Last Call comments on SMIL 2.1 Last Call WD which were sent to the SMIL mailing list (www-smil@w3.org), and responses to those comments.

A reminder for LC Review was sent to the www-smil and Chairs list.

Public Comments include:

1. SMIL21: References [Status: Comment answered / no reaction from Requestor]
2. References to SMIL 2.1 in SVG 1.2 [Status: Comment answered / no reaction from Requestor]
3. SMIL 2.1 WD Overviews [Status: Request approved / agreed by Requestor]
4. It's OK for SVG to override the definition of the default eventbase element [Status: Request approved / agreed by Requestor]
5. Liaison to W3C Re SMIL 2.1 [Status: Comment answered / no reaction from Requestor]
6. SMIL 2.1 LC comment [Status: Comment answered / no reaction from Requestor]

Notification of these Last Call responses was sent to all of the commentors and the SMIL list: http://lists.w3.org/Archives/Public/www-smil/2005JanMar/author.html

---

Issue 1: SMIL21: References

• From: Bjoern Hoehrmann <derhoermi@gmx.net>
• Sent: Wed, 02 Feb 2005 12:39:48 +0100
• Archived: http://lists.w3.org/Archives/Public/www-smil/2005JanMar/0004.html

Comment:

Dear Synchronized Multimedia Working Group,

http://www.w3.org/TR/2005/WD-SMIL2-20050201/refs.html is a horrible mess; at least 12 references are outdated (e.g., MathML, RFC1766, UAAG, URI, UTF8, XFORMS, XHTML10, XHTML+SMIL, XML10, XSCHEMA, XPTR, and draft-ietf-avt-rtp-mime-00), it does not distinguish between normative and informative references, it sometimes gets URI policies wrong (e.g., http://www.w3.org/TR/SVG/ is the latest SVG Rec, not the latest version of SVG 1.1) and is generally inconsistent with other technical reports, many of which comply with http://www.w3.org/2001/06/manual/#ref-section. The section further has character encoding issues, e.g., it's "Håkon" rather than "HÃ¥kon".

http://www.w3.org/TR/2005/REC-SMIL2-20050107/refs.html seems to be subject to most of these problems too (and claims to be part of a PER rather than a Recommendation...), please change the Working Draft to include reasonable references and publish normative corrections to the corresponding section in SMIL 2.0.

The references checker http://www.w3.org/2004/07/references-checker-ui will help you to spot outdated references.

regards.

Björn Höhrmann

Issue 2: References to SMIL 2.1 in SVG 1.2

• From: Bjoern Hoehrmann <derhoermi@gmx.net>
• Sent: Thu, 10 Feb 2005 19:26:31 +0100
• Archived: http://lists.w3.org/Archives/Public/www-smil/2005JanMar/0007.html

Comment:

Dear Scalable Vector Graphics Working Group, Dear Synchronized Multimedia Working Group,

Dear W3C Communications Team,

I've already expressed my opposition [1] against the versioning requirements imposed by W3C's publication rules [2] and on how W3C manages the Technical Report URL space [3] and it seems SMIL 2.1 provides an opportunity to repeat parts of the argument. E.g.,

http://www.w3.org/TR/2004/WD-SVG12-20041027/animation.html
refers to SMIL 2.0
e.g. using http://www.w3.org/TR/smil20/smil-transitions.html

which now redirects to

http://www.w3.org/TR/SMIL2/smil-transitions.html

which is not the SMIL 2.0 Recommendation but rather the SMIL 2.1 Working Draft. Obviously such a policy change comes unexpected and introduces all sorts of confusion. In particular because

SMIL 2.1 states

If this specification is approved as a W3C Recommendation, it will supersede the 07 January 2005 version of the SMIL 2.0 Recommendation (Second Edition) [SMIL20]. The term "supersede" is not defined in the Process document and there does not seem to be a reasonable interpretation for it... The Process document should be updated to include a definition for this term if W3C intends to continue using it outside of the well-understood SotD note.

There is further no reasonable way to replace the links to SMIL 2.0 in the SVG 1.2 Working Draft, it would have to use the "dated" URLs which refer to SMIL 2.0 Second Edition. That's not a very useful reference should there ever be a SMIL 2.0 Third Edition.

The idea behind linking to the "latest" version is exactly that there is no confusion about the status of the reference if the referenced document gets updated and to aid readers who prefer to read the latest normative text than old, incorrect text plus the errata (should they remember to look into it).

I thus request, again, that the publication rules are changed such that they do not contradict W3C's publication practise and that (consequently, as that would mean that revised editions of a specification do not get new version numbers) each Technical Report's latest edition be made referencable through a URL, for example, SMIL 2.1 should be at http://www.w3.org/TR/smil21/ not <http://www.w3.org/TR/SMIL2/>.

I would further like to request, though that's of much less con-cern to me, that no "latest foo version" URLs are published, I think http://www.w3.org/TR/soap/ and http://www.w3.org/TR/html/ have already caused sufficient confusion and there is very little use to link to such documents, in particular, if there is no consistent maintenance for such documents, the "soap" and "html" documents here are quite different indeed.

The SVG 1.2 Working Draft should be updated to refer to the right version of the document (one that actually includes the text that is referred to and/or corresponds to the version the document cites; ideally both, of course, but I'll address "changes-only documents" separately).

[1] http://lists.w3.org/Archives/Member/w3c-archive/2004Aug/thread.html#12

[2] http://www.w3.org/2004/02/02-pubrules.html#head

[3] http://lists.w3.org/Archives/Public/site-comments/2004Mar/thread.html#21

Thanks,
--
Björn Höhrmann · mailto:bjBjörn Höhrmann

Issue 3 SMIL 2.1 WD Overviews

• From: Jose Ramirez <joseram@empirenet.com>
• Date: Wed, 16 Feb 2005 08:35:10 -0800
• Archived: http://lists.w3.org/Archives/Public/www-smil/2005JanMar/0014.html

Comment:

Hello,

Great to see SMIL progressing :)
I put together some overviews of the latest SMIL 2.1 WD, to make it easier to follow along.

http://www.geocities.com/ramirez_j2001/smil21wd/index.htm

Good Luck,

Jose Ramirez

Issue 4: It's OK for SVG to override the definition of the default eventbase element

• From: Patrick Schmitz <cogit@ludicrum.org>
• Date: Thu, 10 Feb 2005 15:11:20 -0800
• Archived: http://lists.w3.org/Archives/Member/symm/2005Feb/0035.html

Comment:

Note that in the referenced section, the reference to SMIL ANIMATION is not a link. Furthermore, in SMIL 2.0 animation there is no mention of the eventbase.
In SMIL Animation, the default eventbase for animation elements was the animation target. In SMIL 2.0 this was lost somehow. This should be fixed in 2.1, IMO.

Patrick

Issue 5: Liaison to W3C Re SMIL 2.1 (Mobile Application Environment Group of the Open Mobile Alliance)

• From: angwin@uk.ibm.com (OMA BAC-MAE)
• Sent: mer. 23/02/2005 15:49
• Archived: http://lists.w3.org/Archives/Public/www-smil/2005JanMar/0015.html

Comment:

1 Overview

OMA's Mobile Application Environment (MAE) group, a subgroup of the Browsing and Content Working Group (BAC), has requested its members to review the SMIL V2.1 draft in last call with a view to consolidating and reaching consensus on those comments.

However for reasons of timing and to ensure the comments are received by the W3C as quickly as possible the two comments received from members of MAE are being forwarded to you as is.

2 Proposal

During a requested review of the latest draft under Last Call, i.e. http://www.w3.org/TR/2005/WD-SMIL2-20050201/, two MAE members commented. These comments are provided as is to the W3C’s SMIL WG:

a) section 14.3.4 "Content Control Modules"

this section defines semantics for the prefetch element which is believed to be used to retrieve content from a server.
If this is the case and this profile is used for MMS this means that the SMIL presentation does not only refer to content included in the downloaded multipart of the MMS message but also to content on the network. This means a rather big extension to the MMS client application as it has to have "browser like" functionality by retrieving content from the network.

Clarification as to intent is requested so we can assess the significance of this change.

<this comment from Obigo>

b) Section 7.3 SMIL Basic Media Module:

This section was the subject of previous comments.

All of these media elements are semantically identical. When playing back a media object, the player must not derive the exact type of the media object from the name of the media object element. Instead, it must rely solely on other sources about the type, such as type information contained in the type attribute, or the type information communicated by a server or the operating system.

Authors, however, should make sure that the group into which of the media object falls (animation, audio, img, video, text or textstream) is reflected in the element name. This is in order to increase the readability of the SMIL document. When in doubt about the group of a media object, authors should use the generic "ref" element.

The problem we see is that an <audio> element, pointing at a video or SVG stream, should play that stream as if the <audio> was really a <video> or <animation> element respectively. Any basic media element pointing to a stream of a different type is supposed to play it. We find this very confusing, and implementations cannot use specialized objects dedicated to one media type only to implement the playing of that media type, they have to use a generic, more complex object. There are also issues about single media control, such as playing only the video in an audio+video package.

We suggest to remove those two paragraphs, or at least to lessen the implementation constraint by allowing implementations to have specialized objects to play each media type, in the spirit of:

- the <audio> element shall be able to play a audio stream, and may be able to play other types of streams
- same for animation, img and video

Our request is inline with the recommendation 4.1.2 in SMIL 2.0 Extension for Professional Multimedia Authoring
http://www.w3.org/TR/2003/NOTE-SMIL2-AuthExt-20030512/#L838

For the <video> element, it may however be adequate extend the functionality in this way:
- the <video> element shall be able to play a video stream, shall be able to play a video stream and an audio stream when they are packaged together, and may be able to play other types of streams.

The above was suggested to us when discussing the fact that the vast majority of existing Web content uses this playing of a video and an audio streams within the same SMIL element.

<this comment from Streamezzo>

3 Requested Action(s)

OMA MAE requests the W3C SMIL WG to consider the points raised in the above proposal as it determines the final specification for SMIL 2.1
Should W3C SMIL WG wish to ask questions or enter into further dialogue regarding the points raised OMA MAE would be more than happy to do assist.

4 Conclusion

OMA MAE wishes to thank the W3C SMIL WG in anticipation of its consideration of the points raised within this liaison.

Issue 6: SMIL 2.1 LC comment

• From: Karl Dubost <karl@w3.org>
• Date: Mon, 7 Mar 2005 14:53:09 -0500
• Archived: http://lists.w3.org/Archives/Public/www-smil/2005JanMar/0027.html

Comment:

Dear SMIL WG,

Sorry for the belated comments, and if you can't take into account, I will understand. (I was sick the whole last two weeks).

I would like that you reconsider the publication of SMIL 2.1 diff specification. I had tried to make a QA review of the specification but it's almost impossible given the organization of the document. Basically the document has a very strong usability issue which makes very difficult if not impossible to define the conformance model.

These are a few comments.

* how a partial spec (SMIL 2.1) can supersede a full spec SMIL 2.0

* how to manage the errata section of parts which are still in a supersed specification SMIL 2.0

* how to implement a superseded specification SMIL 2.0

* what does that mean a normative reference to a superseded specification SMIL 2.0

* The Spec SMIL 2.1 has an awful usability

If the document is still published as a diff document, I would like to see a clear analysis of the Conformance Model of SMIL 2.1.

I recommend you to read Specification Guidelines that should help you to define a better specification.

http://www.w3.org/TR/qaframe-spec/

Sorry for these negative comments. :/ I would have preferred to be more positive.

Best Regards
--

Karl Dubost - http://www.w3.org/People/karl/

W3C Conformance Manager

Thierry MICHEL (tmichel@w3.org)

Last Updated:$Date: 2005/05/13 13:40:27 $