- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 19 Dec 2024 17:02:09 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <D6E1F4AE-D55A-4E6D-8CB7-96B61F1D34C1@bbc.co.uk>
Thanks all for attending the last TTWG call in 2024. Minutes can be found in HTML format at https://www.w3.org/2024/12/19-tt-minutes.html
In plain text:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
19 December 2024
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2024/12/05-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/297
[4] https://www.w3.org/2024/12/19-tt-irc
Attendees
Present
Andreas, Atsushi, Cyril, Nigel, Pierre
Regrets
Gary
Chair
Nigel
Scribe
nigel
Contents
1. [5]This meeting
2. [6]DAPT
1. [7]CR publication status
2. [8]Add an XSD w3c/dapt#273
3. [9]Add daptm:descType feature and permit user-defined
values w3c/dapt#278
3. [10]IMSC 1.3
4. [11]Charter 2025
5. [12]AOB - Thanks for all your work in 2024!
Meeting minutes
This meeting
Nigel: Today we have some DAPT stuff, IMSC 1.3 and Charter.
… And an end of year AOB.
… Anyone for anything else, or points to make sure we get to?
Pierre: IMSC and ARIB
Nigel: That's on the agenda
DAPT
CR publication status
Nigel: I don't believe Atsushi has opened the transition
request GitHub issue yet.
… We have a late substantive PR, and there's a publication
moratorium I think next week and the week after
Atsushi: I haven't heard from Security WG and will ping Simone
for this shortly.
Nigel: I'm hoping we can get this published really soon in
January
Atsushi: I believe so. I plan to file the transition request
issue , which is already 1.5 months ago
… so I believe we can set a deadline of 0.5 or 1 month from now
… In any case I will ping them - a normal amount of time has
already elapsed.
Add an XSD [13]w3c/dapt#273
[13] https://github.com/w3c/dapt/issues/273
github: [14]w3c/dapt#273
[14] https://github.com/w3c/dapt/pull/273
Cyril: I thought there would be a quick way to run a command
line tool to validate
… a document against an XSD.
… I didn't find one.
… Maybe we should document that for people
Nigel: I still feel sure there are command line tools.
… I found a python library called xmlschema and another Java
app that wraps native Java
… functionality that should do it.
… It's really easy to write a few lines of python to validate
against the schema,
… so one option is to create a validator and put it in the
repo, or in a separate repo.
… What's most useful here?
Cyril: If I struggle, others would too. Obviously you can write
a wrapper around a library,
… and people might not be confident.
… I agree, if you have a python wrapper it would help people.
… Could be in the same repo, I don't know.
Andreas: Usually a command line utility would work. I'm not
sure what's wrong with this schema.
Cyril: I tried xmllint and it didn't work. Saxon EE may have
it, but Saxon HE doesn't.
Andreas: Saxon EE definitely, it's well known, but it's not a
free tool.
… I can also check. As you say, it's not only an issue for DAPT
but all other TTML schemas.
… Pierre, you are also implementing an online schema validator,
right?
Pierre: Yes, just the Java one. It's a wrapper.
… Very few command line validators work with more than one XSD.
… If you have dependencies between XSDs it's much harder.
… Online is best, right, because it's easiest for people to
run.
… But a command line wrapper that includes all the XSDs and
loads them properly is probably easiest for the end user.
Nigel: If it's going to help validate the PR I can add a few
lines of Python and install instructions
… into the repo.
Cyril: I support that.
SUMMARY: @nigelmegitt to add a validator script that uses the
XSD
Nigel: Any other recommendations for command line validators
also very welcome!
Add daptm:descType feature and permit user-defined values
[15]w3c/dapt#278
[15] https://github.com/w3c/dapt/issues/278
github: [16]w3c/dapt#278
[16] https://github.com/w3c/dapt/pull/278
Nigel: This has an approval and has been open for 13 days, so
my plan is to merge it tomorrow.
… I wanted to raise it in a call because it's substantive.
… And to give the opportunity for comment.
Cyril: It feels like the Registry definition should state if
user defined values should be allowed,
… I mean guidance to registry authors to think about allowing
user defined values.
Nigel: We had it in one registry and not in the other.
Cyril: Yes, we just missed it.
Nigel: But this is more than that - we were missing an
extension feature for descType,
… so this adds that.
… Once it's merged I'll add it to the implementation report.
… [describes the PR as per the PR description]
… Does anyone need more time for this? If not I'll merge it
tomorrow.
no requests for more time
SUMMARY: @nigelmegitt to merge tomorrow if no new requests for
change
IMSC 1.3
Pierre: I plan to create an initial draft after the break
Nigel: Great. Do you need any new repos?
Pierre: No I don't think so
Nigel: It's just about creating the document then
Pierre: Yes. Sorry for the delay.
… We're about to run out of time for any ARIB stuff
… so unless there's something concrete in the next couple of
weeks its not going to make it.
… The window is closing.
Nigel: We had some communication with ARIB. Are we expecting
anything from them?
Atsushi: We can send a liaison and continue with private
conversations.
… I suppose it is quite hard for them to make official
statements in the timescale.
Pierre: They've had 4 years! It's fine though, if they're not
interested.
Atsushi: I will contact them directly in person.
… They need to get stamps from bottom to top for any official
response, even if it's the same answer
… that they give unofficially.
… The easiest way is to ask them just in person about any
updates and
… after we update our spec and we ask them via an official
liaison if it is fine for them then they
… will say yes.
Pierre: I do have a philosophical question:
… So far we have done IMSC incrementally, incrementing version
numbers.
… Every time we have added and deprecated features.
… The next version will presumably be 1.3.
… Do we really want that or adopt a different scheme.
… In 1.2 there was one feature in particular added,
downloadable fonts.
… I've not seen that used in practice.
… Has it been used?
… If not, should we consider deprecating it or is there a
different mechanism
… by which we can communicate to the world that it is not
really used.
… 1.2 also did other things like improving the document
structure.
Nigel: The need for a specific font is definitely something
that the BBC has.
… The mechanism for this depends on the delivery route.
… In the UK there's an IP TV platform called Freely that uses a
DASH implementation, and
… BBC signals subtitles in DASH manifests for that, and uses a
DVB DASH feature external
… to the TTML document, which tells the player to load a font
and associates it with a fontFamily name.
… So our subtitles come out in our font.
Pierre: The IMF (Interoperable Master Format) also does this.
Andreas: And DVB TTML has a mechanism too.
Pierre: Of all the features that's not one that's been
requested.
Nigel: My philosophical reason for being a bit keen at least to
keep it is:
… what if an IMSC document is referenced directly in a web
page, that might have some kind of
… polyfill or whatever for playing IMSC documents? Without the
feature, there's no other
… way to signal the need for a font.
Pierre: I don't disagree, but we're far from having native
playback of TTML in pages.
… The question on my mind is do we want to carry around
something that's aspirational, or not?
… There are pluses and minuses. The minus is that it's not
great to have an unimplemented feature.
… It's a way to have bugs that we don't know, and a source for
spec errors.
… There are tons of things in HTML and CSS that are in the spec
and partially implemented.
… So we could go down that path.
Andreas: I'm hesitant on that feature because it's not an
exotic one.
… The use case seems to be not very far away from what could be
needed in operation.
… If it's really an issue to carry this feature around we
should ask the community, rather than
… jumpting to deprecation.
Nigel: We should think about path to deprecation, and the
community.
… The cost of retaining a feature already in a Rec is minimal.
Pierre: The cost could be in user surprise though, if document
authors use it and find it doesn't work.
… It's only one feature among so many.
… It sounds like for the first draft at least it will stay in,
and we can think about it.
Nigel: It's absolutely worth raising.
Pierre: The challenge more widely is around interop.
… Thanks for that, I appreciate the input.
… I will create a set of PRs, one for every issue, and send
them for review.
Nigel: What will you raise them against?
Pierre: The head of the repo is 1.2, as soon as we merge one
then it will become a 1.3 ED.
Nigel: In terms of timing, January should be fine.
… Otherwise getting it in the new Charter could be awkward
Pierre: It should be possible to merge at least one so we have
a draft to point to.
Charter 2025
Nigel: My draft charter PR has had approvals from everyone who
needs to.
… Atsushi, do you want me to merge it?
Atsushi: You can merge it.
… From now I need to issue advance notice to AC and update it
in line with the Charter Template
… and request Horizontal Review which takes maybe 1 month.
… After that I don't think we will receive any comments but we
may update minor things.
… Then I will request a 1 month AC review period.
… I will raise another pull request for the charter template
changes.
… Also if anyone in the WG or anyone from participating
organisations in TTWG has any comments
… on the current Charter please provide them as soon as
possible.
… Before bringing it to AC!
<atsushi> [17]check at htmlpreview
[17] https://htmlpreview.github.io/?https://raw.githubusercontent.com/w3c/charter-timed-text/refs/heads/issue-0088/charter2025/index.html
AOB - Thanks for all your work in 2024!
Nigel: Thanks for all your hard work this year everyone, a
small number of us doing a lot.
… Have a good break if you're getting one.
Pierre: Warmest wishes for the holidays and the new year
Andreas: All the best from me for the new year - have a nice
time
Cyril: Likewise!
Nigel: The next call will be 16th January. I cancelled the 2nd
Jan one due to availability.
… Let's adjourn for today and for 2024. See you next year!
[adjourns meeting]
Minutes manually created (not a transcript), formatted by
[18]scribe.perl version 240 (Tue Dec 10 03:59:59 2024 UTC).
[18] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 19 December 2024 17:02:19 UTC