- From: Michael Dolan <mdolan@newtbt.com>
- Date: Wed, 7 May 2014 04:30:27 -0700
- To: <public-tt@w3.org>
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