The replies here are reflex responses primarily from Ron Ghosh; the main intention may be to stimulate other replies from potential participants.
Uncertainty in Q for fourth columnRather than equate this as an error term it would be better to define it as a resolution width, in which case it should be clearly defined as being FWHM or standard deviation. (Adrian Rennie)
Disquiet over the future of HDFEven today only a limited number of packages offer direct interfaces to HDF4. What can be expected if HDF5 is now an incompatible, and at present little used variant? (John Barnes, Ron Ghosh et al.)
This was a point of prime importance at the NeXus workshop, and the software developers showed willingness to push for more general integration of the new standard HDF5, (already, for example, it is a standard component of Octave, a gnuish-lookalike for Matlab).
The design of the NeXus software does allow several options for rendering the HDF version transparent for the Users. Similarly at a more fundamental level HDF5 code is orthogonal to HDF4, and both can co-exist in the same package.
There remain vast volumes of data stored in HDF4 format, which will never be rewritten in the newer format. In implementing the rewrite for HDF5 NCSA is recognising that usage of HDF now extends beyond what the earlier format could satisfy.
Synchrotrons use commercially available detectors, with their own data formatsThe solution at RIKEN/SPring-8 is to use networking software to provide a uniform interface for users to treat the different data types. (Tetsuro Fujisawa).
This would appear to be ripe for discussion in future canSAS meetings when we take up the problems of formatting raw data (having solved those of treated data). An important point in favour of HDF5 now appears to be the high performance which can be attained in performing I/O operations.