Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

base classes always extend NXobject. Can a base class extend another base class? #135

Open
prjemian opened this issue Jun 13, 2022 · 4 comments
Assignees

Comments

@prjemian
Copy link
Contributor

prjemian commented Jun 13, 2022

@sanbrock
Copy link

also nexusformat/definitions#1059

@sanbrock
Copy link

sanbrock commented Sep 15, 2022

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 base_classes 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.

@sanbrock
Copy link

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.

@sanbrock
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: Done
Development

No branches or pull requests

2 participants