W3C home > Mailing lists > Public > public-tt@w3.org > May 2014

Re: 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]

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>
Message-ID: <CFAA7483.1E6C2%nigel.megitt@bbc.co.uk>
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

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:15 UTC