Open nigelmegitt opened 1 year ago
I don't think DAPT script should represent intermediate states. I don't expect authoring tools to exchange half-finished documents.
This is related to #52
Because it might be tricky to define exact values in the spec with precise semantics for a script event type, we would prefer if the spec used a generic "string" type and define a registry where each company could define its own types.
A registry is fine. Although it might be tricky, I think it would be beneficial for industry in general at least to try to converge on commonly used values where possible, with an extension mechanism where none of the defined values works.
The feels almost as a duplicate of #140
Agree, #140 looks like a duplicate of this issue in many ways. Certainly we should be able to address both with the same decision.
Considering how to mark up a document that's mid-stage in the workflow between two script types, for example an Original Dialogue List that's being translated, let's say half of it has been translated.
First question: what should the script type be?
Second question: Would it be reasonable to mark up each Script Event with a
ttm:role
indicating its contents, using the same values as we are defining for Script Type? For example those events that have been translated could be marked asx-DUBBING_TRANSLATED_DIALOGUE_LIST
whereas those that have not yet been translated could be marked asx-DUBBING_ORIGINAL_DIALOGUE_LIST
.Since there's no restriction on the content elements that can have a
ttm:role
attribute we can't actually stop people from doing this, so I think it would make sense to embrace it.We might want to define how the
tt/head@ttm:role
attribute value should be set in case this practice is adopted. For example, "The Script type SHOULD indicate the earliest workflow step used by any of the Script Events in the document" or something like that.