Re: Formal Object to any new CR of IMSC1

On Fri, Dec 11, 2015 at 11:54 AM, Michael Dolan <mdolan@newtbt.com> wrote:

> Why does a document that does not declare its profile have to have a
> default between two specific IMSC1 profiles?
>

The "Document Interchange Context" may be told or otherwise know (from
context of use) it is an IMSC document, but not which IMSC profile applies.


> Lacking the signaling, it might be something else entirely (i.e. nether
> IMSC1 profile).
>

In which case the "Document Interchange Context" has not been told or
determined it is an IMSC document, in which case a general-purpose,
multiple profile TTML processor may (absent other information) treat it as
a TTML1 document in which case the DFXP Transformation Profile would apply.


>   How do you even know to select one of the two IMSC1 profiles?  It might
> be some other subset of TTML (especially for text which might only have the
> NS namespace).
>

See above.


>
>
> And, if so somehow, why can’t the signaling be external?
>

It could be, in which case the language I propose already covers this
circumstance without resorting to the failsafe fallback.

If no ttp:profile <http://www.w3.org/TR/ttml1/#parameter-attribute-profile>
 attribute is present in a *Document Instance*, and if the *Document
Interchange Context* does not make an implicit or explicit reference to and
does not otherwise make a determination of a pre-defined profile defined
herein, then the IMSC Text profile applies.


>   It is required in any real application to tell the difference in some
> manner.  For example, in track selection in DECE (ISOBMFF) such signaling
> for text versus image is required external track metadata. Ditto for ATSC
> DASH – the manifest has required metadata.
>

Note that Cyril has already raised the issue about how a metadata generator
should determine which IMSC profile should apply, however, no definitive
answer was provided (as far as I recall).


>
>
>                 Mike
>
>
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Friday, December 11, 2015 10:21 AM
> *To:* Andreas Tai <tai@irt.de>
> *Cc:* Nigel Megitt <nigel.megitt@bbc.co.uk>; TTWG <public-tt@w3.org>
> *Subject:* 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>
> 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> 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
>
> ------------------------------------------------
>
>
>