[NeXus-committee] OO-NeXus

[Ray Osborn]

Sorry to pepper the committee with so many emails, but I am just getting over my jet lag and so I'm only now paying attention to the agenda.

I see there is a discussion about the future of OO-NeXus. I would just like to suggest that, in this and other technical areas, the Python tree API would be a great way to test any ideas. In a sense, we have already implemented an OO-NeXus, with separate Python classes for every NXclass, but we haven't added any other OO features, such as (multiple?) inheritance, although I did make the NXmonitor group a subclass of NXdata since they both need to be plotted. 

In fact, the Python Tree API is an excellent way to do general testing of new concepts, such as the new group signal attributes being discussed. It is fairly easy to test how well you can construct general plotting methods that read these attributes and take default actions. I think we have suffered in the NIAC from having to make decisions in the abstract, e.g. concerning NXgeometry, without getting operational experience of their consequences, and prototyping in Python is one way to get around that. Perhaps, when there is a new proposal, we could request that use cases are tested in Python before the proposal is finalized.

Just a thought.
Ray
-- 
Ray Osborn
Materials Science Division
Argonne National Laboratory
Argonne, IL 60439, USA
Phone: +1 (630) 252-9011
Email: ROsborn at anl.gov