W3C home > Mailing lists > Public > public-tt@w3.org > August 2014

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

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Wed, 13 Aug 2014 13:17:49 +0000
To: Pierre-Anthony Lemieux <pal@sandflow.com>
CC: Timed Text Working Group <public-tt@w3.org>
Message-ID: <D0111C40.FB03%nigel.megitt@bbc.co.uk>
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 13:18:25 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:17 UTC