ISSUE-366: xml:id uniqueness needs to be broken for some uses of condition

condition vs xml:id

xml:id uniqueness needs to be broken for some uses of condition

State:
OPEN
Product:
TTML2
Raised by:
Nigel Megitt
Opened on:
2015-01-16
Description:
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>

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) .
Related Actions Items:
No related actions
Related emails:
  1. Call for Consensus to request transition of TTML1 3rd Edition to Proposed Recommendation (from nigel.megitt@bbc.co.uk on 2018-09-12)
  2. {minutes} TTWG Meeting 2015-01-22 (from nigel.megitt@bbc.co.uk on 2015-01-22)
  3. {agenda} TTWG Meeting 2015-01-22 (from nigel.megitt@bbc.co.uk on 2015-01-21)
  4. Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] (from silviapfeiffer1@gmail.com on 2015-01-16)
  5. Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] (from glenn@skynav.com on 2015-01-16)
  6. Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] (from glenn@skynav.com on 2015-01-16)
  7. Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] (from nigel.megitt@bbc.co.uk on 2015-01-16)
  8. Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] (from glenn@skynav.com on 2015-01-16)
  9. Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] (from silviapfeiffer1@gmail.com on 2015-01-16)
  10. Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] (from nigel.megitt@bbc.co.uk on 2015-01-16)
  11. Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] (from glenn@skynav.com on 2015-01-16)
  12. Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] (from glenn@skynav.com on 2015-01-16)
  13. Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] (from silviapfeiffer1@gmail.com on 2015-01-16)
  14. Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] (from nigel.megitt@bbc.co.uk on 2015-01-16)
  15. Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] (from nigel.megitt@bbc.co.uk on 2015-01-16)
  16. Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] (from glenn@skynav.com on 2015-01-16)
  17. Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] (from glenn@skynav.com on 2015-01-16)
  18. RE: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] (from John.Birch@screensystems.tv on 2015-01-16)
  19. ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for some uses of condition [TTML2] (from sysbot+tracker@w3.org on 2015-01-16)

Related notes:

Not possible. The condition mechanism operates only at the semantic level, and not the syntactic level. Any document that contains an element that replicates the xml:id of another element is an invalid XML document. Period.

Glenn Adams, 19 Feb 2015, 14:57:16

Display change log ATOM feed


David Singer <singer@apple.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>, Chairs, Thierry Michel <tmichel@w3.org>, Philippe Le Hégaret <plh@w3.org>, Atsushi Shimono <atsushi@w3.org>, Staff Contacts
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: 366.html,v 1.1 2019/11/12 10:07:22 carcone Exp $