Meeting minutes
This Meeting
Nigel: Today we have DAPT, IMSC and TPAC planning. Any other business?
no other business
DAPT
CR Must-have issues
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
… w3c/dapt#237 Add nested div feature and mark as permitted, at risk
… That was a technical one, can be merged tomorrow I think.
… w3c/dapt#233 I'd like to come back to.
… w3c/dapt#232 I opened a PR for last night
Cyril: I'm not sure about the approach, let's talk about it.
Nigel: OK
… 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.
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 w3c/dapt#75
github: w3c/
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 w3c/dapt#241
github: w3c/
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 w3c/dapt#240
github: w3c/
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 w3c/imsc#583
github: w3c/
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 w3c/
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
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]