-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor the HRM #586
base: main
Are you sure you want to change the base?
Refactor the HRM #586
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good as is, though I think more discussion is warranted, about maintaining the SHALL requirement, and if we should be giving any forward guidance to the industry about how we intend to decouple the specifications in the future.
Also §2. Introduction mentions the HRM:
To assist implementers in developing Processors that can render all Document Instances, § 11. Hypothetical Render Model specifies an hypothetical rendering model that is used to measure and limiting Document Instance complexity.
so that probably needs to change.
|
||
<p class="note">As specified in [[ttml2]], <code>tts:overflow</code> has no effect on the extent of the region, and hence the | ||
total normalized drawing area S(E<sub>n</sub>) at <a href='#paint-regions'></a>.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately this note is not duplicated in IMSC-HRM. Worth opening an issue to add it somewhere, so the information is not lost?
<section> | ||
<h4>Hypothetical Render Model</h4> | ||
|
||
<p><a>Document Instance</a> SHALL conform to the Hypothetical Render Model specified at [[!imsc-hrm]].</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm interested to know why this is a SHALL: when we discussed it before, and my recollection is based on what is captured in the linked issue, the idea was to make the two Recommendations independent, so that it would be possible to conform to IMSC but not the HRM, for example.
I don't currently have a strong view, and doing it this way is the "minimal change", but I'd like us to consider the pros and cons, perhaps on a TTWG call.
Also, we should add a note here or in the changes section (or both) because although this appears to be a "no net normative change" edit, in fact it removes HRM conformance requirements for the image profile, since we removed image painting metrics from the IMSC-HRM spec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the idea was to make the two Recommendations independent, so that it would be possible to conform to IMSC but not the HRM, for example.
Thanks for the reminder. I agree that it makes sense to remove the SHALL here.
The Timed Text Working Group just discussed
The full IRC log of that discussion<nigel> Subtopic: Refactor the HRM #586<nigel> github: https://github.com//pull/586 <nigel> Pierre: The current version of IMSC includes both the definition of the profile and also the HRM <nigel> .. that constrains the complexity of IMSC documents. <nigel> .. A conformant IMSC document is defined as one that also conforms to the HRM. <nigel> .. Now the HRM is a separate document, and I think we had discussed in the past <nigel> .. removing the requirement that an IMSC document conforms to the HRM <nigel> .. and merely point to it as an additional specification that users might want to use. <nigel> .. That has two advantages, <nigel> .. a. It reduces the strong dependence between the specs <nigel> .. b. it matches reality where not every IMSC application checks the HRM <nigel> .. The goal is to remove the HRM from IMSC 1.3 and the suggestion is to also remove conformance <nigel> .. as part of the definition of a conformant IMSC document. <nigel> Nigel: I wanted to surface this because I wanted a wider group to have visibility, than just me and Pierre. <nigel> .. Also, there are other options: <nigel> .. 1. Keep the hard requirement <nigel> .. 2. Keep the hard requirement but flag that it is likely to be softened in the future <nigel> .. 3. Change to a SHOULD <nigel> .. 4. Change to a MAY <atai> q+ <nigel> Pierre: I would not use the term MAY in practice <nigel> ack atsushi <nigel> ack ata <nigel> Andreas: As a data point, when we defined EBU-TT-D and discussed in HbbTV, and wanted to <nigel> .. align with IMSC we had long discussions about the HRM and whether we include the constraint. <nigel> .. We decided not to have this requirement for the HRM. <nigel> .. If it is a strict requirement that leaves the possibility to have EBU-TT-D documents that do not <nigel> .. conform to IMSC I don't think it is a big issue at the moment but it is likely to reflect the reality <nigel> .. as Pierre is proposing. <nigel> Nigel: So you're in favour of removing the requirement and referencing as an option (i.e. 4) <nigel> Andreas: Yes <nigel> Nigel: Any other thoughts? <nigel> Pierre: I would have a different opinion if I thought this would go against practice, so there's very little risk here. <nigel> SUMMARY: Remove the hard dependency on IMSC-HRM conformance, and reference as an option for users. |
Closes #582