Re: Creation order: time stamps or sequence numbers

Hi Russ,

> >     I think supporting creation order for attributes might be a bit
> > more of a problem than for the other kinds of objects, but from
> > reading your description of the attribute number below, it doesn't
> > look like it's a real problem if the "creation order" of attributes
> > changes.  Is that so?
> 
> Oops, I realize I didn't actually answer the question.  The netCDF
> interface (for mostly historical reasons that are hard to justify now)
> permits deleting attributes but not deleting variables or dimensions.
> So attribute numbers can change if you delete preceding attributes,
> but that doesn't change the order of remaining attributes.  The only
> way to change the attribute order would be to delete an attribute and
> then later re-add it at the end, but doing that would have to be
> intentional, so the new order is still preserved.
    Ok, I reviewed our code for attributes and we are already handling them
in a manner which preserves the creation order, so that shouldn't be a
problem.  (I did add a note to write a unit test that verifies that this
continues to be so, also :-)

    Quincey
>From owner-netcdf-hdf@xxxxxxxxxxxxxxxx 17 2003 Nov -0700 07:19:56 
Message-ID: <wrxy8ufjcvn.fsf@xxxxxxxxxxxxxxxxxxxxxxx>
Date: 17 Nov 2003 07:19:56 -0700
From: Ed Hartnett <ed@xxxxxxxxxxxxxxxx>
To: netcdf-hdf@xxxxxxxxxxxxxxxx
Subject: Quincey - Question about character
Received: (from majordo@localhost)
        by unidata.ucar.edu (UCAR/Unidata) id hAHEJwvq003284
        for netcdf-hdf-out; Mon, 17 Nov 2003 07:19:58 -0700 (MST)
Received: from rodney.unidata.ucar.edu (rodney.unidata.ucar.edu 
[128.117.140.88])
        by unidata.ucar.edu (UCAR/Unidata) with ESMTP id hAHEJvOb003280
        for <netcdf-hdf@xxxxxxxxxxxxxxxx>; Mon, 17 Nov 2003 07:19:57 -0700 (MST)
Organization: UCAR/Unidata
Keywords: 200311171419.hAHEJvOb003280
Lines: 13
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netcdf-hdf@xxxxxxxxxxxxxxxx
Precedence: bulk

Howdy Quincey!

Is it the intention that the HDF5 type H5T_NATIVE_CHAR for ASCII
strings, H5T_NATIVE_UCHAR for unsigned byte data, and H5T_NATIVE_SCHAR
for signed byte data?

I'm suprised and very happy if so, because it would be very handy for
me to have a type for ASCII data which is different from signed char
data.

Thanks,

Ed