- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Tue, 27 May 2014 15:32:39 +0000
- To: Pierre-Anthony Lemieux <pal@sandflow.com>
- CC: Timed Text Working Group <public-tt@w3.org>
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 15:33:20 UTC