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: Thu, 14 Aug 2014 14:52:07 +0200
Message-ID: <CAF_7JxDqLvz--6fG6ELgSWMeN_5-603QNzQSAeuqfSCF3-w2nQ@mail.gmail.com>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>
Cc: Timed Text Working Group <public-tt@w3.org>
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, 14 August 2014 12:52:58 UTC

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