Meeting minutes
This Meeting
Nigel: Today we have:
… * Rechartering Formal Objection Council status update
… * DAPT
… * IMSC-HRM
… * AOB - 1st meeting of next year.
… Any other AOB?
Rechartering Formal Objection Council status update
Nigel: Thanks Atsushi for pointing me at messages that PLH sent recently:
https://
https://
Nigel: This is partly in response to the Members' meeting at 1400 on 2022-12-20 and the conversation
… that I, Philippe, and Florian had about the options for FO Council.
… However, it does mean that the frustration with getting a timely response may return if they do not
… answer quickly. In the meantime, what is going to happen about the TTWG Charter that expires
… at the end of the year?
Atsushi: As far as I heard, FO Council may not provide decision, but provided proposal that TTWG accepted.
… So if the counter-parties accept that then that would resolve the objections, which might be one possible scenario for now.
Nigel: Yes. My question is what will happen to the TTWG Charter?
Atsushi: In parallel, a short extension is expected, from my conversation with Philippe.
Nigel: Okay, thank you.
Atsushi: At least with that, possible publications around Jan/Feb.
Nigel: Any more points to raise on this topic?
IMSC-HRM
CR1 Exit Criteria
github: https://
Nigel: Is this still a draft PR?
Pierre: Yes, to prevent merging, as much as anything else.
… The outstanding thing is how to label at-risk features.
… I'm not happy with it.
… I think we should go back to a simple statement rather than linking to issues.
… It's confusing, and doesn't bring us anything because we don't have many features at risk.
… I propose to remove those links.
Nigel: I'm not sure what the problem is - I'm actually quite happy with it as it stands.
Pierre: OK, what about you Atsushi?
Atsushi: I don't have objections
Pierre: Okay, maybe we should resolve those threads and call it done.
SUMMARY: Proceed as-is
Clarify that the IMSC HRM specifies document conformance w3c/imsc-hrm#60
<Github> https://
Github: https://
Pierre: Mostly a discussion between me and Nigel.
… I'm proposing that conformance be expressed in terms of a sequence of ISDs
… generated from a collection of IMSC Documents.
… My thinking is that there is an unambiguous procedure for doing that so
… I think it's pretty clear. I'm not sure I fully understand your concerns Nigel.
… I understand one practical concern, that the test suite is not going to have a sequence of ISDs
… as artefacts, that I agree with.
… In my mind the conformance section of the document is very different from the testing artefacts
… and what's in the spec can be more abstract than what is in the tests so I don't see the conflict there.
… I want to understand what you see as the issue with conformance being of a sequence of ISDs
… generated from a group of IMSC Documents.
Nigel: I completely agree with how you just expressed it but that's not what the spec says.
… It doesn't say that the sequence of ISDs are from an IMSC Document.
Pierre: I think you're concerned with the turn of the sentence that starts "Given a sequence of ISDs ..."
Nigel: Yes I think that's right
Pierre: Okay, thanks, I'll propose a change to the sentence to flip that round.
… It's important to leave it loose because "given a sequence of IMSC documents" the sequence of ISDs
… is not the same as what you process. First, the last ISD is infinite. Second, there's typically some
… temporal interval used to clip the sequence.
… I don't think we need to go to that detail in the conformance, I think we need to keep it vague.
Nigel: Two things. Infinite last ISD, and application of temporal clipping.
… Looking at Infinite last ISD, I don't think that makes any difference, because there's no work to do
… on the last ISD.
Pierre: Unless there's a sequence of IMSC documents and you need to move on to the next one
… before the ISD from the current one ends.
Nigel: Ah, that's another issue again, about sequence handling which I don't think we've formally defined.
Pierre: That's because the algorithm doesn't care - it just cares about ISDs, which is so that we don't have
… to deal with clipping of ISDs etc.
Nigel: Let's say there's an error found in an ISD that's clipped at the boundary of two IMSC documents.
… Is it the first doc, the second doc, or the clipping metadata?
… We have no control or knowledge of the clipping metadata, but we need to declare what thing is non-conformant.
Pierre: Is your concern that it will be difficult in testing to separate ISD creation from IMSC HRM?
… Meaning that the results we get might be wrong because the ISD creation step was inconsistent across
… implementations.
Nigel: My concern is that there are too many unknowns.
… We have no defined semantic for combining ISDs from different IMSC documents,
… so we cannot point to a source of error if there is one.
… I think we could reasonably say "here are the rules for ISDs generated from one IMSC document,
… and if you have a way of combining ISD sequences from multiple documents, that's fine, you can
… run the algorithm on that, but we can't tell you what's wrong because it's out of our scope".
Pierre: In my mind it's been straightforward because ISDs have a duration and you just stack them.
Nigel: That's not enough!
Pierre: Maybe that's where the disagreement is.
Nigel: You have to have rules for dealing with overlaps.
… We haven't ever defined that. Something like EBU-TT Live does.
Pierre: In my mind you would never do that because there would be an ambiguity.
… You could say "a non-overlapping sequence of ISDs".
Nigel: You have to know how the inevitable overlaps are generated.
Pierre: You could say that the overlaps have to have been resolved.
Nigel: But then that resolution depends on some algorithm we haven't specified and don't know.
… We can't assess conformance given an important missing step.
Pierre: We could require that the test inputs are single IMSC documents, synthesised from ISD sequences.
Nigel: That would be fine.
Pierre: That would remove the need to deal with overlap.
Nigel: Yes, we need to move overlap resolution elsewhere.
Pierre: So in my mind the algorithm is purely about a sequence of ISDs, and we don't care where they come from,
… but in testing we only test single IMSC documents.
Nigel: I think we should put all the overlap resolution and recombination into an IMSC document outside the spec,
… instead, the input is one IMSC document that generates the sequence of ISDs, and that one document
… is a pass/fail.
… And we can note that some folk might have schemes where there are multiple IMSC documents that
… generate multiple ISDs, and that's great, but they have to be responsible for generating an IMSC document
… that generates the equivalent sequence of ISDs.
Pierre: Okay I can take a stab at that, I think I understand, thanks.
SUMMARY: @palemieux to draft an edit as per the above discussion.
DAPT
Nigel: Cyril, any points to raise to the group?
Cyril: Mainly same as last time, editing continues.
… We can talk about the profile issue.
… Nigel, I'm working on your notion of transcript still!
Nigel: Yes, there are two pull requests that both deal with those in different ways.
Cyril: Yes, the first pull request didn't define the terms and was tricky to understand.
Nigel: If it would help I can merge the two pull requests so you can see the changes all together.
Cyril: Yes, go ahead.
ttp:profile on root, and conformance terminology w3c/dapt#104
github: https://
<Github> https://
Cyril: I'm happy that we're digging into this but we need to make it easy for new folk to understand.
Nigel: I think #103 is improving this.
Cyril: From a video world, having two profiles is confusing and we need to clarify it.
… They don't know about processor profile vs content profile.
Nigel: This issue came from a conversation with Glenn about some things I wanted to do that
… TTML2 didn't seem to allow.
… The starting point is TTML1 backwards compatibility.
… For DAPT, we simply aren't interested in that.
… We only want to use contentProfiles and possibly optionally processorProfiles, but not ttp:profile
… but all the relevant feature designators in TTML2 include the TTML1 #profile, and effectively require
… implementers to code for ttp:profile even though we are prohibiting its use.
… Glenn proposed a way to express this in the formal language of TTML2 profiles, which I've done
… in #103. It essentially defines an extension for this one thing and says "this is prohibited".
… There's a message from Glenn that I haven't read yet about TTML2 handling of different values of the
… value attribute on the ttp:feature element.
… The essence is we want to be able to say "it's permitted in a document, and must be implemented in a processor"
… which doesn't seem possible in TTML2. I think he's pointing me at something I missed.
Cyril: Every standard has that, optional features that must be supported by the player.
Nigel: Of course!
Cyril: I'm not clear about this processor profile part.
Nigel: One of the things I've done is move the profile definition into the appendix, still normative,
… but kept the important/interesting stuff that we need people to understand to before the appendices.
… It keeps the formality but makes the document seem shorter.
Cyril: I like that idea.
Nigel: At the moment I've had to define a content profile and a processor profile distinctly,
… and it'd be much better if we could have only one. I will keep working with Glenn to understand if
… I can actually do that.
SUMMARY: @nigelmegitt to continue talking to @skynavga about how to simplify this.
AOB - next meeting
Nigel: Next meeting is scheduled for 2023-01-05. I can't make that.
Cyril: I also sent regrets for that.
Gary: Might be worth cancelling.
… I think a lot of people are out so there won't be much to discuss anyway
Nigel: Okay I'll cancel and our next call will be on 2023-01-19.
Meeting close
Nigel: Thanks everyone for all your work this year and for suffering through the great TTWG Charter fiasco.
… Have a good break, look forward to seeing you next year.
Cyril: Thank you for your chairing!
Gary: Yes, thank you.
Atsushi: Thank you.
Pierre: Warmest wishes for the holiday season.
Nigel: [adjourns meeting]