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: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thu, 14 Aug 2014 12:12:44 +0000
To: Pierre-Anthony Lemieux <pal@sandflow.com>
CC: Timed Text Working Group <public-tt@w3.org>
Message-ID: <D012647A.FD7C%nigel.megitt@bbc.co.uk>
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:13:18 UTC

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