Re: something startling I just noticed...

Quincey,

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