You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Role name description should be more specific #188
Description
The description and recommendations around the values of "Role" in collections are currently quite vague. This may impeed interoperability. We should expand our recommendations/examples in this space, potentially referencing existing specifications in this space.
Use Case
As an ingest vendor, I would like to understand what should appear in the role field when I create multi-essence Flows.
As a store browser/Flow player, I would like to understand how to display to my user the contents of the multi-essence Flow/Source I'm looking at.
TSC 2026-05-15
This has been reworked to move away from using role to indicate editorial purpose, since that's largely a property of the Source itself. As a result a tag has been added, and role has been made optional in new option R3d which is currently proposed as the selected approach.
At the same time a new ADR has been added exploring how audio channels might be mapped in TAMS using container_mapping.
Finally #197 has been created and a draft ADR written to explore how to select the correct Flow.
This will be the topic of ongoing discussion to consider how channel mapping should work.
TSC 2026-06-26
At the suggestion of @johnbilt a field will be added to signal sort order of collection members, mainly to make them stable in places they have to be represented and displayed, and to give a hint about which to choose all things being equal.
Audio channel mapping needs more thinking: ADR0049 Option 4 probably makes most sense on navigating the tree, but we should capture somewhere the intended layout of channels in a more durable way than by convention. Some whiteboarding has produced a variety of options, which will be written up for exploration.
However the matter of audio channel mapping will be split into a separate ticket, to allow this one to progress otherwise
TSC 2026-07-10
PR #173 closed and replaced by new #225 with a cleaned up version of where we got to. Audio channel mapping now moved to a future ticket (which has not yet been opened).
There is more interest in audio channel mapping, so we should keep working on that together.
For now this one is open for review
TSC 2026-08-07
SMG: Made a few minor tweaks, better called out that editorial purpose should exist even without a collection. Now ready to merge.
GS: There's a lot in here: are we happy it's been reviewed?
SMG: It's been shrunk substantially since #225 with the audio channel questions being extracted to #226, so it's now a much smaller PR. We've had quite a lot of discussions about it.
SMG: Will do history tidyup and merge
Activity
samdbmg commentedon May 1, 2026
TSC 2026-05-01
Flagged for discussion, but I haven't actually finished the work, so we'll come back to this next time
samdbmg commentedon May 15, 2026
TSC 2026-05-15
This has been reworked to move away from using
roleto indicate editorial purpose, since that's largely a property of the Source itself. As a result a tag has been added, androlehas been made optional in new optionR3dwhich is currently proposed as the selected approach.At the same time a new ADR has been added exploring how audio channels might be mapped in TAMS using
container_mapping.Finally #197 has been created and a draft ADR written to explore how to select the correct Flow.
This will be the topic of ongoing discussion to consider how channel mapping should work.
samdbmg commentedon Jun 26, 2026
TSC 2026-06-26
At the suggestion of @johnbilt a field will be added to signal sort order of collection members, mainly to make them stable in places they have to be represented and displayed, and to give a hint about which to choose all things being equal.
Audio channel mapping needs more thinking: ADR0049 Option 4 probably makes most sense on navigating the tree, but we should capture somewhere the intended layout of channels in a more durable way than by convention. Some whiteboarding has produced a variety of options, which will be written up for exploration.
However the matter of audio channel mapping will be split into a separate ticket, to allow this one to progress otherwise
samdbmg commentedon Jul 10, 2026
TSC 2026-07-10
PR #173 closed and replaced by new #225 with a cleaned up version of where we got to. Audio channel mapping now moved to a future ticket (which has not yet been opened).
There is more interest in audio channel mapping, so we should keep working on that together.
For now this one is open for review
samdbmg commentedon Jul 10, 2026
Audio channel work captured by #226
samdbmg commentedon Aug 7, 2026
TSC 2026-08-07
SMG: Made a few minor tweaks, better called out that editorial purpose should exist even without a collection. Now ready to merge.
GS: There's a lot in here: are we happy it's been reviewed?
SMG: It's been shrunk substantially since #225 with the audio channel questions being extracted to #226, so it's now a much smaller PR. We've had quite a lot of discussions about it.
SMG: Will do history tidyup and merge