RE: Processor Profile, Content Profile and codecs

I think there is a good deal of confusion in this thread...  

In this context, there is only the processor profile (not the new TTML2 content profile).  If TTML2 needs tuning, we can do that later.  If TTML1 is still confusing then file an issue and maybe there will be a 3rd edition.

Contributing to the confusion, "profile" is overloaded.  When I used the term below in my options I was referring to the media type profile parameter currently defined in TTML1/IANA to be the processor profile designator URI.

The Profile Registry is the processor profile short names (with optional combinations), substantively identical to the media type profile parameter values - the processor profile designator URIs.

So, Nigel's #5 is exactly my #2 and is what our POR (Plan Of Record - sorry) is, and what I plan to document in the draft Note. 

So, let's get the draft W3C Note drafted (a lot harder editorial learning curve than I expected - gulp), review it here until we like it, discuss a few details in MPEG about what is needed and where it should be documented, and then update the W3C Note accordingly.

Make better sense?

 Mike

-----Original Message-----
From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk] 
Sent: Tuesday, October 6, 2015 6:20 AM
To: Cyril Concolato <cyril.concolato@telecom-paristech.fr>; 'TTWG' <public-tt@w3.org>
Subject: Re: Processor Profile, Content Profile and codecs

On 06/10/2015 12:39, "Cyril Concolato"
<cyril.concolato@telecom-paristech.fr> wrote:

>Hi all,
>
>Consider the following scenario:
>- someone has authored a TTML document
>- someone else needs to generate the "codecs" attribute for this 
>document (either because the document is served by an HTTP server which 
>wants to compare the associated processor profile with what the HTTP 
>client accepts, or because it needs to add a codecs attribute to a DASH 
>MPD, or because the document is packaged in an MP4 and the MP4 is to be 
>fed to a MediaSource Buffer or described in a DASH MPD).
>
>The question is simple: how to find out which processor profile a given 
>document conforms to?

That's easy. The answer is always none - a document conforms to a content profile and a processor conforms to a processor profile. You might want to ask how to find out which processor profile is required to process a document that may optionally state a content profile though.

>
>For TTML2 [2], there is a definition of 'processor profile' and a 
>process to find it out:
>"Processor profiles are declared by using (1) 
>the|ttp:processorProfiles| 
><https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html?con
>ten 
>t-type=text/html;charset=utf-8#profile-attribute-processorProfiles>attr
>ibu
>te
>on the root|tt|element, (2) one or more|ttp:profile| 
><https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html?con
>ten t-type=text/html;charset=utf-8#profile-vocabulary-profile>elements
>of type|processor|, or (3) a combination of these two mechanisms. If 
>not declared, a processor profile is inferred from a declared content 
>profile or from adefault profile 
><https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html?con
>ten t-type=text/html;charset=utf-8#terms-default-profile>."
>If the attribute is used, this seems clear to me.
>If elements are used, the designator may not be present: "if not 
>specified, the defined profile is considered to be an undesignated 
>profile". I guess this means that the processor profile in that case is 
>considered "not declared" and then inferred or defaulted.
>If the profile is inferred or defaulted, there seems to be a way to 
>find the associated designator, but I'm not sure, as it seems to be a 
>complex task to do [3]. Are there restrictions in derived specs to 
>always either use the attributes?

No there aren't such restrictions.

>
>For TTML1 [1], the notion of processor profile does not exist. The spec 
>however says:
>"The profile of TTML that must be supported by a TTML/Content 
>Processor/in order to process a/Document Instance/is determined either
>(1) by specifying a|ttp:profile|attribute on the root|tt|element, as 
>defined by*6.2.8 ttp:profile* 
><http://www.w3.org/TR/ttml1/#parameter-attribute-profile>, or (2) by 
>including one or more|ttp:profile|elements in the|head|element, in 
>accordance with*6.1.1 ttp:profile* 
><http://www.w3.org/TR/ttml1/#parameter-vocabulary-profile>."
>I understand that the notion of profile in TTML1 is equivalent to the 
>notion of 'processor profile' in TTML1;.

s/'processor profile' in TTML1/'processor profile' in TTML2

>
>The differences with TTML2 seems to be that:
>- there is no default or inferred profile.

There is: from TTML1SE §5.2: "If neither ttp:profile attribute nor ttp:profile element is present in a Document Instance, and if the Document Interchange Context does not make an implicit or explicit reference to a pre-defined profile or does not specify a Profile Definition Document or another equivalent set of feature designations, then the DFXP Transformation profile applies."

>- the ttp:profile element does not have a designator attribute.

What would a designator attribute be for? Features have designators, not profiles. There is a use attribute though.

>So for cases where the ttp:profile attribute is not used, how can the 
>profile identifier be determined? Are there recommendations in derived 
>TTML specifications (EBU, SMPTE, ...) to always set the ttp:profile 
>attribute?

In TTML1SE § 5.2, a Note includes: "it is permitted that the Document Interchange Context determines the applicable profile through private agreement, out-of-band protocol, or common use (between sender and
receiver) of a profile defined by an external specification."

In other words, the spec is deliberately silent on how the profile identifier can be determined if it is not within the document itself.

I'm not aware of a specific recommendation to set the ttp:profile attribute. In EBU-TT it is actually prohibited - an alternate ebuttm:conformsToStandard element is permitted, cardinality 0..*, to indicate all of the standards to which the EBU-TT document claims conformance. For EBU-TT Part 1 v1.1 there is a recommendation to include the value "urn:ebu:tt:exchange:2015-09". The EBU did not consider that the ttp:profile attribute carries the same semantic.

>Additionally, the "profile" parameter defined in TTML1's MIME type 
>registration says:
>"The document profile of a TTMLDocument Instance may be specified using 
>an optional|profile|parameter, which, if specified, the value of which 
>must adhere to the syntax and semantics of|ttp:profile|parameter 
>defined by Section*6.2.8 ttp:profile* 
><http://www.w3.org/TR/ttml1/#parameter-attribute-profile>of the 
>published specification."
>
>IIUC, this means that for TTML1 the 'profile' MIME parameter is 
>equivalent (but with long URI values) to the 'codecs' we are discussing.

The use of short codes instead of long URI values is significant. The addition of extra syntax would also be significant. But if you omit the operators and consider the short code and the URI to be synonyms, then yes, I think there's a form of equivalence. What do you conclude or gain from that?

Nigel


>
>Cyril
>
>[1] http://www.w3.org/TR/ttml1/
>[2] https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html
>[3]
>https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html?cont
>ent 
>-type=text/html;charset=utf-8#semantics-processor-profile-processing
>
>--
>Cyril Concolato
>Multimedia Group / Telecom ParisTech
>http://concolato.wp.mines-telecom.fr/
>@cconcolato
>
>

Received on Tuesday, 6 October 2015 16:55:29 UTC