Re: Examples of Per-Profile IMSC Specific Presentation Processing by a MPIP

On Fri, Jan 8, 2016 at 10:56 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:

> Thanks Glenn,
>
> This helps answer one of my questions from yesterday's meeting.
>
> It is tempting to cautiously suggest that we could define the behaviour
> for a presentation processor, be it a single profile or multiple profile
> IMSC processor, that causes it to exhibit the desired behaviour regardless
> of which profile the document actually conforms to, making the decision
> process moot in that case.
>
> In other words:
> * processors that support IMSC-I (IPIP) will always successfully process
> conforming IMSC-I documents
> * processors that support IMSC-T (TPIP) will always successfully
> process conforming IMSC-T documents
> * processors that support both IMSC-I and IMSC-T (MPIP) will always
> successfully process conforming IMSC-I documents and conforming IMSC-T
> documents without needing to know which they are in advance of processing
>
> I'm not sure how long the list will end up being, but for the examples
> you've provided here are some potential rules that would hopefully allow
> implementations to behave desirably, i.e. to make every effort to present
> content in the intended way, inline below:
>
> From: Glenn Adams <glenn@skynav.com> Date: Thursday, 7 January 2016 19:19
>
> Since folks have wondered what type of semantic processing may need to
> discriminate on which profile applies, I have collected a small set of
> examples that apply to presentation processing without any consideration of
> verification/validation. At least one implementation (TTPE) implements code
> to handle these cases:
>
>    - nested tt:div
>       - IMSC-T supports nested div, while IMSC-I does not; an MPIP needs
>       to respect nesting for the former, but ignore (or collapse divs) or abort
>       for the latter;
>
> An MPIP or IPIP encountering a div with an image attribute and one or more
> descendant child div, p, span or br elements shall process the image
> attribute and may ignore the div's content and child elements.
> An MPIP or IPIP encountering a div D with an image attribute where D has a
> parent div element may ignore D.
>
>
>    - tts:displayAlign
>       - IMSC-T supports all values, while IMSC-I prohibits its use; so an
>       MPIP would need to use displayAlign when processing the former, but ignore
>       or abort for the latter;
>
> An MPIP or IPIP may ignore any specified value of displayAlign when
> presenting images.
>
> (in this case I don't think the value of displayAlign has any impact
> anyway since the image is required to be equal in size to the region)
>
>
>    - tts:padding
>       - IMSC-T supports padding on region, while IMSC-I does not; an MPIP
>       needs to respect the former, and ignore (or abort) the latter
>
> An MPIP or IPIP encountering an image attribute on a div whose applicable
> region has a non-zero tts:padding style attribute on any edge shall ignore
> the padding when presenting the image.
>
>
>    - tts:writingMode
>       - IMSC-T supports all values, while IMSC-I prohibits vertical
>       modes; so an an MPIP would need to enable all modes for the former, but
>       ignore or abort if vertical mode is used with the latter;
>
> An MPIP or IPIP encountering an image attribute on a div whose applicable
> region has a vertical writing mode (as enumerated by the
> #writingMode-vertical feature in TTML1) shall present the image without
> rotation or reflection.
>
> > MPIP = Multiple-Profile IMSC Processor
> IPIP = Image Profile IMSC Processor
> TPIP = Text Profile IMSC Processor
>
> Might this be a helpful approach? Reasons I can think of why it might not
> be helpful are:
> 1) it could invalidate existing implementations
> 2) the list may be so long that we cannot complete this exercise sensibly
>
> In many cases the only scenario I can construct where an MPIP might have
> to worry about these rules is one where it is processing a non-conformant
> document instance, i.e. one that would  be rejected by validating
> processors for either profile. Perhaps we would be able to limit the list
> to scenarios that could reasonably be encountered by valid documents.
>
> Thoughts welcome, positive or negative.
>

Your proposal is merely using a heuristic, inline mechanism for determining
whether image or text profile applies; namely, you have substituted "when
presenting an image (during runtime processing)" with "determine which
profile applies (in advance)".

In your modified approach, one might end up processing images that appear
in a document that purports to use the Text profile. Furthermore, your
approach would preclude the presentation processor from also performing
content verification/validation, either inline or as a preliminary step.

Both types of implementation are permitted by IMSC, since (1) it leaves the
details of processing non-conforming content to the implementation, and (2)
it leaves the decision of whether to verify/validate content to the
implementation.

In any case, your alternative approach is not equivalent to an a priori
resolution of the applicable profile, as indicated above.


> (I need more time to look at the proposed text in the other related email
> – I just got to this one first)
>
> Nigel
>
>
>
> ----------------------------
>
> 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.
>
> ---------------------
>