- From: Glenn Adams <glenn@skynav.com>
- Date: Fri, 16 Jan 2015 09:11:22 -0700
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Public TTWG List <public-tt@w3.org>, Nigel Megitt <nigel.megitt@bbc.co.uk>
- Message-ID: <CACQ=j+cXKt2UD64MXOOtC5D9DJB3wDvWBRWFJp8VyNt8_biyNw@mail.gmail.com>
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