- From: Glenn Adams <glenn@skynav.com>
- Date: Fri, 16 Jan 2015 08:56:47 -0700
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Cc: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <CACQ=j+cSZZ=3Lfh2Pn=8XtTRsPaUSkEZpbCt7NoTpo7TgSUJZA@mail.gmail.com>
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 > To: Nigel Megitt <nigel.megitt@bbc.co.uk> > Cc: Timed Text Working Group <public-tt@w3.org> > Subject: Re: ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to > be broken for some uses of condition [TTML2] > > > > 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. > > > > >> >> >> 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 15:57:35 UTC