- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Tue, 27 May 2014 16:04:43 +0000
- To: Pierre-Anthony Lemieux <pal@sandflow.com>
- CC: Timed Text Working Group <public-tt@w3.org>
Hi Pierre, >Perhaps you are asking how conformance to this supplementary >specification would be signaled? Not really, but if I were asking that what would your answer be? There are no feature designators for complexity at the moment. Kind regards, Nigel On 27/05/2014 16:48, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote: >Hi Nigel, > >> and a document exceeding the minimum >> parameter values as stated in IMSC would not be conformant. > >The document would be conformant to the supplementary specification >overriding the default HRM parameter values specified in IMSC. > >Perhaps you are asking how conformance to this supplementary >specification would be signaled? > >Thanks, > >-- Pierre > >On Tue, May 27, 2014 at 8:32 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> >wrote: >> Hi Pierre, >> >>>As currently drafted, IMSC allows anyone to unambiguously define and >>>document new values for the HRM parameters. >> >> >> Sorry, I'm not seeing this: IMSC provides no mechanism for allowing new >> HRM parameter values to be adopted, and a document exceeding the minimum >> parameter values as stated in IMSC would not be conformant. This means >> that any content profile conformance would be discounted by a binary >> 'conformant/not conformant' decision based on the complexity >>measurement. >> I'd prefer to parameterise it explicitly in the IMSC spec so that a >> document can be IMSC syntax and content conformant and separately >> conformant to a stated complexity level. >> >> This would allow other complexity levels to be introduced in the future >> without having to write a whole new spec. >> >> Kind regards, >> >> Nigel >> >> >> On 27/05/2014 16:22, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote: >> >>>Hi Nigel, >>> >>>> If we do, let's make them as useful as we can, >>>> by allowing for reasonable variations. >>> >>>I like the idea of reducing friction to adoption. >>> >>>As currently drafted, IMSC allows anyone to unambiguously define and >>>document new values for the HRM parameters. Please elaborate on the >>>obstacles one would face if one were to do so. Do you foresee >>>implementation and/or specification issues? >>> >>>Thanks, >>> >>>-- Pierre >>> >>>On Tue, May 27, 2014 at 3:50 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> >>>wrote: >>>> Hi Pierre, >>>> >>>>>As it stands, anyone in the world can unilaterally create a >>>>>specification defining new values. How can it be "more open" than >>>>>that? >>>> >>>> If we don't need standards why bother with a standards body like W3C? >>>>If >>>> we do, let's make them as useful as we can, by allowing for reasonable >>>> variations. >>>> >>>> Kind regards, >>>> >>>> Nigel >>>> >>>> >>>> >>>> >>>> On 23/05/2014 17:50, "Pierre-Anthony Lemieux" <pal@sandflow.com> >>>>wrote: >>>> >>>>>Hi Nigel, >>>>> >>>>>> I see what you mean that you could create a new 'super-profile' >>>>>>that >>>>>>has >>>>>> higher value complexity parameters, and existing IMSC documents >>>>>>would >>>>>>conform to it. >>>>> >>>>>Exactly! >>>>> >>>>>> It just seems a lot of effort to go to just to be able to draw >>>>>>glyphs >>>>>>on the screen more >>>>>> quickly, when the rest of the document structure is identical. >>>>> >>>>>Where is the effort? The specification could be a single page defining >>>>>new values for these parameters. >>>>> >>>>>> Yes it would - actually I'd like a more open mechanism >>>>>> to specify alternate sets of values >>>>> >>>>>As it stands, anyone in the world can unilaterally create a >>>>>specification defining new values. How can it be "more open" than >>>>>that? >>>>> >>>>>Thanks, >>>>> >>>>>-- Pierre >>>>> >>>>>On Fri, May 23, 2014 at 9:30 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> >>>>>wrote: >>>>>> Hi Pierre, >>>>>> >>>>>> On 23/05/2014 16:56, "Pierre-Anthony Lemieux" <pal@sandflow.com> >>>>>>wrote: >>>>>> >>>>>>>Hi Nigel, >>>>>>> >>>>>>>> so that it can be used to construct maximally complex test >>>>>>>>documents >>>>>>>>that compliant >>>>>>>> processors must be able to process successfully, while permitting >>>>>>>>processors >>>>>>>> to process even more complex documents. >>>>>>> >>>>>>>I am not aware of provisions in the specification that prevent >>>>>>>processors from implementing capabilities beyond that required to >>>>>>>process documents that conform to (proposed) IMSC 1.0. >>>>>> >>>>>> Agreed. >>>>>> >>>>>>> >>>>>>>> > This would open up the possibility for future increases in >>>>>>>>complexity >>>>>>>> by allowing the threshold values for sub-profiles of IMSC to be >>>>>>>>changed >>>>>>>> to 'greater complexity', in the knowledge that pre-existing IMSC >>>>>>>>compliant >>>>>>>> documents will be continue to be processable. >>>>>>> >>>>>>>Yes. That option exists in my mind. >>>>>> >>>>>> I suppose this is a matter of perspective - I see what you mean that >>>>>>you >>>>>> could create a new 'super-profile' that has higher value complexity >>>>>> parameters, and existing IMSC documents would conform to it. It just >>>>>>seems >>>>>> a lot of effort to go to just to be able to draw glyphs on the >>>>>>screen >>>>>>more >>>>>> quickly, when the rest of the document structure is identical. >>>>>> >>>>>>>>Very closely related to this, the HRM (§7) [1] in various places >>>>>>>>sets >>>>>>>>threshold >>>>>>>> parameter values using the wording "Unless specified otherwise, >>>>>>>>the >>>>>>>>following table >>>>>>>> shall specify..." but there is no mechanism for specifying >>>>>>>>otherwise >>>>>>> >>>>>>>As it stands, the mechanism to specify otherwise would be in a >>>>>>>different specification. In other words, anyone in the world could >>>>>>>write a specification referencing IMSC 1.0 and including a provision >>>>>>>such as "the Normalized image copy performance factor (ICpy) shall >>>>>>>be >>>>>>>12". >>>>>>> >>>>>>>Would clarifying this in the specification make sense? >>>>>> >>>>>> Yes it would - actually I'd like a more open mechanism to specify >>>>>> alternate sets of values but this would help too. >>>>>> >>>>>>> >>>>>>>> It should be permitted for processors not to be subject to the HRM >>>>>>>>values at all, >>>>>>> >>>>>>>Processors are not subject to HRM constraints, IMSC 1.0 documents >>>>>>>are. >>>>>>>As suggested above, processors can choose to implement abilities >>>>>>>that >>>>>>>go beyond that required to process IMSC 1.0 documents, e.g. to >>>>>>>process >>>>>>>other profiles, including profiles that extend IMSC 1.0. >>>>>> >>>>>> Understood - I meant this in the context of a minimal processor >>>>>>profile >>>>>> not as written in the current working draft. >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> Nigel >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>On Fri, May 23, 2014 at 5:54 AM, Timed Text Working Group Issue >>>>>>>Tracker <sysbot+tracker@w3.org> wrote: >>>>>>>> ISSUE-319 (HRM should be a processor compliance test): HRM should >>>>>>>>be a >>>>>>>>processor compliance test and allow different levels of complexity >>>>>>>>for >>>>>>>>different use cases [TTML IMSC 1.0] >>>>>>>> >>>>>>>> http://www.w3.org/AudioVideo/TT/tracker/issues/319 >>>>>>>> >>>>>>>> Raised by: Nigel Megitt >>>>>>>> On product: TTML IMSC 1.0 >>>>>>>> >>>>>>>> The Hypothetical Render Model is defined as a content profile >>>>>>>>constraint, which appears to set a maximum complexity on all >>>>>>>>documents. >>>>>>>>It would be better to make it a minimal processor profile >>>>>>>>constraint, >>>>>>>>i.e. so that it can be used to construct maximally complex test >>>>>>>>documents that compliant processors must be able to process >>>>>>>>successfully, while permitting processors to process even more >>>>>>>>complex >>>>>>>>documents. >>>>>>>> >>>>>>>> This would open up the possibility for future increases in >>>>>>>>complexity >>>>>>>>by allowing the threshold values for sub-profiles of IMSC to be >>>>>>>>changed >>>>>>>>to 'greater complexity', in the knowledge that pre-existing IMSC >>>>>>>>compliant documents will be continue to be processable. >>>>>>>> >>>>>>>> Very closely related to this, the HRM (§7) [1] in various places >>>>>>>>sets >>>>>>>>threshold parameter values using the wording "Unless specified >>>>>>>>otherwise, the following table shall specify..." but there is no >>>>>>>>mechanism for specifying otherwise; §4.7 simply states that all >>>>>>>>sequences "of intermediate synchronic documents SHALL be >>>>>>>>reproducible..." without providing any reference to an external >>>>>>>>location >>>>>>>>where the parameters in the HRM can be set to other values. >>>>>>>> >>>>>>>> One possible solution to this is to introduce a 'complexity level' >>>>>>>>table and list the current parameter values as, for example >>>>>>>>'complexity >>>>>>>>level 1' and change the wording in §4.7 to state that for use cases >>>>>>>>that >>>>>>>>need to specify complexity they must either specify an equivalent >>>>>>>>table >>>>>>>>with alternative parameter values or use the default 'level 1' >>>>>>>>values. >>>>>>>>It should be permitted for processors not to be subject to the HRM >>>>>>>>values at all, and there should be scope in future versions of IMSC >>>>>>>>to >>>>>>>>add more levels, if there is a strong argument for doing so. >>>>>>>> >>>>>>>> [1] http://www.w3.org/TR/ttml-imsc1/#hypothetical-render-model >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ----------------------------- >>>>>> http://www.bbc.co.uk >>>>>> This e-mail (and any attachments) is confidential and >>>>>> may contain personal views which are not the views of the BBC unless >>>>>>specifically stated. >>>>>> If you have received it in >>>>>> error, please delete it from your system. >>>>>> Do not use, copy or disclose the >>>>>> information in any way nor act in reliance on it and notify the >>>>>>sender >>>>>> immediately. >>>>>> Please note that the BBC monitors e-mails >>>>>> sent or received. >>>>>> Further communication will signify your consent to >>>>>> this. >>>>>> ----------------------------- >>>> >>
Received on Tuesday, 27 May 2014 16:05:13 UTC