Meeting minutes
This meeting
Nigel: On today's agenda we have:
… * IMSC-HRM
… * DAPT
… * TPAC 2023 planning
… Is there any other business, or points to make sure we cover?
group: no other business
IMSC-HRM
IMSC-HRM Tests
Nigel: Thank you Pierre for putting together the pull request to add IMSC-HRM tests
github: https://
Nigel: notes that w3c/imsc-hrm-tests needs to be added to github bot's list
Nigel: I sent an email Friday last week, asking to be allowed to merge before the normal 2 weeks
… Andreas approved. Pragmatically, I'm happy to merge this, we can point implementers to the tests
… Are there any objections to doing that?
… No objections, Pierre, feel free to merge
Pierre: Thank you
Nigel: The next steps are the call for implementations. This is really a call for everyone who can to share that we're looking for evidence of implementation
… That could be a large body of content that passes the validator or meets the requirements of IMSC HRM
Pierre: https://
Nigel: When we published CR we also published a blog post that requests implementations. This is a more refined version of that request
Pierre: It's intended to be really targeted
… It's a substantial amount of effort to pull content from libraries and run the HRM. Alternately, create an implementation of the HRM and synthetic content as an independent test vector
… To maximise the chances of people hearing about it, we should send directly to people or groups who may be interested, as a personal email
… We could do it formally, or add names to a spreadsheet to avoid sending to the same person twice
Nigel: With DAPT, we used the wiki in the repo to have an outreach log
… I don't think there's sensitivity about publishing who we've asked. But if there is, we could do it in the member-only wiki
Pierre: Might not be sensitive if it's by company
News post requesting implementations of IMSC-HRM
Pierre: Maybe we can use the the implementation report wiki, to keep it all in one place
Nigel: That's fine too
Pierre: We should add a link to the wiki from GitHub, by the way
… https://
Nigel: An action to take is tabulate the different tests into the implementation report, to show which implementations pass which tests
Pierre: I can do that
Nigel: Looking at the call for content text, the note saying that image profile support will be removed. There's a chicken and egg problem, if we don't make tests we can't include the feature in the end
Pierre: Either the community cares and will contact us, but if not we shouldn't feel bad about removing the feature. I know it's in use, we get bug reports on IMSC.js
Nigel: I'll add words on image profile, as we're looking for help
Pierre: The date is there to set expectation for when to respond
Nigel: Let's allow more time, say, October
Pierre: Do you have people in mind?
Nigel: Yes, two as implementers. For bodies of content, I should be able to do some myself, but unsure who else to ask
… Matt, would be handy also if you also want to?
Pierre: Content that's actually in production
Matt: We may have some IMSC material. I don't think we have anything suitable off the shelf
… We can try generating from some of our tools
Nigel: We're looking for real audience facing content that meets HRM requirements
Matt: I can run through some of our content
Pierre: That would be awesome
Nigel: Shall we follow up offline on who to contact?
Pierre: OK
Nigel: Is there anything else to do on IMSC HRM?
… Hearing no. Thank you for creating all those tests. Pierre and I talked last week, and the way the tests are organised might hint at improving the specification structure itself
… I can raise an issue on that. It's about how we define the available time to render an ISD, as the lesser of IPD and time from prevous ISD
… It would simplify one of the complicated bullet points in the spec
DAPT
Nigel: I sent lots of requests for wide review. We don't have a contact for ITIC, Pierre you might be able to help?
Pierre: I've pinged them, they're usually responsive, so I'll follow up with them
… I suspect this might not be on their radar
Nigel: The other thing we need to do is horizontal review. I completed and reviewed with Cyril the accessibility self review, also the security and privacy self review
… I raised the review request with the APA WG
DAPT Wide Review outreach log wiki page
Nigel: I have been logging everything I've done in the wiki
… I can't do the next action, the security and privacy reviews without adding sections on those to the spec
… I raised a PR to do that, awaiting review. If anyone can review, please do
Pull request to Add Privacy and Security Section w3c/dapt#168
Nigel: There's an action on Cyril to request the TAG and i18n reviews
… Some issues to discuss. One of the internationalisation points is about holding information only in attributes. You can't sensibly have markup in attributes so if you need to mix LTR and RTL in attributes, it's tricky
… It's a problem in DAPT as we've specified that some human-readable text, such as remarks on translations, are put into metadata attributes like ttm:desc
… TTML has long had this feature already, allowing some kinds of metadata just to be in attributes
… ttm:desc is element, not an attribute. The content specified for ttm:desc is PCDATA only, not mixed content that can contain spans with markup
… So if you want to markup language or direction on different parts of a ttm:desc element, you can't
… It also applies to ttm:name, ttm:item, ttm:copyright
<atsushi> https://
Atsushi: Does it relate to the requirement in this URL?
Nigel: Yes
Atsushi: If I understand correctly, markup is preferred
Nigel: That's very helpful. So I'll add a pointer in the issue, and say we require support for unicode control characters
Chris: Is unicode control characters what the i18n group say they dislike?
Atsushi: Assigning the attribute as markup will help with semantics, but if we use the unicode code points, there's a need to understand the unicode characters itself. Could be a processing overhead. I think that's the root cause
How can mixed direction ltr and rtl be specified in metadata elements w3c/dapt#164
Nigel: Other things we've received on DAPT, I got some instant feedback on wide review from APA WG
… They said DAPT looks like a typo, as it says "A DAPT", and ADAPT refers to something else. So people suggesting it needs a name change
… I'm not completely convinced I agree with their conclusion. I tried to search for ADAPT in the context of dubbing and audio description
… But didn't find anything. There's a WAI-Adapt, that used to be called the "personalisation task force". It's not a document or a spec, but they were sensitive to that
… Not sure what action to take. Maybe edit the start of that sentence
cpn: The title is clearly the Dubbing and Audio description Profile - perhaps if it is spelled
… out at first, rather than jumping into the acronyms, that would help.
Nigel: We could also add a pronunciation note, as we read it as D-A-P-T, not "dapt"
Matt: Reminds me of EBU-TT ;-)
APA WG feedback - name looks like a typo for ADAPT w3c/dapt#167
Support within workflowType for generic script origination w3c/dapt#169
github: https://
Matt: I looked at some of the detail in the spec. We have been thinking that a structured script file we can commission people to produce, e.g., third party, would be a useful starting point for subtitles for deaf and hard of hearing, and dubbing and translation workflows
Nigel: yes, daptm:workflowType
Matt: There's a workflow type property. It's mandatory, either dubbing or AD. When we commission one of these, it could also be used for subtitles for deaf and hard of hearing and for translation subtitles as well as dubbing
… At the moment, we'd mark it up as dubbing, but that would be erroneous
… We don't necessarily know which of the subtitling, dubbing, or translation subtitling it might need to flow through. It could be one or all three
Nigel: Are you proposing a new value for workflowType?
Matt: I think so, but don't know what I'd call it
Nigel: Would transcription work?
Matt: It needs to be something generic like that. Depends whether you see it as describing the workflow or describing what's in the document
… For commercial reasons, we might not want the third party to know it's being used for dubbing if they're not been commissioned to do that work
Nigel: That's interesting
Matt: Was there a view on whether the workflow is describing what it contributes towards?
… That was my reading of it
Nigel: Yes. I can see that being helpful
… Any other thoughts on this?
SUMMARY: Helpful to clarify if worfklowType is intended to capture current state or end outcome; adding a transcription value could be commercially useful for some user groups.
Registries
Nigel: A long time ago, I created a boilerplate registry, in the TTWG repo PR 243
github: https://
Nigel: As there's been no comments, and all comments resolved, so I propose to merge the PR, and then create registries based on this: two for DAPT
… Need to work out how, either as separate documents or directly inside DAPT
… Unless you want more time to review, I propose merging
cpn: The only thing in my mind was about editor's drafts of draft registry status,
… in Respec. Did you make any progress with that?
Nigel: I didn't do anything about that!
… It's a good point
Chris: It's a separate issue.
Atsushi: I suppose WebCodecs registry is using slimline publication that we are using for DAPT,
… where they auto-publish to /TR on merge
… If so, there's no difference between ED and the published one on /TR so the state of ED for Draft Registries
… is not needed.
cpn: Here, you haven't decided if the Registry is a separate document or within the spec itself.
Nigel: Yes
Chris: No need to delay it on my account then - that was my only question.
Nigel: Anyone else?
group: No
SUMMARY: TTWG call 2023-07-20: merge this pull request
Meeting Close
Nigel: Thanks everyone, we're over-time - let's cover any TPAC-related issues offline.
… [adjourns meeting]