- From: Andreas Tai <tai@irt.de>
- Date: Sun, 19 Oct 2014 16:02:48 +0200
- To: Glenn Adams <glenn@skynav.com>, public-tt <public-tt@w3.org>, cyril.concolato@telecom-paristech.fr
- Message-ID: <5443C488.8040807@irt.de>
Thanks, Glenn! See comments inline: Am 18.10.2014 um 17:11 schrieb Glenn Adams: > > At present, the rules for registration cited at [1] include: > > 1. ... > 2. Each entry must include an absolute URI that serves as the TTML > Profile Designator that identifies the processor profile. > 3. Each entry should include a link that references a TTML Profile > Definition Document that formally specifies the processor profile > using TTML profile definition vocabulary. > 4. ... > > > Requirement (2) mandates the use of a "TTML Profile Designator". This is exactly the part I am concerned about. If a specification is not a TTML profile (in the way that is defined by TTML 2) how can there be a TTML profile designator? > Your inquiry thus raises the question of whether it is possible to > have a "TTML Profile Designator" for which there is no associated > "TTML Profile Definition Document". Yes, that makes indeed no sense. My use case is where there is no TTML profile. > Note that while the former (2) is mandated, the latter (3) is merely > recommended. > > Further, our recent consensus resolution was to have the > 'processorProfiles' MIME type parameter be semantically equivalent to > the TTML2 'ttp:processorProfiles' parameter attribute, with the only > difference being that the former uses a simpler syntax (short names > and simple combiner operators). > Not sure about the timeline to come to an applicable solutions but I had the impression there is some need for a solution before TTML 2 gets final recommendation status. > Given these requirements, I'm not sure how to deal with an informal > profile that doesn't have an associated TTML Profile Definition Document. I can understand that. The term "informal profile" is pretty vague. > It would seem much simpler to define such a document and associate it > with this informal profile. > > [1] > https://www.w3.org/wiki/TTML/CodecsRegistry#Registration_Entry_Requirements_and_Update_Process But my conclusion would be different. It is more to allow the signalling of specs that do not use the TTML profiling mechanism. Best regards, Andreas > > Best regards, > > Andreas > > >> 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 <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:03:47 UTC