- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Wed, 20 Aug 2014 21:39:09 -0700
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Cc: Timed Text Working Group <public-tt@w3.org>
Addressed at https://dvcs.w3.org/hg/ttml/rev/8dfffa75d2c9 -- Pierre On Fri, Aug 15, 2014 at 2:12 PM, Pierre-Anthony Lemieux <pal@sandflow.com> wrote: > Sounds good. > > Thanks, > > -- Pierre > > On Fri, Aug 15, 2014 at 6:10 PM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote: >> Sorry, I’ve just noticed something else: list item 3 refers to a ‘child >> element of p’ but since #nested-span is permitted this should read >> ‘descendant element of p’. >> >> Nigel >> >> >> >> On 14/08/2014 14:13, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote: >> >>>See revised draft at https://dvcs.w3.org/hg/ttml/rev/4423508e4ed8 >>> >>>Thanks, >>> >>>-- Pierre >>> >>> >>>On Thu, Aug 14, 2014 at 2:59 PM, Nigel Megitt <nigel.megitt@bbc.co.uk> >>>wrote: >>>> Hi Pierre, >>>> >>>> Sorry, scratch those additions of ’serialised' - I just double checked >>>>the >>>> definition of an XML document and the term ‘serialised’ (or ‘serialised’ >>>> if you prefer) isn’t required. >>>> >>>> Nigel >>>> >>>> >>>> On 14/08/2014 13:52, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote: >>>> >>>>>Hi Nigel, >>>>> >>>>>> Looks good to me. I’d add the word ‘serialized’ too: >>>>> >>>>>What does 'serialized' mean here and/or what is the intent? >>>>> >>>>>It is not defined in TTML. >>>>> >>>>>Thanks, >>>>> >>>>>-- Pierre >>>>> >>>>>On Thu, Aug 14, 2014 at 2:34 PM, Nigel Megitt <nigel.megitt@bbc.co.uk> >>>>>wrote: >>>>>> Hi Pierre, >>>>>> >>>>>>>"""A progressively decodable subtitle document is structured to >>>>>> facilitate presentation before the document is received in its >>>>>> entirety, and can be identified using ittp:progressivelyDecodable >>>>>> attribute.""" >>>>>> >>>>>> Looks good to me. I’d add the word ‘serialised’ too: >>>>>> >>>>>> >>>>>> """A progressively decodable serialised subtitle document is >>>>>>structured >>>>>>to >>>>>> facilitate presentation before the document is received in its >>>>>> entirety, and can be identified using ittp:progressivelyDecodable >>>>>> attribute.""" >>>>>> >>>>>> I’d also change: >>>>>> >>>>>> >>>>>> "A subtitle document for which the computed value of >>>>>> ittp:progressivelyDecodable is "true" shall be a progressively >>>>>>decodable >>>>>> subtitle document." >>>>>> >>>>>> to: >>>>>> >>>>>> "A serialised subtitle document for which the computed value of >>>>>> ittp:progressivelyDecodable is "true" shall be a progressively >>>>>>decodable >>>>>> subtitle document." >>>>>> >>>>>> In combination with my previous proposal for list item 4 in section >>>>>>5.5.2 >>>>>> I think that addresses the question I raised, thanks. >>>>>> >>>>>> Nigel >>>>>> >>>>>> >>>>>> >>>>>> On 14/08/2014 13:22, "Pierre-Anthony Lemieux" <pal@sandflow.com> >>>>>>wrote: >>>>>> >>>>>>>Hi Nigel, >>>>>>> >>>>>>>As you note, ittp:progressivelyDecodable is intended to indicate that >>>>>>>a document is structured to facilitate progressive presentation. It >>>>>>>makes no claims on progressive transformation, therefore it should >>>>>>>have no impact on transformation processor conformance. >>>>>>> >>>>>>>> My proposal is to remove this requirement [to progressively process] >>>>>>>>from transformation processors only. >>>>>>> >>>>>>>Where do you see this requirement? >>>>>>> >>>>>>>Annex D.2 states "A transformation processor supports the >>>>>>>#progressivelyDecodable feature if it recognizes and is capable of >>>>>>>transforming values of the ittp:progressivelyDecodable" >>>>>>> >>>>>>>Are you merely suggesting changing: >>>>>>> >>>>>>>"""A progressively decodable subtitle document is structured to >>>>>>>facilitate processing before the document is received in its entirety, >>>>>>>and can be identified using ittp:progressivelyDecodable attribute.""" >>>>>>> >>>>>>>to >>>>>>> >>>>>>>"""A progressively decodable subtitle document is structured to >>>>>>>facilitate presentation before the document is received in its >>>>>>>entirety, and can be identified using ittp:progressivelyDecodable >>>>>>>attribute.""" >>>>>>> >>>>>>>Thanks, >>>>>>> >>>>>>>-- Pierre >>>>>>> >>>>>>>On Thu, Aug 14, 2014 at 2:12 PM, Nigel Megitt <nigel.megitt@bbc.co.uk> >>>>>>>wrote: >>>>>>>> Hi Pierre, >>>>>>>> >>>>>>>> The question is: can the transformation processor can progressively >>>>>>>> process a serialised IMSC document whose ittp:progressivelyDecodable >>>>>>>> parameter is “true”? The general answer to this question is no, it >>>>>>>>can >>>>>>>> not. If you ask the same question of a presentation processor you >>>>>>>>get >>>>>>>>the >>>>>>>> answer yes, it can, because the requirement is more specific: to >>>>>>>>generate >>>>>>>> a time ordered sequence of ISDs. >>>>>>>> >>>>>>>>>As specified, a transformation processor conforming to an IMSC >>>>>>>>>profile >>>>>>>>>needs to be able to process any IMSC document >>>>>>>> >>>>>>>> This is a logical impossibility if the transformation processor is >>>>>>>> required to be able to process the IMSC document progressively. >>>>>>>> >>>>>>>> My proposal is to remove this requirement [to progressively process] >>>>>>>>from >>>>>>>> transformation processors only. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> >>>>>>>> Nigel >>>>>>>> >>>>>>>> >>>>>>>> On 14/08/2014 12:57, "Pierre-Anthony Lemieux" <pal@sandflow.com> >>>>>>>>wrote: >>>>>>>> >>>>>>>>>Hi Nigel, >>>>>>>>> >>>>>>>>>> I think this means that progressive >>>>>>>>>> decoding must be omitted from the transformation processor profile >>>>>>>>>> conformance as defined in section 3 Conformance. >>>>>>>>> >>>>>>>>>I do not follow. As specified, a transformation processor conforming >>>>>>>>>to >>>>>>>>>an IMSC >>>>>>>>>profile needs to be able to process any IMSC document just as a >>>>>>>>>presentation processor conforming to an IMSC profile needs to be >>>>>>>>>able >>>>>>>>>to present any IMSC document. >>>>>>>>> >>>>>>>>>Best, >>>>>>>>> >>>>>>>>>-- Pierre >>>>>>>>> >>>>>>>>>On Thu, Aug 14, 2014 at 1:21 PM, Nigel Megitt >>>>>>>>><nigel.megitt@bbc.co.uk> >>>>>>>>>wrote: >>>>>>>>>> On 13/08/2014 17:36, "Pierre-Anthony Lemieux" <pal@sandflow.com> >>>>>>>>>>wrote: >>>>>>>>>>>>The timing of the <p> is defined only by the parent <div> but >>>>>>>>>>>>since >>>>>>>>>>>>the >>>>>>>>>>>> opening tag and therefore the attributes of the div will be >>>>>>>>>>>>parsed >>>>>>>>>>>>before >>>>>>>>>>>> the <p> that’s okay by the current rule. >>>>>>>>>>> >>>>>>>>>>>Yes. It is permitted. >>>>>>>>>> >>>>>>>>>> Thanks: in that case the rule is indeed for explicit references by >>>>>>>>>>id >>>>>>>>>>and >>>>>>>>>> not implicit ones. >>>>>>>>>> >>>>>>>>>> The consequence of this is that a serialised ‘progressively >>>>>>>>>>decodable’ >>>>>>>>>> IMSC document may be processed progressively for display purposes >>>>>>>>>>but >>>>>>>>>>not, >>>>>>>>>> in general, for other transformations. I think this means that >>>>>>>>>>progressive >>>>>>>>>> decoding must be omitted from the transformation processor profile >>>>>>>>>> conformance as defined in section 3 Conformance. In other words, >>>>>>>>>> progressive decode actually defines progressive presentation only, >>>>>>>>>>not >>>>>>>>>> progressive transformation. >>>>>>>>>> >>>>>>>>>> Kind regards, >>>>>>>>>> >>>>>>>>>> Nigel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>Best, >>>>>>>>>>> >>>>>>>>>>>-- Pierre >>>>>>>>>>> >>>>>>>>>>>On Wed, Aug 13, 2014 at 4:38 PM, Nigel Megitt >>>>>>>>>>><nigel.megitt@bbc.co.uk> >>>>>>>>>>>wrote: >>>>>>>>>>>> Hi Pierre, >>>>>>>>>>>> >>>>>>>>>>>>>> or an implicit reference e.g. a tree traversal required to >>>>>>>>>>>>>>compute >>>>>>>>>>>>>>the >>>>>>>>>>>>>>value of an attribute by inspection of descendants >>>>>>>>>>>> >>>>>>>>>>>>>Can you provide an example? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> <div begin="00:02:00" end="00:02:30"> >>>>>>>>>>>> <p> >>>>>>>>>>>> [some stuff] >>>>>>>>>>>> </p> >>>>>>>>>>>> </div> >>>>>>>>>>>> >>>>>>>>>>>> The timing of the <p> is defined only by the parent <div> but >>>>>>>>>>>>since >>>>>>>>>>>>the >>>>>>>>>>>> opening tag and therefore the attributes of the div will be >>>>>>>>>>>>parsed >>>>>>>>>>>>before >>>>>>>>>>>> the <p> that’s okay by the current rule. If you want to flip >>>>>>>>>>>>this >>>>>>>>>>>>round >>>>>>>>>>>> and compute the active times of a <div> that doesn’t have any >>>>>>>>>>>>timing >>>>>>>>>>>> attributes itself or in an ancestor, then the rule wouldn’t >>>>>>>>>>>>work: >>>>>>>>>>>> >>>>>>>>>>>> <div id="d1"> >>>>>>>>>>>> <p id="p5" begin="00:02:00" end="00:02:15"> >>>>>>>>>>>> p5 content >>>>>>>>>>>> </p> >>>>>>>>>>>> <p id="p6"begin="00:02:15" end="00:02:30"> >>>>>>>>>>>> p6 content >>>>>>>>>>>> </p> >>>>>>>>>>>> </div> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Arguably d1 makes implicit reference to p5 and p6 for timing, >>>>>>>>>>>>though >>>>>>>>>>>>it >>>>>>>>>>>> probably doesn’t matter if all you want to do is make ISDs. Do >>>>>>>>>>>>you >>>>>>>>>>>>need >>>>>>>>>>>> this to be progressively decodable? >>>>>>>>>>>> >>>>>>>>>>>> Nigel >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 13/08/2014 15:06, "Pierre-Anthony Lemieux" <pal@sandflow.com> >>>>>>>>>>>>wrote: >>>>>>>>>>>> >>>>>>>>>>>>>Hi Nigel, >>>>>>>>>>>>> >>>>>>>>>>>>>> I think the 4th point is intended >>>>>>>>>>>>>> to address that though, i.e. it works for both explicit and >>>>>>>>>>>>>>implicit >>>>>>>>>>>>>> references. >>>>>>>>>>>>> >>>>>>>>>>>>>The 4th point is intended to address explicit references only. >>>>>>>>>>>>> >>>>>>>>>>>>>> > or an implicit reference e.g. a tree traversal required to >>>>>>>>>>>>>> compute the value of an attribute by inspection of descendants >>>>>>>>>>>>> >>>>>>>>>>>>>Can you provide an example? >>>>>>>>>>>>> >>>>>>>>>>>>>>I prefer this: it clears up the “mapping” question. >>>>>>>>>>>>> >>>>>>>>>>>>>Ok. Great. >>>>>>>>>>>>> >>>>>>>>>>>>>Best, >>>>>>>>>>>>> >>>>>>>>>>>>>-- Pierre >>>>>>>>>>>>> >>>>>>>>>>>>>On Wed, Aug 13, 2014 at 3:17 PM, Nigel Megitt >>>>>>>>>>>>><nigel.megitt@bbc.co.uk> >>>>>>>>>>>>>wrote: >>>>>>>>>>>>>> Hi Pierre, >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>Do you mean to compare the byte locations of the opening tag >>>>>>>>>>>>>>>>of >>>>>>>>>>>>>>>>the >>>>>>>>>>>>>>>>elements in the flattened document structure, for example? >>>>>>>>>>>>>> >>>>>>>>>>>>>>>Sure. I am not convinced we need to be this specific. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> We do. In a non-ordered hierarchical structure including >>>>>>>>>>>>>>temporal >>>>>>>>>>>>>>concepts >>>>>>>>>>>>>> there’s a lot of scope for misunderstanding if we use terms >>>>>>>>>>>>>>like >>>>>>>>>>>>>>“earlier" >>>>>>>>>>>>>> and “later”. Since you mean something very specific here it >>>>>>>>>>>>>>would >>>>>>>>>>>>>>be >>>>>>>>>>>>>> helpful to be as precise as possible. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>AFAIK the only means in TTML for a first element to >>>>>>>>>>>>>>>'reference' >>>>>>>>>>>>>>>a >>>>>>>>>>>>>>>second >>>>>>>>>>>>>>>element is using xml:id, and a <p> cannot contain another <p>. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is correct for explicit references but there are also >>>>>>>>>>>>>>implicit >>>>>>>>>>>>>> structural references, for example the way that begin and end >>>>>>>>>>>>>>times, >>>>>>>>>>>>>> styles etc may be computed by traversing the tree and >>>>>>>>>>>>>>analysing >>>>>>>>>>>>>>the >>>>>>>>>>>>>> attributes of ascendants or descendants. I think the 4th point >>>>>>>>>>>>>>is >>>>>>>>>>>>>>intended >>>>>>>>>>>>>> to address that though, i.e. it works for both explicit and >>>>>>>>>>>>>>implicit >>>>>>>>>>>>>> references. For example a <p> whose timing is derived from its >>>>>>>>>>>>>>parent >>>>>>>>>>>>>> <div> would be okay. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I’ve just noticed on re-reading that the wording on point 4 >>>>>>>>>>>>>>doesn’t >>>>>>>>>>>>>>say >>>>>>>>>>>>>> what it looks like it means: >>>>>>>>>>>>>> >>>>>>>>>>>>>> "4. no first element references a second element that occurs >>>>>>>>>>>>>>after >>>>>>>>>>>>>>the >>>>>>>>>>>>>> first element in the document." >>>>>>>>>>>>>> >>>>>>>>>>>>>> reads to me that no element is permitted to reference any >>>>>>>>>>>>>>other >>>>>>>>>>>>>>element >>>>>>>>>>>>>> than the first element in the document. So I think it should >>>>>>>>>>>>>>say >>>>>>>>>>>>>>something >>>>>>>>>>>>>> like: >>>>>>>>>>>>>> >>>>>>>>>>>>>> "4. no element E1 references another element E2 where the >>>>>>>>>>>>>>opening >>>>>>>>>>>>>>tag >>>>>>>>>>>>>>of >>>>>>>>>>>>>> E2 occurs after the opening tag of E1, either by an explicit >>>>>>>>>>>>>>reference >>>>>>>>>>>>>> using xml:id or an implicit reference e.g. a tree traversal >>>>>>>>>>>>>>required >>>>>>>>>>>>>>to >>>>>>>>>>>>>> compute the value of an attribute by inspection of >>>>>>>>>>>>>>descendants." >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>What about: >>>>>>>>>>>>>> >>>>>>>>>>>>>>>"given two Intermediate Synchronic Documents A and B with >>>>>>>>>>>>>>>presentation >>>>>>>>>>>>>>>times TA and TB, respectively, TA is not greater than TB if A >>>>>>>>>>>>>>>includes a >>>>>>>>>>>>>>>p element that occurs earlier in the document than any p >>>>>>>>>>>>>>>element >>>>>>>>>>>>>>>that >>>>>>>>>>>>>>>B >>>>>>>>>>>>>>>includes;" >>>>>>>>>>>>>> >>>>>>>>>>>>>> I prefer this: it clears up the “mapping” question. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Nigel >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 13/08/2014 12:56, "Pierre-Anthony Lemieux" >>>>>>>>>>>>>><pal@sandflow.com> >>>>>>>>>>>>>>wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>>Hi Nigel, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>My input. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>that the test for earlier and >>>>>>>>>>>>>>>> later is not precisely enough defined. >>>>>>>>>>>>>>>> Do you mean to compare the byte locations of the opening tag >>>>>>>>>>>>>>>>of >>>>>>>>>>>>>>>>the >>>>>>>>>>>>>>>>elements in the flattened document structure, for example? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>Sure. I am not convinced we need to be this specific. AFAIK >>>>>>>>>>>>>>>the >>>>>>>>>>>>>>>only >>>>>>>>>>>>>>>means in TTML for a first element to 'reference' a second >>>>>>>>>>>>>>>element >>>>>>>>>>>>>>>is >>>>>>>>>>>>>>>using xml:id, and a <p> cannot contain another <p>. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>Please propose specific text if you are not happy with the >>>>>>>>>>>>>>>current >>>>>>>>>>>>>>>text. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It is also unclear in the new wording (list item 2) how an >>>>>>>>>>>>>>>>ISD >>>>>>>>>>>>>>>>³maps² >>>>>>>>>>>>>>>>to a >>>>>>>>>>>>>>>> content element. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>What about: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>""" >>>>>>>>>>>>>>>given two Intermediate Synchronic Documents A and B with >>>>>>>>>>>>>>>presentation >>>>>>>>>>>>>>>times TA and TB, respectively, TA is not greater than TB if A >>>>>>>>>>>>>>>includes >>>>>>>>>>>>>>>a p element that occurs earlier in the document than any p >>>>>>>>>>>>>>>element >>>>>>>>>>>>>>>that B includes; >>>>>>>>>>>>>>>""" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>Did the 3rd ISD above 'map' to p2? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>No. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>-- Pierre >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>On Wed, Aug 13, 2014 at 11:35 AM, Nigel Megitt >>>>>>>>>>>>>>><nigel.megitt@bbc.co.uk> >>>>>>>>>>>>>>>wrote: >>>>>>>>>>>>>>>> Hi Pierre, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I¹ve added a note to ISSUE-330, quoted here for convenience: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The updated text uses phrases such as Œearlier/later in the >>>>>>>>>>>>>>>>document¹ >>>>>>>>>>>>>>>>- >>>>>>>>>>>>>>>> this does not address my original concern, that the test for >>>>>>>>>>>>>>>>earlier >>>>>>>>>>>>>>>>and >>>>>>>>>>>>>>>> later is not precisely enough defined. Do you mean to >>>>>>>>>>>>>>>>compare >>>>>>>>>>>>>>>>the >>>>>>>>>>>>>>>>byte >>>>>>>>>>>>>>>> locations of the opening tag of the elements in the >>>>>>>>>>>>>>>>flattened >>>>>>>>>>>>>>>>document >>>>>>>>>>>>>>>> structure, for example? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It is also unclear in the new wording (list item 2) how an >>>>>>>>>>>>>>>>ISD >>>>>>>>>>>>>>>>³maps² >>>>>>>>>>>>>>>>to a >>>>>>>>>>>>>>>> content element. An ISD is typically constructed from >>>>>>>>>>>>>>>>multiple >>>>>>>>>>>>>>>>elements >>>>>>>>>>>>>>>> simultaneously. There seems to be an assumption that an ISD >>>>>>>>>>>>>>>>can >>>>>>>>>>>>>>>>only >>>>>>>>>>>>>>>> relate to a single p, which is such a significant constraint >>>>>>>>>>>>>>>>that >>>>>>>>>>>>>>>>I >>>>>>>>>>>>>>>>wonder >>>>>>>>>>>>>>>> if it was intended. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Take this example: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <p id="p1" begin="00:01:00" end="00:02:00"> >>>>>>>>>>>>>>>> [some stuff] >>>>>>>>>>>>>>>> </p> >>>>>>>>>>>>>>>> <p id="p2" begin="00:01:30" end="00:01:45"> >>>>>>>>>>>>>>>> [some other stuff] >>>>>>>>>>>>>>>> </p> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We have here the following ISDs: >>>>>>>>>>>>>>>> 1. 00:01:00 containing p1 >>>>>>>>>>>>>>>> 2. 00:01:30 containing p1 and p2 >>>>>>>>>>>>>>>> 3. 00:01.45 containing p1 >>>>>>>>>>>>>>>> 4. 00:02:00 containing nothing >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is this progressively decodable? Did the 3rd ISD above 'map' >>>>>>>>>>>>>>>>to >>>>>>>>>>>>>>>>p2? >>>>>>>>>>>>>>>>It >>>>>>>>>>>>>>>> doesn't itself contain p2: it simply has its timing derived >>>>>>>>>>>>>>>>from >>>>>>>>>>>>>>>>p2. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Kind regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Nigel >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>On Tue, Aug 12, 2014 at 5:02 PM, Pierre-Anthony Lemieux >>>>>>>>>>>>>>><pal@sandflow.com> wrote: >>>>>>>>>>>>>>>> Addressed at https://dvcs.w3.org/hg/ttml/rev/80f2493f9079 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- Pierre >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, May 21, 2014 at 1:10 PM, Timed Text Working Group >>>>>>>>>>>>>>>>Issue >>>>>>>>>>>>>>>> Tracker <sysbot+tracker@w3.org> wrote: >>>>>>>>>>>>>>>>> ISSUE-310 (progressivelyDecodable needs hierarchical >>>>>>>>>>>>>>>>>definition): >>>>>>>>>>>>>>>>>Forward reference rule doesn't take into account child >>>>>>>>>>>>>>>>>elements >>>>>>>>>>>>>>>>>[TTML >>>>>>>>>>>>>>>>>IMSC 1.0] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://www.w3.org/AudioVideo/TT/tracker/issues/310 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Raised by: Nigel Megitt >>>>>>>>>>>>>>>>> On product: TTML IMSC 1.0 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The definition of ttp:progressivelyDecodable [1] could be >>>>>>>>>>>>>>>>>interpreted >>>>>>>>>>>>>>>>>as describing an impossible scenario as it requires that no >>>>>>>>>>>>>>>>>element >>>>>>>>>>>>>>>>>references another element occurring later in the document. >>>>>>>>>>>>>>>>>It >>>>>>>>>>>>>>>>>does >>>>>>>>>>>>>>>>>not >>>>>>>>>>>>>>>>>define "later" to mean 'after the close tag'. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Since the computed time for a content element may depend on >>>>>>>>>>>>>>>>>the >>>>>>>>>>>>>>>>>computed times of its children, and those children are >>>>>>>>>>>>>>>>>defined >>>>>>>>>>>>>>>>>later >>>>>>>>>>>>>>>>>(bytewise) in the document than the opening tag this >>>>>>>>>>>>>>>>>possibly >>>>>>>>>>>>>>>>>unintended interpretation would result in all documents >>>>>>>>>>>>>>>>>being >>>>>>>>>>>>>>>>>invalid >>>>>>>>>>>>>>>>>if progressivelyDecodable is "true". >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> However, if the "after the close tag" clarification is >>>>>>>>>>>>>>>>>added >>>>>>>>>>>>>>>>>then >>>>>>>>>>>>>>>>>the >>>>>>>>>>>>>>>>>concept becomes meaningless because validation would require >>>>>>>>>>>>>>>>>waiting >>>>>>>>>>>>>>>>>until </body> which would negate the utility of the >>>>>>>>>>>>>>>>>attribute. >>>>>>>>>>>>>>>>>Something needs to be added that references the hierarchical >>>>>>>>>>>>>>>>>structure >>>>>>>>>>>>>>>>>of the document when interpreting this attribute. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Incidentally there is also a typo somewhere because the >>>>>>>>>>>>>>>>>attribute >>>>>>>>>>>>>>>>>is >>>>>>>>>>>>>>>>>described alternately as being in ttp: namespace and imsc: >>>>>>>>>>>>>>>>>namespace, >>>>>>>>>>>>>>>>>and both shouldn't be true. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>>http://www.w3.org/TR/ttml-imsc1/#ttp-progressivelyDecodable >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>
Received on Thursday, 21 August 2014 04:39:58 UTC