Various stuff

[Ray Osborn]

Just some comments on Mark's e-mail.

>   - I think napi is stable enough to justify a 1.0.0

I had missed the fact that NEXUS_VERSION is defined in NAPI.H.  I presume
that we should just change that to 1.0.0 now.  If we include a similar
parameter constant in the Fortran include file, we should have covered our
bases.  I would like to announce the official release of v 1.0.0 by the end
of next week if possible, if someone can make the necessary changes.

>   - NXwritedata: is not to good an idea: I prefer the NXenterdata coming
>     with NXdict. It creates the dataset and opens it. Then you can write 
>     an arbitrary number of data slabs, compress it (when I put that in),
>     add n attributes etc. My point is that NXenterdata is more flexible.

I would like to see the code to NXenterdata.  I don't disagree that
flexibility is an asset, but I still believe that we should have something
like NXwritedata since it is what we are all typing over and over again at
the moment.  In addition, I am very keen that the default method of writing
SDS's should include the "units" attribute since we want to encourage people
to include it as much as possible.

Don't forget that NeXus is meant to be easy for non-experts to use e.g. me. 
As an example, GKS is much more flexible than PGPLOT, but most
scientist/programmers seem to prefer the latter because it is much simpler
to produce decent plots quickly (it's also free, unlike Dec GKS, but that's
another story).

>   - Shouldn't NXdict be made publicly available? I'am using it now
>     for writing data files for two instruments. This means, that the main
>     component, the definition string parser, is working. The rest of the
>     code is very straightforward. There are two options for NXDICT
>     publicity: we put it in the repository. This may be a mess and
confusing
>     because NXDICT consists of a lot of files, as it uses various support
>     components. The second option is that I do a NXDICT page for my 
>     www-server, name myself NXDICT maintainer and a link is made from the 
>     general NeXus page to the NXDICT page. What is preferred?

I agree that NXDICT should be made public.  Unless we start using the same
CVS procedures on NXDICT, I am happy for you to maintain updates to NXDICT. 
I would like to have some information for the web pages over here, but if
you want to write separate HTML describing NXDICT, I can point to it and, of
course, the code can be stored on any FTP site.  However, if there are
non-NXDICT-specific routines, such as NXenterdata, that would be useful to
regular the regular API, I would prefer them included with the rest, rather
than with NXDICT alone. 

>   - BTW: I think Przememk's and Nick's tcl-interface and the Browser
should
>     really be available as well.

I agree.  Przemek & Nick, is there a chance of either a tar file, or, even
better, some documentation that I can point to from the NeXus utility page?

>   - A colleage of mine has written a F77 NeXus browser. He hit a glitch or
>     may be not a glitch. NXgetnextentry returns ALL vGroups in a file.
Now,
>     HDF uses various support vGroups which showed up in the browser. His
>     suggestion is, that NXgetnextentry should only return vGroups whose
>     classnames start with NX, as required by NeXus. I did not put it in 
>     because the way it is now, napi may be of use to other HDF users as
>     well. Any opinions?

There are a lot of junk Vgroups in the average HDF file which I would rather
the user did not have to worry about.  If the ones you are referring to are
the dummy Vgroups used to contain SDS dimension scale information, then I
certainly believe that they should be hidden.  That's one of the reasons for
using NeXus rather than HDF.  If the only way of removing them is to
restrict the classes to NX ones, we may have to do that although I agree
that it is not entirely satisfactory.  The other way is to identify the HDF
classes that are assigned to these junk Vgroups, and filter them out before
passing them back to the browser.

>   - The string and attribute business is a mess. Dr. Rieman is right about

>     NXgetattribute. It should do a void pointer and not a char.

I see Freddie has already corrected that.  Thanks.

>   - I'am currently doing only string attributes in my data files. But this
>     could change till summer, when we start again.

This probably means that your NeXus files don't conform precisely to what's
defined on the web page.  If you read the section on NXdata groups, we ask
that the "axis" attribute to be set to the integer value of the dimension to
which the SDS applies (axis=1 for x-axis, axis=2 for y-axis etc.).  I am a
bit concerned that we are all following our own version of the standard,
rather than the standard itself.  If what I've written on the web pages is
not adequate or incorrect, then we should debate that in the NeXus mailing
list and improve it.  In the meantime, please use it or the standard will be
as elusive as a standard U**x operating system.

Regards,
Ray
-- 
Dr Ray Osborn                Tel: +1 (630) 252-9011
Materials Science Division   Fax: +1 (630) 252-7777
Argonne National Laboratory  E-mail: ROsborn at anl.gov
Argonne, IL 60439-4845