Re: [CF-metadata] [cf-convention/cf-conventions] Clarify and update CF rules for deprecating content (#328)
Dear all I'd like to repeat my earlier points that * We should make use of the existing list, namely the conformance document, for the purposes being discussed here - I don't think we need a new list. * We don't have to distinguish positive and negative categories, because they are logically related: prohibition = negative requirement, deprecation = negative recommendation. Does anyone disagree with those points, I wonder? Which of these categories should be used if we discover a *flaw* in the convention, which allows metadata to be produced that can't be interpreted correctly or reliably (as in https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/314)?__;!!G2kpM7uM-TzIFchu!hyhLEMLDzUlm9Sg9Um2Auq80CWA3cMBoc6vBg7NtxWJIfNXhgjtZu_8brtb6g5m6xi6Q6D-B8DM$ The rules say "deprecate" but I think now that's too weak. We should *prohibit* the use of the flawed convention (not the whole version, just the affected part) for writing new data (but also reassure users that existing data isn't being invalidated). I appreciate the arguments about the need for a further distinction, and I agree this could help in other cases. I suggest that we need to distinguish between recommendations which are made for good practice (and could remain for ever), and recommendations which are made because there are alternative ways to do something where one is preferred and the other might be abolished in future. That is, we would have three categories in the conformance document, rather than two. An example of a good-practice recommendation in the conformance document is "The name of a multidimensional coordinate variable should not match the name of any of its dimensions." We do not envisage making this a requirement. In general, we do not try to foresee the future of the CF convention, so I think most of the current recommendations are for good-practice. There should only be a few where we think it's really likely that we are going to abolish something in future. I note that, up to now, we have not abolished anything. One reason for that is because past data continues to exist for a long time. Therefore it's hard to withdraw support for any feature in data-reading programs without causing inconvenience, although you can in data-writing programs. I know that you can always inspect the Conventions attribute, but most user programs don't pay attention to that, I imagine, and we should avoid making things awkward for users. Hence I would suggest identifying which current recommendations in the conformance document, or which should be in it but aren't, ought to be promoted to a new category of things which really might become requirements/prohibitions in future. What could this new category be called? Warnings? Best wishes Jonathan -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/328*issuecomment-848719885__;Iw!!G2kpM7uM-TzIFchu!hyhLEMLDzUlm9Sg9Um2Auq80CWA3cMBoc6vBg7NtxWJIfNXhgjtZu_8brtb6g5m6xi6QvnZbQp8$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarify and update CF rules for deprecating content (#328)
I agree with what @ethanrd and @erget said, namely that we have errata and what I would call deprecations. I think it is quite important to actually remove deprecations at some point, preferably under a predictable policy, e.g. two versions after the initial deprecation. The reason is that these features really become a burden on producers of CF tooling, like libraries for reading CF files. If we essentially allow everything indefinitely, it becomes increasingly difficult to produce a conforming implementation. This really is worse in the case of deprecations and errata than with normal evolution, because deprecation often seems to happen together with a new formulation taking the place of the deprecated feature. That, in turn, implies that as a library maintainer now you need to take care of two different formulations of the same phenomenon, of which one is known to be bad in some sense. If somebody really needs to rely on an old feature, they are always free to write a file according to the old standard and put the corresponding ":conventions" attribute inside. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/328*issuecomment-848588450__;Iw!!G2kpM7uM-TzIFchu!m0Hh2lFlQbNr3K8jUs3bLTNFDZCd9A7B0ScRwydD_u-spI_AYT9-tW1q5DAXZVkD7RU1bzIp3YA$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Clarify and update CF rules for deprecating content (#328)
TLDR: My opinion is that the rules are sound for correcting errata, but we do not describe what to do in the case of deprecation. **This may not be necessary because we could consider deprecation normal care and feeding for the standard.** I do agree that we should have a list of deprecations and the CF Checker should warn of deprecated features. We could consider deciding upon and announcing versions at which we will remove deprecated features. Musings: I too prefer simplicity, when it's possible. Would it be possible to use the deprecation mechanism differently for 2 classes of items?: 1. Errata 2. Discontinued features My reasoning here is that we would remove these items from the standard with different speeds. As @JonathanGregory [highlights](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/328*issuecomment-845988627__;Iw!!G2kpM7uM-TzIFchu!kXYuwF-2YjStEOzj-iFUZtdCH2Jc63S_-jzEC_BSmA5IJifoAffEIYbRoKYlPgkUICwXjK1vjik$ ), there is [a procedure for errata](https://urldefense.us/v3/__http://cfconventions.org/rules.html__;!!G2kpM7uM-TzIFchu!kXYuwF-2YjStEOzj-iFUZtdCH2Jc63S_-jzEC_BSmA5IJifoAffEIYbRoKYlPgkUICwXWRmWopQ$ ) (abridged by me): > > If the change... turns out to be ... flawed, ... a new version of the > > conventions will be prepared immediately, with the second digit of the > > version number incremented, and will be recommended to be used instead of > > the flawed version. The flawed version will be deprecated by a statement in > > the standard document and the conformance document. However, any data > > written with the flawed version will not be invalidated, although it may be > > problematic for users. This remains reasonable in my mind, and it would be used in the case that quick action is needed. Then there are deprecations like @ethanrd [notes](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/328*issuecomment-846140071__;Iw!!G2kpM7uM-TzIFchu!kXYuwF-2YjStEOzj-iFUZtdCH2Jc63S_-jzEC_BSmA5IJifoAffEIYbRoKYlPgkUICwX5OjddvA$ ) - I'll speak to the use of `projection_x_coordinate` and `projection_y_coordinate` in conjunction with the `geostationary` grid mapping, as I was involved in that one. That is a feature discovered to be erroneous and deprecated by us. However, we've been living with this error for many years now and nobody complained - the deprecation was due to an (over-) abundance of precision. Thus we have not yet set a date at which mention of those attributes will be completely removed from that part of the standard; it is not urgent. We could adopt the same approach if we ever have a feature that is overly complex and we no longer want to support the use of it - I'm not advocating this, but for the sake of argument let's say it's [the use of packed data described in Section 8.1](https://urldefense.us/v3/__http://cfconventions.org/cf-conventions/cf-conventions.html*packed-data__;Iw!!G2kpM7uM-TzIFchu!kXYuwF-2YjStEOzj-iFUZtdCH2Jc63S_-jzEC_BSmA5IJifoAffEIYbRoKYlPgkUICwXLDEwogE$ ). In that case, we could deprecate the feature, and even inform users with e.g. 2 releases of notice that it will at some point disappear from the standard. In this case it would not be due to an error, but we could treat it the same way. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/328*issuecomment-848506261__;Iw!!G2kpM7uM-TzIFchu!kXYuwF-2YjStEOzj-iFUZtdCH2Jc63S_-jzEC_BSmA5IJifoAffEIYbRoKYlPgkUICwXU-MfPUI$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
