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 13:57:29 +0200
Message-ID: <CAF_7JxCaEsf45n9e_-s8T4a=7MXH0X-zT2Aj+rdKdnbUv+nfYg@mail.gmail.com>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>
Cc: Timed Text Working Group <public-tt@w3.org>
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 11:58:19 UTC

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