Rather than using ttm:role for script type, define new attribute

[nigelmegitt]

Rather than defining new values for ttm:role for script type, I suggest we create a new attribute in the daptm: namespace called scriptType 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.

[cconcolato]

Agree on the namespaced attribute, but do we really need a registry?

[nigelmegitt]

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.

[css-meeting-bot]

The Timed Text Working Group just discussed Rather than using ttm:role for script type, define new attribute w3c/dapt#54, and agreed to the following:

• SUMMARY: Define new script type attribute and don't make it a registry

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