- From: Andreas Tai <tai@irt.de>
- Date: Sun, 19 Oct 2014 16:15:39 +0200
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- CC: Public TTWG List <public-tt@w3.org>, Glenn Adams <glenn@skynav.com>, Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Message-ID: <5443C78B.5030504@irt.de>
Hi Silvia, Thanks for asking! The use case for the specs in question is less to extend but to restrict TTML. I don't think that this requirement is a design error of TTML but on the contrary a proof for it`s rich "vocabulary" that can be applied to many different use case scenarios. It is a given that some organisations and companies decided to subset TTML and customize it for their scenario. The leading idea was often to ease the way for implementations that are build for these scenarios. The extensions that have been made in this context are very, very limited. In general I think that it is a more realistic standardisation scenario where the coverage of specific scenarios is done by organisation who are closest to these scenarios. This seems more efficient. On the other hand it is important to align the activities with the work of the TTWG. I think this happened so far and worked quite well. Best regards, Andreas Am 19.10.2014 um 01:23 schrieb Silvia Pfeiffer: > > If you're extending ttml, why not do that through this WG here? > > Just a thought... > Back to lurking. > > Regards, > Silvia. > > On 18 Oct 2014 21:59, "Andreas Tai" <tai@irt.de <mailto:tai@irt.de>> > wrote: > > Understood. One question: A specification that builds on TTML and > but has not a normative list of TTML features and extensions is > not a TTML profile, correct? > > Best regards, > > Andreas > > Am 17.10.2014 um 18:53 schrieb Glenn Adams: >> I'm afraid I will have to object to the notion of creating a >> thing called a TTML "dialect" that is not describable as a TTML >> "profile". We definitely *do not* need an alternative >> characterization of TTML processor requirements or content >> constraints. >> >> On Fri, Oct 17, 2014 at 8:23 AM, Andreas Tai <tai@irt.de >> <mailto:tai@irt.de>> wrote: >> >> Hi Cyril, >> >> Thanks for the quick feedback! See some comment inline. >> >> Am 17.10.2014 um 15:32 schrieb Cyril Concolato: >> >> Hi Andreas, >> >> Le 17/10/2014 14:33, Andreas Tai a écrit : >> >> As I understand the main intent of this communication >> is to define the responsibilities of the MPEG and >> TTWG for the signalling of "TTML document dialects" >> in an MP4 container. There seems an agreement to use >> the MPEG codecs parameter where MPEG has the task to >> define a prefix and TTWG to define suffix. >> >> How the W3C/TTWG defines that suffix is not of core >> interest for the MPEG group (as long the general >> syntax for codecs parameter is followed). I highlight >> this because my following comment may not stop this >> letter because the "Suffix" definition is not decided >> yet and in the responsibility of the TTWG. >> >> Regarding the proposed solution in the liaison letter >> (and in this thread) more discussion seems to be >> needed. From my current review it may not be >> applicable for all "TTML dialects". Some "dialects", >> like EBU-TT-D, do not rely on the defined semantics >> of TTML profiles. Therefore I do not think that it is >> a good idea to make "TTML profiles" as a central >> concept for the codecs registry for "TTML dialects". >> >> The idea would be that EBU-TT-D would be registered and >> have a short name to be used as a dialect in the >> processorProfiles parameter. >> >> In general this would meet an important requirement from >> decoder implementers. >> >> EBU-TT-D may not "rely on the defined semantics of TTML >> profiles" but it can be viewed as a "dialect" of TTML. Is >> that clearer? >> >> >> I think that the general pattern is a adequate solution. The >> problem I see is with the definition what is meant by a >> processor profile. A processor profile has defined semantics. >> It reference the TTML profile mechanism. This mechanism is a >> formally well-thought-out concept. But it is not used >> consistently or not used by some TTML dialects. As well it >> has not been fully understood by some implementers. Therefore >> it would be good to have the (additional) possibility to just >> reference the specification of the "TTML dialect" without >> using the profile semantics. >> >> Maybe the terms profiles or processorProfiles are >> misleading, I don't know. >> >> In the current registry proposal (and in the TTML2) draft >> "processor profile" has defined semantics. I think it was >> chosen on purpose (although I do not agree that this is the >> best solution). >> >> | Maybe we should talk about dialects to cover not just >> profiles of TTML but extensions too. >> >> I think the use of an alternative term would be a good idea >> because "profile" has a link to the semantic concept of TTML >> profiles and often this linkage is not intended. >> >> Best regards, >> >> Andreas >> >> >> >> Cyril >> >> >> Best regards, >> >> Andreas >> >> Am 17.10.2014 um 00:16 schrieb Michael Dolan: >> >> Take 2 on the communication to MPEG - attached. >> Over to Dave (really this >> time). >> >> -----Original Message----- >> From: Michael Dolan [mailto:mdolan@newtbt.com >> <mailto:mdolan@newtbt.com>] >> Sent: Thursday, October 16, 2014 1:35 PM >> To: 'Timed Text Working Group' >> Subject: RE: proposed updated response to MPEG on >> codecs >> >> That would be the proper thing to do. >> >> -----Original Message----- >> From: David Singer [mailto:singer@apple.com >> <mailto:singer@apple.com>] >> Sent: Thursday, October 16, 2014 1:07 PM >> To: Glenn Adams >> Cc: Michael Dolan; Timed Text Working Group >> Subject: Re: proposed updated response to MPEG on >> codecs >> >> Seems that way >> >> On Oct 16, 2014, at 12:57 , Glenn Adams >> <glenn@skynav.com <mailto:glenn@skynav.com>> wrote: >> >> we could always define this new MIME media >> type parameter in TTML2, >> but >> >> wouldn't we need to update the current registration? >> >> On Thu, Oct 16, 2014 at 1:01 PM, David >> (Standards) Singer >> >> <singer@apple.com <mailto:singer@apple.com>> wrote: >> >> On Oct 16, 2014, at 10:22 , Michael Dolan >> <mdolan@newtbt.com >> <mailto:mdolan@newtbt.com>> wrote: >> >> I cannot support defining a formal media >> type string (including any >> of >> >> its parameters) on an informal wiki. This is >> highly irregular. >> >> agreed. I think that MPEG should say "the >> mime type the contents >> would >> >> have if in a separate file goes here, with any >> optional parameters" and stop >> at that. >> >> So, MPEG doesn't care how irregular we are, >> but we should not be >> >> irregular, of course. >> >> I believe its general syntax and >> semantics must be normatively >> defined >> >> in TTML2 as part of the media type (and >> preferably in my view) then >> registered with IANA (not the other way around >> either). >> >> yup >> >> Mike >> >> From: Nigel Megitt >> [mailto:nigel.megitt@bbc.co.uk >> <mailto:nigel.megitt@bbc.co.uk>] >> Sent: Thursday, October 16, 2014 9:23 AM >> To: Michael Dolan >> Cc: Timed Text Working Group >> Subject: Re: proposed updated response to >> MPEG on codecs >> >> >> >> >> On 16 Oct 2014, at 16:52, Michael Dolan >> <mdolan@newtbt.com >> <mailto:mdolan@newtbt.com>> wrote: >> >> Thanks for fixes. I assume Dave will >> update before posting. >> >> As for the your second point, I am not >> sure that I follow. We must >> >> define the new media type parameter formally in >> TTML2 or our decisions and >> this communication are meaningless. Is your >> point that we did not agree as >> a group to register the update with IANA? I >> agree, but I also did not say >> that to MPEG (although I personally think we should). >> >> >> I was expecting the MIME type parameter >> to be external to TTML2 and >> >> defined on the registry page. I'm not against >> updating the IANA registration >> if that's useful but we haven't decided to do >> that. If we do, then clearly >> the relevant part of the TTML 2 spec would need >> updating to match. If we >> don't, then there may be no changes resulting, in >> TTML2. >> >> Since there may therefore be no change in >> TTML 2 I don't want to >> give >> >> the wrong impression. >> >> Nigel >> >> >> >> Mike >> >> From: Nigel Megitt >> [mailto:nigel.megitt@bbc.co.uk >> <mailto:nigel.megitt@bbc.co.uk>] >> Sent: Thursday, October 16, 2014 8:39 AM >> To: Michael Dolan; 'Timed Text Working Group' >> Subject: Re: proposed updated response to >> MPEG on codecs >> >> Thanks for the quick turnaround Mike. 3 >> things: >> >> typo: s/medaType/mediaType >> correction: s/procProfile/processorProfiles >> >> Query: do we want the sentence "Its >> parameters will be extended in >> TTML2 >> >> to include the proposed syntax above." ? Unless >> we're changing the IANA >> registration then I do not think we have agreed >> to do this. >> >> Kind regards, >> >> Nigel >> >> >> From: Michael Dolan <mdolan@newtbt.com >> <mailto:mdolan@newtbt.com>> >> Date: Thursday, 16 October 2014 16:29 >> To: 'Timed Text Working Group' >> <public-tt@w3.org <mailto:public-tt@w3.org>> >> Subject: proposed updated response to >> MPEG on codecs >> Resent-From: <public-tt@w3.org >> <mailto:public-tt@w3.org>> >> Resent-Date: Thursday, 16 October 2014 16:30 >> >> Per my action item from today, please see >> the attached. >> >> Over to Dave and Nigel for review to see >> if I captured where we >> ended up >> >> in today's call; then over to Dave to upload to >> MPEG (or I can if needed). >> >> Time is very short and should be posted >> Sunday morning CEDT. >> >> Regards, >> >> Mike >> >> Michael A DOLAN >> TBT, Inc. PO Box 190 >> Del Mar, CA 92014 >> (m) +1-858-882-7497 <tel:%2B1-858-882-7497> >> mdolan@newtbt.com <mailto:mdolan@newtbt.com> >> >> David Singer >> Manager, Software Standards, Apple Inc. >> >> >> >> David Singer >> Manager, Software Standards, Apple Inc. >> >> >> >> >> >> >> >> >> -- >> ------------------------------------------------ >> Andreas Tai >> Production Systems Television IRT - Institut fuer >> Rundfunktechnik GmbH >> R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR >> Floriansmuehlstrasse 60, D-80939 Munich, Germany >> >> Phone: +49 89 32399-389 <tel:%2B49%2089%2032399-389> | Fax: >> +49 89 32399-200 <tel:%2B49%2089%2032399-200> >> http: www.irt.de <http://www.irt.de> | Email: tai@irt.de >> <mailto:tai@irt.de> >> ------------------------------------------------ >> >> registration court& managing director: >> Munich Commercial, RegNo. B 5191 >> Dr. Klaus Illgner-Fehns >> ------------------------------------------------ >> >> >> >> > > > -- > ------------------------------------------------ > Andreas Tai > Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH > R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR > Floriansmuehlstrasse 60, D-80939 Munich, Germany > > Phone:+49 89 32399-389 <tel:%2B49%2089%2032399-389> | Fax:+49 89 32399-200 <tel:%2B49%2089%2032399-200> > http:www.irt.de <http://www.irt.de> | Email:tai@irt.de <mailto:tai@irt.de> > ------------------------------------------------ > > registration court& managing director: > Munich Commercial, RegNo. B 5191 > Dr. Klaus Illgner-Fehns > ------------------------------------------------ > -- ------------------------------------------------ Andreas Tai Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR Floriansmuehlstrasse 60, D-80939 Munich, Germany Phone: +49 89 32399-389 | Fax: +49 89 32399-200 http: www.irt.de | Email: tai@irt.de ------------------------------------------------ registration court& managing director: Munich Commercial, RegNo. B 5191 Dr. Klaus Illgner-Fehns ------------------------------------------------
Received on Sunday, 19 October 2014 14:16:51 UTC