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:11:22 -0700
Message-ID: <CACQ=j+cXKt2UD64MXOOtC5D9DJB3wDvWBRWFJp8VyNt8_biyNw@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: Public TTWG List <public-tt@w3.org>, Nigel Megitt <nigel.megitt@bbc.co.uk>
On Fri, Jan 16, 2015 at 8:48 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
wrote:

> 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.]
>

ah, that would be fail XML (let alone schema) validity, so we don't have to
consider that case since it is not semantically relevant

*Validity constraint: IDREF*

Values of type *IDREF* must match the Name
<http://www.w3.org/TR/REC-xml/#NT-Name> production, and values of type
*IDREFS* must match Names <http://www.w3.org/TR/REC-xml/#NT-Names>; each
Name <http://www.w3.org/TR/REC-xml/#NT-Name> must match the value of an ID
attribute on some element in the XML document; i.e. *IDREF* values must match
the value of some ID attribute.


> > 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 .
>
Not sure what you mean here.


> 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 16:12:11 UTC

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