- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Sat, 21 Jun 2014 17:07:07 -0700
- To: Glenn Adams <glenn@skynav.com>
- Cc: "public-tt@w3.org" <public-tt@w3.org>
> 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. 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 Sunday, 22 June 2014 00:07:56 UTC