Re: Formal Object to any new CR of IMSC1

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.

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 
> <mailto:glenn@skynav.com>> wrote:
>
>
>
>     On Fri, Dec 11, 2015 at 2:51 AM, Nigel Megitt
>     <nigel.megitt@bbc.co.uk <mailto: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
>         <mailto: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
------------------------------------------------