W3C home > Mailing lists > Public > public-tt@w3.org > January 2015

Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2]

From: Glenn Adams <glenn@skynav.com>
Date: Fri, 16 Jan 2015 07:18:08 -0700
Message-ID: <CACQ=j+eMbarCt-btkw0ZMRhD9htRWZfdv5ELpm7pFmUKV7Tq8w@mail.gmail.com>
To: Timed Text Working Group <public-tt@w3.org>
On Fri, Jan 16, 2015 at 2:52 AM, Timed Text Working Group Issue Tracker <
sysbot+tracker@w3.org> wrote:

> ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for
> some uses of condition [TTML2]
> http://www.w3.org/AudioVideo/TT/tracker/issues/366
> Raised by: Nigel Megitt
> On product: TTML2
> Consider the use case in which an author wishes to permit the viewer of a
> TTML2 document to select from one of a number of style choices, either
> depending on a parameter or a media query, for example choices that vary
> tts:fontSize and tts:extent to accommodate 'normal size font', 'large size
> font' and 'small size font' options.
> The condition attribute can only be used to omit an element from semantic
> processing, not to change its behaviour. One might imagine that the
> following is a way to proceed:
> ...
> <layout>
> <region xml:id="r1" condition="parameter(text_size)=='large size font'"
> tts:extent="95vw 30vh" .../>
> <region xml:id="r1" condition="parameter(text_size)=='normal size font'"
> tts:extent="80vw 20vh" .../>
> <region xml:id="r1" condition="parameter(text_size)=='small size font'"
> tts:extent="60vw 15vh" .../>
> </layout>
> <styling>
> <style xml:id="sFontSize" condition="parameter(text_size)=='large size
> font'" tts:fontSize="15vh"/>
> <style xml:id="sFontSize" condition="parameter(text_size)=='normal size
> font'" tts:fontSize="10vh"/>
> <style xml:id="sFontSize" condition="parameter(text_size)=='small size
> font'" tts:fontSize="7.5vh"/>
> <style xml:id="sDefaultFont" style="sFontSize"
> tts:fontFamily="myFontFamily"/>
> </styling>
> ...
> <body>
> <div region="r1" style="sDefaultFont">
> ...
> </div>
> </body>

Condition is not intended to be used like #ifdef | #ifndef, i.e., as a
syntactic inclusion/exclusion system, but as semantic inclusion/exclusion
only. There are perfectly good alternatives to the above that do not
require duplicating ids, such as:

<style xml:id="s0" tts:fontFamily="myFontFamily"/>
<style xml:id="s1" condition="parameter(text_size)=='large size font'"
tts:fontSize="15vh" tts:extent="95vw 30vh"/>
<style xml:id="s2" condition="parameter(text_size)=='normal size font'"
tts:fontSize="10vh" tts:extent="80vw 20vh"/>
<style xml:id="s3" condition="parameter(text_size)=='small size font'"
tts:fontSize="7.5vh" tts:extent="60vw 15vh"/>

<region xml:id="r1" style="s0 s1 s2 s3"/>

> However this construct, which requires use of xml:id for style and region
> reference, breaks xml:id uniqueness rules, resulting in invalid documents.
> What options are there for achieving this use case? I can see:
> a) repeating all the content in the document with different style and
> region references and specifying condition only on the content,
> b) basing everything on the initial element and making that conditional
> (since nothing needs to refer to initial by xml:id), and specifying all
> regions inline - unfortunately this may be very verbose in terms of
> repeating regions on many content elements, but it could work for cases
> where there are only a few regions and they can be associated with body or
> div elements.
> Neither of these two options is particularly attractive - a) is highly
> repetitious and offers no advantage over the provision of multiple
> documents with any associated costs for asset management and distribution
> there. b) is limited in basing style on initial so it is a 'one chance'
> condition, and it is potentially repetitious in region definition.
> By the way, there are at least three audience groups for which this use
> case exists: 1) Those who have reading difficulties with normal size text;
> 2) users of different devices, where it has been established that text
> needs to be rendered at different sizes on large screen televisions from
> smartphones for example; 3) those who just want to be able to customise the
> display.
> It would be great if the condition construct could be used to allow some
> predefined viewing options to be authored into the document, i.e. in a
> controlled way by the document author. I can't see how this can be achieved
> at present though.
> What solution choices are there? Perhaps the easiest is to redefine the
> condition construct so that it also includes an 'if then else if' syntax in
> which attributes can be defined, so you might end up with, for example:
> <region xml:id="r1" condition="if parameter(text_size)=='large size font'
> then (tts:extent='95vw 30vh' elseif parameter(text_size)='normal size font'
> then (tts:extent='80vw 20vh') elseif parameter(text_size)='small size font'
> then (tts:extent='60vw 15vh') else (tts:extent='80vw 20vh')"/>
> Then xml:id rules are not broken and region r1 can be referenced safely
> with the attribute evaluation only being conditional. I'd advocate
> retaining the ability to specify a condition that can be used to exclude
> the entire element from semantic processing, as now.
> Another solution to this problem might be to define some preprocessing
> using XPath to select specific elements and/or attributes and set values on
> the basis of the same condition functions that have already been specified,
> i.e. parameter, media, supports. Something like:
> <tt:tt [parameters etc]>
> <preprocess>
>    <rule condition="parameter(text_size)=='large size text'"
> path="//region[@xml:id='r1']">
>       <attributes tts:extent="95vw 30vh">
>    </rule>
> </preprocess>
> <head>
>    <layout><region xml:id="r1"/></layout>
> ...
> It would be an error for a path attribute to refer to anywhere except
> <head> or <body> or their descendants.
> This option would also have the incidental effect that it would provide
> similar functionality to declarative styling. All the rules would be
> executed in document order prior to processing the <head>. Preprocessing
> could of course also be performed externally to the document before
> processing, if a 'user style' is desirable (as is the case for any XML
> document) .
Received on Friday, 16 January 2015 14:18:56 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:20 UTC