Skip to content
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

If referencing from IMSC, references will be circular #51

Closed
nigelmegitt opened this issue Oct 6, 2022 · 8 comments
Closed

If referencing from IMSC, references will be circular #51

nigelmegitt opened this issue Oct 6, 2022 · 8 comments
Assignees
Milestone

Comments

@nigelmegitt
Copy link
Contributor

The IMSC-HRM uses terms defined normatively in IMSC, for example "presented region". In preparation for normatively referencing IMSC-HRM from IMSC, we should ensure that there are no circular references that cannot be resolved.

@palemieux
Copy link
Contributor

In preparation for normatively referencing IMSC-HRM from IMSC,

I am not convinced IMSC should reference IMSC-HRM.

@palemieux palemieux added this to the CR1 milestone Nov 7, 2022
@nigelmegitt
Copy link
Contributor Author

I am not convinced IMSC should reference IMSC-HRM.

That was the basis on which I thought we were doing the work. What alternative(s) do you have in mind?

@palemieux
Copy link
Contributor

I am thinking IMSC focuses on semantics and syntax, and IMSC HRM focuses on presentation performance constraints. Organization can choose to adopt only the first without the second, although, evidently, we would recommend they adopt both and could have an informative note in IMSC suggesting as such.

@nigelmegitt
Copy link
Contributor Author

This probably warrants a discussion!

The effect of removing HRM from current IMSC would be that "IMSC conformance" would no longer carry any sense that the document has limited presentation complexity, which is both a significant dilution and an opportunity for future development. We might also remove the constraint on the maximum number of regions in IMSC. I'd like more industry feedback before making such a big change.

@palemieux
Copy link
Contributor

The reality is that, until recently, very few actually enforced the HRM, despite being part of conformance, so the HRM being part of the core IMSC recommendation does not guarantee its adoption.

We also have the constraints that existing IMSC editions have their own versions of the HRM.

Finally, as you point out, it is not clear how to avoid circular references if the HRM, which requires IMSC, is referenced from IMSC.

We could always split conformance as a separate document, which is not unusual.

@css-meeting-bot
Copy link
Member

The Timed Text Working Group just discussed Plan to reference IMSC-HRM from future revisions of IMSC?, and agreed to the following:

  • SUMMARY: Keep the references circular for the time being, and check that they can all be resolved successfully.
  • SUMMARY: Nigel to verify that the current text will not cause any issues.
The full IRC log of that discussion <nigel> Subtopic: Plan to reference IMSC-HRM from future revisions of IMSC?
<nigel> Nigel: This comes from a comment in #51 where Pierre said he thought we
<nigel> .. should not reference IMSC-HRM from IMSC.
<nigel> .. First question: are you saying we should remove the normative requirement to meet IMSC-HRM from IMSC?
<nigel> Pierre: Yes, that's correct. It would remove that from conformance in future editions of IMSC.
<nigel> Nigel: The argument is that it's not used?
<nigel> Pierre: Two arguments. A) to avoid the circular reference.
<nigel> .. B) It won't have a significant difference because organisations that want to enforce
<nigel> .. the HRM have called it out separately.
<nigel> .. I don't think it will cause an impact in practice.
<nigel> .. We can always have a note in IMSC that points to IMSC-HRM, e.g.
<atsushi> +1 for informative note to inform, consumer can choose to apply both or only imsc
<nigel> .. saying "this spec does not impose any constraints on presentation complexity, here's where to find it".
<nigel> Nigel: This raises the question of if IMSC-HRM needs to be a Rec track document?
<nigel> Pierre: To the extent that other orgs would use it for conformance I think they would appreciate it being
<nigel> .. a Rec track document. To a large extent it depends on those external organisations.
<nigel> .. I know some that would be reluctant to reference a WG Note for instance.
<nigel> Nigel: And the positive reason for removing from IMSC - is it only to avoid the circular reference?
<nigel> Cyril: Why is it a problem to have circular references? Other specs do that a lot - almost every standard in ISO!
<nigel> Nigel: We've always tried to be clear about the chain of dependencies from spec to spec, and avoided
<nigel> .. circular references.
<nigel> .. That was my next question too, is this the only way to avoid circular references?
<nigel> Atsushi: I'm curious too - I believe this is something that humans can check, for circularity,
<nigel> .. e.g. if A defines in terms of B and B is defined in terms of A. That can even be in one specification.
<nigel> .. It cannot easily be detected automatically.
<nigel> Nigel: That's right, there are ways to deal with this. Also, can IMSC-HRM stand on its own, or can
<nigel> .. it be used only for IMSC.
<nigel> Pierre: It's a constraint on IMSC, the dependency is pretty obvious that IMSC-HRM depends on IMSC.
<nigel> .. For better or worse, for many implementations, renderers have implemented IMSC but not the HRM validation.
<nigel> Pierre: I think circular references are bad simply because they're circular.
<nigel> .. I don't want this to be an obstacle. If there's a desire to have a circular reference I'm not going to
<nigel> .. no-vote the document.
<nigel> .. Imagine: circular refs are bad because if IMSC gets updated without updating IMSC-HRM, then you don't
<nigel> .. go back to where you started if you follow the reference. Sometimes that's harmless, sometimes harmful.
<nigel> .. Being serious about conformance. which some orgs are, then we would have a separate conformance
<nigel> .. document.
<nigel> Nigel: That would be the IMSC spec though?
<nigel> Pierre: Not always. I'm simply advocating having IMSC-HRM reference IMSC, and have an undated
<nigel> .. reference from IMSC to IMSC-HRM.
<nigel> .. Maybe later we'll have a spec on readability complexity for Western European languages, as a separate spec.
<nigel> Nigel: I'd like two things to happen:
<nigel> .. 1. We arrange it so that the decision about how to reference IMSC-HRM from IMSC is made separately,
<nigel> .. which means:
<nigel> .. 2. We word IMSC-HRM so that it can be referenced normatively from IMSC, if that's what we some time want.
<nigel> .. An easy way to deal with this circular reference is to duplicate the definition.
<nigel> Pierre: That is an editorial nightmare - I'd object to that.
<nigel> Nigel: Is it though? Is it worse?
<nigel> Pierre: Yes, it causes work.
<nigel> Nigel: My argument is that a change to one doc doesn't then require a change to the other, because
<nigel> .. the definition has document-level scope only.
<nigel> Pierre: I'd prefer circular references than defining the same term twice in two different specifications.
<nigel> .. I've never seen that end well.
<nigel> Nigel: I'm thinking that carefully arranged circular references might be the best option here.
<nigel> .. My original issue was that there should be no circular references _that cannot be resolved_, so if we
<nigel> .. can check that, it should be fine.
<nigel> Pierre: I think the references are undated now, so I think it will work.
<nigel> Nigel: Let's say we make some tweak to a defined term in a future version of IMSC, can we make
<nigel> .. it so that the reference to that term in IMSC-HRM is to the one for the version of IMSC that applies?
<nigel> Pierre: We should try to avoid doing that and if we do, we should do it very carefully.
<nigel> .. One could argue that we should reference a particular version of IMSC.
<nigel> .. Nowadays in practice people look at the latest version.
<nigel> .. The responsibility would be on us, if we make a substantive change to a definition or something
<nigel> .. depended upon in the spec, then we better warn people, it could be disruptive.
<nigel> .. Like changing glyph buffer Gn to glyph back buffer is really editorial, but it we were to change
<nigel> .. Presented Region that would have a negative impact and we might want to define a new term instead.
<nigel> Github: https://github.com//issues/51
<nigel> Pierre: Not to be philosophical, let's not make a new version of IMSC that's incompatible with an old one!
<nigel> .. I've seen that in other specs.
<nigel> SUMMARY: Keep the references circular for the time being, and check that they can all be resolved successfully.
<nigel> Pierre: We can defer this until we revise IMSC to reference IMSC-HRM.
<nigel> Nigel: No, I want us to make sure we don't put something in IMSC-HRM that gives us a problem later.
<nigel> Pierre: I'm not aware of anything that gives us that problem right now.
<nigel> Nigel: That may well be the case.
<nigel> SUMMARY: Nigel to verify that the current text will not cause any issues.

@nigelmegitt nigelmegitt self-assigned this Nov 22, 2022
@palemieux
Copy link
Contributor

palemieux commented Dec 14, 2022

@nigelmegitt See #60 which defines what conformance to the the HRM means. This definition can be referenced by other organizations and/or standards as they see fit, without having to normatively reference this specification from IMSC -- an undated informative note from future versions of IMSC might be useful.

@nigelmegitt
Copy link
Contributor Author

I did a pass through the current spec and any references back to IMSC seem fine. Closing with no change needed.

@nigelmegitt nigelmegitt closed this as not planned Won't fix, can't repro, duplicate, stale Jan 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants