search

w3c / dapt

Dubbing and Audio description Profiles of TTML2
https://w3c.github.io/dapt/
Other
5 stars 3 forks source link

Add inline Registry Section #196

Closed nigelmegitt closed 5 months ago

nigelmegitt commented 6 months ago

Closes #195. Incorporates and modifies the TTWG boilerplate registry definition, and specifies starter tables for daptm:descType and daptm:eventType.

Preview | Diff

nigelmegitt commented 6 months ago

Self-review: it would be much more helpful to readers if the registry tables were placed within the sections where they apply rather than in appendix G. I'll refactor to move them there.

nigelmegitt commented 6 months ago

Still to do: a few styling tweaks, and a note about registry sections in the document conventions.

nigelmegitt commented 6 months ago

Ready to review now @cconcolato and anyone else.

nigelmegitt commented 6 months ago

There will be some more tweaks to this based on https://lists.w3.org/Archives/Public/spec-prod/2023OctDec/0009.html from @jyasskin and a W3C Slack response from @dbaron:

There were other points, but I think they're less clear cut, and worth discussing more. In some cases it seems like this PR does what the Process says it should do, but the Process might need fixing.

nigelmegitt commented 6 months ago

Those tweaks made in 20380b0.

One change made is to adjust the styling so the blue registry table section sidebar only appears on the left rather than on both sides, because data tables get "fixed up" by the W3C fixup.js script to be in a wrapper with the "overlarge" class, which means they can overlap the border on the right.

nigelmegitt commented 6 months ago

LGTM Do we need section G.1.2.2.2 given that TTWG is the custodian of the defined registries?

Yes, see G.1.1 which allows for a path in case TTWG no longer exists.

css-meeting-bot commented 6 months ago

The Timed Text Working Group just discussed Add inline Registry Section w3c/dapt#196, and agreed to the following:

The full IRC log of that discussion <nigel> Subtopic: Add inline Registry Section w3c/dapt#196
<nigel> github: https://github.com/w3c/dapt/pull/196
<cpn> Nigel: Thank you Cyril for reviewing. Please take a look
<cpn> ... We wanted registry tables in a few places, so this uses new features in W3C Process. They can be updated outside the normal Rec track process
<cpn> ... I've based this on the boilerplate text in the TTWG repo
<cpn> ... In doing this, I've had to raise a Process issue, but it's probably acceptable now to meet process requirements
<cpn> ... Please look, to see if it has any issues
<nigel> SUMMARY: Please review!
nigelmegitt commented 5 months ago

I plan to merge this on Nov 23 if there are no unresolved objections, since that will have been 2 weeks since this PR was properly ready for review.

himorin commented 5 months ago

Added some minor questions, but overall seems fine for me. One note, it seems working for now, but we may need to turn postProcess function into Promise if timing issue (not replaced within streamline publication) occurred.

nigelmegitt commented 5 months ago

we may need to turn postProcess function into Promise if timing issue (not replaced within streamline publication) occurred

How could there be a timing issue? As far as I can tell, everything else has already run beforehand, except maybe fixup.js which doesn't interact with this. I'd be more worried that making it async would cause a timing issue.

himorin commented 5 months ago

we may need to turn postProcess function into Promise if timing issue (not replaced within streamline publication) occurred

How could there be a timing issue? As far as I can tell, everything else has already run beforehand, except maybe fixup.js which doesn't interact with this. I'd be more worried that making it async would cause a timing issue.

In respec processing, if promise returned for postProcess, respec will wait to be resolved before going to next task. https://lists.w3.org/Archives/Public/spec-prod/2017JanMar/0006.html (around mid)