[NeXus-tech] NeXus data file schema

[Pete Jemian]

Freddie:

Seems we now have a slightly different approach to use in preparing the 
NeXus
data file schema, based on yesterday's tech committee meeting.
Changes to what we have now will be necessary.

First, to validate a NeXus data file, we need to
 * if HDF, convert NeXus HDF  to NeXus XML but don't include the big 
blocks of data
 * transform the NeXus XML data file to an internal XML file format for 
validation
    (mostly, this is needed to handle the NXentry/definition that 
identifies if a NXDL
    application is to override the NXentry)
 * validate the internal XML file against the master XML Schema (one 
single file)

We can generate one master XML Schema to validate XML files that contain
the structure of NeXus data files.  Here is a brief description:
    transform 
{base_classes,applications,contributed_definitions}/*.nxdl.xml
    into XML Schema rules
    and combine,
    with content from nxdlTypes.xsd,
    into one master XML Schema file
    for use in validating transformed NeXus data files.

The base_class NXDL files will be transformed according to the existing 
rules
_EXCEPT_ that, since they will be combined together into a master
XML Schema, it is not necessary to use to "import" other groups.

An XML Comment can be used to describe the version of each NXDL
that contributes to the master schema.

The NXDL for applications will be transformed so that a NXmonopd.nxdl.xml
will still result in a NXmonopd group being created in the master schema.
The NeXus data file will be transformed so that NXentry/definition=NXmonopd
elements will become NXmonopd elements.  This means the part of the master
schema that validates NXroot elements needs to accept NXmonopd as an
alternative to NXentry.  (And other application NXDLs similarly to 
NXmonopd.)

Transformation rules for NXDL of base_classes and applications is nearly 
identical
except that fields and groups in base_classes are always optional while
fields and groups in applications are always required unless designated 
optional.
(This set of rules is not in the existing transformations or XML Schema 
yet.)

A couple disadvantages to the approach of a master schema are apparent:
 *   the master schema file is large (relative term, maybe 100-200 kB?)
 *   master schema file contains more than necessary for any one data file
 *   cannot be used directly to validate NeXus data files, the data files
        must always be transformed, even if they are XML
 *   any changes in the NXDL requires creation of a new master schema

Despite these disadvantages, the advantages of apparent simplicity to 
the user
and the data file validation process seem superior.

Pete

-- 
----------------------------------------------------------
  Pete R. Jemian, Ph.D.                <jemian at anl.gov>
  Beam line Controls and Data Acquisition, Group Leader
  Advanced Photon Source,   Argonne National Laboratory
  Argonne, IL  60439                   630 - 252 - 3189
-----------------------------------------------------------
     Education is the one thing for which people
        are willing to pay yet not receive.
-----------------------------------------------------------