[Nexus] About application definitions

[V. Armando Sole]

Happy New Year!

At the ESRF we do not intend to use the old fashion way of writing the 
application definitions at the top level inside an NXentry but inside 
one (or several) NXsubentry. That will allow us to treat the files in 
the same way whether they are single or multiple technique files.

I am revising the documentation concerning NXsubentry but I do not know 
if the latest documentation is the one at:

http://download.nexusformat.org/sphinx/classes/base_classes/NXsubentry.html?highlight=nxsubentry

So, I would like to get that point confirmed.

I have to say (repeat?) that the way definitions are presented to the 
potential users look very tedious. We *do* intend to recreate the NeXus 
structure as much as we can, but as definitions are currently presented 
they almost imply to repeat the NXentry structure in the NXsubentry. For 
you it was easy to say "we have foreseen a single application definition 
at the NXentry level, we just give the option to have it at an 
NXsubentry level and that's all". My point is that when having it at the 
NXentry level, you needed some structure to keep things tidy, but when 
NXsubentry appeared, the structure is overkill.

 From a practical point of view, a simple definition for technique XXXX, 
requiting datasets I0 and It and a set of energies, it would require:

entry at NXentry
     ...
     whatever_name at NXsubentry
         definition (NX_CHAR="XXXX", @version, @URL)
         I0 [NXFLOAT]
         It [NX_FLOAT]
         energy [NX_FLOAT]

So, it continues to look a mistake to me, to present the definitions as 
forcing to have "energy" inside an NXmonochromator group, I0 inside an 
NXmonitor or an NXdetector and It inside an NXdetector. Please note that 
I am not saying it is a bad idea to have them inside those groups!. What 
I am saying is that to validate that a file implements the above 
definition, one only needs to validate the presence of I0, It and 
energy. Whether they are datasets of links to actual datasets is 
irrelevant.

You may say that since we intend to implement the NeXus structure, we 
should not worry so much and you are correct. The point is, and I repeat 
myself, that some communities and/or facilities are elaborating their 
own "data exchange" formats based on HDF5 that are *nothing else* than 
the equivalent of an application definition the way I have presented it 
here.

I would aim to present application definitions in that way. The entrance 
ticket for the potential users just interested on data analysis would be 
"less expensive". All what you would be asking compared to community 
driven definitions would be to include strings specifying the technique 
they implement, the version (optional but great!) and the URL describing 
it (optional but also great!).

You could go as far as presenting that approach as the "official NeXus 
approach to incorporate community driven definitions". I think you have 
no choice, so better show some flexibility.

Best wishes,

Armando