Re: Formal Object to any new CR of IMSC1

On Fri, Dec 11, 2015 at 10:46 AM, Andreas Tai <tai@irt.de> wrote:

> Dear Glenn, Nigel, Pierre,
>
> I read through the complete conversation on github and on this thread. May
> be (and hopefully) this turns out to be a very useful discussion to make
> the life of TTML implementers easier.
>
> How I understand Glenn's concern there is a missing solution for the
> following scenario:
>
> A processor that is an IMSC processor gets a document where neither from
> ttp:profile, ebuttm:conformsToStandard and also not from the interchange
> context the information can be derived if the document should be processed
> according to the IMSC 1 Text or IMSC 1 Image profile. If there is no
> deterministic algorithm that defines what the processor should assume in
> this case, the processor is unable to know what rules he needs to apply and
> also he does not know if he can process the document at all.
>
> There is some discussion and reservation from Nigel and Pierre that there
> is such a thing as a generic IMSC processor (that combines the feature of
> the Text and Image profile), but lets take this assumption.
>

After giving this last point some further thought, I would suggest we use
the term "multiple-profile processor" to describe such a processor. The
reason being that the term "generic processor" is already defined in TTML1
to effectively mean the common core, i.e., intersection of, processing
components of multiple profiles, which is a bit different than supporting
multiple profile instances.

As for assuming the existence of such a processor, we don't have to assume,
since the TTV, TTX, and TTPE tools in the Timed Text Toolkit [1] are all
multiple-profile processors, where the set of available profiles when
processing any given document is determined by a "model" parameter provided
to the tool set. Examples of (already implemented) values of models and the
set of available profiles used when applying the model include:

   - ttml1 model
      - dfxp presentation profile
      - dfxp transformation profile
      - dfxp full profile
   - ttml2 model
      - ttml2 presentation profile
      - ttml2 transformation profile
      - ttml2 full profile
      - all ttml1 profiles
   - nflxtt model
      - nflx-cc profile
      - nflx-sdh profile
   - imsc1 model
      - imsc1 text profile
      - imsc1 image profile

Although these tools could employ a pre-processor to guess the profile
given a specific model, this is undesirable for a number of reasons: (1)
there is no standard definition of the heuristics that would be used, thus
resulting in non-interoperability; (2) in a validation/verification context
the use of heuristics to approximate essential processing parameters (such
as profile) reduces the certainty of results.

[1] https://github.com/skynav/ttt



>
> We had a long discussion at the last TPAC meeting in October 2015 about
> the need to specify the information about the "profile" of an TTML
> document. If no information is provided at all (neither through the
> interchange context nor explicitly in the document) this makes it is not
> only very hard for a processor, it makes it maybe impossible to apply a
> consistent and interoperable processing. We therefore agreed to strongly
> advise to provide this information by the known means because otherwise
> processing will be unpredictable. We could even make it stronger by saying
> that in the absence of such information this can not be a IMSC or other
> profile's document and if the the processor behaves just as a IMSC
> processor (could be by configuration as in the case stated by Glenn) then
> he should reject the document. The benefit of this behaviour would be that
> it "encourages" all users to specify the needed information.[1]
>
> The option that Glenn favoured (apply by default the Text profile if an
> IMSC processor gets a TTML document with missing profile information) is
> less strict. But although I think the behaviour proposed above is clearer
> and give better guidance I would not oppose such a solution in case there
> is no other agreed solution.
>
> Best regards,
>
> Andreas
>
> [1]  Of course a TTML 1 processor that conforms to the DFXP Transformation
> profile would be able to process such a document but if he does not conform
> to this profile he also may reject the document.
>
>
>
> Am 11.12.2015 um 17:11 schrieb Glenn Adams:
>
> I should make another point, which is that by your suggestion (that the
> TTML1 fallback applies), then all EBU-TT-D documents that attempt to
> conform to the IMSC text profile will be interpreted as a non-IMSC document
> in the absence of document interchange determination. Is that desirable
> behavior? I think not. It tells me the design is broken.
>
> On Fri, Dec 11, 2015 at 9:03 AM, Glenn Adams <glenn@skynav.com> wrote:
>
>>
>>
>> On Fri, Dec 11, 2015 at 2:51 AM, Nigel Megitt < <nigel.megitt@bbc.co.uk>
>> nigel.megitt@bbc.co.uk> wrote:
>>
>>> Glenn,
>>>
>>> I do not think this is a helpful move.
>>>
>>> To recap the GitHub issue discussion:
>>>
>>> Since IMSC defines two profiles of TTML the normative fallback defined
>>> in TTML1 applies in the absence of any other defined behaviour.
>>>
>>
>> That won't work, since in the EBU-TT-D case, it would be wrong to apply
>> the DFXP Transformation Profile.
>>
>>
>>>
>>> Furthermore the mechanisms for specifying either of the two profiles are
>>> coincident with the ttp:profile attribute as defined in TTML 1 and the
>>> presence  of ebuttm:conformsToStandard with the appropriate value for
>>> EBU-TT-D also indicates IMSC text profile conformance.
>>>
>>> So this objection does not appear to be well formed, in that the
>>> assertion that no fallback behaviour is defined is false.
>>>
>>
>> Clearly by "no fallback" I mean no fallback that yields an IMSC profile.
>> So in that sense my point stands.
>>
>>
>>>
>>> At the very least, IMSC is no worse than TTML1 in this respect, a topic
>>> which was much discussed at our recent face to face meeting.
>>>
>>
>> Without a determination of IMSC profile that yields either text or image
>> profile, it is not possible to process a document that purports to be an
>> IMSC conforming document since processor conformance is defined in terms of
>> knowledge of the applicable profile.
>>
>>
>>>
>>> Finally, it is clear that we do not have consensus for an IMSC specific
>>> algorithm, which by the way would further fragment the processing of
>>> generic TTML documents since any such processor would have to be configured
>>> somehow to expect one of either TTML or IMSC to know which rules to use. It
>>> is clear that IMSC is intended to be a profile of TTML and not a separate
>>> format in its own right.
>>>
>>
>> But that [any such processor would have to be configured somehow to
>> expect one of either TTML or IMSC to know which rules to use] is manifestly
>> true already, with or without an IMSC specific algorithm.
>>
>>
>>>
>>> I hope these arguments will persuade you to consider other options.
>>>
>>
>> From my perspective, both you and Pierre are not attempting to address my
>> comment substantively. I have proposed one possible fallback algorithm, I'm
>> willing to entertain other algorithms as long as they produce one of two
>> answers: IMSC text or IMSC image profile and do not require pre-parsing the
>> entire document.
>>
>> Until that occurs, my objection stands.
>>
>>
>>>
>>> Kind regards
>>>
>>> Nigel
>>>
>>>
>>>
>>> > On 11 Dec 2015, at 00:37, Glenn Adams < <glenn@skynav.com>
>>> glenn@skynav.com> wrote:
>>> >
>>> > Unless and until a fallback profile is mandated normatively in IMSC1,
>>> SKYNAV formally objects to any new CR being published.
>>>
>>>
>>> -----------------------------
>>> 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.
>>> -----------------------------
>>>
>>
>>
>
>
> --
> ------------------------------------------------
> 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
> ------------------------------------------------
>
>