Re: Formal Object to any new CR of IMSC1

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).

[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
>>
>> ------------------------------------------------
>>
>>
>
>

Received on Friday, 11 December 2015 20:53:40 UTC