Hi Russ,
Sorry for the delays in replying as I'm catching up on e-mail after
vacation.
I don't think a rank-0 array datatype would be a really good change.
Perhaps changing the dataspace (which can have a rank of 0) for the attribute
would be more appropriate?
Quincey
> We're developing an alternative straw-person draft of mapping netCDF
> to HDF5, at least for the first deliverable of netCDF-3 on HDF5.
>
> Currently, we're thinking of storing the netCDF dimension IDs for a
> netCDF variable in an HDF5 array attribute, _ncdimids, associated with
> the HDF5 dataset corresponding to the variable. This works fine for
> array variables, but scalar (rank 0) netCDF variables have no
> associated dimension IDs.
>
> Various ways to encode this in HDF5 include:
>
> - no _ncdimids attribute for scalar variables
>
> - an _ncdimids attribute that is not an array
>
> - a rank-0 _ndimids array attribute. In this case, the rank of
> _ncdimids would always correspond to the rank of the associated
> variable, whether scalar or dimensioned.
>
> The latter is not currently possible in HDF5, but would be if rank-0
> arrays were supported.
>
> I don't know how disruptive it would be to permit rank-0 arrays as a
> Datatype, so if it has lots of unpleasant side effects, please just
> ignore this minor request. But if it's relatively easy, you might
> find other uses for rank-0 arrays, for example, as something to return
> to represent an empty result of a query that typically returns an
> array. We've found that treating rank-k multidimensional arrays
> pretty much the same for k = 0, 1, 2, ... makes some code simpler.
>
> --Russ
>
