This is a bit of an odd one in that going from /map/active to /map/active/{outputId} whereby you're selecting one property from a sub-object rather than simply an element of an array isn't quite like any other part of this or other NMOS APIs. However, if the aim of that resource is to provide a minimal version of /map/active it may still be useful to have the 'activation' key present. If that's going to be possible, it makes more sense for the other key to be 'map' rather than showing the contents of 'map'. Based on that, it's the example that's wrong.
https://github.com/AMWA-TV/nmos-audio-channel-mapping/blob/v1.0.1/examples/map/map-active-output-get-200.json is unfortunately inconsistent with the schema https://github.com/AMWA-TV/nmos-audio-channel-mapping/blob/v1.0.1/APIs/schemas/map-active-output-response-schema.json
Conclusion from Slack discussion:
This is a bit of an odd one in that going from /map/active to /map/active/{outputId} whereby you're selecting one property from a sub-object rather than simply an element of an array isn't quite like any other part of this or other NMOS APIs. However, if the aim of that resource is to provide a minimal version of /map/active it may still be useful to have the 'activation' key present. If that's going to be possible, it makes more sense for the other key to be 'map' rather than showing the contents of 'map'. Based on that, it's the example that's wrong.
Worth noting that the test suite doesn't current test the /map/active/{outputId} endpoints. - I've added https://github.com/AMWA-TV/nmos-testing/issues/550 Also, that this inconsistency would have been caught if https://github.com/AMWA-TV/nmos-doc-build-scripts/issues/1 were implemented.