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, 13 Aug 2014 16:06:40 +0200
Message-ID: <CAF_7JxDxzNZXfcDPOvLTA6tXw4s606_vu9YBa7DYJYE7TxqheA@mail.gmail.com>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>
Cc: Timed Text Working Group <public-tt@w3.org>
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 Wednesday, 13 August 2014 14:07:35 UTC

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