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: Wed, 20 Aug 2014 21:39:09 -0700
Message-ID: <CAF_7JxAZPycq-xw4dzr5drwT8YANcUbw8EEWh_CoHbNT7YZONA@mail.gmail.com>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>
Cc: Timed Text Working Group <public-tt@w3.org>
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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
Received on Thursday, 21 August 2014 04:39:58 UTC

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