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:22:11 +0200
Message-ID: <CAF_7JxChcmyg0Ojh3qfmO7o9xeVx-hFGDCBm=ox+CjCLkFiAZg@mail.gmail.com>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>
Cc: Timed Text Working Group <public-tt@w3.org>
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:23:03 UTC

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