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

On May 6, 2014, at 2:55 , Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:

> 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?

Ah, I never said.

In my proposal, there is no order.  The + is an inclusive ‘or’ meaning that the document is simultaneously compliant with all those profiles, and if you support more than zero of them, you can go ahead, decode and present what you understand (i.e. is in one of our supported profiles), ignore what you don’t, and that’s totally OK with the content author.

In MP4 we use the same concept for brands: they identify a spec or profile, and are a claim and a permission.
claim: this file has everything required by that profile, and nothing prohibited by it
permission: if you support only that profile, and you go ahead and decode and handle what you recognize, and ignore everything else, the author is fine with that result


> 
> 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 document is compliant with both the DFXP and IMSC specs”.  It’s not a list of namespaces used, or schemas used (though they are both relevant to the extent that profiles require them or permit extensions).

> 
> 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.

David Singer
Manager, Software Standards, Apple Inc.

Received on Tuesday, 6 May 2014 23:33:00 UTC