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