- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Fri, 15 Aug 2014 23:12:21 +0200
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Cc: Timed Text Working Group <public-tt@w3.org>
Sounds good. Thanks, -- Pierre On Fri, Aug 15, 2014 at 6:10 PM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote: > Sorry, I’ve just noticed something else: list item 3 refers to a ‘child > element of p’ but since #nested-span is permitted this should read > ‘descendant element of p’. > > 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 Friday, 15 August 2014 21:13:11 UTC