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

On 16 Jan 2015 16:31, "Glenn Adams" <glenn@skynav.com> wrote:
>
>
> On Fri, Jan 16, 2015 at 8:01 AM, Silvia Pfeiffer <
silviapfeiffer1@gmail.com> wrote:
>>
>>
>> On 16 Jan 2015 15:40, "Nigel Megitt" <nigel.megitt@bbc.co.uk> wrote:
>> >
>> > From: Glenn Adams <glenn@skynav.com> Date: Friday, 16 January 2015
14:33
>> >
>> >> We could also upgrade @region to IDREFS, like @style, in which case,
if more than one of the referenced regions is semantically active, i.e.,
condition is not false on multiple referenced regions, we could define
behavior as one of:
>> >> use the first (and only first) referenced region that is semantically
active;
>> >
>> > Seems like a good idea, as a minimum.
>> >>
>> >> select the content into all referenced regions that are semantically
active;
>> >
>> > I don't know a use case for this.
>>
>> FWIW: on the web, ID is semantically supposed to point to 1 or 0
elements, not to more. I'd highly recommend for the first option to avoid
confusions.
>
> The distinction is between IDREF and IDREFS. The former points exactly
one element (not zero).

[FWIW: It's zero if the target does not exist.]

> The latter points at one or more elements.
>
> We already have a few attributes typed as IDREFS, such as @animate,
@style, and @ttm:agent.
>
> The idea being discussed here is upgrading @region from IDREF to IDREFS

No worries. I thought you wanted to keep it in sync with xml:I'd .

Cheers,
Silvia.

> so that it may reference multiple region elements, some (or all but one)
of which may be semantically excluded by @condition. The only question in
my mind was whether the interpretation of @region with more than one
non-null, i.e., more than one non-conditionally-excluded, region references
should mean (1) use first non-null region, or (2) use all non-null regions
(i.e., map the same content to the multiple non-null regions).
>
> I have a preference for the latter interpretation for the sake of
symmetry.
>
>>
>> Cheers,
>> Silvia.
>>
>> >
>> >
>> >>
>> >> On Fri, Jan 16, 2015 at 7:18 AM, Glenn Adams <glenn@skynav.com> wrote:
>> >>>
>> >>>
>> >>>
>> >>> 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 15:49:13 UTC