Open prjemian opened 2 years ago
As mentioned in the above issue #1059, in NeXus Base Classes are already extended in another Base Class using the 'type=' notation:
_Here, the assumption is that all data items defined under the tree of the referenced base class and in the trees of the base classes referenced therein will automatically be available for reuse under a (not always) specified ‘name’ in the new definition. Hence, definitions are inherited inside baseclasses as well. When such reference also provides extra definition elements (e.g. doc in case of NXbeam/DATA), this is handled as a specific definition only valid for this item which further specifies the original base definition (in case of NXbeam/DATA(doc), the original NXdata(doc) is actually extended).
The use of 'extend=' for the a definition does the same as the 'type=' in case of a group. Hence, we do not introduce anything new, or complicate the standard. The contrary, we would simplify it, because the practice of not using the 'extend=' in base classes results in copied definitions which will become unmaintainable with the increase of the Vocabulary.
A good example is NXentry and NXsubentry. Checking them shows that a huge majority of the items inside NXentry could have been simply inherited by NXsubentry, instead of being copy-pasted over. While (@IDF_version, title, experiment_identifier, experiment_description, collection_identifier, ntry_identifier, etc.) are all the same, it seems that the only reason while the items (@default, entry_identifier_uuid, DATA, thumbnail/@type, thumbnail/@mime_type) are different, because some changes were introduced only in one location and the other were accidentally forgotten to be updated. Using the 'extends=' also in Base Classes would allow keeping them maintained much easier.
Will be happy to contribute with a pull request also for cnxvalidate with the small modification to support the use of extends not only in Application Definitions but also in Base Classes.
@mkoennecke Is not it the line at the end of NXVloadBaseClass where we could include the call "mergeInheritance(self);" just like in case of NXVloadAppDef to support merging definitions from another Base Classe? Hence, we could avoid the need of copying definitions over manually as in case of NXsubentry.