'@name' in 'Module' vs in 'ModuleClass'
According to current definition, 'Module' is the subclass of 'ModuleClass'. So a 'Module' should inherit the '@name' attribute from 'ModuleClass'.
In the example of 'mseed.xml', 'extends' from ModuleClass "BooleanState", the 'name' attribute is overridden as "power". Does this mean the Module "power" no longer contain the attribute 'name'="BooleanState", but only 'name'="Power"?
<Modules> <Module name="power"> <extends domain="hgi.dal.core" class="BooleanState"/> </Module> </Modules>
Or should it be modeled as an extended attribute: "ModuleInstanceName" (according to TS-0023, or find another similar term) so as to keep the original type information (i.e. "BooleanState") in the Module subclass? In this case, "Module" really becomes something more than "ModuleClass".
<Modules> <Module instanceName="power"> <extends domain="hgi.dal.core" class="BooleanState"/> </Module> </Modules>
It is currently used as in your first example, for example in the DeviceRefrigerator: three different Modules for different temperature zones, all inherit from the ModuleClass Temperature. So,inheriting changes the name. So far, I always assumed that in a real implementation the parent-child-relationship is kept as in most objet oriented languages (like using an is-a operator).
Assuming we follow your second example, would we allow multiple levels of inheritance? Then this special name (instanceName) would not help much.
And should we introduce the "hiding" of inherited data points and actions in a child class?
What i was thinking is it might be useful to keep the original class-name information in the inherited Module. But you mean, in the implementation, the parent-child relationship is always kept even without a explicit attribute, so no need to introduce 'instanceName' to keep the original class info i.e. 'name'?
In the case of multiple-level inheritance, you may be right. Unless each level introduce its own 'instanceName', parent class info cannot be fully kept along the blood line..
But from the data exchange perspective (sever-client), there is no clear clue whether the 3 temperature zones are all inherited from the same 'temperature' ModuleClass if we don't keep the original class info?
As for introducing the 'hiding' capability, i don't understand how it's related to this issue..
I am not sure whether we need to distinguish this. If we define that an is-a operation and identification must be possible then we don't need to have an extra naming construct. Example:
A <- B <- C
(C inherits from B, B inherits from A)
Then the following term should be true:
C is B && B is A && C is A
hiding: you are right, I will open a new issue.