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