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]

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