[NeXus-tech] Proposed NXpoise class

[Herbert J. Bernstein]

It will be important in the future to actually validate the axes, so
long-term NXcollection is not appropriate.  For historical reasons in robot
kinematics, poise is a meaningful and appropriate term.  If there is no
strong objection to poise:NXpoise, I will go forward with that in place of
pose:NXcollection in CBFlib.  Graeme has asked that this be an absolute
replacement, rather than an optional alternative to pose:NXcollection.  By
making it a base class, rather than an
application definition, the presence of any particular field in it is
optional, but the intention is that
the axes relevant to the detector would be in a poise:NXpoise group in the
NXdectector class
and the axes relevant to the goniometer would be in a poise:NXpoise group
in the NXgoniometer class.  This could be added into the NXmx application
definition and/or into the relevant base classes.  Right now, NXmx has
neither pose:NXcollection nor poise:NXpoise, so formally this would just be
an addition to the existing application definition, not a change.  There
are some axes given in NXdetector_module directly without an intervening
class.  Those axes have fixed
names in the NXdetector_module base class definition, but if other axes or
the same axes under
different names are needed, having poise:NXpoise would provide the
flexibility to do that without
the need for prefixes.

If time permits, we should discuss this at our meeting on Wednesday.

Regards,
  Herbert


On Mon, Mar 31, 2014 at 1:13 PM, <Tobias.Richter at diamond.ac.uk> wrote:

> 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
>
>
>
>
>
> _______________________________________________
> NeXus-tech mailing list
> NeXus-tech at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-tech
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nexusformat.org/mailman/private/nexus-tech/attachments/20140331/230d96a0/attachment.html>