Re: Liaison Statement to W3C (SC 29 N 13268)

+Paul Cotton
+Liaisons

We need to send a reply to the MPEG MMT liaison letter of Feb 19. I suggest we reply in a similar way to the reply sent recently to OIPF/HbbTV/DTG, where we directed the discussion to our mail lists and bug tracking system. I have a draft below.

(FYI, the MMT group published an updated version of their spec for balloting, which is posted publicly here:
http://www.itscj.ipsj.or.jp/sc29/open/29view/29n13303c.htm
Just go to the "CD ballot text" link at the bottom of the webpage to download the latest MMT spec.)

Here is a first draft, largely copied from the previous reply:

"To Shinji Watanabe, Assistant Secretary, ISO/IEC JTC 1/SC 29

The Web and TV Interest Group of the W3C reviewed your liaison letter of February 19. Overall, we believe both use cases can be met addressed by HTML5 and related specifications. However, the use case as described in the liaison letter were not in sufficient detail to answer all technical questions raised in our review. We suggest that a more effective interactive dialog can happen through use of our mailing lists and bug tracking system.

The W3C is always interested and open to discuss requirements from other organizations and/or individuals. This is done through public mailing lists. For the issues you raise concerning HTML5, we encourage you to post the use cases or perceived functionality gaps to public-html.w3.org<http://public-html.w3.org> <public-html@w3.org>, which will initiate a dialog on these issues in a richer and more timely manner than with liaison letters.

If you have specific comments on the existing specifications, you can also use the public bugzilla list to raise issues against the HTML5 spec:
https://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG   ****Not sure this is the best link ***

Finally, if you believe that you would benefit from some more discussion with other stakeholders in the media industry before submitting a proposal/comment to the HTML WG, you could also consider participating in a dialog with the Web&TV IG public list first, by posting to:
public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>

Also note that the HTML WG has recently defined a concept of "extensions specifications". This is explained in more details here

http://dev.w3.org/html5/decision-policy/html5-2014-plan.html

In short, extension specifications are allowed to "extend" HTML5 spec and at the same time to proceed at their own pace and being integrated into the main spec (HTML 5.x) as soon as they are ready, without affecting the timeline of the other extensions or of the main specification.

Best regards,
Mark Vickers on behalf of the W3C Web&TV IG, or (better) someone from the W3C Liaisons group"

Thanks,
mav


On Feb 21, 2013, at 4:04 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

On Thu, Feb 21, 2013 at 7:55 PM, Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr<mailto:jean-claude.dufourd@telecom-paristech.fr>> wrote:
Le 21/2/13 04:58 , Silvia Pfeiffer a écrit :
On Thu, Feb 21, 2013 at 8:37 AM, Bob Lund <B.Lund@cablelabs.com<mailto:B.Lund@cablelabs.com>> wrote:
1.     The ability to accurately time the playback of different media elements (for instance using wall clock time) in the document in a declarative manner, i.e. without reverting to scripting in a way similar to SMIL. MMT does not require a scripting engine.
I'm not sure why scripting is optional in MMT. Can someone familiar with SMIL describe what declarative form they're looking for here?


SMIL allows wallcock time synchronization through using wallclock times in @begin and @end attributes [1] within <par> and <seq> markup. It requires that the document "start" time has to be associated with a wallclock time and thus allows the mapping.
JCD: Yes, that is what they mean when writing about SMIL.



The closest effort to this at the W3C FAIK is the Web Animations work [2] which is planning to introduce a document timeline [3]. It's still in its early stages, so no browser implementation. Also, I don't know if it will satisfy the "declarative markup" requirement, because it only introduces a JS API for now. But it's probably well worth pointing out this effort to MPEG.

[1] http://www.w3.org/TR/2005/REC-SMIL2-20050107/smil-timing.html#Timing-WallclockSyncValueSyntax
[2] https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/index.html
[3] https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/index.html#the-document-timeline

--

Overall, I do wonder about what MMT has to do with these application-level requirements. IIUC MMT is about delivering packed media, so it's an enabler of applications. It should not need to look at HTML & the JS APIs for defining its specifications.
JCD: We have told the MMT group over and over that they are mixing layers, that their MMT architecture is a mess, etc.
I have personally fought against this particular part of MMT, called Composition Information, for 2 years.
Most of the people involved in the design of DASH have said the same.
It seems the W3C liaison still did not help.

Fair enough. :-)

Silvia.