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

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

From: David Singer <singer@apple.com>
Date: Tue, 06 May 2014 16:35:12 -0700
Cc: Michael Dolan <mdolan@newtbt.com>, "public-tt@w3.org" <public-tt@w3.org>
Message-id: <5712D221-1CED-441F-9562-574F18B0A9E0@apple.com>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>

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-full
>>>>>> s13f ->
>>>>>> http://www.smpte-ra.org/schemas/2052-1/2013/profiles/smpte-tt-full
>>>>>> 
>>>>>> 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 Tuesday, 6 May 2014 23:35:42 UTC

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