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 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 Friday, 23 May 2014 16:51:36 UTC