Validation check for reserved prefixes and suffixes #639
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
b600071 to
8afb8e6
Compare
1 task
rettigl
reviewed
May 16, 2025
|
@rettigl fixed most of what you were suggesting. Before, I was also missing that fields with reserved suffixes must be written as e.g. |
rettigl
approved these changes
May 19, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
2CA4
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
NeXus defines reserved prefixes and suffixes that may only be used in a certain context.
Here, we implement checks for both prefixes and suffixes:
DECTRIS_prefix is only valid for attributes inDECTRISdetectors, i.e., inNXmx). Any other use is prohibited. We check the context and log an error if such attributes exist out of context. Note that for some reserved prefixes, we can not write them from pynxtools, so their use is disallowed. We still write these attributes as undocumented, though (could be removed).NXobject, but also inNXdataandNXtransformations). Note that you can use these suffixes freely outside of their scope (e.g. you can useFIELDNAME_end) anyway you like if you are not withinNXtransformations. Here, we basically check that if a reserved suffix is used, the initial field also exists (e.g. if we define a fieldmy_field_weights, we check thatmy_fieldexists as well.