Add section about IMSC compatibility

[nigelmegitt]

Addresses #332.

• Export some terms so they can be used in other specs e.g. IMSC
• Add a section on signalling conformance to IMSC
• Add a section on IMSC compatibility, including a subsection on how DAPT metadata can be used in the subtitle production workflow.

---

Preview | Diff

[css-meeting-bot]

The Timed Text Working Group just discussed Add section about IMSC compatibility w3c/dapt#333, and agreed to the following:

• SUMMARY: Group to review

The full IRC log of that discussion

<nigel> Subtopic: Add section about IMSC compatibility #333
<nigel> github: https://github.com//pull/333
<nigel> Pierre: Nigel and I discussed this in a chat.
<nigel> .. Because IMSC prohibits use of features that are not supported,
<nigel> .. it wouldn't support DAPT features like audio.
<nigel> .. But that doesn't mean that it is impossible to build a player that would play both.
<nigel> Cyril: The subset of DAPT documents that do not contain any audio could be IMSC compatible, right?
<nigel> Nigel: Yes that's right
<nigel> .. My thinking is that this is not a problem.
<nigel> .. The analogy I draw is with images and text - we don't provide a mechanism in IMSC Text to
<nigel> .. include images. They're another representation of the text, potentially.
<nigel> .. And so is audio.
<nigel> Nigel: In the pull request (and for IMSC too) I included a section on signaling,
<nigel> .. and an informative appendix on compatibility with other TTML based specifications
<nigel> .. and within that, one example, which is IMSC Text.
<nigel> .. [summarises the changes in the pull request]
<nigel> .. The equivalent IMSC pull request is w3c/imsc#625, again, editorial.
<nigel> .. Any thoughts about this.
<nigel> Cyril: You're looking for review?
<nigel> Nigel: Yes, the IMSC pull request was opened 2 weeks ago, the DAPT one a few days later.
<nigel> .. I need reviews before I can merge.
<nigel> .. These are editorial changes.
<nigel> SUMMARY: Group to review

[nigelmegitt]

Self review:

• Somehow this introduces DAPT as a reference
• It also ends up referencing three different versions of IMSC
• The IMSC profile signalling section should be moved into the new appendix, rather than where it is at the time of this review, in the DAPT profile signalling section.

[palemieux]

I am not in love with duplicating prose between DAPT and IMSC 1.3.

Ideally the compatibility prose would be in a single document.

Perhaps it makes most sense to have it only in the DAPT document since presumably making DAPT docs conform to IMSC helps DAPT because there are already IMSC renderers?

If the prose is in the DAPT doc, then the IMSC doc can informatively point to it.

[nigelmegitt]

Perhaps it makes most sense to have it only in the DAPT document since presumably making DAPT docs conform to IMSC helps DAPT because there are already IMSC renderers?

I don't think this is the motivation. Rather, it is because it makes sense in some workflows to use DAPT as a starting point to make subtitles or captions, which would presumably be IMSC documents, and it is useful to note the potential benefits of that approach and how it can be done.

I am not in love with duplicating prose between DAPT and IMSC 1.3.

Ideally the compatibility prose would be in a single document.

...

If the prose is in the DAPT doc, then the IMSC doc can informatively point to it.

Hmm, this is worth discussing. I duplicated it because I think it is useful and important for readers of both specifications, and it's generally preferable not to make people click through to other documents unless that's strictly needed. I'm happy to be flexible with this, but I can't work out which is the better spec to contain the text, and which should refer to it, if we take that approach!

I guess the first point to consider is if the text should actually be the same, or if there are some aspects that are more important for readers of IMSC and others for readers of DAPT.

[palemieux]

I don't think this is the motivation. Rather, it is because it makes sense in some workflows to use DAPT as a starting point to make subtitles or captions, which would presumably be IMSC documents, and it is useful to note the potential benefits of that approach and how it can be done.

Having both DAPT and IMSC be subset of TTML is greatly useful since concepts and software building blocks can be reused.

In what scenario(s), would having a document conform to both DAPT and IMSC be useful if an IMSC document (created for distribution) cannot generally be used in a DAPT workflow, and vice versa?

[nigelmegitt]

In what scenario(s), would having a document conform to both DAPT and IMSC be useful if an IMSC document (created for distribution) cannot generally be used in a DAPT workflow, and vice versa?

Adding DAPT metadata to an IMSC document intended for client playback could be very useful, and even drive player behaviour in "advanced" players, for example by offering some method for viewing the speaker names that might not be in the text being displayed in a particular ISD, or for driving speech to text for translation subtitles mixed in with non-translation subtitles.

The features of IMSC Text that are absent from DAPT are essentially styling and layout. Adding either of those to a DAPT document could be used in some authoring environment to affect presentation, e.g. changing how text looks to provide emphasis in the text, that might affect how an actor voices the text when making an audio recording. However I'd caution that a DAPT document that includes translations into multiple languages might make no sense to use in the context of IMSC using an IMSC native player.

In summary:

• Using an IMSC document in a DAPT workflow could be possible, but it's not clear to me why someone would do that, maybe using hard of hearing subtitles as a starting point for a transcript of the audio, I suppose, prior to translation (my expectation is to begin with a clean transcript, more commonly, but I can imagine skipping that for cost/pragmatism reasons);
• Using a DAPT document in an IMSC workflow would clearly make sense, though I suspect that it would most likely make sense to generate n DAPT+IMSC documents from 1 DAPT document if that starting document contains multiple language variants;
• In either case it's not necessarily the case that a document created to conform to one profile can generally be used in a workflow intended for the other, but there are likely some good benefits in specific use cases.