Re: Options for Groups in netCDF-4

• To: netcdf-hdf@xxxxxxxxxxxxxxxx
• Subject: Re: Options for Groups in netCDF-4
• From: Russ Rew <russ@xxxxxxxxxxxxxxxx>
• Date: Mon, 26 Apr 2004 16:36:56 -0600

"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

• Follow-Ups:
  • Re: Options for Groups in netCDF-4
    • From: Robert E. McGrath

• References:
  • Re: Options for Groups in netCDF-4
    • From: Robert E. McGrath