- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Thu, 14 Aug 2014 15:13:33 +0200
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Cc: Timed Text Working Group <public-tt@w3.org>
See revised draft at https://dvcs.w3.org/hg/ttml/rev/4423508e4ed8 Thanks, -- Pierre On Thu, Aug 14, 2014 at 2:59 PM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote: > 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 13:14:23 UTC