- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 22 Dec 2022 17:30:47 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <65EAB1BB-9D35-432D-8391-7C2C5C52176E@bbc.co.uk>
Thanks all for attending this, the final TTWG call of 2022. Minutes can be found in HTML format at https://www.w3.org/2022/12/22-tt-minutes.html
Our next call will be on 2023-01-19.
Until then, wishing you well over the festive season, whatever you’re doing.
Those minutes in text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
22 December 2022
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2022/12/08-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/235
[4] https://www.w3.org/2022/12/22-tt-irc
Attendees
Present
Atsushi, Cyril, Gary, Nigel, Pierre
Regrets
none
Chair
Gary, Nigel
Scribe
nigel
Contents
1. [5]This Meeting
2. [6]Rechartering Formal Objection Council status update
3. [7]IMSC-HRM
1. [8]CR1 Exit Criteria
2. [9]Clarify that the IMSC HRM specifies document
conformance w3c/imsc-hrm#60
4. [10]DAPT
1. [11]ttp:profile on root, and conformance terminology
w3c/dapt#104
5. [12]AOB - next meeting
6. [13]Meeting close
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:
[14]https://lists.w3.org/Archives/Member/
member-charters-review/2022Dec/0001.html
[14] https://lists.w3.org/Archives/Member/member-charters-review/2022Dec/0001.html
[15]https://lists.w3.org/Archives/Member/
member-charters-review/2022Dec/0000.html
[15] https://lists.w3.org/Archives/Member/member-charters-review/2022Dec/0000.html
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: [16]https://github.com/w3c/imsc-hrm/pull/59
[16] https://github.com/w3c/imsc-hrm/pull/59
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> [17]https://github.com/w3c/imsc-hrm/pull/60 : Clarify
that the IMSC HRM specifies document conformance
[17] https://github.com/w3c/imsc-hrm/pull/60
Github: [18]https://github.com/w3c/imsc-hrm/pull/60
[18] https://github.com/w3c/imsc-hrm/pull/60
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: [19]https://github.com/w3c/dapt/issues/104
[19] https://github.com/w3c/dapt/issues/104
<Github> [20]https://github.com/w3c/dapt/issues/104 :
ttp:profile on root, and conformance terminology
[20] https://github.com/w3c/dapt/issues/104
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]
Minutes manually created (not a transcript), formatted by
[21]scribe.perl version 197 (Tue Nov 8 15:42:48 2022 UTC).
[21] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 22 December 2022 17:31:08 UTC