- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Wed, 13 Aug 2014 18:36:13 +0200
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Cc: Timed Text Working Group <public-tt@w3.org>
Ni Nigel, > 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. 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 Wednesday, 13 August 2014 16:37:06 UTC