Re: Formal Object to any new CR of IMSC1

On Fri, Dec 11, 2015 at 1:52 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Hi Glenn et al.,
>
> > 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).
>
> Cyril's feedback [1] directly led to the recommendation [2-3] that
> ttp:profile or ebuttm:conformsToStandard be present to signal
> conformance to either Image Profile or Text Profile (see Section
> 6.10).
>

ok, except that this usage is defined to be optional (SHOULD), and we need
a fallback in case that recommendations is not followed


>
> [1] https://lists.w3.org/Archives/Public/public-tt/2015Oct/0026.html
> [2] http://www.w3.org/2015/10/08-tt-minutes.html
> [3] https://github.com/w3c/imsc/issues/75
>
> Best,
>
> -- Pierre
>
> On Fri, Dec 11, 2015 at 12:42 PM, Glenn Adams <glenn@skynav.com> wrote:
> >
> >
> > 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 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
> >>
> >> ------------------------------------------------
> >>
> >>
> >
> >
>