Skip to content

[Feature]: Change pynwb.validate(io=...) to match pynwb.validate(paths=[path]) #1807

@rly

Description

@rly

What would you like to see added to PyNWB?

From #1777 and follow-up to #1511

The behavior of the pynwb.validate function with paths kwarg, pynwb.validate function with io kwarg, and pynwb.validate CLI are inconsistent and therefore confusing. We added the first option while keeping the other two to maintain backwards compatibility, but this is causing issues downstream. These methods should all do the same basic validation behavior with the same argument names, except that the pynwb.validate function with paths kwargs and CLI should open each passed file using NWBHDF5IO (and later using the generic read function that will be added, to account for Zarr files) and then call pynwb.validate on each io object.

This is a breaking change requiring a major version bump.

Is your feature request related to a problem?

No response

What solution would you like?

Desired changed features:

The core validate function should take as input an HDMFIO object and return a list of machine-readable JSON validation results (#1179).

  • It validates a file against all namespaces together (requires Account for all loaded namespaces during validation hdmf-dev/hdmf#608)
  • You cannot validate against a single namespace in isolation because it doesn't really make sense. The file may contain objects of a neurodata type from a non-dependent namespace, which would not be interpretable. e.g., validating against "core" only, when the file contains a Device subtype defined in an extension, and when the Device is required by another type, results in an error because the Device subtype is not recognized (see [Bug]: PYNWB_VALIDATION when using ndx-miniscope extension #1777).
  • You can validate against either all namespaces together or all namespaces loaded in the global type map.

There should be a separate function and CLI to get a list of cached namespaces and their dependencies of a file.

Do you have any interest in helping implement the feature?

Yes.

Code of Conduct

Metadata

Metadata

Assignees

Labels

category: enhancementimprovements of code or code behaviorpriority: highimpacts proper operation or use of feature important to most userstopic: validatorissues related to validation of files

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions