-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rather than using ttm:role for script type, define new attribute #54
Comments
Agree on the namespaced attribute, but do we really need a registry? |
I'd propose a registry assuming that no different normative requirements apply depending on the value. If they do (i.e. "if this script type then that syntax must be present, but if that other script type then some other rule must be met") then the values should be explicitly defined and can not be part of a registry. It just makes updates easier later, like if we discover that there's some benefit to splitting up the audio description script types into different workflow stages. |
The Timed Text Working Group just discussed
The full IRC log of that discussion<nigel> Topic: Rather than using ttm:role for script type, define new attribute #54<nigel> Github: https://github.com//issues/54 <nigel> Nigel: Suggestion at the moment is to define a new attribute in daptm: namespace for the script type. <nigel> .. Other alternatives are: <nigel> .. 1. Add values to ttm:role via registry <nigel> .. 2. Use some other existing metadata such as something defined by EBU in ebuttm: namespace <nigel> .. It occurred to me that the path of least resistance is to define a new attribute. <nigel> .. Then there's the question of future flexibility, where I suggested we define the value space in a registry. <nigel> .. Do we have semantic or syntactic constraints on the document based on script type? <nigel> Cyril: Yes, for example Character is mandatory when dubbing. <nigel> .. So depending on the script type value you may require this or that. <nigel> .. The more I think of it the more I prefer a specific attribute rather than making implementers worry about ttm:role and its other possible values. <nigel> .. This way we isolate/limit the work to be done. <nigel> .. My take on registry is only introduce it if we need to in the future. <nigel> .. It would only be editorial? <nigel> Nigel: It's possible to have registry tables embedded in Recs <nigel> Cyril: I would prefer to avoid that for now. <nigel> Nigel: That's fine for me, let's do that. <nigel> SUMMARY: Define new script type attribute and don't make it a registry |
Rather than defining new values for
ttm:role
for script type, I suggest we create a new attribute in thedaptm:
namespace calledscriptType
and make its values a Registry track list.We can then include this in the
tt
element so that minimal (SAX) parsing is required before discovering the script type.The text was updated successfully, but these errors were encountered: