- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Wed, 13 Aug 2014 14:38:20 +0000
- To: Pierre-Anthony Lemieux <pal@sandflow.com>
- CC: Timed Text Working Group <public-tt@w3.org>
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 Wednesday, 13 August 2014 14:38:57 UTC