Re: [IMSC] Thoughts re: issue-312 -- itts:forcedDisplay

On Fri, Jun 20, 2014 at 10:33 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Hi Glenn,
>
> Thanks for the feedback.
>
> > no, [forcedDisplayModeParameter] should not be a parameter, in which
> > it would go into some
> > parameter namespace, but should be a metadata attribute,
> ittm:forcedDisplay
>
> forcedDisplayModeParameter != itts:forcedDisplay.
> forcedDisplayModeParameter would be a parameter passed by the
> application to the processor, not a parameter within the document.
>

What do you mean by "application" in this context? I also don't know what
parameter means in this context, e.g., what does it mean vis-a-vis a TTML
parameter, i.e., an attribute expressing a TTML parameter.


>
> > in other words, TTML will remain silent on any presentation semantics of
> such an attribute;
>
> How would interoperability be achieved?
>

By defining a standard mechanism for expressing conditional content
contingent on external processor state, e.g., selected language, whether
display of some content is forced or not, etc.

I am opposed to a one-off solution to a special case of the conditional
content problem. And the forcedDisplay feature is exactly such a special
case.


>
> Thanks,
>
> -- Pierre
>
> On Fri, Jun 20, 2014 at 8:58 PM, Glenn Adams <glenn@skynav.com> wrote:
> >
> > On Fri, Jun 20, 2014 at 7:05 PM, Pierre-Anthony Lemieux <
> pal@sandflow.com>
> > wrote:
> >>
> >> Hi all,
> >>
> >> During our last call, I noted two concerns with the itts:forcedDisplay
> >> feature as currently drafted.
> >>
> >> (a) the semantics of the itts:forcedDisplay feature are not
> >> sufficiently specified
> >> (b) the representation of itts:forcedDisplay as an attribute is not
> >> desirable
> >
> >
> > that should read as a style attribute
> >
> >>
> >>
> >> To address (a), below is proposed prose:
> >>
> >> """
> >> The presentation processor SHALL accept an optional boolean parameter
> >> called forcedDisplayModeParameter, whose value may be set by the
> >> application. If not set, the value of forcedDisplayModeParameter shall
> >> be assumed to be equal to "false".
> >
> >
> > no, it should not be a parameter, in which it would go into some
> parameter
> > namespace, but should be a metadata attribute, ittm:forcedDisplay
> >
> > i'm not sure why you wish to lengthen the name unnecessarily
> >
> >
> >>
> >>
> >> If the value of forcedDisplayModeParameter is "true", a content
> >> element with a itts:forcedDisplay computed value of "false" shall be
> >> assumed to have a tts:visibility computed value equal to "hidden",
> >> even if tts:visibility is otherwise set to "true".
> >> """
> >
> >
> > now, this is again placing style/presentation semantics on this metadata
> > attribute, which is inapropriate
> >
> >>
> >>
> >> The idea is to essentially ignore the itts:forcedDisplay attribute
> >> unless otherwise specifically requested by the application.
> >
> >
> > i'm not sure what "requested by the application" means here
> >
> >>
> >> This also
> >> clarifies that itts:forcedDisplay has "no effect on content layout or
> >> composition, but merely determines whether composed content is visible
> >> or not."
> >
> >
> > if that is the purpose, then the tts:visibility property should be used
> and
> > therefore there is no need for a new forcedDisplay attribute
> >
> >>
> >> As next step, I plan to create examples.
> >>
> >> Re: (b), I am not comfortable rejecting a solution that users have
> >> devised and implemented based on actual use cases and in the absence
> >> of specific guidance and/or prohibition in TTML 1.0.
> >
> >
> > if those users expect that the TTWG would simply adopt a solution as a
> fait
> > accompli, then they are naive; an appropriate process would have been to
> > bring use cases and requirements to the TTWG first, not bring a solution
> as
> > a given
> >
> > at this point, I think the best that can be hoped for IMSC is to define a
> > metadata attribute ittm:forcedDisplay which is described as a hint that
> the
> > associated content is intended to be selected as a candidate for display
> by
> > a higher level protocol (outside the scope of formally defined TTML
> > processing); in other words, TTML will remain silent on any presentation
> > semantics of such an attribute;
> >
> > on the other hand, we may choose in TTML2 to define a conditional content
> > mechanism similar to the SMIL or SVG switch element, that could address
> this
> > use case
> >
> >>
> >>
> >> Best,
> >>
> >> -- Pierre
> >>
> >
>