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

See revised draft at https://dvcs.w3.org/hg/ttml/rev/4423508e4ed8

Thanks,

-- Pierre


On Thu, Aug 14, 2014 at 2:59 PM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
> Hi Pierre,
>
> Sorry, scratch those additions of ’serialised' - I just double checked the
> definition of an XML document and the term ‘serialised’ (or ‘serialised’
> if you prefer) isn’t required.
>
> Nigel
>
>
> On 14/08/2014 13:52, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote:
>
>>Hi Nigel,
>>
>>> Looks good to me. I’d add the word ‘serialized’ too:
>>
>>What does 'serialized' mean here and/or what is the intent?
>>
>>It is not defined in TTML.
>>
>>Thanks,
>>
>>-- Pierre
>>
>>On Thu, Aug 14, 2014 at 2:34 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>
>>wrote:
>>> 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 13:14:23 UTC