Re: Formal Object to any new CR of IMSC1

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