netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
"Robert E. McGrath" <mcgrath@xxxxxxxxxxxxx> wrote: > A few comments. > > 1. General Intro > > First, I wanted to suggest a general comment that might be in > the introduction. > > The HDF5 Group object is used to create a structured name space > for a file. HDF5 provides a very generic mechanism, with very little > restriction on how it can be used. > > If NetCDF4 uses Groups, it will define a profile (or profiles) > to specify how HDF5 Groups (and names) are used and interpreted > within NetCDF4. This document presents ideas for what the > profile should be. OK, thanks, I inserted that in the introduction. > 2. RE HDF5 names > > HDF5 places very little restriction on path names. NetCDF4 > should certainly define restrictions as needed. Currently, netCDF-3 permits alphanumeric characters and "_", "-", or "." special characters in names. Hence, permitting an interpretation for "/" in netCDF names won't clash with any existing netCDF-3 names or conventions. > 3. Should there be more than one profile? > > This document presents several plausible approaches to using > HDF5 Groups and names. > > Is it necessary to select only one? Or is it worth considering > the possibility of multiple profiles (with the NetCDF4 software > managing the differences.) > > From the initial document, I see several potential profiles: > > * netCDF3 compatibity > * "multifile" file, e.g., Group == netCDF3 file > - distinguished netCDF root > * Hierarchical NetCDF > - restricted to a tree > - general graph allowed > * several possible profiles for using/interpreting path names > One approach would be to define several profiles, with format > support to indicate what profile to use and mappings between profiles, > if necessary (e.g., for netCDF3 compatibility it > is necessary to define how to interpret paths as names). > > The reason for considering this approach is that it would > be a shame to lock in one model now, only to discover that > users need something else in a few years. A multiple > profile approach can be extended with new profiles in > the future. You may be right, but for the initial release I'd prefer to choose and support only one profile. How can I do this in a way that avoids lock in and permits future extensions? Without some usage experience, it's hard to predict how Groups will be used in netCDF-4, and what extensions users will want later. --Russ