Version translation in the Node API

[garethsb]

https://github.com/AMWA-TV/is-04/blob/v1.3.x/docs/Upgrade%20Path.md#version-translations says:

Nodes which support multiple versions simultaneously MUST ensure that all of their resources meet the schemas for each corresponding version of the specification which is supported. Where necessary features are only available in the most recent version(s) of the specification it could be necessary to expose only a limited subset of a Node's resources from lower versioned endpoints.

The typical problem is likely to be with values that aren't permitted by earlier versions' schemas.

E.g. if IS-04 v1.3 resources use property values which are not compliant per IS-04 v1.2 schema, how should it proceed - should it not include the resource at all in its Node API v1.2, or should it have the resource with offending property values being removed or replaced with default values?

Examples:

1. IS-04 v1.3 Sender with WebSocket or MQTT transport (and also therefore manifest_href set to null)
2. IS-04 v1.3 Video Flow with transfer_characteristic set to LINEAR (if omitted, default of SDR would apply)
3. IS-04 v1.3 Video Flow with transfer_characteristic set to UNSPECIFIED (if omitted, default of SDR would apply)
4. IS-04 v1.3 Device controls with authorization set to true (v1.2 schemas actually allow the additional property, so v1.2 registry probably won't reject it, but v1.2 clients wouldn't expect it)
5. IS-04 v1.3 Device controls with authorization set to false

Seems reasonably clear that in case 1, the resource should not be included in Node API v1.2. Seems reasonably clear that in case 5, the resource may be included as-is in Node API v1.2. But I'm not sure where to draw the line in between.

FWIW, it bugs me that the requirements for Query API conforming resources from e.g. v1.3 to v1.2 are the opposite of the Node API requirements in two key ways: the spec suggests removing properties that aren't prohibited by the earlier version schema, but keeping values which are:

When conforming a resource to an earlier API version, Query API implementations SHOULD make best efforts to remove attributes which were not references in earlier versions' schemas. The core attributes which fall into this category are documented here for clarity, but the same data could be derived from analysis of the schema changes between API versions. Implementers need to be aware that in the future new attributes can be defined externally to this specification.

Note that removal of these keys does not guarantee conformance to the schema of the earlier API version due to the addition of new enum values and similar features in more recent API versions. As such, Query APIs SHOULD NOT validate translated resources against schemas.