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