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