Dear Jonathan,
removal/backward incompatibility is a difficult issue, and having
several ways to do things just because of backward compatibility will
make CF hard to understand. It is not only new features in CF which
introduces too many ways to do things, also the existing document has
plenty of examples, e.g. at least 6 different ways to describe a
latitude axis (and that even without counting standard_name and axis
attributes).
While I think maintaining two sets of CF (1.x, 2.x) will be very hard, I
think acceptance of a CF-2.x series can only be achieved with enough
compatibility.
I liked the way of the HTML-4 group to allow for a "transitional" and a
"strict" set of features. This should make it easy to adapt existing
datasets to CF-2-transitional, while new datasets should be tested
against a 'strict' CF-checker.
I agree with your comments about the way of discussion, history and open
communications is import.
Best regards,
Heiko
On 2014-09-19 16:11, Jonathan Gregory wrote:
Dear John
So I propose we have a 3 month discussion period where we clarify what the
issues are and possible improvements or changes. We wont try too hard
during that period to create final wording, and divergences of opinion will
be recorded rather than resolved. After that we will have another 3 month
period where we try to write a document and make decisions.
It is good to have a timescale for discussion. That might not be long enough,
but let's see!
I propose these ground-rules for what we discuss:
1. Changes needed to use the extended model.
2. Possible things to deprecate or remove.
3. Possible new functionality esp if it comes from using the extended
model.
4. Backwards compatibility is desirable, but not required if there is a
substantial advantage in simplicity and clarity. So respect precedent and
dont constrain important innovation.
By "extended model" do you mean the netCDF4 model? I don't think we should
begin with an *aim* to use the netCDF4 model. The question is, what do we need
to do which we *can't* do in the classic model, or could be done much more
easily in the extended model than in the classic model? That is, changes to CF
should be driven by use-cases, not technology. So I would combine 3 and 1 as
(1) What use-cases cannot be met with the classic model, or could be met much
more easily with the extended model?
Since "remove" implies "backward-incompatible", I would put (2) as
(2) Possible things to deprecate (because there is a better way to do it
- I assume - are there other reasons?)
Then
(3) Possible things to remove, or to require if they are currently only
optional. Such changes mean backwards-incompatibility. I think that the
default should be backwards compatibility. There has to be a strong advantage
for making incompatible changes. (NB I am not saying that backward
incompatibility is out of the question!)
I do not think we should introduce a new way of doing something because
it might look nicer, unless it is clearly functionally much better than the
existing way. Also, if we introduce a new way to do something, we should
carefully consider removing the old way, because it is easier for users of
the convention if there is only one way to do something.
Whatever way the discussion is done, I think it's important that
- it should be public to read and contribute to
- it should have a history, so we can all see what we and others said earlier.
Best wishes and thanks
Jonathan
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Dr. Heiko Klein Tel. + 47 22 96 32 58
Development Section / IT Department Fax. + 47 22 69 63 55
Norwegian Meteorological Institute http://www.met.no
P.O. Box 43 Blindern 0313 Oslo NORWAY
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
