[NeXus-tech] Summary of last telco

[Mark Koennecke]

Hi,

I made a little summary of what we were up to on the last telco.
To keep us on track. I hope I did not miss something important.

Hear you tomorrow,

              Mark

NeXus Telco Summary, Week 41
==============================

Main topic: requirements of MX

1) Coordinate frame (done)
2) SI Units, can be specified in application definition
3) Missing feature: standard way to detail standard error:
    Suggestion: append _esd to data name.
4) variants, still open
5) Structure of beam etc. May  be missing fields, easy
6) Rotation axes. This kicked off a discussion on NXgoniometer.
    Which is essentially a collection of axes. What was felt missing
    was a way to give a field a type. NeXus knows types up to now
    only for classes. A type for a field would mean that certain
    attributes must be present. For examples for an axes: 
transformation_type,
    vector, offset, depends_on and some.

    There was some understanding that this field type should be a
    separate attribute, like NX_class.

    The idea of an axes class came up and was rejected (temporarily)
    for two reasons:
    - The transformation_type, vector,... attribute scheme has been
      decided upon
    - A common criticism of NeXus is that there is to much hierarchy. An
     NXaxis group would increase this.

    It was felt that this is a bigger thing. To let sink in  a bit and
    discuss at the next Telco
7) Detector orientation and such: covered, additional fields may be needed
8) Image masks: covered with the DECTRIS work
9) some more additional fields

Other pending issues:


NXgoniometer
-------------

Is ready for suggestiona and voting pending the resolution of the
field type axis issue mentioned above. As NXgoniomter is just a
collection of axes and a depends_on field and may be some stuff like
name etc.


Variants
------------

Different versions of fields, may be updated after a refinement.
We more or less ditched the approaches:
- Having an NXsubentry because it requires populating a whole
   hierarchy with links
- NXvariant group, holding only variants of some fields. Deemed to
   complicated

The most popular approach appeared to be some form of appending
_variant to field names. Or, if there is more then one variant:
_variant_somename, _variant_someothername. It is still unclear
how this is to be used. IMHO, the latest stance on this was to
update the actual value with the best one and store the old one
in a variant. There was agreement that time_stamps ought to be added
to affected fields and variants.

Polarisation
-----------------

Current polarisation fields in NeXus reflect neutron use cases.
Needs enhancement for X-rays. Waiting for an expert to make
suggestions.

NXaperture
-------------

Eugen trying to reformulate this.


NXslit and NXpinhole
-----------------------

Check again.

FEL
--------

Herbert argued for two more detector parameters in order to cober the
FEL case. This was not principally opposed but Herbert was tasked to
provide a little description what this is for. For us to understand
what we agree too.


Missing
------------

I am feeling like I missed something important in this summary.
But seem not to remember it. Someone to help out?