- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 14 Aug 2014 12:59:16 +0000
- To: Pierre-Anthony Lemieux <pal@sandflow.com>
- CC: Timed Text Working Group <public-tt@w3.org>
Hi Pierre, Sorry, scratch those additions of ’serialised' - I just double checked the definition of an XML document and the term ‘serialised’ (or ‘serialised’ if you prefer) isn’t required. Nigel On 14/08/2014 13:52, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote: >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:59:46 UTC