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

Thanks, looks good to me.

Nigel


On 14/08/2014 14:13, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote:

>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:34:14 UTC