- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Fri, 13 Sep 2024 09:46:17 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <746CD11C-80D5-4610-A8D0-D2A7D00650EC@bbc.co.uk>
Those minutes from yesterday in plain text, as promised:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
12 September 2024
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2024/08/29-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/290
[4] https://www.w3.org/2024/09/12-tt-irc
Attendees
Present
Andreas, Atsushi, Cyril, Gary, Nigel, Pierre
Regrets
-
Chair
Gary, Nigel
Scribe
nigel
Contents
1. [5]This Meeting
2. [6]DAPT
1. [7]CR Must-have issues
2. [8]Consider defining restrictions per Script Type
w3c/dapt#75
3. [9]Remove Script Event Type, use Represents instead
w3c/dapt#241
4. [10]Add legacy metadata structure and media zero
timecode metadata w3c/dapt#240
3. [11]IMSC superscript/subscript support w3c/imsc#583
4. [12]TPAC 2024
5. [13]Meeting close
Meeting minutes
This Meeting
Nigel: Today we have DAPT, IMSC and TPAC planning. Any other
business?
no other business
DAPT
CR Must-have issues
[14]CR must-have issues
[14] https://github.com/w3c/dapt/issues?q=is:issue+is:open+label:"CR+must-have"
Nigel: Last week we said we'd try to get PRs open for today so
that they will have had a long enough
… approval period to merge in time to agree to publish CR at
TPAC
… I've opened 3 pull requests, one can be merged tomorrow if
not today
… [15]w3c/dapt#237 Add nested div feature and mark as
permitted, at risk
… That was a technical one, can be merged tomorrow I think.
… [16]w3c/dapt#233 I'd like to come back to.
… [17]w3c/dapt#232 I opened a PR for last night
[15] https://github.com/w3c/dapt/issues/237
[16] https://github.com/w3c/dapt/issues/233
[17] https://github.com/w3c/dapt/issues/232
Cyril: I'm not sure about the approach, let's talk about it.
Nigel: OK
… [18]w3c/dapt#227 to merge represents and script event type,
which I just opened earlier today,
… which we can have a quick look at.
… Then we had 75 and 44 which Cyril was going to have a look
at.
[18] https://github.com/w3c/dapt/issues/227
Cyril: I think we can close them, shall we discuss them, maybe
start with #75?
Nigel: Let's do that
Consider defining restrictions per Script Type [19]w3c/dapt#75
[19] https://github.com/w3c/dapt/issues/75
github: [20]w3c/dapt#75
[20] https://github.com/w3c/dapt/issues/75
Cyril: A lot of things have changed since this was opened.
… The gist of this issue is, if I place myself as a Netflix
receiver of scripts,
… I want to be able to validate that if I receive a dubbing
script it's not an audio description script,
… and vice versa.
… I can see that if somebody delivers a dubbing script to
Netflix we will check that the <audio>
… element is not present in it, and reject a delivery if it
does, for example.
… We do that for subtitles, have additional restrictions not in
IMSC but Netflix-specific.
… When I opened this issue I wondered how many of these
restrictions should be core vs
… organisation specific. I thought it would make sense to
distinguish these transcript types.
… For example in an original transcript each event should have
at most one <p> and the language source
… should be equal to the xml:lang always.
… We can go to CR without this. The risk is that the actual
profile that is implemented has more
… restrictions than what it specified in the spec, and some
people may impose additional restrictions than
… the spec.
Nigel: What should we do - take the label off, or close with no
action?
… I think we're missing a proposal for what these per-script
type restrictions would be.
Cyril: I realise that, we could still decide to go to CR
without them.
Nigel: I think so, yes.
Cyril: This could be a good segue into the discussion about
represents.
Andreas: Apologies I lost a bit of progress on the spec.
… Just to check the use case, it is to work out whether a
script is a dubbing script or an audio description script?
… I think that is a reasonable use case.
Nigel: This has hurt my head in the past because I'm not sure
how prescriptive we are about
… the different lifecycle stages for getting to localised
versions - is an original language transcript
… a dubbing script, say? It's a start for one, or for
subtitles, or both.
Cyril: I would like to keep this open and propose something
based on represents
SUMMARY: @cconcolato to make a proposal
Remove Script Event Type, use Represents instead [21]w3c/dapt#241
[21] https://github.com/w3c/dapt/issues/241
github: [22]w3c/dapt#241
[22] https://github.com/w3c/dapt/pull/241
Nigel: [shows pull request preview]
… Question about whether to formalise the relationship when a
content descriptor is a subset of another one.
Cyril: 2 comments, one editorial, one technical.
… 1. Editorial: there's no question on the intent, merging the
fields is a good decision.
… Why did you choose to make it a Shared Property?
… It behaves very similarly to text language source and other
attributes.
… 2. Technical: I think we need to better explain the
inheritance model that goes with it.
… To me, I see Represents as similar to xml:lang or
daptm:langSrc - you specify it somewhere and it
… applies to the whole tree, and if you specify it somewhere
else it is possibly to narrow down the value
… for that part of the tree, a group of divs or one div.
… For example for a dubbing script a represents at the top
level could say "dialog nonDialogSounds"
… and for specific events you would say this is a dialog or a
nonDialogSound.
… We shouldn't be able to say something in represents at the
top level and then contradict that at a lower level,
… e.g. by not having any nonDialogSounds in the body but
claiming it at the root.
Nigel: My thinking here is that there is no inheritance model
… You could make the inheritance model one where you replace an
inherited value with one
… specified at a lower level, but additive inheritance would
not work.
… Let's say I commission a transcript including dialog and
nonDialog sounds, but the media
… has no nonDialogSounds, then it makes sense to have no Script
Events that represent nonDialogSounds.
[discussion of inheritance, inclusion and exclusion
constraints]
Gary: Could the top level one be a default one?
Nigel: Could make represents mandatory on Script Events
Cyril: Can't have a single Script Event be visual and nonVisual
at the same time.
Andreas: Why can't we apply the same inheritance rule as
xml:lang, so that the lowest
… attribute in the tree defines what the event is, so it's not
a restriction, it's just overriding what is above.
… It's a general rule, e.g. for namespaces, xml:lang and
others.
… To make this restriction makes it complicated to validate.
Nigel: It's a list, and it only applies to the element it is
on.
Cyril: In that case your idea to make it mandatory on Script
Event is probably better.
… It would lead to some verbosity.
Gary: An alternative is to have represents be a single item and
have a documentRepresents with a list
Cyril: Could do that
Gary: Then you could do normal inheritance
Cyril: It's like langSrc, where the document can have multiple
source languages
… I realise that langSrc is just one value but I thought we
discussed having multiple values
Nigel: Need to close this due to time. Please add comments to
the issue clarifying the requirements.
Cyril: OK
SUMMARY: Reviewers to consider the PR and if necessary comment
regarding the requirements, in the issue.
Add legacy metadata structure and media zero timecode metadata
[23]w3c/dapt#240
[23] https://github.com/w3c/dapt/issues/240
github: [24]w3c/dapt#240
[24] https://github.com/w3c/dapt/pull/240
Cyril: I added my comment already. Why add the legacy
structure?
… Why make it an element not an attribute, e.g. on the tt
element?
Nigel: I wanted to provide a home for legacy conversion data,
and to make it really clear that
… it isn't something that should carry any presentation
semantics.
… We could do it the way you suggest, of course.
… I fear that people won't read the spec and putting the data
here gives a really strong hint.
Cyril: I think I raised the point in the past - it's not
specific to DAPT, it could be a TTML thing.
… I understand that we need it in DAPT, but maybe we could
define it in the TTML namespace, and transfer
… it into TTML2 later.
Nigel: I'm happy to consider other use cases, I actually don't
know of any right now.
Andreas: I was present when we started the discussion but
haven't followed the current solution of the issue.
… When we started I also had the feeling that it could have
wider applicability than DAPT, and have other use cases,
… so would be better in another namespace, or aligned with the
parent specification.
… Sorry for not fully reviewing what you have proposed here.
… What we have in EBU-TT, couldn't the same thing be expressed
with what you propose here for DAPT?
Nigel: I don't think so, happy to be shown otherwise.
… Need to close for time, please continue to review and
discuss.
… Wonder how strong your feeling is about the data structure as
proposed, Cyril?
Cyril: I don't understand the point of the legacy metadata, why
it's different from other conversion data.
… Also would like to see an informative reference to ESEF to
explain it.
SUMMARY: Review to continue
IMSC superscript/subscript support [25]w3c/imsc#583
[25] https://github.com/w3c/imsc/issues/583
github: [26]w3c/imsc#583
[26] https://github.com/w3c/imsc/issues/583
Nigel: This was discussed in the EBU Media Access Technology
group call last Tuesday,
… and the main summary is that for French especially, if the
feature were available it would be used,
… but French people are used to non-superscript ordinals at the
moment.
… There are other similar use cases for numbers in chemical
symbols or in "square metres" etc,
… in Norwegian and German.
SUMMARY: EBU positive about requirement, unclear if anyone
"cannot live without" the feature.
TPAC 2024
Nigel: We've had agenda requests - see [27]w3c/ttwg#291
[27] https://github.com/w3c/ttwg/issues/291
Gary: I will be around remotely, at least on the Friday.
Nigel: Time constraints for the WebVTT topics?
Gary: I don't think I have any, I'm good to go at any time
during the meeting
[28]Wiki page
[28] https://www.w3.org/wiki/TimedText/tpac2024#Agenda_and_Schedule
Nigel: If anyone has any constraints on timing, please let us
know
… MediaWG meets in the morning, we may be better using the
afternoon for the WebVTT topics
Gary: I'll ping James and Marcos to see if they have any time
constraints.
Nigel: Thank you
Meeting close
Nigel: Thanks everyone. Our next meeting will be, as on the
TTWG Calendar, Monday 23rd September,
… joint with the MEIG.
… [adjourns meeting]
Minutes manually created (not a transcript), formatted by
[29]scribe.perl version 229 (Thu Jul 25 08:38:54 2024 UTC).
[29] https://w3c.github.io/scribe2/scribedoc.html
From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thursday 12 September 2024 at 18:05
To: "public-tt@w3.org" <public-tt@w3.org>
Subject: {Minutes} TTWG Teleconference 2024-09-12
Resent from: <public-tt@w3.org>
Resent date: Thursday 12 September 2024 at 18:04
Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2024/09/12-tt-minutes.html
There seem to be system problems preventing me from sending a plain text version in the normal format, so I’ll send that on later when the problems are resolved.
Our next meeting will be at TPAC, a joint meeting with the Media and Entertainment Interest Group.
Please do check out the TTWG TPAC wiki page<https://www.w3.org/wiki/TimedText/tpac2024> for links, topics and schedules, and request any agenda topics by adding a comment to w3c/ttwg#291<https://github.com/w3c/ttwg/issues/291> which is the agenda GitHub issue.
One last thing: I didn’t get round to the agenda topic<https://github.com/w3c/ttwg/issues/290#issuecomment-2331075335> for the first ever community-wide W3C survey today – and the deadline is tomorrow! Here’s what Coralie sent:
For the first time, W3C is conducting a community-wide survey. We want to get to know our community better, investigate needs, and understand our community’s vision of how we fulfill our mission for the world-wide web.
This survey is being run through Typeform, an online survey platform that supports all major operating systems, is accessible, and has been tested to confirm compatibility with assistive technologies.
This survey is open to W3C Members and people who participate in W3C group activities, and anyone involved in the Web. It is anonymous and takes 6 minutes or more to complete.
We ask that you use the link that you received in email if you did. We prepared a survey that has 4 additional questions that are specific to W3C Members. So two versions of the survey are being circulated, one for members and one for non-members.
Please help us disseminate the links of the survey for the rest of the community with your group(s), team(s), your networks, your friends that are interested in the impact of web standards on humanity.
The survey closes on Friday 13 September 2024. We look forward to hearing from you.
English Members: https://gzobeteisdd.typeform.com/to/uaESY6Q8
English External: https://gzobeteisdd.typeform.com/to/TeoUTslq
French Members: https://gzobeteisdd.typeform.com/to/U1C58KLO
French External: https://gzobeteisdd.typeform.com/to/Tyj602HT
Japanese Members: https://gzobeteisdd.typeform.com/to/dniLBGUQ
Japanese External: https://gzobeteisdd.typeform.com/to/zGk33stT
Chinese Members: https://gzobeteisdd.typeform.com/to/Mu6ARgiJ
Chinese External: https://gzobeteisdd.typeform.com/to/S0KxM3CK
Received on Friday, 13 September 2024 09:46:35 UTC