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