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