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 09:16:29 -0700
Message-ID: <CACQ=j+eM4VJv1G0Mqf5eZUr6tmJcnugn056B_oa9XN2rzbNSGQ@mail.gmail.com>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>
Cc: Timed Text Working Group <public-tt@w3.org>
On Fri, Jan 16, 2015 at 9:03 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:

>  From: Glenn Adams <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>
> wrote:
>
>>  From: Glenn Adams <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>
>> 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?
>

no, since resolvability may be contingent on external conditions, e.g., a
reference to an external resource will never be resolvable on a processor
that has no access to external resources;


>  What should the processor do if it encounters an unresolved resource?
>

attempt to resolve the next source element to a resource;


>  Should a processor distinguish a deliberately empty data element
> (length="0") from one that has been excluded (condition="false")?
>

yes; the former is always resolvable (but has no data content), the latter
may or may not be resolvable and may have any length, including zero


>
>
>
>>>
>>>  From: Glenn Adams <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> 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:17:16 UTC

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