- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Thu, 14 Aug 2014 14:22:11 +0200
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Cc: Timed Text Working Group <public-tt@w3.org>
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:23:03 UTC