Editorial review of Identifier Mapping behaviours

[garethsb]

From an AMWA Slack thread, in response to questions about the minutiae of https://specs.amwa.tv/is-04/releases/v1.3.2/docs/Data_Model_-_Identifier_Mapping.html

My personal opinion (not speaking for e.g. Architecture Review Group) is that the Identifier Mapping section could do with a rewrite based on last 5 years of experience of building real devices. The basic concepts around ID uniqueness and resource life-cycles make sense but some of the specific recommendations and requirements are... odd.

The basic concept is that if you change fundamental characteristics of something, or change what is upstream of it in the media pipeline, you have really destroyed one resource and created a new one in its place, so it should get a new ID.

In counterpoint, if you only change incidental properties of the resource, it should keep the same ID, and if you make a configuration change that "brings back" effectively the same resource, the same ID c/should be used.

The algorithm to generate UUIDs is not specified, just these things which should cause it to be changed or not changed. A name-based UUID with appropriate properties combined into the name would have the right characteristics.

Many of the detailed rules(?) and examples(?) don't correspond with actual practice, and several parts haven't been updated to reflect the change to the referential integrity rules in v1.1 to make Device the owner of Flows

[peterbrightwell]

Discussed on ARG call 2024-09-11. Agreed importance of this area (which also affects e.g. IS-13) but it's going to take time even to understand the current guidance before rewriting.