Post by RonL on Jun 24, 2019 15:15:57 GMT
I’m drafting some OEM schema for functionality not covered by DMTF schema. While I realize I can do as I wish within the OEM sections, I prefer to follow Redfish convention. So. I have questions regarding providing an indication of supported capabilities of an implementation. First, here are 3 types of examples of indicating supported capabilities in DMTF schemas:
I don’t see an example (grepping for members ending in Supported) where there is a setting with enumerated values and the schema provides a related Supported member for the implementation to indicate which enumerated values are supported. This would be useful for the client UI I expect to have in order to provide just the supported capabilities in its menus.
Question 1: Is there a preference for putting the capability indicator along with the configuration member together in a substructure similar to example 1 above even if it is only these 2 members?
That seems overly complicated to me for this simple case, especially if one has a large collection of configuration members. For example (please excuse my informal shorthand notation I’m adopting for brevity):
ConfigA: a|b|c
ConfigASupported: [a, b, c]
ConfigB: d|e|f|g
ConfigBSupported: [d, g]
…
Where a|b|c represents a scalar that can take on one of the enumerated values a, b or c.
And [a,b,c] is an array consisting of a subset up to the full set of a, b and c. In the case of not supporting any, the server implementation could return a zero length array, but it is simpler and more likely to just not return either member to show a lack of support.
Question2: Also, are my thoughts in these following scenarios reasonable?
Ron
- A structure with only related members composed of a serviceEnable member and supported capabilities of that service (e.g. Manager GraphicalConsole)
- A structure of various capabilities unrelated to specific members (e.g. ServiceRoot ProtocolFeaturesSupported)
- A member called "MaxNumSupported" in Redundancy.
I don’t see an example (grepping for members ending in Supported) where there is a setting with enumerated values and the schema provides a related Supported member for the implementation to indicate which enumerated values are supported. This would be useful for the client UI I expect to have in order to provide just the supported capabilities in its menus.
Question 1: Is there a preference for putting the capability indicator along with the configuration member together in a substructure similar to example 1 above even if it is only these 2 members?
That seems overly complicated to me for this simple case, especially if one has a large collection of configuration members. For example (please excuse my informal shorthand notation I’m adopting for brevity):
ConfigA: a|b|c
ConfigASupported: [a, b, c]
ConfigB: d|e|f|g
ConfigBSupported: [d, g]
…
Where a|b|c represents a scalar that can take on one of the enumerated values a, b or c.
And [a,b,c] is an array consisting of a subset up to the full set of a, b and c. In the case of not supporting any, the server implementation could return a zero length array, but it is simpler and more likely to just not return either member to show a lack of support.
Question2: Also, are my thoughts in these following scenarios reasonable?
- I don’t see value in providing a capabilities indication for Boolean members where the client can perform a GET and observe whether the optional member in question appears in the implemented response instead just as easy as looking for a "xxxSupported" member. And if you don't support it, why provide the corresponding "xxxSupported" member?
- For read only members returning enumerations, the client UI likely would not care about what subset the implementation provides, being able to present the returned values without knowing or caring what subset the server might send (but validating them as valid enumerated values - it just doesn't care that certain enumerations may never appear in responses).
Ron
