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