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 [email protected], 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 [email protected].
