Replace workflowType with represents

[nigelmegitt]

Closes #169 and #194 by replacing workflowType with represents, which is a comma-separated list of things that the document contents can be considered an alternative for, where each of the values is an entry in a Registry Table.

---

Preview | Diff

[nigelmegitt]

The data model diagram didn't survive unscathed, and needs to be re-fixed. It's technically correct but aesthetically a disaster.

---

Update: fixed in 6b86c50

[nigelmegitt]

Question: should we make the <content-descriptor> a Registry Table so we can add other values in the future?

[css-meeting-bot]

The Timed Text Working Group just discussed Changing workflowType to alternativeFor, and agreed to the following:

• SUMMARY: @nigelmegitt Change `<content-descriptor>` to be a Registry Table; change name to "represents".

The full IRC log of that discussion

<nigel> Subtopic: Changing workflowType to alternativeFor
<nigel> github: https://github.com//pull/217
<nigel> -> https://github.com//pull/217 Replace workflowType with alternativeFor #217
<nigel> Nigel: Related issue:
<nigel> -> https://github.com//issues/169 Support within workflowType for generic script origination #169
<nigel> Nigel: The problem we had was that workflowType, being restricted to audioDescription or dubbing,
<nigel> .. didn't actually work all that well for everyone in the chain.
<nigel> .. For example it didn't cover things like production of a transcript and/or translation
<nigel> .. with the intent of using it for subtitles.
<nigel> .. So I replaced it with alternativeFor, which is a description of which components of the related media
<nigel> .. the document contents represent, or are an alternative for.
<nigel> .. It's a comma separated list, with four possible values in the list.
<nigel> .. Those are dialogue, nonDialogueSounds, visualNonText and visualText.
<nigel> .. Very few other changes were needed.
<nigel> .. Two questions from me:
<Cyril> RRSAgent, pointer
<RRSAgent> See https://www.w3.org/2024/03/28-tt-irc#T16-19-29
<nigel> .. 1. Since nothing depends on this list, at present, should the values come from a Registry Table
<nigel> .. 2. Should we keep this as a mandatory attribute, or can it be optional?
<nigel> s/Table/Table?
<atai> q+
<nigel> Cyril: I don't disagree with how it's done.
<nigel> .. Wondering if the term "alternativeFor" is the right term. I think we had "represents" before.
<nigel> .. Why this choice?
<nigel> Nigel: Yes, I thought someone didn't like "represents", maybe you Cyril?!
<nigel> .. Also, I wanted to tie it in with accessibility language and terminology a bit more closely,
<nigel> .. so that people in that world are comfortable with what this is doing.
<nigel> .. I don't mind changing it to a different name.
<nigel> ack atai
<nigel> Andreas: When I read the term, I was wondering what it means too - it's not intuitive.
<nigel> .. If we go in this direction, "represents" as a term is more accessible.
<nigel> .. Also, in the approach, I see the benefit of it, and the goal to separate the different uses more clearly.
<nigel> .. But it kind of breaks with terms used in the industry like dubbing and audio description.
<nigel> .. For that, they need to get their head around it. That's my first impression.
<nigel> Nigel: I did add a note about typical values for those use cases but I get what you mean.
<nigel> Cyril: As you indicated, "alternative" is a key word for accessibility. I need to think about it.
<nigel> .. I'm not sure a transcript is really an alternative - is the transcript used to produce dubbing or AD really an alternative?
<nigel> Nigel: I'm not glued to this - I've explained my reasoning, but the reasons aren't strong.
<nigel> Cyril: Regarding the question about registry, I'm not sure.
<nigel> .. It's good for implementation and extensibility to use a registry.
<nigel> .. But the way you've structured the keywords, it feels like it covers the entire space,
<nigel> .. with the union representing everything.
<nigel> Nigel: Maybe, but there could be something else.
<nigel> Cyril: You might want more granularity - text could be signs, time and dates etc.
<nigel> .. So now I think about it, using a registry is better probably.
<nigel> Nigel: OK
<nigel> Cyril: The last question was about making it optional vs mandatory.
<nigel> .. What is the use case where you wouldn't know what your script represents?
<nigel> .. It may evolve, but at any point in time you should know what the script represents.
<nigel> .. so I still think it should be mandatory.
<nigel> Nigel: I'm happy to take the action to turn the content-descriptor values into a Registry Table.
<nigel> .. The other possible action is renaming it to "represents" or some other thing.
<nigel> Cyril: [reads the original issue] I don't think I have a problem with "represents"
<nigel> Nigel: OK, any other thoughts before I give myself the action to change it?
<nigel> no other comments
<nigel> SUMMARY: @nigelmegitt Change `<content-descriptor>` to be a Registry Table; change name to "represents".

[nigelmegitt]

I plan to merge this on Thursday 11th April if there are no objections, since that will be 2 weeks after I made the last significant change, to make <content-descriptor> a registry table. Will check in during the TTWG call before doing so.

[mattsimpson3]

Works for me.

[css-meeting-bot]

The Timed Text Working Group just discussed Replace workflowType with represents w3c/dapt#217, and agreed to the following:

• SUMMARY: Merge pull request, deal with script event type and represents in a separate issue

The full IRC log of that discussion

<nigel> Subtopic: Replace workflowType with represents #217
<nigel> github: https://github.com//pull/217
<nigel> Matt: Apologies, I didn't notice anything coming through to me for the review request.
<nigel> Nigel: This is about replacing workflowType with represents as a list of the content types that
<nigel> .. the document represents.
<nigel> .. Last time we talked we agreed to make the <content-descriptor> into a Registry Table,
<nigel> .. and I made that change after the call.
<nigel> .. We also had it as "alternativeFor" last time and had agreed to change that into "represents" which I also did.
<nigel> Matt: [recalls the discussion, agrees with the intent]
<nigel> Nigel: The question for me now is do I go ahead and merge now or wait for a review and
<nigel> .. take appropriate response on the basis of that.
<nigel> Matt: I feel I need to read it.
<nigel> Cyril: I don't have any change to my pull request approval.
<nigel> .. Just wondering about the granularity of the "represents", could we use represents on Script Events?
<nigel> Nigel: Further down the tree?
<nigel> Cyril: Yes, if you want to know which Script Events actually correspond to each type, we already have
<nigel> .. Script Event Description which is human readable, and we have Script Event Type that has a Registry,
<nigel> .. but the values don't align - we have dialogue, spoken text, on screen text...
<nigel> Nigel: Ooh I hadn't thought of that. Looking at it, I agree, it seems like this could be one list.
<nigel> Matt: I'm happy with the general approach.
<nigel> Cyril: I'm thinking - if you were to replace the values of represents by the values of Script Event Type...
<nigel> .. If you made a set of the Script Event Types in the document, would that work?
<nigel> Nigel: I see 3 options.
<nigel> .. 1. What you said Cyril, allow the event type values to be coalesced into represents at the document level.
<nigel> .. 2. Add a mapping from event type into a simpler smaller set of represents values, e.g. title and OnScreenText in event type
<nigel> .. both map to visualText in represents.
<nigel> .. 3. Replace eventType with represents and use the same registry table for both.
<nigel> .. The nuance is that represents allows a list, whereas eventType maybe should be a single value.
<nigel> Cyril: Sorry I only noticed this now. Also the registry table for script event type needs some descriptions.
<nigel> .. I like the idea of the column for mapping to represents.
<nigel> .. I was wondering what the point of spokenText is?
<nigel> Nigel: We spent no time looking at the registry table values for event type, they're just example values.
<nigel> Cyril: I agree those are the three options, I don't have a strong view.
<nigel> .. You may not want the same granularity of description at the document level as at the script event type.
<nigel> Nigel: That's why I was thinking of the mapping idea.
<nigel> .. I think that if we want to do the mapping, that would be a new issue and pull request.
<nigel> Cyril: A 4th option is to not have the document level summary at all but inspect the document contents
<nigel> .. to see what it contains.
<nigel> Nigel: That's true, but...
<nigel> Cyril: In the workflow you want an early indication of the potential uses of the document.
<nigel> Nigel: So you're arguing against that previous point?!
<nigel> Cyril: Yes, I just wanted to note the possibility in case we want to come back to this in the future.
<nigel> Nigel: What to do?
<nigel> .. Options:
<nigel> .. 1. Merge now and open a separate issue and pull request to deal with mapping from script event type to represents
<nigel> .. 2. Go round the loop one more time and try to fix this up before merging
<nigel> .. 3. Merge now and do nothing about script event type for the time being.
<nigel> .. By the way we will need to come back to all the Registry Tables at some point to make sue
<nigel> .. they have the right values. All of the entries are Provisional right now.
<nigel> s/sue/sure
<nigel> .. Any preferences?
<nigel> .. My preference is to merge now and then incrementally improve.
<nigel> Cyril: We should have an issue that tracks it then.
<nigel> Nigel: Do you want to open that then?
<nigel> Cyril: Doing it now.
<nigel> Matt: Apologies, got to run to another meeting, please prod me if there's any more review needed. Apologies again for not noticing this one.
<nigel> Matt leaves
<nigel> SUMMARY: Merge pull request, deal with script event type and represents in a separate issue