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

After giving some further thought to forward references, I realized that
the case of style elements having forward references is irrelevant in terms
of serialized decoding. This is because these references are never followed
(dereferenced) when parsing the style elements, but only when performing
the Style Resolution Process [1], which is invoked by Step 2 of Synchronic
Flow Processing [2], which is performed only after the <head/> element is
completely parsed.

So, in fact, there is no problem with forward chained style references.

[1]
http://www.w3.org/TR/2013/REC-ttml1-20130924/#semantics-style-resolution-process-overall
[2]
http://www.w3.org/TR/2013/REC-ttml1-20130924/#semantics-region-layout-step-2



On Wed, Aug 20, 2014 at 10:39 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Addressed at https://dvcs.w3.org/hg/ttml/rev/8dfffa75d2c9
>
> -- Pierre
>
> On Fri, Aug 15, 2014 at 2:12 PM, Pierre-Anthony Lemieux
> <pal@sandflow.com> wrote:
> > Sounds good.
> >
> > Thanks,
> >
> > -- Pierre
> >
> > On Fri, Aug 15, 2014 at 6:10 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>
> wrote:
> >> Sorry, I’ve just noticed something else: list item 3 refers to a ‘child
> >> element of p’ but since #nested-span is permitted this should read
> >> ‘descendant element of p’.
> >>
> >> Nigel
> >>
> >>
> >>
> >> On 14/08/2014 14:13, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote:
> >>
> >>>See revised draft at https://dvcs.w3.org/hg/ttml/rev/4423508e4ed8
> >>>
> >>>Thanks,
> >>>
> >>>-- Pierre
> >>>
> >>>
> >>>On Thu, Aug 14, 2014 at 2:59 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>
> >>>wrote:
> >>>> Hi Pierre,
> >>>>
> >>>> Sorry, scratch those additions of ’serialised' - I just double checked
> >>>>the
> >>>> definition of an XML document and the term ‘serialised’ (or
> ‘serialised’
> >>>> if you prefer) isn’t required.
> >>>>
> >>>> Nigel
> >>>>
> >>>>
> >>>> On 14/08/2014 13:52, "Pierre-Anthony Lemieux" <pal@sandflow.com>
> wrote:
> >>>>
> >>>>>Hi Nigel,
> >>>>>
> >>>>>> Looks good to me. I’d add the word ‘serialized’ too:
> >>>>>
> >>>>>What does 'serialized' mean here and/or what is the intent?
> >>>>>
> >>>>>It is not defined in TTML.
> >>>>>
> >>>>>Thanks,
> >>>>>
> >>>>>-- Pierre
> >>>>>
> >>>>>On Thu, Aug 14, 2014 at 2:34 PM, Nigel Megitt <nigel.megitt@bbc.co.uk
> >
> >>>>>wrote:
> >>>>>> Hi Pierre,
> >>>>>>
> >>>>>>>"""A progressively decodable subtitle document is structured to
> >>>>>> facilitate presentation before the document is received in its
> >>>>>> entirety, and can be identified using ittp:progressivelyDecodable
> >>>>>> attribute."""
> >>>>>>
> >>>>>> Looks good to me. I’d add the word ‘serialised’ too:
> >>>>>>
> >>>>>>
> >>>>>> """A progressively decodable serialised subtitle document is
> >>>>>>structured
> >>>>>>to
> >>>>>> facilitate presentation before the document is received in its
> >>>>>> entirety, and can be identified using ittp:progressivelyDecodable
> >>>>>> attribute."""
> >>>>>>
> >>>>>> I’d also change:
> >>>>>>
> >>>>>>
> >>>>>> "A subtitle document for which the computed value of
> >>>>>> ittp:progressivelyDecodable is "true" shall be a progressively
> >>>>>>decodable
> >>>>>> subtitle document."
> >>>>>>
> >>>>>> to:
> >>>>>>
> >>>>>> "A serialised subtitle document for which the computed value of
> >>>>>> ittp:progressivelyDecodable is "true" shall be a progressively
> >>>>>>decodable
> >>>>>> subtitle document."
> >>>>>>
> >>>>>> In combination with my previous proposal for list item 4 in section
> >>>>>>5.5.2
> >>>>>> I think that addresses the question I raised, thanks.
> >>>>>>
> >>>>>> Nigel
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 14/08/2014 13:22, "Pierre-Anthony Lemieux" <pal@sandflow.com>
> >>>>>>wrote:
> >>>>>>
> >>>>>>>Hi Nigel,
> >>>>>>>
> >>>>>>>As you note, ittp:progressivelyDecodable is intended to indicate
> that
> >>>>>>>a document is structured to facilitate progressive presentation. It
> >>>>>>>makes no claims on progressive transformation, therefore it should
> >>>>>>>have no impact on transformation processor conformance.
> >>>>>>>
> >>>>>>>> My proposal is to remove this requirement [to progressively
> process]
> >>>>>>>>from transformation processors only.
> >>>>>>>
> >>>>>>>Where do you see this requirement?
> >>>>>>>
> >>>>>>>Annex D.2 states "A transformation processor supports the
> >>>>>>>#progressivelyDecodable feature if it recognizes and is capable of
> >>>>>>>transforming values of the ittp:progressivelyDecodable"
> >>>>>>>
> >>>>>>>Are you merely suggesting changing:
> >>>>>>>
> >>>>>>>"""A progressively decodable subtitle document is structured to
> >>>>>>>facilitate processing before the document is received in its
> entirety,
> >>>>>>>and can be identified using ittp:progressivelyDecodable
> attribute."""
> >>>>>>>
> >>>>>>>to
> >>>>>>>
> >>>>>>>"""A progressively decodable subtitle document is structured to
> >>>>>>>facilitate presentation before the document is received in its
> >>>>>>>entirety, and can be identified using ittp:progressivelyDecodable
> >>>>>>>attribute."""
> >>>>>>>
> >>>>>>>Thanks,
> >>>>>>>
> >>>>>>>-- Pierre
> >>>>>>>
> >>>>>>>On Thu, Aug 14, 2014 at 2:12 PM, Nigel Megitt <
> nigel.megitt@bbc.co.uk>
> >>>>>>>wrote:
> >>>>>>>> Hi Pierre,
> >>>>>>>>
> >>>>>>>> The question is: can the transformation processor can
> progressively
> >>>>>>>> process a serialised IMSC document whose
> ittp:progressivelyDecodable
> >>>>>>>> parameter is “true”? The general answer to this question is no, it
> >>>>>>>>can
> >>>>>>>> not. If you ask the same question of a presentation processor you
> >>>>>>>>get
> >>>>>>>>the
> >>>>>>>> answer yes, it can, because the requirement is more specific: to
> >>>>>>>>generate
> >>>>>>>> a time ordered sequence of ISDs.
> >>>>>>>>
> >>>>>>>>>As specified, a transformation processor conforming to an IMSC
> >>>>>>>>>profile
> >>>>>>>>>needs to be able to process any IMSC document
> >>>>>>>>
> >>>>>>>> This is a logical impossibility if the transformation processor is
> >>>>>>>> required to be able to process the IMSC document progressively.
> >>>>>>>>
> >>>>>>>> My proposal is to remove this requirement [to progressively
> process]
> >>>>>>>>from
> >>>>>>>> transformation processors only.
> >>>>>>>>
> >>>>>>>> Kind regards,
> >>>>>>>>
> >>>>>>>> Nigel
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 14/08/2014 12:57, "Pierre-Anthony Lemieux" <pal@sandflow.com>
> >>>>>>>>wrote:
> >>>>>>>>
> >>>>>>>>>Hi Nigel,
> >>>>>>>>>
> >>>>>>>>>>  I think this means that progressive
> >>>>>>>>>> decoding must be omitted from the transformation processor
> profile
> >>>>>>>>>> conformance as defined in section 3 Conformance.
> >>>>>>>>>
> >>>>>>>>>I do not follow. As specified, a transformation processor
> conforming
> >>>>>>>>>to
> >>>>>>>>>an IMSC
> >>>>>>>>>profile needs to be able to process any IMSC document just as a
> >>>>>>>>>presentation processor conforming to an IMSC profile needs to be
> >>>>>>>>>able
> >>>>>>>>>to present any IMSC document.
> >>>>>>>>>
> >>>>>>>>>Best,
> >>>>>>>>>
> >>>>>>>>>-- Pierre
> >>>>>>>>>
> >>>>>>>>>On Thu, Aug 14, 2014 at 1:21 PM, Nigel Megitt
> >>>>>>>>><nigel.megitt@bbc.co.uk>
> >>>>>>>>>wrote:
> >>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
>
>