Liaison Statement

Title:	Liaison to W3C Re SMIL 2.1	Public       Confidential LS[1]
To:	W3C SMIL Working Group
Copy:	Philipp Hoschka
Response to:
Source:	Mobile Application Environment Group of the Open Mobile Alliance
Send Replies to:	OMA BAC-MAE
Contact(s):	A J Angwin angwin@uk.ibm.com
Attachments:	n/a

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.