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: Pierre-Anthony Lemieux <pal@sandflow.com>
Date: Fri, 15 Aug 2014 23:12:21 +0200
Message-ID: <CAF_7JxC=ceTNxDtPsU9LHrhMAN2txmZ0EwEHqE74vm5Sm9ZT+A@mail.gmail.com>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>
Cc: Timed Text Working Group <public-tt@w3.org>
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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>
Received on Friday, 15 August 2014 21:13:11 UTC

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