Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] from Nigel Megitt on 2015-01-16 (public-tt@w3.org from January 2015)

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Fri, 16 Jan 2015 16:03:50 +0000
To: Glenn Adams <glenn@skynav.com>
CC: Timed Text Working Group <public-tt@w3.org>
Message-ID: <D0DEE61F.1911C%nigel.megitt@bbc.co.uk>
From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> Date: Friday, 16 January 2015 15:56
On Fri, Jan 16, 2015 at 8:33 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:
From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> Date: Friday, 16 January 2015 15:24



On Fri, Jan 16, 2015 at 7:38 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:
Ah, thanks Glenn, that solution didn't occur to me. It would be worth clarifying  in the spec that semantic exclusion applies also to references to excluded elements, or equivalently that referenced elements that are semantically excluded evaluate to 'null' and can be pruned. At present there's nothing in the spec that defines the behaviour in the scenario in which an element references another that has been semantically excluded.

I can add some informative text on this, but these normative semantics currently fall out naturally in step 2 of [1].

[1] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#semantics-style-resolution-processing-sss


I don't see how it does naturally fall out – perhaps it needs some normative wording such as changing "for each style element SREF" to "for each semantically included style element SREF". I'd argue that this is not a tautology since we have a new concept of style elements that exist but are semantically excluded.

that's reasonable

For example either as a change to the condition section or to places where references might be made, e.g. §10.2.1 style.

Presumably the same arises when a src attribute is a fragment identifier that points to a semantically excluded data element.

Could you elaborate this scenario? I can see how a <source> child of <data> would not resolve to a resource if @condition were false, but not sure what you have in mind about @src attribute, since one can only have one @src attribute and it only takes one URI.

Take the example from data, but modify it to exclude the data via a condition, leaving with a source element whose src URI points to nothing:


<head>
  <resources>
    <data xml:id="sharedImageData" type="image/png" length="119" condition="false">
      iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAIAAACQd1PeAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8
      YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAMSURBVBhXY2BgYAAAAAQAAVzN/2kAAAAASUVORK5CYII=
    </data>
    <image xml:id="sharedImage">
      <source src="#sharedImageData"/> <!-- This points to a semantically excluded resource now -->
    </image>
  </resources>
</head>
...
<body xmlns:tts="http://www.w3.org/ns/ttml#styling">
  <div tts:backgroundImage="#sharedImage"/>
  <div tts:backgroundImage="#sharedImage"/>
</body>



OK. It is clear I need to better define what I intended by "exclude an element from semantic processing". What I intended is that the element still exists and can be referenced, by that its meaning is null, e.g., a data element that is conditionally excluded doesn't contain any data (or resolve to a resource), a style element that is conditionally excluded doesn't contain any styles, etc.

That makes sense. It leads to the follow up questions:

 Is it an error state to reference an unresolvable resource?
 What should the processor do if it encounters an unresolved resource?
 Should a processor distinguish a deliberately empty data element (length="0") from one that has been excluded (condition="false")?




From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> Date: Friday, 16 January 2015 14:18


On Fri, Jan 16, 2015 at 2:52 AM, Timed Text Working Group Issue Tracker <sysbot+tracker@w3.org<mailto: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:

<styling>
<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"/>
</styling>

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


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 16:04:22 UTC