[Nexus] question about NeXus classes

[Darren Dale]

Hi Peter,

On Friday 25 July 2008 13:35:13 Peterson, Peter F. wrote:
> Darren,
>
> Thank you for the question.
>
> The current philosophy of classes is that they are to be thought of as
> dictionaries. If you are familiar with xml schema (xsd) the "any" tag is
> appropriate. This means that there is one NXdetector which covers all
> the various types of detectors in existence. If a particular detector
> needs another field that isn't in the current NXdetector, then it should
> be added. Subclassing is not an idea that can be applied to the base
> classes.

Thanks for responding. I have almost no experience with xml, so please excuse 
my ignorance: if I need additional fields, I can add them, but I should 
continue to use the existing classes. Is that correct?

> However, the NIAC has noted the similarities in several of classes and
> applying the object oriented design techniques such as subclassing. The
> committee agreed that this is the direction for the future, but are
> waiting until the current definitions (v2.0) can be finalized.

I'd like to explain what I'm working on. I have been developing a program for 
acquisition and analysis at my beamline, and have been generating hdf5 files 
using pytables. I am now working on updating my data model to format the files 
according to the nexus guidelines, and am starting at the foundation: an 
object-oriented interface to the hdf5 file and tree. This foundation is not 
built on the nexus api or the official nexus python bindings, nonetheless I want 
to make sure my files adhere to the standard. For example:

t = NXfile('NXtest.h5')
vortex = t['entry']['instrument']['vortex']

That currently inspects the node's attributes and returns an instance of the 
NXdetector python class. In the future I can also inspect the nodes "type" and 
"description" attributes to find a more specialized constructor if necessary, 
one that provides additional methods and a richer interface to the same 
underlying NXdetector data.

I'm just getting started, so right now I can access the data in a pythonic way 
and return basic NX* object instances, but the objects are all featureless 
aside from providing access to the underlying data. Since I'm just getting 
started, it would be helpful if you could share any information concerning the 
future of nexus' definitions and organization. Are the committee's discussions 
available on the web? Do you think my approach is one that the nexus 
developers could be comfortable with, or should I be considering another 
approach? My hope is that the project would eventually be useful to the wider 
community.

Thanks,
Darren

> Peter Peterson
>
> -----Original Message-----
> From: nexus-bounces at nexusformat.org
> [mailto:nexus-bounces at nexusformat.org] On Behalf Of Darren Dale
> Sent: Friday, July 25, 2008 12:53 PM
> To: nexus at nexusformat.org
> Subject: [Nexus] question about NeXus classes
>
> Hello,
>
> I have a question regarding specialization of the generic class
> definitions
> listed at  http://www.nexusformat.org/Design#NeXus_Classes . Is it
> acceptable
> to create a subclass of NXdetector that is specific to a single- or
> multi-element energy-dispersive detector, called NX_Vortex90EX for
> example,
> and save that class name to NX_class? If that is not advisable, I guess
> I
> could use an additional attribute like NX_subclass. I'm just trying to
> get a
> sense of the intended use of the NX_class attribute and its limitations.
>
> Thanks,
> Darren