Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0]

List items 1, 3 and 4 in §5.5.2 ittp:progressivelyDecodable are about the contents of a TTML document not an ISD.

List item 2 refers to ‘presentation times’ of ISDs - these are what I read as the implied begin times. It may be that we need to define “presentation time” more precisely to make this clear.

I can see how it may be unclear to some readers whether ‘the document’ in points 3 and 4 refers to one of the ISDs introduced in point 2 or to the TTML document itself, so maybe there’s work to do there.



From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>>
Date: Wednesday, 13 August 2014 16:12
To: Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>>
Cc: Pierre-Anthony Lemieux <pal@sandflow.com<mailto:pal@sandflow.com>>, Timed Text Working Group <public-tt@w3.org<mailto:public-tt@w3.org>>
Subject: Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0]

There seems to be some confusion here. An ISD contains no timing information, at least in TTML1, though there are implied begin and duration parameters associated with each ISD as a whole (but not currently expressed in the serialized XML of an ISD).

Note that I intend to formalize ISD serialization in TTML2 so as to include these two parameters. Also I need to deal with the temporal affects of the <animate/> element in TTML2 as pertains to mapping to ISDs. But these issues don't impact IMSC1.



On Wed, Aug 13, 2014 at 8:38 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:sysbot%2Btracker@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

>>>>>
>>>>>
>>>>>
>>