On 12/13/2011 10:40 AM, Jonathan Gregory wrote:
OTOH, if we start thinking in terms of the extended model, a
Structure ("compound type" in HDF5 parlance) might be useful. What
do you think about starting to think about possible uses of extended
data model?
Thomas suggested groups. We could put the component data variables of a
vector or tensor in a netCDF-4 group, and I guess we could allow a group
to have a generic standard_name, like we are proposing the umbrella would
have one. This is neat, and the main objection is that it's not the classic
model! Therefore lots of existing software would not be able to read the
components any more. It is not backward-compatible. There has to be a strong
reason for breaking backward compatibility. What do you think? What are the
relative advantages of groups and compound types?
Jonathan,
I agree with your reasoning. It is worth considering the use of Groups,
but the approach should be weighed against the best proposals that can
be generated that stick to the classic model. Fundamentally the need is
for 2 bit of semantics:
1. associate components together so they form a conceptual N-vector object
2. associate metadata with the N-vector object
Having said this, it is not desirable to follow a path for evaluating
new proposals that implicitly rules out the use of superior netCDF-4
approaches. To avoid this dilemma we need to bring the client reference
libraries into the discussion (Java netCDF and "libCF"). Over time if
the developer community were using of reference libraries, it would be
possible to simultaneously support both "classic" netCDF-3 encodings,
and improved netCDF4 encodings. The client application would hardly
know or care which encoding was in use. This creates a path for forward
advancement of the file structure without doing violence to backward
compatibility.
Beating the libCF drum: the development of libCF is so important! We
have to provide a path for developers to write code that is based on CF
semantic abstractions, instead of the details of CF file structure.
Else we will be constantly holding back the progress of CF.
- Steve
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
