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

Apologies for the late comment (it just took me a while to go through 
the complete thread).

In general I agree with the arguments from David Singer. We need a 
simple solution for a problem that David summarized in one of his emails:

> Look, we have a number of TTML profiles already with significant overlap.  If I write a document that stays in that intersection, someone implementing EBU TT, SMPTE TT, W3C DFXP, and so on, should all be fine.  I suspect many simple cases will fall into this intersection.  Documents ought to be able to say so.

I agree as well that we should make the solution not more complex than 
the problem we are trying to solve. The solution should not only be 
technically feasible but also easy enough to understand. There are 
already some views outside of the TTML specification circle that TTML 
and the interplay of the different TTML "flavours" are to complex to 
understand. Whether this is true or not: we should not provide further 
evidence for this views.

Two additional issues that are important in this context:

1) There should be solution that works with TTML "flavours" that are 
based on TTML 1. We can not wait until TTML 2. Dash profiles are already 
specified or will be finalized soon. Implementers are asking already for 
a way to signal the conformance to a specific TTML Standard outside the 
XML document.

2) The codec parameters should not be depended on the TTML 1 profile 
mechanism/feature. It is enough to point to the specifications. For 
SMPTE-TT, CFF-TT, EBU-TT-D, SDP-US and in the future IMSC there are 
always normative documents. It is enough to reference that 
specifications. Please also note that EBU-TT-D does not use the TTML 
profile mechanism. So it would not be possible to signal EBU-TT-D 
conformance. We discussed the profile mechanism several times in the EBU 
group and always decided not to adopt it at the end (The new 
content/processor profile proposal was not discussed in detail but this 
would be for TTML 2 anyway).

Best regards,

Andreas

Am 15.05.2014 09:47, schrieb David Singer:
> 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.
>
>


-- 
------------------------------------------------
Andreas Tai
Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH
R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
Floriansmuehlstrasse 60, D-80939 Munich, Germany

Phone: +49 89 32399-389 | Fax: +49 89 32399-200
http: www.irt.de | Email: tai@irt.de
------------------------------------------------

registration court&  managing director:
Munich Commercial, RegNo. B 5191
Dr. Klaus Illgner-Fehns
------------------------------------------------

Received on Thursday, 15 May 2014 10:41:42 UTC