- From: David Singer <singer@apple.com>
- Date: Tue, 06 May 2014 16:35:12 -0700
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Cc: Michael Dolan <mdolan@newtbt.com>, "public-tt@w3.org" <public-tt@w3.org>
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