- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 14 Aug 2014 13:33:41 +0000
- To: Pierre-Anthony Lemieux <pal@sandflow.com>
- CC: Timed Text Working Group <public-tt@w3.org>
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