Re: proposed updated response to MPEG on codecs

On Wed, Oct 22, 2014 at 7:48 AM, Andreas Tai <tai@irt.de> wrote:

>  Hi Glenn,
>
> Am 19.10.2014 um 18:02 schrieb Glenn Adams:
>
>    Given these requirements, I'm not sure how to deal with an informal
>> profile that doesn't have an associated TTML Profile Definition Document.
>>
>>  I can understand that. The term "informal profile" is pretty vague.
>>
>>   It would seem much simpler to define such a document and associate it
>> with this informal profile.
>>
>>  [1]
>> https://www.w3.org/wiki/TTML/CodecsRegistry#Registration_Entry_Requirements_and_Update_Process
>>
>>
>>
>>  But my conclusion would be different. It is more to allow the signalling
>> of specs that do not use the TTML profiling mechanism.
>>
>
>  Since I haven't seen a rationale for avoiding use of the TTML profile
> mechanism in a specification defining activity, I am not willing to
> concede. Note that one can use the TTML profile mechanism in a defining
> activity without necessarily requiring a processor to use it.
>
>
>
> The profiling mechanism is useful to have an informative reference what is
> supported in different TTML profiles. It helps for an informative (!)
> overview. Therefore it can be used and is used in a specification defining
> activity. But I have some concerns to use it as a normative reference.
> Discussion on this mechanism and different views on this mechanisms have
> been expressed on this list in previous discussion. One of my concerns is
> that different "profiles" list the same feature but require only a limited
> support for that feature.
>

I suppose here you are referring to, e.g., specifying #color in a profile
definition document, but further restricting content to a subset of the
value space of #color, thus ending up with an effective difference in what
is required from a processor and what is permitted in a document.

In the TTML1 context, this could have been resolved by defining new
extension designators, e.g.,

<ttp:extension value="requires">
http://example.com/ttml/extension/#color-rgb-triple-only</ttp:extension>

However, that path was not taken as far as I know.

As of now, with TTML2 one has more options:

(1) define extensions that semantically extend or restrict an existing
profile or extension, e.g.,

<ttp:extension value="requires" restricts="
http://www.w3.org/ns/ttml/feature#color">
http://example.com/ttml/extension/#color-rgb-triple-only</ttp:extension>

this semantics of which may be fine-tuned using the new
ttp:permitFeatureWidening parameter property.

(2) formally define a content profile separate from a processor profile, or
define only a content profile from which a processor profile is inferrred,
about which see ttp:inferProcessorProfile{Method,Source};


> The limitation can vary per profile/dialect. As far as I know there is no
> way to express this with the TTML profile mechanisms.
>
> This is not a proposal to add a "subsetting mechanisms" for TTML features.
>

So we already have a subsetting mechanism in TTML2. Would you suggest it be
changed/improved?


> This would add more semantics to this architecture and would not help
> adoption.
>

Adoption is somewhat orthogonal. One can normatively use the mechanism as
part of a profile specifying activity, and yet not require its use in
processing. Or one can separately define content and processor profiles,
making one more lenient than the other.

In the world of the various formal and informal "profiles" of HTML, SVG,
CSS, etc., one can describe a similar store: some profiles focus on content
constraints/requirements, others focus on processor support, and some
specify both (sometimes without distinguishing which applies, other times
being more precise). In that context, there is really no formal way to
specifying processor requirements, so one ends up having to use various
techniques to mitigate differences in processor support. Such as using
scripting to assess at runtime whether a feature is supported or not. That
has proven adequate (more or less). However, we don't have scripting in
TTML, so there is really no way for content to be altered based on runtime
discovery of feature support.

As for adoption, I personally don't see any barrier to implementing
processor support for TTML #profile. I have implemented it in the past
without any difficulty. There are more complex features already present in
TTML1 (e.g., UAX14) or being added in TTML2, such as ruby support as well
as IMSC's HRM. The "it's too complex" argument doesn't seem adequate.

In any case, even if one chooses to not require implementation support for
#profile, that doesn't argue that one can't or shouldn't use it in a
specifying activity. Furthermore, one can do the latter normatively,
without doing the former at all; i.e., normative use of #profile for
specifying doesn't imply normative use of #profile in presentation
processors.


>
> Best regards,
>
> Andreas
>
> --
> ------------------------------------------------
> 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
> ------------------------------------------------
>
>