{"action":"opened","issue":{"url":"https://api.github.com/repos/plehegar/dummy/issues/87","labels_url":"https://api.github.com/repos/plehegar/dummy/issues/87/labels{/name}","comments_url":"https://api.github.com/repos/plehegar/dummy/issues/87/comments","events_url":"https://api.github.com/repos/plehegar/dummy/issues/87/events","html_url":"https://github.com/plehegar/dummy/issues/87","id":114506109,"number":87,"title":"HRM should be a processor compliance test and allow different levels of complexity for different use cases","user":{"login":"plehegar","id":1490400,"avatar_url":"https://avatars.githubusercontent.com/u/1490400?v=3","gravatar_id":"","url":"https://api.github.com/users/plehegar","html_url":"https://github.com/plehegar","followers_url":"https://api.github.com/users/plehegar/followers","following_url":"https://api.github.com/users/plehegar/following{/other_user}","gists_url":"https://api.github.com/users/plehegar/gists{/gist_id}","starred_url":"https://api.github.com/users/plehegar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/plehegar/subscriptions","organizations_url":"https://api.github.com/users/plehegar/orgs","repos_url":"https://api.github.com/users/plehegar/repos","events_url":"https://api.github.com/users/plehegar/events{/privacy}","received_events_url":"https://api.github.com/users/plehegar/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/plehegar/dummy/labels/imsc2","name":"imsc2","color":"ededed"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-11-02T01:04:26Z","updated_at":"2015-11-02T01:04:27Z","closed_at":null,"body":"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.\n\nThis 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. \n\nVery closely related to this, the HRM (chapter 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; chapter 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. \n\nOne 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 chapter 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.\n\n[1] http://www.w3.org/TR/ttml-imsc1/#hypothetical-render-model\n\n(raised by Nigel Megitt on 2014-05-23)\nFrom tracker issue http://www.w3.org/AudioVideo/TT/tracker/issues/319"}}