Version numbers (also Occams' razor etc)

[Ray Osborn]

I didn't take part in last week's debate, but I agreed with Jon and Mark
that we should stick to using HDF's way of defining attributes.  I don't
believe that we should let attributes proliferate for no reason.  They are
designed to annotate the SDS to which they are attached rather than store
extra data i.e. they should really help the reading program to process the
SDS correctly rather than provide extra data that might be of independent
interest.  This is clearly the case with e.g. the "axis" attribute, which
only tells the program which dimension the data refers to and is of no
interest otherwise.  In open Genie, for example, it would be used to decide
whether to call the SDS "x" or not, when read into a workspace.  The units
attribute would determine what is put in "xlabel".  In neither case should
they be stored independently. 

>I hear a bang, can smell gunsmoke curling past my face and my foot
>hurts!
>
>Let's say we're "pragmatic" and stick with attributes.  Can we use our
>knowledge that there is duplication in the standard to sort out the
>NX_CHAR/attribute issue?
>
>We already have an interface for writing all kinds of data into a NeXus
>file - without ambiguity from FORTRAN or C. Here is the mechanism we are
>duplicating:
>
> NXmakedata(file_id, data_name, data_type, rank, dimensions[]);
> NXputdata(file_id, data_name);
>
>what we don't have is a call sequence such as below
>
> NXmakedata(file_id, attr_name, data_type, rank, dimensions[]);
>--> NXopenattribute(file_id, attr_name, data_name);
> NXputdata(file_id, attr_name);
>
>where data_name in the NXopenattribute call is a name of the data in the
>currently open NXgroup (required to specify which item to add the
>attribute to).
>

The one call to NXputattr is entirely sufficient.  As I have stated in
earlier posts, I would prefer that NXputdata did not have to be preceded by
NXmakedata and NXopendata since the extra function calls make NAPI seem much
more complicated than it really is.  I certainly don't want NXputattr
similarly encumbered.

>Now we are really able promise what I think we have been saying in this
>thread - that attributes should be allowed to be any type, not just
>restricted to NX_CHAR.
>
>Otherwise, how can anyone add a Rank-2 SDS as a dimension scale
>attribute, the current NXputattr requires the data to be a void* but we
>provide no way via the NAPI of obtaining a void* to a NAPI created SDS
>(without recourse to HDF)?
>

I believe that attributes can only ever be one-dimensional, or scalar.  We
don't ever want to have rank-2 attributes.  Dimension scales are separate
SDSs in the NXdata group, not attributes.

>What of NXputattr and NXgetattr ?  Let's  take a decision to remove the
>"type" parameter, change the "value" to char* and make them simple
>helper routines to call the above sequence for Strings only. There is a
>real ambiguity problem with the current calls which is going to trip
>people up for years to come otherwise!
>
>I'm playing devil's advocate here, but there is a fundamental underlying
>design issue here which won't go away! - In fact, the only reason we are
>discussing this now is that a user had a problem with the _second_ way
>we provide of writing data into a file.
>

The reason a user had a problem is that the API did not conform to what was
written in the web documentation.  That has now been corrected and so, as
far as I'm aware, the problem no longer exists. The NX_CHAR problem is one
of backward compatibility that Mark says is not a serious issue.  I don't
think that attributes represent any kind of problem.  Am I missing something
important?

I have no idea yet how we will store attributes in HDF-5.  Presumably we
should wait to find out how NCSA recommends we migrate old HDF data first.  

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