- From: Glenn Adams <glenn@skynav.com>
- Date: Fri, 16 Jan 2015 09:16:29 -0700
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Cc: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <CACQ=j+eM4VJv1G0Mqf5eZUr6tmJcnugn056B_oa9XN2rzbNSGQ@mail.gmail.com>
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