The smallest number of schema changes required to support transports extensibility #177
Conversation
Co-authored-by: Gareth Sylvester-Bradley <31761158+garethsb@users.noreply.github.com>
Co-authored-by: Gareth Sylvester-Bradley <31761158+garethsb@users.noreply.github.com>
Co-authored-by: Gareth Sylvester-Bradley <31761158+garethsb@users.noreply.github.com>
Co-authored-by: Gareth Sylvester-Bradley <31761158+garethsb@users.noreply.github.com>
Co-authored-by: Gareth Sylvester-Bradley <31761158+garethsb@users.noreply.github.com>
garethsb
force-pushed
the
publish-transports-extensibility
branch
from
209e9de to
416dd2a
Compare
|
transporttype-response-schema.json must allow vendor defined transports as per https://specs.amwa.tv/nmos-parameter-registers/branches/main/transports "Manufacturers MAY use their own namespaces to indicate transports which are not currently defined within the NMOS namespace." |
| "type": "string", | ||
| "pattern": "^urn:x-nmos:transport:[a-zA-Z0-9_]+$" | ||
| }, | ||
| { | ||
| "description": "Any manufacturer-specific transport type URN base defined in the Transports register of the NMOS Parameter Registers", |
There was a problem hiding this comment.
Do we expect manufacturer namespaces to be registered in the transports register? I feel this whole area is thin in terms of interoperability. What would a controller be expected to do when it encounters a manufacturer namespace?
There was a problem hiding this comment.
I would assume that the controller then check if it knows about this transport and then use the vendor specific schemas about such transport. There may be an issue if multiple vendors claim the same namespace ...
Suggested change Co-authored-by: Gareth Sylvester-Bradley <31761158+garethsb@users.noreply.github.com>
This does not include any markdown paragraph yet to introduce the concept of extending supported transports through NMOS Transport Parameters.