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