W3C home > Mailing lists > Public > public-tt@w3.org > May 2014

RE: Liaison response - template on MIME type parameter for TimedText

From: Michael Dolan <mdolan@newtbt.com>
Date: Wed, 7 May 2014 04:30:27 -0700
To: <public-tt@w3.org>
Message-ID: <034101cf69e7$c21baff0$46530fd0$@newtbt.com>
There are misunderstandings here that we don't seem to get past.  I think we need to discuss in a meeting.  I am unable to attend this week's telecon, so perhaps let's shoot for the 16th.

-----Original Message-----
From: David Singer [mailto:singer@apple.com] 
Sent: Tuesday, May 06, 2014 4:35 PM
To: Nigel Megitt
Cc: Michael Dolan; public-tt@w3.org
Subject: Re: Liaison response - template on MIME type parameter for TimedText


On May 6, 2014, at 8:29 , Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:

> On 06/05/2014 16:08, "Michael Dolan" <mdolan@newtbt.com> wrote:
> 
>> I'm still not sure we're in agreement on what can be registered and 
>> signaled.  I maintain that any foreign namespace extensions must be 
>> permitted to be registered, not just "flavors" (profiles) of TTML.  
>> It's not about whether W3C defined the profile or not.  It's about 
>> including registration and use of extensions.
>> 
>> Before we deal with versions of profiles and the other semantics, can 
>> we get closure on the above?
> 
> Okay let's try to do that.
> 
> I'm not persuaded that namespaces are at the heart of this.

Nor me.  I think that this is a question for the profiles themselves.  “In this profile, only namespaces X, Y and Z may be present”.  “In this profile, the basic structures must be from namespace X, but any extension elements and attributes from other namespaces are permitted, though a reader can ignore them.”  and so on.

> 
> Profiles of TTML are languages based on TTML which can be expected in 
> general to contain:
> 
> . A constrained subset of a version of TTML, where the constraint may 
> be in syntax or semantics, such as restricting the color space etc.
> . Behaviours not specified by TTML, such as defining for a specific 
> scenario initial values left absent from the more general TTML.
> . Extensions relative to TTML, which may be new syntax and semantics 
> that by definition must be in alternate namespaces.
> 
> (I deliberately omit misuse of existing TTML vocabulary in ways not 
> permitted in TTML)
> 
> Namespaces are therefore a subset of what a receiving processor might 
> need to address, and can be derived from knowledge of the registered 
> short name or, if the processor chooses to parse the document, by 
> inspecting the document itself.
> 
> Maybe I've misunderstood the problem?

I think you have it.  Profiles are about interop, and namespaces and schemas are only a part of that.  Behavior is important (just like in WGs :-))

> 
> Nigel
> 
> 
> 
>> 
>>      Mike
>> 
>> -----Original Message-----
>> From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
>> Sent: Tuesday, May 06, 2014 7:39 AM
>> To: Michael Dolan; public-tt@w3.org
>> Subject: Re: Liaison response - template on MIME type parameter for 
>> TimedText
>> 
>> On 06/05/2014 13:22, "Michael Dolan" <mdolan@newtbt.com> wrote:
>> 
>>> Nigel-
>>> 
>>> I am not promoting namespace/schema over our agreed design approach 
>>> of the other day using profile strings, etc.
>> 
>> Glad we're agreed!
>> 
>>> 
>>> However, I have to say that in #1, well, don't do that.  If it 
>>> matters, provide a different schema URI and call it something other than "ttml"
>>> (e.g. "imsc").  For #2, OK but those are basically the same 
>>> unanswered questions as for the profile design.
>> 
>> It seems to be considered good practice [2] to have mutable 
>> namespaces as long as they're declared as such, which is the case in 
>> TTML1. The specification versioning problem is unlikely to disappear, 
>> and requiring a change of namespace name for every new version of the 
>> same specification would probably cause more problems than it would solve.
>> 
>> [2] http://www.w3.org/2001/tag/doc/namespaceState.html#namespacedef
>> 
>>> I believe that we must be able to signal capabilities other than one 
>>> or more TTML profiles, e.g. "TTML" + required 3rd party namespace, 
>>> or the design will be mostly useless in  my opinion.  Constraining 
>>> it to one or more pure profiles of TTML will have limited 
>>> application. We need to resolve this before attempting semantic 
>>> discussions about a constrained design.
>> 
>> Again, agreed, though I'd make this more a logical concept than 
>> relating it to namespaces. The proposal on the table would permit 
>> other flavours of TTML than those published/recommended by W3C to be 
>> registered. I would propose that the decision "is this a flavour of 
>> TTML that we should register?" can be delegated to the TTWG and the 
>> W3C consensus process, after bringing a "request to register" to the 
>> group. Listing a format on a W3C registry page would merely log the 
>> usage of the short name and would not confer any stronger form of 
>> validation or endorsement of the listed format. I'd expect the group 
>> to reject any formats that do not appear to be a form of TTML at all.
>> 
>> Take for example EBU-TT-D: it uses a subset of TTML namespace 
>> features and additional EBU namespace features, and a fully 
>> conformant processor for this type should process both sets. However 
>> I wouldn't describe those namespaces in the short codes or the 
>> registry - I'd just say the equivalent of "this is TTML and this is 
>> EBU-TT-D" and leave the namespace issue to the receiving system. If 
>> it knows it can process EBU-TT-D then it must know about the EBU 
>> namespace already. If it is unaware of EBU-TT-D then it may choose to 
>> process as TTML and would in that case use the TTML rules and effectively discard the non-TTML namespace content.
>> 
>> Does this come down to a semantic question for the processor of 
>> 'processor must understand format Z' vs 'be warned that this document 
>> may contain features from format Z'? I don't wish to redefine what's 
>> already in TTML1SE and planned for TTML2 during parsing but we need 
>> to guide a pre-parsing decision with this information. Maybe we need 
>> a second operator additional to + that means 'and the processor must 
>> be able to process it', such as & (assuming that's a legal character 
>> in the codecs parameter).
>> 
>> So:
>> 
>> codecs = stpp.TTML.tt1f+ebuttd would tell the receiving system that 
>> it may encounter EBU-TT-D content, whereas
>> 
>> codecs = stpp.TTML.tt1f&ebuttd would tell the receiving system that 
>> it must be able to process EBU-TT-D content.
>> 
>> In both cases the string after TTML begins with at least one TTML profile.
>> I'm not sure if that would always be possible.
>> 
>> 
>> Or maybe we don't need to do anything other than describe the 
>> contents and leave the rest up to the receiving system.
>> 
>> Kind regards,
>> 
>> Nigel
>> 
>>> 
>>> Regards,
>>> 
>>>      Mike
>>> 
>>> -----Original Message-----
>>> From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
>>> Sent: Tuesday, May 06, 2014 2:55 AM
>>> To: Michael Dolan; public-tt@w3.org
>>> Subject: Re: Liaison response - template on MIME type parameter for 
>>> TimedText
>>> 
>>> There's a more substantive issue IMHO. Namespace and schemaLocation 
>>> do not adequately identify a particular variant of TTML, nor is it 
>>> clear how they should be derived. There are two issues, at least:
>>> 
>>> 1. If a profile uses a mutable namespace (which I would normally
>>> expect) then different versions of the same profile will have the 
>>> same namespace and schemaLocation and thus not be distinguishable.
>>> 2. It is unclear whether all of the namespaces used in a document 
>>> must be listed or just those that are relevant for downstream 
>>> processing. If a processor sees a namespace that was not listed what 
>>> should it's behaviour be? I do not believe that we are trying to 
>>> create something here that should have an impact during processing 
>>> of the document; rather the parameter can be used either to select 
>>> an appropriate document or to decide whether or not to download and 
>>> process a document or ignore it.
>>> Similarly it should not be a requirement for the MP4 packager to 
>>> parse the document to work out all of the namespaces that are actually used.
>>> 
>>> Returning to the current alternative proposal, I have a question 
>>> about the stpp.TTML.[short name1]+[short name 2]+[etc] idea: what is 
>>> the order of precedence if we use the + symbol?
>>> 
>>> I can imagine stpp.TTML.DFXP+IMSC being interpreted either as "this 
>>> document is a DFXP TTML document and an IMSC TTML document" or "this 
>>> document is a DFXP TTML document and some other unregistered thing 
>>> called IMSC". Are we free to say that the + operator has higher 
>>> precedence than the . "operator" to ensure that the former 
>>> interpretation holds?
>>> 
>>> This isn't as obvious as it looks at first: in TTML §4 [1] we say 
>>> abstract document types can be validated by pruning all content in 
>>> non-TT namespaces. Consider an alternate format XX that has a 
>>> similar rule that prunes all non-XX namespace content. Someone 
>>> constructs a document that contains both TT namespace elements and 
>>> XX namespace elements at the top level. The document now serves dual 
>>> purposes (ignoring for the moment whether or not this is a good 
>>> idea), and could potentially be described either as 
>>> "stpp.TTML.tt1f+stpp.XX" or as "stpp.TTML.tt1f+XX" - which of these 
>>> is correct depends on how we and MPEG collectively define the syntax in the codecs parameter.
>>> 
>>> [1] http://www.w3.org/TR/ttml1/#profiles
>>> 
>>> In the current proposal there is no way to signal conformance to two 
>>> mutually independent XML formats that can legally be combined in the 
>>> same document.
>>> 
>>> (in case you're wondering, no, I don't actually want to do this but 
>>> I'm just observing the effect of the undefined parts of the current
>>> proposal)
>>> 
>>> Nigel
>>> 
>>> 
>>> On 05/05/2014 14:58, "Michael Dolan" <mdolan@newtbt.com> wrote:
>>> 
>>>> Cyril-
>>>> 
>>>> No one (I don't think) is opposed to addressing the issue.  And, I 
>>>> think W3C has accepted the ownership of its parts of it. The 
>>>> questions are about the technical details.
>>>> 
>>>> There already is a registered media type - "application/ttml-xml".
>>>> So, one of my questions was essentially why not build on that?  
>>>> Dave seems to prefer building on the MP4 4C code and I'm still 
>>>> studying the two approaches.
>>>> 
>>>> As you know, the namespaces and schemaLocations are already 
>>>> signaling at the
>>>> MP4 layer. They can be extracted into a codecs string, but there 
>>>> are apparently objections to the resulting length of the string.  I 
>>>> thought that was the only real issue being addressed, no?
>>>> 
>>>> Regards,
>>>> 
>>>>     Mike
>>>> 
>>>> -----Original Message-----
>>>> From: Cyril Concolato [mailto:cyril.concolato@telecom-paristech.fr]
>>>> Sent: Monday, May 05, 2014 4:43 AM
>>>> To: public-tt@w3.org
>>>> Subject: Re: Liaison response - template on MIME type parameter for 
>>>> TimedText
>>>> 
>>>> Hi all,
>>>> 
>>>> Some points worth highlighting/repeating:
>>>> 
>>>> - Aside from the MP4 problem, the problem is general. Consider a 
>>>> DASH MPD pointing to a TTML file (not packaged in a MP4). How can a 
>>>> player know that it'll be able to play it meaningfully without 
>>>> downloading the entire TTML file? Does it actually need to know or 
>>>> will it always be able to do something with a TTML file? The 
>>>> solution to this problem will provide the basis for the solution to 
>>>> the MP4 problem. Has the TTML WG considered defining a 'codecs' or 
>>>> 'profile' MIME parameter for TTML?
>>>> 
>>>> - the codecs parameter of MP4 files is useful for identifying the 
>>>> content of each track in the file before the file is fully downloaded.
>>>> In Adaptive Streaming contexts such as DASH, the initialization 
>>>> segment can also be downloaded in a first step to get information. 
>>>> So the codecs parameter does not have to provide all information. 
>>>> It could just indicate that the track contains some flavor of TTML 
>>>> and let the initialization segment provide more details. In that 
>>>> case, the solution could be as simple
>>>> as: codecs="stpp.ttml"
>>>> 
>>>> - If more than TTML is needed, remember that a typical workflow for 
>>>> packaging/dashing is: get one (or more) TTML file, package it into 
>>>> an
>>>> (existing) MP4 file, produce an MPD from that MP4 file. Only in the 
>>>> last step is the 'codecs' parameter generated. In MSE cases, you 
>>>> don't even need the MPD but you need to get (most likely in JS) the 
>>>> codecs parameter to create the source buffer. Ideally, the TTML 'codecs'
>>>> string generator should not have to look at the content of the TTML 
>>>> document, only at the track sample entry (similar to AVC codecs 
>>>> generation).
>>>> 
>>>> Regards,
>>>> Cyril
>>>> 
>>>> 03/05/2014 20:01, David Singer a écrit :
>>>>> On May 3, 2014, at 9:06 , Glenn Adams <glenn@skynav.com> wrote:
>>>>> 
>>>>>> 
>>>>>> On Fri, May 2, 2014 at 12:23 PM, David Singer <singer@apple.com>
>>>>>> wrote:
>>>>>> 
>>>>>> On Apr 30, 2014, at 16:40 , Michael Dolan <mdolan@newtbt.com> wrote:
>>>>>> 
>>>>>>> Nigel, Dave and all-
>>>>>>> 
>>>>>>> Is there a TTWG Proposal?
>>>>>>> 
>>>>>>> Would ³stpp² be registered somewhere where it would be 
>>>>>>> unambiguous from
>>>> other Codecs strings unrelated to TTML?  I don¹t mean the sample 
>>>> entry 4C code, but in the Codecs string namespace.  Wouldn¹t it 
>>>> have to be ³application/mp4+stppŠ.²?  Or why not use 
>>>> ³application/ttml+xml² (and similar for WebVTT)?
>>>>>> The codecs string starts with the 4CC of the sample entry.  After 
>>>>>> that,
>>>> whoever defined that 4CC gets to say what¹s the next element.  And 
>>>> they get to say what¹s after that, and so on.
>>>>>> 
>>>>>> stpp says ³some sort of XML²,
>>>>>> 
>>>>>> since VTT isn't XML, then would it use something different from stpp?
>>>>> yes, we have different 4CCs for text-based and XML-based formats.
>>>>> stpp is for XML-based
>>>>> 
>>>>>> 
>>>>>> and is owned by MPEG.  So indeed the step that goes from Œstpp¹ 
>>>>>> to Œsome
>>>> sort of TTML¹ is owned by MPEG, and MPEG still needs to resolve this.
>>>>>> 
>>>>>> The thrust is that IF MPEG solves that, THEN there will be names 
>>>>>> to identify TTML dialects, that could go next.  So you would see
>>>>>> 
>>>>>> codecs=stpp.<some MPEG magic to say it is TTML
>>>>>> happens>.TTMLFULL+IMSC+SDPUS+EBUTT
>>>>>> 
>>>>>> I would expect something more simple, e.g.
>>>>>> 
>>>>>> stpp.vtt
>>>>>> stpp.ttml.tt1f
>>>>>> stpp.ttml.tt1p
>>>>>> stpp.ttml.tt1t
>>>>>> stpp.ttml.sdpu
>>>>>> stpp.ttml.st10
>>>>>> stpp.ttml.st13
>>>>> indeed, MPEG is likely to say that TTML means ³go to the W3C, thou
>>>> sluggard, and be wise²
>>>>> 
>>>>>> where we have a registry for mapping the third IDs above to TTML 
>>>>>> profile
>>>> designators, e.g.
>>>>>> 
>>>>>> tt1f -> http://www.w3.org/ns/ttml/dfxp-full
>>>>>> tt1p -> http://www.w3.org/ns/ttml/dfxp-presentation
>>>>>> tt1t -> http://www.w3.org/ns/ttml/dfxp-transformation
>>>>>> tt1u -> http://www.w3.org/ns/ttml/sdp-us s10f -> 
>>>>>> http://www.smpte-ra.org/schemas/2052-1/2010/profiles/smpte-tt-ful
>>>>>> l
>>>>>> s13f ->
>>>>>> http://www.smpte-ra.org/schemas/2052-1/2013/profiles/smpte-tt-ful
>>>>>> l
>>>>>> 
>>>>>> we definitely do not want to create a new syntax/language for use 
>>>>>> in codecs that describes some way to combine profiles; that 
>>>>>> function is already defined by the ttml profile definition 
>>>>>> document syntax
>>>>> we¹re not, but we have to indicate somehow that a document is 
>>>>> compatible
>>>> with more than one profile.  we also are not restricted here to a 
>>>> 4-character-name, so we can use slightly longer names if they are 
>>>> mnemonic.
>>>>> 
>>>>> we can¹t split into several entries as you suggest;  there is one 
>>>>> entry
>>>> per track, those separated by commas.
>>>>> 
>>>>> codecs=stpp.ttml.tt1f,stpp.ttml.tt1p
>>>>> 
>>>>> means two tracks, whereas
>>>>> 
>>>>> codecs=stpp.ttml.tt1f+tt1p
>>>>> 
>>>>> means one track compatible with two TTML profiles.  Big difference.
>>>>> (I am not wedded to plus, but comma and period are both taken
>>>>> already)
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> for example.
>>>>>> 
>>>>>> For the TTWG to say ³yes, we¹ll take on dialect naming and 
>>>>>> forming that
>>>> second-level parameter² is important; it then means that if MPEG 
>>>> finds a clean solution to the first level, the actual problem in 
>>>> hand is solved.
>>>> I¹d like the MP4 people to realize before the July meeting that 
>>>> this is urgent, and come up with ideas and maybe online discussion ASAP.
>>>>>> 
>>>>>> This is all provisional ‹ on the TTWG getting agreement not only
>>>> internally, but with the partners; and on us all liking the final 
>>>> result, of course.
>>>>>> 
>>>>>> Makes sense?
>>>>>> 
>>>>>>> I understand how one could signal profiles of TTML that a 
>>>>>>> document
>>>> conformed to concurrently, as in the example ­ all of TTML and EBU-TT.
>>>> But
>>>> the signaling requirements go beyond that ­ there is often multiple 
>>>> namespaces in use in one document that are not, as an aggregate, a 
>>>> single ³profile². So, these must be explicitly signaled as well 
>>>> since nearly all profiles permit foreign namespaces.  To 
>>>> accommodate this, the ³short names² have to be defined as ³profiles 
>>>> of namespaces² I think.
>>>>>>> 
>>>>>>> For example, if a document uses the CFF-TT text profile of the 
>>>>>>> TTML Full
>>>> profile, plus SMPTE-TT #608 (US captions), plus CFF-TT metadata, 
>>>> and it was compatible with IMSC, SDP-US and EBU-TT, then it might look like:
>>>> Codecs=xxxxx.TTMLFULL+IMSC+SDPUS+EBUTT+CFFT+CFFM+SMPTE608.
>>>>>>> 
>>>>>>> Regards,
>>>>>>>                 Mike
>>>>>>> 
>>>>>>> p.s. I would give the SC29 Secretary a hint about the target of 
>>>>>>> the
>>>> liaison (MPEG v JPEG).  And, you understand you will not receive a 
>>>> reply until mid-to-late July, right?
>>>>>>> 
>>>>>>> 
>>>>>>> From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
>>>>>>> Sent: Wednesday, April 30, 2014 11:48 AM
>>>>>>> To: watanabe@itscj.ipsj.or.jp
>>>>>>> Cc: Timed Text Working Group
>>>>>>> Subject: Liaison response - template on MIME type parameter for 
>>>>>>> TimedText
>>>>>>> 
>>>>>>> Dear Mr. Watanabe,
>>>>>>> 
>>>>>>> Thank you for your liaison N14444 of April 2014.
>>>>>>> 
>>>>>>> We think that we can indeed find a solution together.  We are 
>>>>>>> looking into creating a table of formal "short names" for the 
>>>>>>> profiles of W3C TTML and the profiles of formats derived from it 
>>>>>>> (such
>>>> as SMPTE-TT, EBU-TT, and so on).  If MPEG were to propose how to 
>>>> step from the four-character-code of the sample entry 
>>>> (XMLSubtitleSampleEntry and
>>>> XMLMetaDataSampleEntry) to something that identifies "a document 
>>>> compatible with one or more profiles of TTML", then we could 
>>>> propose a string composed of a set of one or more these short names 
>>>> as the next parameter.
>>>>>>> 
>>>>>>> For example, say W3C defines two profile short names "W3CTTML" 
>>>>>>> and "EBUTTML", and MPEG defines the name "TTML" as referring to 
>>>>>>> the overall family, one might see
>>>>>>> 
>>>>>>> codecs=stpp.TTML.W3CTTML+EBUTTML,avc1
>>>>>>> 
>>>>>>> as a codecs string of a file carrying AVC (H.264) and TTML 
>>>>>>> subtitles that are additionally EBU-TT conformant.
>>>>>>> 
>>>>>>> We would check with those deriving from TTML (e.g. at SMPTE, EBU 
>>>>>>> and
>>>> DECE) if this approach and design are acceptable, before we 
>>>> formalise this.
>>>>>>> 
>>>>>>> Kind regards,
>>>>>>> 
>>>>>>> Nigel Megitt, David Singer (chairs, Timed Text Working Group, 
>>>>>>> W3C)
>>>>>>> 
>>>>>>> --
>>>>>>> 
>>>>>>> Nigel Megitt
>>>>>>> Lead Technologist, BBC Technology, Distribution & Archives
>>>>>>> Telephone: +44 (0)3030807996
>>>>>>> Internal (Lync): 0807996
>>>>>>> BC4 A3 Broadcast Centre, Media Village, 201 Wood Lane, London 
>>>>>>> W12 7TP
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ----------------------------
>>>>>>> 
>>>>>>> http://www.bbc.co.uk
>>>>>>> This e-mail (and any attachments) is confidential and may 
>>>>>>> contain
>>>> personal views which are not the views of the BBC unless 
>>>> specifically stated.
>>>>>>> If you have received it in error, please delete it from your system.
>>>>>>> Do not use, copy or disclose the information in any way nor act 
>>>>>>> in
>>>> reliance on it and notify the sender immediately.
>>>>>>> Please note that the BBC monitors e-mails sent or received.
>>>>>>> Further communication will signify your consent to this.
>>>>>>> 
>>>>>>> ---------------------
>>>>>>> 
>>>>>> David Singer
>>>>>> Manager, Software Standards, Apple Inc.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> David Singer
>>>>> Manager, Software Standards, Apple Inc.
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Cyril Concolato
>>>> Multimedia Group / Telecom ParisTech 
>>>> http://concolato.wp.mines-telecom.fr/
>>>> @cconcolato
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> -----------------------------
>>> http://www.bbc.co.uk
>>> This e-mail (and any attachments) is confidential and may contain 
>>> personal views which are not the views of the BBC unless 
>>> specifically stated.
>>> If you have received it in
>>> error, please delete it from your system.
>>> Do not use, copy or disclose the
>>> information in any way nor act in reliance on it and notify the 
>>> sender immediately.
>>> Please note that the BBC monitors e-mails sent or received.
>>> Further communication will signify your consent to this.
>>> -----------------------------
>>> 
>>> 
>> 
>> 
>> 
>> -----------------------------
>> http://www.bbc.co.uk
>> This e-mail (and any attachments) is confidential and may contain 
>> personal views which are not the views of the BBC unless specifically 
>> stated.
>> If you have received it in
>> error, please delete it from your system.
>> Do not use, copy or disclose the
>> information in any way nor act in reliance on it and notify the 
>> sender immediately.
>> Please note that the BBC monitors e-mails sent or received.
>> Further communication will signify your consent to this.
>> -----------------------------
>> 
>> 
> 
> 
> 
> -----------------------------
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain 
> personal views which are not the views of the BBC unless specifically stated.
> If you have received it in
> error, please delete it from your system.
> Do not use, copy or disclose the
> information in any way nor act in reliance on it and notify the sender 
> immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
> -----------------------------

David Singer
Manager, Software Standards, Apple Inc.
Received on Wednesday, 7 May 2014 11:31:14 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:15 UTC