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 15:32:39 +0000
To: Pierre-Anthony Lemieux <pal@sandflow.com>
CC: Timed Text Working Group <public-tt@w3.org>
Message-ID: <CFAA6D1A.1E682%nigel.megitt@bbc.co.uk>
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

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