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

Extend cnxvalidate to validate any NeXus file #13

Open
mkoennecke opened this issue Jun 14, 2016 · 5 comments
Open

Extend cnxvalidate to validate any NeXus file #13

mkoennecke opened this issue Jun 14, 2016 · 5 comments

Comments

@mkoennecke
Copy link
Contributor

Currently cnxvalidate balks if there is no application definition. There is a desire to continue validating against the base classes then, with a hard coded empty application definition. Thus cnxvalidates scope is extended to a general NeXus file validation tool. There may be changes required to the recursion to support that.

mkoennecke added a commit that referenced this issue Jul 15, 2016
…ition.

As implemented now, validation happens against a minimal application definition containing
just an NXentry.

Refs #13
@mkoennecke
Copy link
Contributor Author

I added support for validating NeXus files without an application definition to cnxvalidate.
This has still to be reviewed before we merge it with master.

@mkoennecke
Copy link
Contributor Author

Still to do:

  • Turn current errors about missing root level attributes and application definition to
    warnings
  • Handle the ignore* Attributes
  • Check what happens with a non NeXus HDF5 file, it should come back with that it cannot find
    an NXentry

@mkoennecke
Copy link
Contributor Author

It may be that MXML may be able to pull in default attributes for definitions from the mxdl.xsd

@mkoennecke
Copy link
Contributor Author

With the ignored* attribute it may still make sense to report this as an informational message.

@mkoennecke
Copy link
Contributor Author

There are two ways to implement this:

  • Add code to SecondPassIterator() to recurse into additional base class groups find
  • Make a FAT application definition which contains all that is possible from the base class definitions

There is probably little value in this: we can only find names which are not allowed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant