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

On Sat, Jun 21, 2014 at 6:07 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> > What do you mean by "application" in this context?
>
> The entity that is instructing the presentation processor to render
> the IMSC document.
>
> > 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.
>
> It is not a TTML parameter, as in a ttp:*, but instead a state
> variable passed to the presentation processor instructing it to render
> or not non-forced content, like a function argument in a procedural
> language.
>
> > 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.
>
> Can you think of a generic solution that would reduce to a single
> attribute controlling the rendering of forced content? If so, we could
> consider using it in IMSC.
>

I haven't given it much thought, but if we were to introduce as the general
mechanism a new element type:

<tt:switch condition="expression">
... content elements ...
</tt:switch>

then we could also, or as an alternative, introduce an attribute @condition
on content element vocabulary, e.g.,

<div condition="expression"/>

where *expression* uses a simple expression language such as media queries
level 4 [1] or a derivative.

[1] http://dev.w3.org/csswg/mediaqueries4/

For example,

<p condition="(forced)"/>

<p condition="not (forced)"/>

<p condition="(locale: en)"/>

<p condition="not (locale: en)"/>

<p condition="(forced) or not (locale: en)"/>

...

Where the semantics of @condition is essentially changing step 3 of 9.3.3
[construct intermediate document] to read essentially as follows:

3. evaluating this sub-tree in a postorder traversal, prune elements if
they are not a content element
<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#terms-content-element>,
if they have a condition attribute that evaluates to false, if they are
temporally inactive, if they are empty, or if they aren't associated with
region *R* according to the [associate region]
<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/procedure-associate-region>
 procedure;


>
> Thanks,
>
> -- Pierre
>
> On Fri, Jun 20, 2014 at 10:56 PM, Glenn Adams <glenn@skynav.com> wrote:
> >
> > 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
> >> >>
> >> >
> >
> >
>