Version numbers

[c.m.moreton-smith at rl.ac.uk]

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).

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)?

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.

	Chris


> -----Original Message-----
> From: Freddie Akeroyd [mailto:faa at isise.rl.ac.uk]
> Sent: 24 April 1998 00:13
> To: napi at anl.gov
> Subject: Re: Version numbers
> 
> 
> It would be nice to allow all data types, but problems occur with
> FORTRAN. In C whether a char* refers to a UINT8 or a CHAR8 is not
> distinguised, but in FORTRAN it is. In C you can write your strings as
> UINT8 and all is fine so long as you read them back as a 
> UINT8; however
> as FORTRAN strings are stored differently to streams of bytes 
> i need to
> do a conversion in the interface and hence i need to know whether
> something is a string or not. There is also a "null" termination
> problem with the current C implementation if it were used for 8 bit
> data. Currently if you wrote 8 items of 8 bit data, you would need to
> send an array of length 9 to read them back in again or else your last
> element would be chopped by the '\0'. Allocating 1+length is natural
> for C programmers using strings, but not for C (or FORTRAN) 
> programmers
> handling arrays of 8 bit data! While you might notice your 
> string being
> one character shorter and fix it, you may not notice your final data
> point being replaced by 0. One way round this would be the "strncpy"
> solution i mentioned to a previous attributes query where the 
> interface
> only null terminates a string it is passed more space than is required
> to store it. Basically we have a backward compatability 
> problem as strings
> were previously written as UINT8. In C we can do a partial workaround,
> but the FORTRAN interface has to go one way or the other - if we stick
> to a rigid NX_CHAR only, then it will not be able to read old PSI
> data. I guess the question is what counts more - being able to write 8
> bit data values or being able to read old PSI data from the FORTRAN
> interface?
> 
> Freddie
> > 
> > Regarding the CHAR8, UINT8, INT8 stuff, characters should 
> be characters,
> > integers should be integers, and uints should be uints.  
> The advantage
> > comes at readout time.  If you are trying to make a 
> displayer, then how you
> > disply the SDS or attribute depends upon which type it is.  
> We should allow
> > SDS's to be characters, otherwise we have to support other HDF
> > constructions for storing string information.  I do not see 
> any real need
> > to have an 8 bit int (or unit) attribute, however, why impose that
> > limitation?  Just let people store what the need/want.  As 
> soon as you
> > exclude it, you will find that somebody needs it, and some 
> other software
> > will not work with the change.
> > 
> > Jon
> > 
> > >What is the final word on NX_CHAR? Currently the NAPI code writes
> > >NX_CHAR as DFNT_CHAR8, but treats attributes read in as DFNT_UINT8,
> > >DFNT_CHAR8 or DFNT_UCHAR8 as character types (for backward
> > >compatability) and NULL terminates them; however it looks like the
> > >current NXdict API uses DFNT_INT8 as the character type.  
> This may not
> > >be a problem if we don't allow 8 bit values to be anything 
> other than
> > >strings when they are in attributes - proper 8 bit numbers 
> should be
> > >part of an SDS and not an attribute? Of course, do we then 
> allow SDS's
> > >of characters?
> > >
> > >Freddie
> > >
> > >P.S. I assume we should write a global attribute "NeXus_version"
> > >containing the
> > >     API version when we create a new file - i don't 
> believe we do at the
> > >moment
> > >
> > 
> 
> -- 
> Freddie Akeroyd                        Email:  
> Freddie.Akeroyd at rl.ac.uk
> ISIS Facility                          Tel:    +44 1235 445457
> Rutherford Appleton Laboratory         Fax:    +44 1235 445720
> Chilton, DIDCOT, OX11 OQX, GB          WWW:    
> http://www.isis.rl.ac.uk/
>