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
> CF-metadata at cgd.ucar.edu
> 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
Received on Mon Sep 22 2014 - 01:51:09 BST
