Clarify that the IMSC HRM specifies document conformance

The Timed Text Working Group just discussed Clarify that the IMSC HRM specifies document conformance w3c/imsc-hrm#60, and agreed to the following:

SUMMARY: @palemieux to draft an edit as per the above discussion.

The full IRC log of that discussion

<nigel> Subtopic: Clarify that the IMSC HRM specifies document conformance w3c/imsc-hrm#60
<nigel> Github: https://github.com/w3c/imsc-hrm/pull/60
<nigel> Pierre: Mostly a discussion between me and Nigel.
<nigel> .. I'm proposing that conformance be expressed in terms of a sequence of ISDs
<nigel> .. generated from a collection of IMSC Documents.
<nigel> .. My thinking is that there is an unambiguous procedure for doing that so
<nigel> .. I think it's pretty clear. I'm not sure I fully understand your concerns Nigel.
<nigel> .. I understand one practical concern, that the test suite is not going to have a sequence of ISDs
<nigel> .. as artefacts, that I agree with.
<nigel> .. In my mind the conformance section of the document is very different from the testing artefacts
<nigel> .. and what's in the spec can be more abstract than what is in the tests so I don't see the conflict there.
<nigel> q+
<nigel> .. I want to understand what you see as the issue with conformance being of a sequence of ISDs
<nigel> .. generated from a group of IMSC Documents.
<nigel> ack ni
<nigel> Nigel: I completely agree with how you just expressed it but that's not what the spec says.
<nigel> .. It doesn't say that the sequence of ISDs are from an IMSC Document.
<nigel> Pierre: I think you're concerned with the turn of the sentence that starts "Given a sequence of ISDs ..."
<nigel> Nigel: Yes I think that's right
<nigel> Pierre: Okay, thanks, I'll propose a change to the sentence to flip that round.
<nigel> .. It's important to leave it loose because "given a sequence of IMSC documents" the sequence of ISDs
<nigel> .. is not the same as what you process. First, the last ISD is infinite. Second, there's typically some
<nigel> .. temporal interval used to clip the sequence.
<nigel> .. I don't think we need to go to that detail in the conformance, I think we need to keep it vague.
<nigel> Nigel: Two things. Infinite last ISD, and application of temporal clipping.
<nigel> .. Looking at Infinite last ISD, I don't think that makes any difference, because there's no work to do
<nigel> .. on the last ISD.
<nigel> Pierre: Unless there's a sequence of IMSC documents and you need to move on to the next one
<nigel> .. before the ISD from the current one ends.
<nigel> Nigel: Ah, that's another issue again, about sequence handling which I don't think we've formally defined.
<nigel> Pierre: That's because the algorithm doesn't care - it just cares about ISDs, which is so that we don't have
<nigel> .. to deal with clipping of ISDs etc.
<nigel> Nigel: Let's say there's an error found in an ISD that's clipped at the boundary of two IMSC documents.
<nigel> .. Is it the first doc, the second doc, or the clipping metadata?
<nigel> .. We have no control or knowledge of the clipping metadata, but we need to declare what thing is non-conformant.
<nigel> Pierre: Is your concern that it will be difficult in testing to separate ISD creation from IMSC HRM?
<nigel> .. Meaning that the results we get might be wrong because the ISD creation step was inconsistent across
<nigel> .. implementations.
<nigel> Nigel: My concern is that there are too many unknowns.
<nigel> .. We have no defined semantic for combining ISDs from different IMSC documents,
<nigel> .. so we cannot point to a source of error if there is one.
<nigel> .. I think we could reasonably say "here are the rules for ISDs generated from one IMSC document,
<nigel> .. and if you have a way of combining ISD sequences from multiple documents, that's fine, you can
<nigel> .. run the algorithm on that, but we can't tell you what's wrong because it's out of our scope".
<nigel> Pierre: In my mind it's been straightforward because ISDs have a duration and you just stack them.
<nigel> Nigel: That's not enough!
<nigel> Pierre: Maybe that's where the disagreement is.
<nigel> Nigel: You have to have rules for dealing with overlaps.
<nigel> .. We haven't ever defined that. Something like EBU-TT Live does.
<nigel> Pierre: In my mind you would never do that because there would be an ambiguity.
<nigel> .. You could say "a non-overlapping sequence of ISDs".
<nigel> Nigel: You have to know how the inevitable overlaps are generated.
<nigel> Pierre: You could say that the overlaps have to have been resolved.
<nigel> Nigel: But then that resolution depends on some algorithm we haven't specified and don't know.
<nigel> .. We can't assess conformance given an important missing step.
<nigel> Pierre: We could require that the test inputs are single IMSC documents, synthesised from ISD sequences.
<nigel> Nigel: That would be fine.
<nigel> Pierre: That would remove the need to deal with overlap.
<nigel> Nigel: Yes, we need to move overlap resolution elsewhere.
<nigel> Pierre: So in my mind the algorithm is purely about a sequence of ISDs, and we don't care where they come from,
<nigel> .. but in testing we only test single IMSC documents.
<nigel> Nigel: I think we should put all the overlap resolution and recombination into an IMSC document outside the spec,
<nigel> .. instead, the input is one IMSC document that generates the sequence of ISDs, and that one document
<nigel> .. is a pass/fail.
<nigel> .. And we can note that some folk might have schemes where there are multiple IMSC documents that
<nigel> .. generate multiple ISDs, and that's great, but they have to be responsible for generating an IMSC documewnt
<nigel> .. that generates the equivalent sequence of ISDs.
<nigel> Pierre: Okay I can take a stab at that, I think I understand, thanks.
<nigel> SUMMARY: @palemieux to draft an edit as per the above discussion.
<nigel> s/documewnt/document

w3c / imsc-hrm

Clarify that the IMSC HRM specifies document conformance #60