Overriding and hiding of data points and actions in inModuleClass inheritance
In SDT version 3, when a Module inherits from a ModuleClass, it inherits all the data points, actions etc from its parent.
To support the upcoming Product feature it might be useful to
- override existing data points etc in order to change, for example, optionality. The overriding could be done explicitly for only a certain number of attributes of a data point, e.g. assigning a new optionality, unit of measure. We could (but I am not sure about this) also support a kind of final state for a data point etc, which would mean that the sub-element must not be changed when subclassing.
- hide existing (optional) data points etc in order to remove them from a sub-classed ModuleClass. I am not sure how to do this in a simple way. Perhaps we need define a section where all hidden / not-inherited elements are stated.
My first idea would be a whitelist mechanism. By default, when the whitelist entry is missing, then all attributes or actions are inherited. When the whitelist is present, only the inherited attributes or actions are inherited. Perhaps we need 2 whitelists, one for attributes, one for actions?
It's more complex in the optionality about data-point comparing to ModuleClass. There are two aspects: 1) whether a particular data-point is supported/implemented in the inherited ModuleClass; 2) even if the data-point is inherited, it may not always report values (temporarily unavailable, or not actively reported due to some reason), so an App may fail to read the data-point from oneM2M platform.
For the second case, how do we describe? In some OTT solutions, it's also called 'optional' if the data-point is allowed to be empty.
In my opinion we need to distinguish between the following cases:
A data point is implemented and accessible. The the data is returned (when read) or processed (when written).
Optional data point: the implementation of a data point is optional, ie. a device might not support a data point at all. This could be by intentionally not implementing or not inheriting the data point. Accessing such a data point in any way (reading or writing) should (must?) result in an error.
Unavailable data point: A device supports a data point, but for whatever reason it is not accessible. In that case a default behaviour must be defined, ie. a default value or the last read value. This strongly depends on the use case.
It might be make sense to distinguish between a null/nil value and a default value.