[NeXus-committee] Status of base definitions

[Peterson, Peter F.]

Please read the entire next paragraph.

We have ratified all of the base classes and I just finished changing the definitions so they are valid XML files and make them consistent with the decision that base definitions will not specify bit lengths (NX_FLOAT, not NX_FLOAT32). As promised we are currently in a period of review before a final vote to ratify all of the base classes once and for all. During the review period *all* of the ratified base classes are locked, with the add comment field reinabled. There is also an "proposed ammendment" page <http://www.neutron.anl.gov.:8080/NeXus/82> for suggesting ammendments to the base classes. The review period will end on August 2, 2004 at 9:00AM central. At that point there will be a vote on the ammendments, implementation of the ammendments, then a final display of what the changed base classes are.

Now for those that read entire messages...Before releasing this work to the public we still need to settle the following:
 - units: At the NIAC meeting in CalTech we determined that units will be specified in the singular form, without abbreviation. However, in the current classes they are listed with wide variety; e.g. "cm", "Angstrom3", and "10^n*meter". This needs to be settled and the decision propagated through all of the classes.
 - group and field names are to be specified without abbreviation and using underscores to separate words. Currently there are things like "x_cen" which violate this convention.
 - When restricting the allowed values for fields there is two conventions for string values: "calibration sample" and "calibration_sample". One needs to be chosen.
 - There is no method for specifying chemical composition of a sample. 
 - Connecting data to detector was only specified for point detectors. This needs to be generalized to multiple area detectors.
 - For single crystal experiments there must be a way to specify the goiniometer settings, frequently known as the sample orientation. There is no place to put this at the moment.

Also, to abuse my position, people have suggested the following:
 - NeXus files can be used for storing reduced and processed data. To do this properly there needs to be a mechanism for storing an "audit trail" of where the file came from, what programs were used (including versions), and any other external parameters used in the process.
 - Related to the previous item, a audit trail of how and when the calibration for the instrument found in the file was done.
 - To ease the job of finding instrument characterization measurements (background and incident spectrum), information to locate those measurements can be stored in the file.
 - For large files there is a desire to have a "thumbnail" view of the data without loading the entire NXdata and resampling. Various requests have come in for a place to put a thumbnail image for each NXentry. An example is a 640x480 jpeg: <thumbnail type="NX_BINARY" mime_type="image/jpeg"/>.

Peter Peterson
Executive Secretary, NIAC