Post by nschellenberger on Mar 28, 2023 0:39:42 GMT
I've probably got the wrong end of the stick as usual, but I am a bit confused by some of the uses of the OData.AdditionalProperties annotation in the DMTF Redfish Schema. (Again this comes up in the context of code generation / automated validation, so is somewhat esoteric and not a particular functional problem.)
As I understand the (purely natural language) definition in the OData vocabulary, OData.AdditionalProperties false represents an assurance from the server of the schema to its clients that the server itself will not produce any dynamic properties on instances of that type in its responses. The clients are free, when sending such instances in requests, to include whatever they like to the server (which may, in turn, accept or reject any such dynamic properties, but that is a consideration independent of the annotation.) (The case where the server explicitly guarantees to store the client's dynamic properties already being covered by OpenType=true.)
In particular, it seems odd that all current uses of Redfish.DynamicPropertyPatterns occur on types which are also annotated with OData.AdditionalProperties false. That would seem contradictory: the type at once allows no dynamic properties but also requires any such properties to comply with a naming convention.
In a similar vein, all of the various DMTF Actions properties (per Redfish 1.17.0 §9.6.14 "Actions property") appear to be given ComplexTypes which are empty (but for Oem), and are annotated with OData.AdditionalProperties false. That seems contradictory to their apparent intended use: for the "generic-ish" schema to be low on details, but for the server implementation to "dynamically" fill in type instances in responses with the actions actually supported by the implementation. (As an aside, should those glue types ideally have a Redfish.DynamicPropertyPatterns to highlight the "#ResourceType.ActionName" convention?)
Or do I have it wrong and Redfish intends to imply the opposite: that servers stipulating OData.AdditionalProperties false will brook no dynamic properties in client requests, but make no guarantees about what they themselves might include in responses?
As I understand the (purely natural language) definition in the OData vocabulary, OData.AdditionalProperties false represents an assurance from the server of the schema to its clients that the server itself will not produce any dynamic properties on instances of that type in its responses. The clients are free, when sending such instances in requests, to include whatever they like to the server (which may, in turn, accept or reject any such dynamic properties, but that is a consideration independent of the annotation.) (The case where the server explicitly guarantees to store the client's dynamic properties already being covered by OpenType=true.)
In particular, it seems odd that all current uses of Redfish.DynamicPropertyPatterns occur on types which are also annotated with OData.AdditionalProperties false. That would seem contradictory: the type at once allows no dynamic properties but also requires any such properties to comply with a naming convention.
In a similar vein, all of the various DMTF Actions properties (per Redfish 1.17.0 §9.6.14 "Actions property") appear to be given ComplexTypes which are empty (but for Oem), and are annotated with OData.AdditionalProperties false. That seems contradictory to their apparent intended use: for the "generic-ish" schema to be low on details, but for the server implementation to "dynamically" fill in type instances in responses with the actions actually supported by the implementation. (As an aside, should those glue types ideally have a Redfish.DynamicPropertyPatterns to highlight the "#ResourceType.ActionName" convention?)
Or do I have it wrong and Redfish intends to imply the opposite: that servers stipulating OData.AdditionalProperties false will brook no dynamic properties in client requests, but make no guarantees about what they themselves might include in responses?
