- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 19 Jan 2023 17:15:17 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <AFEEA879-61C7-444F-B2FC-64C44E8A4582@bbc.co.uk>
Thanks all for attending the first TTWG call of this year. Minutes can be found in HTML format at https://www.w3.org/2023/01/19-tt-minutes.html
Summary:
* Atsushi to action requesting an extension to the currently expired TTWG Charter
* Philippe to ask FO Council to make a decision, in absence of consensus for their proposal
* Nigel explained the direction of travel for DAPT in terms of TTML2 profile semantics
* Nigel introduced a GitHub discussion<https://github.com/w3c/ttwg/discussions/241> aimed at generating a reusable boilerplate Registry definition for TTWG use, initially in TTML2 and DAPT
Those minutes in text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
19 January 2023
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2022/12/22-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/237
[4] https://www.w3.org/2023/01/19-tt-irc
Attendees
Present
Andreas, Atsushi, Cyril, Gary, Nigel, Philippe
Regrets
Pierre
Chair
Gary, Nigel
Scribe
nigel
Contents
1. [5]This meeting
2. [6]Charter Status
3. [7]DAPT
1. [8]Clarify Profile Resolution semantics w3c/dapt#103
4. [9]Defining a Registry #241
5. [10]Meeting close
Meeting minutes
This meeting
Nigel: Today: Charter status, DAPT, Registries.
… AOB?
No other business
Charter Status
Nigel: Right now, our Charter is expired according to
[11]TTWG Charters page
[11] https://www.w3.org/groups/wg/timed-text/charters
Philippe: At the minimum we need an extension basically
Nigel: Yes
Philippe: Action item on Atsushi to request at least a 3 month
extension on the Charter so the group can continue to operate
Atsushi: Will do
Philippe: Thank you Atsushi
Cyril: We're very close to FPWD for DAPT.
… Will we be able to publish under the extension?
Philippe: Yes if it is in the current Charter
Nigel: Yes, it is.
Philippe: Until further notice the current charter stays in
effect
Nigel: Question remains open about the status of the new
Charter.
… Philippe pinged Apple and Mozilla and there was a response
from Mozilla.
[12]Member only link to reminder
[12] https://lists.w3.org/Archives/Member/member-charters-review/2023Jan/0004.html
Nigel: I responded to that.
… What I want is to get to a determined state on this, somehow,
as soon as possible.
Philippe: Yes, I agree.
… I am still working with Apple to get a response.
… I also updated Amy yesterday by email.
… The Team was tasked by the FO Council is to establish if the
FO still stands.
… Unless I can get some response I'm going to have to say back
to the FO Council that it still stands.
… I mentioned this to the AB in the previous hour and got no
reaction other than a request to talk from Florian.
… My expectation is that I will have to go back to the FO
Council.
… That's where we are.
Nigel: My reflection here is that this situation was caused by
non-responsiveness from Apple and that
… situation is simply continuing. There has to be a limit here,
I think we've reached it.
Cyril: We still have a Director?
Philippe: Formally speaking, TBL delegated it to Ralph who
delegated it to me, but in doing that he
… told me every FO has to run through the Council.
… Until the Council has made a decision the Director won't do
anything.
… To me, I did warn you that your Charter would create issues
and it did.
… On the other hand, we are still extending so no technical
work is impeded from happening at the moment.
… That's what matters the most, that you guys can still do what
you want to do.
Nigel: Except for the opportunity cost.
Philippe: You're welcome to say you just want a decision from
the Council now if you want.
Nigel: That's what I want. I see Gary nodding.
Gary: Yes, I want the FO Council just to decide.
… We're not immediately blocked but HRM might be blocked from
progressing on the Rec track.
Nigel: Since HRM is a refactor of existing Rec text I think it
is in scope and we can work on it.
Philippe: I don't think I could block it from being published
as FPWD.
Nigel: It's in WD, we will want to move it to CR.
Cyril: I also approve the decision to ask the Council to make a
decision
Nigel: Thank you
Nigel: Do we need to do anything else now Philippe?
Philippe: No, I will check with Florian on Process, but
assuming I'm in line then I will
… go back to the Council and tell them the WG wants a decision,
rather than bouncing the ball around.
… You guys are welcome to give your feelings to the Council
directly.
Nigel: I don't think we are, unless we're invited to. Obviously
we can contact Amy.
Philippe leaves
DAPT
Clarify Profile Resolution semantics w3c/dapt#103
<Github> [13]https://github.com/w3c/dapt/pull/103 : Clarify
Profile Resolution semantics
[13] https://github.com/w3c/dapt/pull/103
github: [14]https://github.com/w3c/dapt/pull/103
[14] https://github.com/w3c/dapt/pull/103
Nigel: I wanted to check in with you about where we're up to
with this.
… To formalise the requirements, the change is:
… * Define some Extension features correspond to the normative
MUST type language in the main body of the spec
… * List dispositions of features and extensions, IMSC-style
… * And then, also, for clarity, include a TTML2 Content
Profile document and a TTML2 Processor Profile document.
… Those are all in the appendix.
… Partly this is driven by a gap in TTML2 processor profile
inference semantics that looks hard to fix.
… For implementers this means that there will effectively be a
checklist of features and extensions
… to implement, in the appendix, or they can just do what the
normative statements in the body of the spec say.
… Cyril and I have discussed this, I wanted to raise with the
group in case anyone has any opinions or questions.
… If this seems interesting, please take a look.
… My next steps are that I am going through the normative
statements in the body text
… and making sure that we have extension features for all of
them so
… that the checklist approach will in fact work,
… and I expect we may need to create tests scoped to each
feature too,
… for CR exit.
… My hope is that by doing this work up-front that gets easier
rather than harder.
SUMMARY: Group informed of approach
Defining a Registry #241
Nigel: I started a GitHub discussion at [15]https://github.com/
w3c/ttwg/discussions/241
[15] https://github.com/w3c/ttwg/discussions/241
[16]GitHub Discussion on Registry
[16] https://github.com/w3c/ttwg/discussions/241
Nigel: [goes through discussion points]
… Motivation for this is we said we wanted to move some TTML2
data into a Registry,
… and we may need to do something similar for DAPT
… My hope is that we can establish a single TTWG approach to
the policy, custodian, rules etc
… that we can reuse for any Registries without having to
discuss this all again!
… Some key assumptions are listed
Gary: The Registry will be in a version control system?
Nigel: Yes
Atsushi: In fact the Registry Track document is on /TR and that
is the final version control system
Nigel: Yes, good point
Atsushi: In any case some practical process needs to be in the
document
Nigel: Yes
… Next steps:
… Please look at the strawman proposal and note any comments or
questions you have on the GitHub discussion page
… Gary I saw you were agreeing with the assumptions about what
is unfriendly to the world, so a positive
… comment about that would be really helpful.
… I'd like to spend maybe 2 meetings/4 weeks looking at this
and then if we have consensus
… the next stage is to write the proposal up more formally as
boilerplate text that can be reused.
… Make sense?
Andreas: Yes!
<atsushi> +1
Atsushi: In case public-tt email reflector stops operating,
there should be a catch-all implemented into the Process
Nigel: the W3C Process, or this TTWG one?
Atsushi: If the WG is closed and archived, and the mailing list
is frozen, then some transition to
… custodianship will happen. I am wondering how that relates to
any custodianship rules in the Registry definition.
… Which should we define and which should be considered in the
Process.
… I'm not sure what will happen after that.
Nigel: It's a good point, we can't know, by definition, what
will happen post-TTWG, assuming everything
… ends at some point!
… Maybe we should explicitly grant permission in our
boilerplate for the Team to delegate it to some other group.
Gary: It does seem like the Process should say something about
Registries, if the WG is no longer around
… then the Team can assign it to another WG or have some other
way to receive and approve requests for
… changes.
Nigel: I will raise this with the Process CG
… It's hypothetical, but one day folk will thank us for
thinking ahead!
Gary: For any W3C spec right?
Atsushi: Yes. I spent many years in Japanese academic culture,
and I've encountered these kinds of
… process concerns many times.
… What happens when the professor is gone?! I'm always curious
about these kind of things.
Atsushi: Do you want to have a new repository for the Registry?
Nigel: I don't think we should have a new repo now.
… The boilerplate can live in the TTWG repo,
… and then it should be copied to wherever it is used later.
Gary: Do we want a separate repo for each registry, or have it
live in the repo of the referencing spec?
Atsushi: I believe we can start a Registry document using
Respec or Bikeshed
… and we can set up a custom GitHub action to specify the
document, so it should be fine
… within TTML2 repo, but if we want to have a separate repo I
need to set it up.
Nigel: I couldn't find a way to do a Registry Track doc in
Respec. Are there any examples?
Atsushi: I believe Respec now has Registry configurations.
[17]How can we configure Respec for Registry track documents?
[17] https://github.com/w3c/ttwg/discussions/241#discussioncomment-4729770
Atsushi: I think it will be easier to configure a separate
Repository per Registry Track doc
… Especially having it in the same repository as an xmlspec
based spec is a nightmare for me.
Atsushi: Let me propose a separate repo for Registry track
docs, please!
Nigel: You're very welcome.
Nigel: Any more on this topic?
Meeting close
Nigel: Thanks all. Happy New Year once again (we said it at the
beginning but I didn't scribe it)
… [adjourns meeting]
Minutes manually created (not a transcript), formatted by
[18]scribe.perl version 197 (Tue Nov 8 15:42:48 2022 UTC).
[18] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 19 January 2023 17:15:36 UTC