[NeXus-tech] Summary of last telco

[Pete Jemian]

Very quietly, in the deep background, I'm working on a revision to the 
nxdl.xsd (XSD Schema) that will validate/define the difference between a 
base class and an application definition.  (See definitions ticket #266) 
  The current implementation in the branch is not going to be the final 
since it has a significant problem (comment #14).  Rather, it will be 
necessary to make separate "definition" elements for each case. 
Contributed definitions do not require a third case since they will be 
either a proposed base class or a proposed application definition.  As a 
result, _all_ NXDL specifications will be modified, but with only a 
trivial change.

The only complication in this work is to avoid unnecessary redefinition 
of common components shared by base classes and application definitions. 
  This is a technical detail best left for an uninterrupted few days. 
Which happens rarely.  It will get done.


There was talk of moving from subversion to git.  What's the current 
status of that talking?  Is it waiting for ticket #266 to be closed?

Pete



http://trac.nexusformat.org/definitions/ticket/266

On 10/22/2013 6:56 AM, Mark Koennecke wrote:
> 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?
>
> _______________________________________________
> NeXus-tech mailing list
> NeXus-tech at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-tech