Re: ISSUE-310 (progressivelyDecodable needs hierarchical definition): Forward reference rule doesn't take into account child elements [TTML IMSC 1.0]

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:35:28 UTC