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

On Mon, May 12, 2014 at 1:34 AM, David Singer <singer@apple.com> wrote:

>
> On May 11, 2014, at 20:30 , Glenn Adams <glenn@skynav.com> wrote:
>
> >
> > On Mon, May 5, 2014 at 5:42 AM, Cyril Concolato <
> cyril.concolato@telecom-paristech.fr> wrote:
> > 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?
> >
> > TTML resources should have a declaration in either the root (<tt>)
> element start tag, in the form of a ttp:profile attribute, that specifies
> the processor profile required to process the document.
>
> You say singular “the”, but a document can be conformant with more than
> one profile, can’t it?  How do I indicate that?
>

In TTML1, it is not possible. However, we do have an open issue to add
support to TTML2 to allow defining a profile by referencing multiple
referenced profiles [1]. This mechanism may be used to refer to such a
combined profile, where the profile designator makes reference to the
definition of the combined profile, e.g., [using the mechanisms for
defining processor profile]

#1 referencing a combination processor profile

<tt ttp:profile="http://example.com/ttml/profile/combination1">

and http://example.com/ttml/profile/combination1 contains the following:

<ttp:profile designator="http://example.com/ttml/profile/combination1"
profileCombination="leastRestrictive">
  <ttp:profile use="http://example.com/ttml/profile/A"/>
  <ttp:profile use="http://example.com/ttml/profile/B"/>
  <ttp:profile use="http://example.com/ttml/profile/C"/>
</ttp:profile>

We also have discussed in the past allowing two other ways to do this:

#2 referencing multiple processor profiles from ttp:profile attribute

<tt ttp:profile="http://example.com/ttml/profile/A
http://example.com/ttml/profile/B http://example.com/ttml/profile/C"
ttp:profileCombination="leastRestrictive">

#3 embedding multiple processor profiles with ttp:profile element

<tt ttp:profileCombination="leastRestrictive">
<head>
<ttp:profile use="http://example.com/ttml/profile/A"/>
<ttp:profile use="http://example.com/ttml/profile/B"/>
<ttp:profile use="http://example.com/ttml/profile/C"/>
</head>
...
</tt>

note that TTML1 already allows this type of combination profile definition
but defines a hard-wired (rather than author specified) combination method

[1] http://www.w3.org/AudioVideo/TT/tracker/issues/280

However, we need to be clear about the purpose of using a profile here. It
is *not* to specify conformance, at least from the way I see people
discussing this matter. Rather, it is to specify what processor profile is
required to process the document. In other words, what features must be
supported by processor according to author's requirements. This is distinct
from what profile(s) the document conforms to. For example, a document may
conform to a profile in which a feature is optionally used, but then
require that feature be supported in order for it to be processed.

The only utility of a statement of content profile conformance is to (1)
perform validation processing, and/or (2) to imply a processor profile in
the absence of an explicit declaration of processor profile. From what I
can tell in this discussion, folks are primarily thinking about the second
of these uses of a content profile conformance declaration. Furthermore, it
appears that, in regard to discussing references to multiple content
profiles, folks are assuming that a disjunction combinator applies; namely,
that the least restrictive expression of any given feature usage
requirement would apply to creating a corresponding processor support
requirement.

For example, say we have three content profiles P, Q, and R that define one
feature F, where P makes F prohibited, Q makes F optional, and R makes F
required. If we then had an expression of conformance (where
"leastRestrictive" profile is similar to an an "or" or "union" operation),
e.g.,

<tt ttp:contentProfile="P Q R"
ttp:contentProfileCombination="leastRestrictive"/>

This declaration effectively says that the document conforms to one (or
more) of content profiles P or Q or R, and with respect to feature F, says
that F is optional. If the document has F, then it would conform to content
profiles Q and R. If the document doesn't have F, then it would conform to
content profiles P and Q.

Now, the author of this document may also declare a processor profile,
possibly as a combination of other processor profiles, which, when
combined, says that support for F is required (independently of whether it
is used in the document). The author might do this because they want to
ensure that a process will be able to handle any documents conforming to
content profile P or Q or R.

Now, in the absence of a declaration of processor profile, a processor
would have to infer a processor profile based on the effective content
profile (i.e., the resulting of combining any number of referenced or
embedded content profiles). It might do that by enumerating the features
and extensions in this effective content profile, and then populating a
corresponding processor profile according to some reasonable mapping, e.g.,


*Content        ProcessorProfile        Profile*
*Value          Value  *

prohibited     optional
optional       optional
required       required

Of these three inferred mappings, the first and third are straightforward,
however, the second isn't so clear. One can imagine a case where an author
may want a processor to be required to support a feature that is expressed
as optional in a content profile. So perhaps we would need another
parameter attribute:

ttp:inferProcessorProfile = (strict|loose) : loose

where strict maps optional in content profile to required in processor
profile, and loose maps optional in content profile to optional in
processor profile.


>
> > That is, I would prefer using the simple expression you specify above:
> codecs="stpp.ttml". Any further determination about processability should
> use the existing TTML profile mechanism described above.
>
> The trouble is that this requires fetching the document.  In some
> environments (e.g. DASH) one wants to make a ‘can play’ determination based
> on the MIME type and its parameters.  Ideally, the MIME type and parameters
> are diagnostic.
>

I understand this desire. However, it is also clear that we are not going
to define a calculus for use in a codecs parameter that is equivalent (in
terms of expressibility) with the formal definition mechanism for processor
and content profiles in TTML2.

I suppose we could define a simple calculus and syntax that addresses the
most likely usage scenario and then define a mapping from that syntax to
the TTML profile mechanisms described above. If an author doesn't want to
be specific, they would simply use a generic codecs="sptt.ttml". In both
cases, the TTML processor would still need to process the profile
references or inline definitions contained in the TTML resource.


>
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
>

Received on Monday, 12 May 2014 16:22:18 UTC