ISSUE-310: Forward reference rule doesn't take into account child elements

progressivelyDecodable needs hierarchical definition

Forward reference rule doesn't take into account child elements

State:
CLOSED
Product:
TTML IMSC 1.0
Raised by:
Nigel Megitt
Opened on:
2014-05-21
Description:
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
Related Actions Items:
No related actions
Related emails:
  1. {minutes} TTWG Meeting 21/8/2014 (from nigel.megitt@bbc.co.uk on 2014-08-21)
  2. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from glenn@skynav.com on 2014-08-21)
  3. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from pal@sandflow.com on 2014-08-20)
  4. {agenda} TTWG Meeting 21/8/2014 (from nigel.megitt@bbc.co.uk on 2014-08-20)
  5. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from pal@sandflow.com on 2014-08-15)
  6. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from nigel.megitt@bbc.co.uk on 2014-08-15)
  7. {minutes} TTWG Meeting 14/8/2014 (from nigel.megitt@bbc.co.uk on 2014-08-14)
  8. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from nigel.megitt@bbc.co.uk on 2014-08-14)
  9. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from pal@sandflow.com on 2014-08-14)
  10. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from nigel.megitt@bbc.co.uk on 2014-08-14)
  11. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from pal@sandflow.com on 2014-08-14)
  12. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from nigel.megitt@bbc.co.uk on 2014-08-14)
  13. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from pal@sandflow.com on 2014-08-14)
  14. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from nigel.megitt@bbc.co.uk on 2014-08-14)
  15. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from pal@sandflow.com on 2014-08-14)
  16. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from nigel.megitt@bbc.co.uk on 2014-08-14)
  17. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from pal@sandflow.com on 2014-08-13)
  18. {agenda} TTWG Meeting 14/8/2014 (from nigel.megitt@bbc.co.uk on 2014-08-13)
  19. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from nigel.megitt@bbc.co.uk on 2014-08-13)
  20. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from glenn@skynav.com on 2014-08-13)
  21. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from nigel.megitt@bbc.co.uk on 2014-08-13)
  22. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from pal@sandflow.com on 2014-08-13)
  23. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from nigel.megitt@bbc.co.uk on 2014-08-13)
  24. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from pal@sandflow.com on 2014-08-13)
  25. Re: ISSUE-330 (Is Presented Region a synonym for temporally active region?): Is Presented Region a synonym for temporally active region? [TTML IMSC 1.0] (from nigel.megitt@bbc.co.uk on 2014-08-13)
  26. Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from pal@sandflow.com on 2014-08-12)
  27. Re: ISSUE-311 (Note on progressivelyDecodable): Note on progressivelyDecodable is not a sentence [TTML IMSC 1.0] (from pal@sandflow.com on 2014-08-12)
  28. Re: {agenda} TTWG Meeting 7/8/2014 (from pal@sandflow.com on 2014-08-06)
  29. {agenda} TTWG Meeting 7/8/2014 (from nigel.megitt@bbc.co.uk on 2014-08-06)
  30. {agenda} TTWG Meeting 31/7/2014 (from nigel.megitt@bbc.co.uk on 2014-07-30)
  31. {agenda} TTWG Meeting 29/5/2014 (from nigel.megitt@bbc.co.uk on 2014-05-28)
  32. {minutes} TTWG Meeting 22/5/2014 (from nigel.megitt@bbc.co.uk on 2014-05-22)
  33. {agenda} TTWG Meeting 22/5/2014 (from nigel.megitt@bbc.co.uk on 2014-05-21)
  34. ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0] (from sysbot+tracker@w3.org on 2014-05-21)

Related notes:

> 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".

Please provide an example.

Pierre-Anthony Lemieux, 21 May 2014, 23:30:11

See TTML1SE §10.2.4 timeContainer and §10.4 Time Intervals for the spec detail.

For example the active time of <body> with no begin, end or dur attribute is derived from the active times of its children. If it contains a set of <div>s with no begin, end or dur attribute then each of their active times is defined by their children, e.g. a set of <p>s.

In this example when a <div> open tag appears the start of its active time is unknown, until the first <p> with a begin time is encountered:

<body><!-- timing must be derived by inspecting the <p> that is later on in the document -->
<div>
<p begin="...">
<!-- This is the first place in the document where decoding can meaningfully commence -->
</p>
</div>
</body><!-- at this point there's a complete view of the timing of all the elements, but there's no point in holding off until here if progressive decoding is to make any sense -->

Nigel Megitt, 22 May 2014, 13:31:16

Addressed at https://dvcs.w3.org/hg/ttml/rev/80f2493f9079

The revised text is based on feedback from CFF-TT implementers.

"progressively decodable" is now essentially defined in terms of:

- the order of the Intermediate Synchronic Documents to which <p> elements map
- constraints on the animation vocabulary

The idea is for the document to consist of a sequence of <p> elements temporally ordered by their start time, and where Intermediate Synchronic Document boundaries can be determined based on the timing of the <p> elements alone.

Pierre-Anthony Lemieux, 12 Aug 2014, 15:02:11

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.

Nigel Megitt, 13 Aug 2014, 09:36:39

Revised at https://dvcs.w3.org/hg/ttml/rev/8dfffa75d2c9 per email 31

Pierre-Anthony Lemieux, 21 Aug 2014, 04:39:49

Display change log ATOM feed

David Singer <singer@apple.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>, Chairs, Thierry Michel <tmichel@w3.org>, Philippe Le Hégaret <plh@w3.org>, Atsushi Shimono <atsushi@w3.org>, Staff Contacts
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: 310.html,v 1.1 2019/11/12 10:06:54 carcone Exp $