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