Re: something startling I just noticed...

Hi Russ,

> >     Yes, local sequence numbers cut both ways sometimes...  Since
> > most (all?)  current netCDF users should be used to a 'flat' file,
> > putting all the objects in the root group of the file and using the
> > creation order in that group seems like a reasonable default.  Then,
> > you could change the definition of the way the creation order
> > information is used for netCDF 4 users so that the group structure
> > was accounted for.  
> >     BTW, I was looking through the netCDF 3 API for functions that
> > take or return an 'index' in the file and I can't find one.  Which
> > function(s) applies to this situation?
> I think we haven't been clear enough in describing what we mean be
> creation order.
    Actually, I do understand what you mean, HDF4 does things basically the
same way.
    For the functions below, how do you get the ID/num of an object when
you don't know the name?  Do you pass in a NULL pointer for the name parameter?
    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?


> In netCDF, there is no global creation order stored
> for all objects that tells whether a particular variable was created
> before or after a particular global attribute, for example.  The "ids"
> for dimensions and variables, and the attribute numbers, record the
> order in which they were defined, and that's all we need to preserve,
> to make sure that we iterate over the netCDF variables in the same
> order in which they were defined, for example.  You're right that
> there is no global index defined over all netCDF objects in a file,
> but the C interface provides these functions to get the dimension ID,
> variable ID, or attribute number, which gives the relative orders for
> dimensions, variables, and attributes:
> Get a dimension ID from its name:
>   int nc_inq_dimid (int ncid, const char *name, int *dimidp)
> Get a variable ID from its name:
>   int nc_inq_varid (int ncid, const char *name, int *varidp)
> Get an attributes number from its variable id and name:
>   int nc_inq_attid   (int ncid, int varid, const char *name, int *attnump)
> By the way, the attribute number is not called an ID intentionally. As
> the Users Guide says:
>   ... The number of an attribute is more volatile than the name, since
>   it can change when other attributes of the same variable are
>   deleted. This is why an attribute number is not called an attribute
>   ID.
> The IDs support iteration through the variables, dimensions, and
> objects in a netCDF file if you don't know the names of anything, so
> they are used by generic software.  Users have gotten used to the fact
> that ncdump, a generic netCDF program, outputs things in the order in
> which they were defined, rather than alphabetical order by name, for
> example.  The same is true for menus and other GUI elements in
> applications.  Since we don't have Groups, grouping variables in a
> conventional order keeps related variables close to each other in
> these contexts.
> I hope this makes it clearer that what we need is not the absolute
> time order of all objects in a netCDF file (that would be overkill but
> would suffice), but rather just some way to determine the order
> dimensions were defined relative to each other, the order variables
> were defined relative to each other, and similarly for variable
> attributes and global attributes.
> In the prototype, we are storing this information in separate HDF
> Datasets.  In an earlier version, we preserved this information by
> encoding the IDs as part of the datasets name, but now we use the same
> names as for the netCDF objects.
> --Russ