[NeXus-committee] NeXus base class discussions

[Ray Osborn]

On 4/16/04 10:48, "Hodges, Jason P." <hodgesj at ornl.gov> wrote:

> 
> Dear All
> 
> I also have been worrying that the definitions are becoming far too
> complicated. Given that Nexus serves two communities (instrument users &
> DAS people), I think we should think of the definitions accordingly.
> First we should think of the instrument definitions, classes etc for the
> user, complexity should be kept to a minimum in this standard. This set
> of definitions is then the core standard at that is all the average user
> would ever be interested in. An expanded set of definitions can then be
> standardized (for optional use) by the DAS members etc that serves
> facilities needs for raw data/ data reduction needs etc. Of course it is
> necessary to think of both when deciding the definitions.
> 

I am sympathetic to concerns about complexity, and was thinking of reminding
people that it is not necessary to have something in the base class
definition if it is only of local use.  The things that -have- to be in the
base classes are those variables that a typical analysis program might
expect to find.  Other information that will only ever be read by a human or
used at a single facility does -not- have to be included.  You are free to
add them when you write your own NeXus file; you just can't expect others to
know what they are (or be interested).

On the other hand, complexity is inevitable.  The base classes are
effectively glossaries of possible terms.  It is not expected that every
NeXus file will contain them all.  For example, the NXgeometry classes will
be of most use in instrument simulations.  It will be rare for an analysis
program to need an NXgeometry class (with the possible exception of those
those doing generalized absorption corrections). Nevertheless, we need to
define how they should be stored for those times -when- they are included.

By the way, in one of his examples, Mark mentioned using two-theta instead
of polar_angle as an example of the complexity he disliked.  This is not an
example of complexity; this is an example of choosing a more precise term to
define something that is very loosely defined in colloquial usage.  Some
people use phi, others two-theta, on a Huber 8-circle, it's something else
(nu?).  Two-theta does not make sense to an inelastic scatterer (it's not
twice anything meaningful).  Terms like polar_angle and azimuthal_angle are
more general and precise, and once NeXus is in widespread use, it will
become perfectly familiar to the average user.  We have to insist on using
these terms if the standard is to have any coherence.

Regards,
Ray
-- 
Dr Ray Osborn                Tel: +1 (630) 252-9011
Materials Science Division   Fax: +1 (630) 252-7777
Argonne National Laboratory  E-mail: ROsborn at anl.gov
Argonne, IL 60439-4845