Schema

From NeXus

Until now NeXus has used the NeXus MetaDTD format for documenting classes and definitions. This page details work in progress to move definitions into XML schema.

Using XML schema allows more rigorous validations to be performed on all NeXus format files and, for NeXus XML files in particular, would make reading by non-NeXus API programs easier. It is hoped the majority of the migration work can be completed in time for the upcoming NIAC2008 and NOBUGS meetings.

If you have any comments or suggestions, please add them to the discussion page

XML Schema For NeXus

Note: only parts of some of the classes/definitions mentioned below have currently been converted as examples.

The structure currently being used is:

• Basic data types (NX_FLOAT32, ISO8601 etc.) are all defined in NeXus.xsd along with enumerations such as nx:validShape
• Base classes are each defined in a separate *.xsd file (e.g.NXentry.xsd) These files will include NeXus.xsd and any other NX*.xsd definitions they need. Using separate files will hopefully make future changes easier for instrument editors etc.
• Instrument definitions will be created by redefining NXentry.xsd (via NXentryType) to change the required components from optional (minOccurs="0") to mandatory (minOccurs="1"). See PROCESSED.xsd for an example
• Some object-orientated features have been added as they make definition writing easier and avoid duplication. For example:
  • an abstract NXchopper has been created that is inherited by NXdisk_chopper and NXfermi_chopper
  • all NeXus object inherit from nx:classBaseType (it just has a "name" attribute that all classes have)
  • beamline components inherit from nx:componentType that contains "distance" and NXgeometry members etc.

For a graphical view see the generated schema documentation.

The schema file area is http://svn.nexusformat.org/definitions/trunk/schema/ which also contains the *.html generated schema documentation files.

The development schema files have an xsi:schemaLocation attribute set to reference files in the same directory, which is useful for debugging. After checkin to subversion, they are published to http://definition.nexusformat.org/schema/3.0/ with the xsi:schemaLocation attribute edited so that they will self include from the web when used for validation purposes. The trunk version of the NeXus XML API now adds a XML schema attributes automatically.

To validate an XML file on the web you can use the following general sites in addition to http://definition.nexusformat.org/validate:

http://www.w3.org/2001/03/webdata/xsv          Go to the second section (file to upload), browse and then "upload and get results"
http://tools.decisionsoft.com/schemaValidate/  Upload file to XML instance (no need to add a schema) and press validate

You can also use the "xmllint" tool, which is part of libxml2. This doesn't seem to pick up the xsi:schemaLocation tag so you need to give the schema path by hand e.g.

    xmllint --schema http://definition.nexusformat.org/schema/3.0/BASE.xsd  my_nexus_file.xml

There is also now an nxvalidate command built as part of the nexus-trunk kit from http://download.nexusformat.org/kits/snapshots.shtml

This command will validate a NeXus file (HDF or XML) by silently converting it to XML with the data stripped and then either

• using "xmllint" if this program is available locally, or
• using "wget" to send the file to the NeXus web site for validation and then displaying the result

Type nxvalidate -h for a list of options

The NXtest.xml file created by running napi_test-xml from the NeXus testsuite can be validated using nxvalidate

TODO

• Finish partially completed schema and translate remaining Meta DTD files
• Define schema types for valid scientific units and reference these from the relevant elements
• Look into using key/keyref/unique constraints as part of validation
• Create some XSLT transforms for displaying schema as tables on the Wiki