Re: [w3ctag/design-reviews] Review of IMSC-HRM (Issue #788)

Hi @rhiaro and @hadleybeeman apologies for not noticing [the Jan 9 comment ](https://github.com/w3ctag/design-reviews/issues/788#issuecomment-1376192275) until now.

## Delta or complete review

In terms of the review request, there have been some significant changes, to make the algorithm clearer but also to deal with some cases discovered in real world content that caused unwanted conformance failures. It's been a while since the original HRM was reviewed in the original IMSC specification, so taking into account both of those factors, I think a complete re-review is reasonable at this stage.

However if you would prefer a delta review, we can certainly prepare a list of changes. (there's already a [commit history](https://github.com/w3c/imsc-hrm/commits/main) link at the top of the working draft).

I do not think there are any particular architectural issues that we would like input on, other than the question about normative or informative referencing. Historically the most challenging parts of the discussion have been the treatment of character code points vs glyphs vs grapheme clusters, but I think we have netted out at an acceptable position, following i18n review.

The other architectural change that we made to the hypothetical render model is that we have introduced an assumption that disconnecting the front buffer from the display (buffer) when there is no content to display is a zero cost operation. Likewise re-connecting when there is content to display.

Editorially, we have changed some of the terms that we use, for clarity. For example we renamed the glyph and image "buffers" to be "caches" which we felt reflected their role better.

## Normative or informative referencing from IMSC

The components in the ecosystem that need to conform are the subtitle/caption documents themselves. 

Currently, with the existing published IMSC Recs, document conformance requires conformance to the HRM in its previous state. The question we are considering is if we should relax that constraint and offer it as an option for adopters via this distinct IMSC-HRM specification, or if we should refactor the existing Recs to retain the constraint, by reference to the IMSC-HRM specification rather than inclusion of the model within each of the specifications.

## Rec or Note

The idea is that content out in the wild is produced to meet the HRM constraints. And that the specification is defining content conformance. Of course, checking such conformance could be done using a validator, and ideally there would be multiple validators; certainly, if there are multiple validators then it is important that they agree with each other. Production tools should effectively be validators too, since they need to produce conformant content.

In other words, the answer to your last question is Yes, that's correct. In my view, this tips the balance in favour of Rec track.



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/788#issuecomment-1424026421
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/788/1424026421@github.com>