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

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 12:59:46 UTC