support for HDF5 dimension scales with null dataspace

[itcarroll]

support for HDF5 dimension scales with null dataspace

[kmuehlbauer]

@itcarroll Thanks for raising. As this might have severe implications I'm inclined to wait for discussion in Unidata/netcdf-c#2571.

Could you give a bit more detail on the use-case?

[itcarroll]

Yes, I'm interested to see the response from Unidata as well. Of course, I may not foresee some undesirable outcome.

My use case concerns datasets like what you get from XArray with xarray.Dataset({'y': ('x', [0.1, 2.3, 4.5]), 'a': ('x', [0, 0, 1])}), having no coordinate variable for shared dimension x. In HDF5 terminology, x is a dimension scale having a dataspace that may either be null, scalar or an array. HDF5 does not enforce any kind of dimensionality agreement between x and y or a.

A creator of HDF5 files, who does not intend to create netCDF4 files nor depend on the netCDF4 libraries, will use a null dataspace for x when creating a file with the same y and a. They would need the netCDF4 libraries (or knowledge of them) to use an array with shape (3,) for x that also has attributes signaling the array should be ignored. The consumer of that file using XArray benefits greatly from the fact that the netcdf4-python and h5netcdf engines do their level best to read this HDF5 file that is not strictly netCDF4.

These engines are already very accommodating in generation of "phony dimensions" in the absence of dimension scales, and I hope those could become less common if the proposed use of null dataspaces catches on.