[NeXus-tech] Proposed NXpoise class

[Tobias.Richter at diamond.ac.uk]

Hi all,

For mostly those reasons I invented "NXgoniometer" a while back. That's at least referenced from the NXmx application definition at the moment. I see no need to have both (goniometer and poise).

On the other hand I also have no problem in storing axes in an NXcollection. The fact that there is no formal schema validation going on in there is still true. What happens instead is a functional validation for an unbroken axis dependency chain. If axes (or devices like detectors) point to axes inside an NXcollection, the intent of the writer is clear that the contents should not be off limits.

Basically I do not care what class is used. As far as I see it we just need to pick one of:

 * NXcollection
 * NXgoniometer
 * NXpoise

Or any other name that finds a majority.

Either we say the base class is empty (like NXcollection) or we could define we allow any number of axes (transformations) in there. Which we could do for the other two. But that's allowed anyway, so it would be for documentation only.
The way we structured that means that we cannot reasonably enforce a location anyway. That was the freedom we wanted there.

Just to be clear: I am more than happy to work on that with Herbert. I just don't have a personal preference over the choices.

Regards,

Tobias

________________________________________
From: nexus-tech-bounces at nexusformat.org [nexus-tech-bounces at nexusformat.org] on behalf of yayahjb [yayahjb at gmail.com]
Sent: 31 March 2014 17:52
To: nexus-tech at nexusformat.org
Cc: Winter, Graeme (DLSLtd,RAL,LSCI)
Subject: [NeXus-tech] Proposed NXpoise class

Dear Colleagues,

   At present, in the CIF-NeXus functional mapping, we are placing
all axes into pose:NXcollection groups.  As previously discussed,
I propose introducing a new poise/NXpoise base class for this
purpose.  I recognize that it is a non-trivial task to provide
attribute-based validation of axis fields, so I suggest that we
introduce NXpoise initially under than same non-validation approach
as NXcollection.  When attribute-based validation of axis fields
is working then we can apply it to the fields in NXpoise without
disturbing the non-validation of NXcollection.

The description would be:

extends NXobject

Use NXpoise to gather together fields defining axes relevant to the
enclosing group, where an axis is a field that has at least the attributes
vector and offset.

If this is acceptable, I will work with Tobias to provide an xml
description.

   Regards,
     Herbert


_______________________________________________
NeXus-tech mailing list
NeXus-tech at nexusformat.org
http://lists.nexusformat.org/mailman/listinfo/nexus-tech

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom