[NeXus-committee] NeXus data file inspection tool. NeXus at ILL. We need to be more flexible.

[Pete Jemian]

Joachim:

Both of these instances are worthy of NIAC review since they are more 
restrictive than the permissive view you encourage.

You are not the first person to interpret the NeXus documentation as 
defining strict rules for what field names can and cannot be used. 
Indeed, the permissive view you encourage is the intent of NeXus 
although you point out it is not expressed as clearly permissive.

Time to change the way we write these words?

Pete



On 9/2/2014, Pete wrote:
 >> Can you you please cite the place in the NeXus documentation that makes
 >> these keywords invalid?

On 9/2/2014 8:26 AM, Joachim Wuttke wrote:
 >
 > Not from the docs but from the manuscript we are working on:
 > "A NeXus base class is rather a dictionary of allowed keywords."
 > Which implies: keywords that are not in the dictionary are not allowed.
 >
 > Even clearer in the next section:
 > "An application definition specifies a data structure for
 > a given application domain. The data structure consists
 > of a hierarchy of NeXus groups. For each group, a min-
 > imum content is specified. Application definitions are
 > therefore complementary to base class definitions, which
 > specify the maximum content of groups."
 >
 >>
 >> On 9/2/2014 7:42 AM, Joachim Wuttke wrote:
 >>> In the last few years, ILL has converted most of its instrument
 >>> to NeXus. Well, something that looks like NeXus - but is invalid
 >>> because they add keywords of their own invention. For instance,
 >>> in the NXdisc_chopper group they use 4 valid keywords and
 >>> 5 invalid ones (guide_height, .., slotwidth).
 >
 >


On 9/2/2014 8:28 AM, Joachim Wuttke wrote:
> And in the docs:
>
> 2.1. Introduction to NeXus definitions
>
> "Base class definitions define the complete set of terms that _might_
> be used in an instance of that class."