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: Thu, 15 May 2014 09:47:47 +0200
Cc: Glenn Adams <glenn@skynav.com>, Cyril Concolato <cyril.concolato@telecom-paristech.fr>, TTWG <public-tt@w3.org>
Message-id: <88582DF1-78FD-443F-975B-684A6123A1B4@apple.com>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>
OK

all we need to convey in the codecs parameter for MP4, or a similar parameter (‘profiles’ probably) is enough to enable the terminal to work out “do I support one or more of these profiles, and therefore, do I support playout of this file?”

Inside the document we can have namespace URIs, schema URIs, document conformance indicators, complex logic to explain the document conformance, and any amount of stuff.  I would keep it simple, myself, but this is a taste question and neither XML nor TTML design lean this way…

Inside the document we need, I think, a simple list:  “To ride on this TTML excursion train, you need to be able to process according to profile P, Q, or R”, and then when someone constructs a MIME type, they can reflect that list in a profiles parameter, or if the TTML is encapsulated in MP4, that list can be made into the sub-parameter of the codecs parameter for stpp.TTML.

I am fine with a neutral separator (‘when viewed as document conformance, the document conforms to P AND Q AND R, when viewed as processor requirement, a processor supporting P OR Q OR R is required, or expressed using and, a P processor AND a Q processor AND an R processor are all satisfactory).  #, or ~, are the two characters that leap out at me.  I actually think plus (+) is fine too.

So something like:

application+xml/ttml;profiles=EBU-TT~SMPTE-TT
codecs=stpp.TTML.EBU-TT~SMPTE-TT

What the syntax is INSIDE the file is undoubtedly more complex.

On May 14, 2014, at 20:06 , Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:

> I don't believe that would help. The choice of interpretation as AND or OR depends on whether you're describing a document's conformance or a set of processors which could handle the document. The likelihood is that the parameter will be misinterpreted whichever we choose, and regardless of how clearly we specify the meaning. 
> 
> I suggest we use a symbol associated with neither AND not OR to highlight to anyone about to make an incorrect assumption that they should look up what it means and not just guess. 
> 
> Perhaps # would work as a two-way combinatorial operator?
> 
> So when used to express conformance with multiple specifications stpp.ttml.abc#def means "conforms to both/all" (the AND relationship) but when used to offer a choice of processors it means "any of these processors can handle" (the OR relationship). 
> 
> Any further decisions about the document or processing choice are delegated to the implementation and may require parsing a document. 
> 
> Nigel
> 
> 
> On 14 May 2014, at 18:52, "David Singer" <singer@apple.com> wrote:
> 
>>> 
>>> codecs=“stpp.ttml.st10+tt1p”
>>> 
>>> or something similar, expressing one TTML track for which either an st10 processor or a tt1p processor are acceptable.
>>> 
>>> ok; but does anyone but me wonder if '+' is the best operator? in my mind it is more associated with AND than OR; could we use '|' instead?
>> 
>> My read of the RFCs is that we need to avoid period, comma, and double-quote, so vertical bar should be fine.
>> 
>> 
>> David Singer
>> Manager, Software Standards, Apple Inc.
>> 
>> 
> 
> 
> -----------------------------
> 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 Thursday, 15 May 2014 07:48:18 UTC

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