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

Ok. The proposed construct is pretty far from the proposed IMSC 1.0
construct though.

-- Pierre

On Sat, Jun 21, 2014 at 7:30 PM, Glenn Adams <glenn@skynav.com> wrote:
>
>
> On Sat, Jun 21, 2014 at 7:32 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
> wrote:
>>
>> I have confirmed that the intent is tts:visibility="hidden".
>>
>> Why would this be a problem?
>
>
> I suppose we could also make @condition apply to the set element in order to
> conditionally apply a style based on a condition expression, e.g.,
>
> <p tts:visibility="hidden">
>   <set condition="(forced)" tts:visibility="visible"/>
>   Forced Content
> </p>
>
>>
>>
>> -- Pierre
>>
>>
>> On Sat, Jun 21, 2014 at 5:56 PM, Pierre-Anthony Lemieux
>> <pal@sandflow.com> wrote:
>> > Hi Glenn,
>> >
>> >> why would one want it to occupy layout space if not selected?
>> >> that doesn't make any sense;
>> >
>> > The forced content would have been positioned with the non-forced
>> > content present. Simply removing the non-forced content from flow
>> > would potentially change the rendered position of the forced content.
>> >
>> > I will confirm this.
>> >
>> > Best,
>> >
>> > -- Pierre
>> >
>> > On Sat, Jun 21, 2014 at 5:50 PM, Glenn Adams <glenn@skynav.com> wrote:
>> >>
>> >> On Sat, Jun 21, 2014 at 6:43 PM, Pierre-Anthony Lemieux
>> >> <pal@sandflow.com>
>> >> wrote:
>> >>>
>> >>> Hi Glenn,
>> >>>
>> >>> Thanks for these initial thoughts.
>> >>>
>> >>> > 3. evaluating this sub-tree in a postorder traversal, prune elements
>> >>> > if they are not a content element, if they have a condition
>> >>> > attribute
>> >>> > that evaluates to false,
>> >>>
>> >>> "Forced" does not remove the content element from layout and flow, but
>> >>> instead
>> >>> effectively sets the visibility to zero, like tts:visibility="hidden".
>> >>
>> >>
>> >> it should; why would one want it to occupy layout space if not
>> >> selected?
>> >> that doesn't make any sense;
>> >>
>> >> i don't see how to handle conditional content and conditional
>> >> visibility; i
>> >> think the best you will get is the former
>> >>
>> >>>
>> >>>
>> >>> Best,
>> >>>
>> >>> -- Pierre
>> >>>
>> >>> On Sat, Jun 21, 2014 at 5:38 PM, Glenn Adams <glenn@skynav.com> wrote:
>> >>> >
>> >>> >
>> >>> > 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, 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]
>> >>> > 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
>> >>> >> >> >>
>> >>> >> >> >
>> >>> >> >
>> >>> >> >
>> >>> >
>> >>> >
>> >>
>> >>
>
>

Received on Monday, 23 June 2014 03:33:04 UTC