"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
