> * 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.
I agree with this. > * We don't have to distinguish positive and negative categories, because > they are logically related: prohibition = negative requirement, deprecation = > negative recommendation. I don't understand this. > 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 #314)? 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 > forever), and recommendations which are made because there are alternative > ways to do something where one is preferred and the other might be abolished > in the 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 the 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. This may very well be a chicken-and-egg problem. After all, if I have to support every feature since the first version anyway, why check the version number? It seems to me that this approach becomes less and less tractable as the complexity of the conventions increases. > 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 the future. What could this new category be > called? Warnings? Continuing this line of thought and drawing further analogy with version numbers in software packages, a flaw that leads to incorrect or uninterpretable metadata could be considered a bug and as such warrant the release of a bug-fix version of the conventions. This could mean releasing version 1.7.1, 1.8.1, and 1.9.1 all at the same time, only changing the relevant bug but otherwise not impacting the feature set of the corresponding version. To avoid undue burden and maintenance of long-obsolete versions one would probably want to declare only a very limited set of versions as supported, say the last two. This way, old versions can be updated to fix manifest flaws, which makes it also more plausible to actually retire deprecated features because a user that relies on such a feature can find comfort in knowing that the old version he now must use does not fall quickly into disrepair. User software, which already increasingly is built on standard libraries for interacting with CF data, can check the conventions attribute in a meaningful way and support different versions of the conventions even when the feature sets differ or offer different best practice implementations for the same encoding requirement. @JonathanGregory is of course correct that all of this goes far beyond #314, but that is how I understood the intent of @ethanrd in opening this issue. -- 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-849742286__;Iw!!G2kpM7uM-TzIFchu!hyEJN_YQK92s3wK9ZPbrGAFjdtabkRMIH3XFy_6dGyumYDZGo4IQ80zsKqYuTmVd_wVcpp_N_lk$ 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.
