@JonathanGregory, I don't agree. You are asking for robust enumeration for a redundant data feature that is recommended against using. This has already been cumbersome for building the current draft. There will be extra work to examine the several dozen other possible cases in Appendix A. Then there will be added future responsibility to check for boundary attribute conflicts whenever a coordinate attribute is newly added or adjusted. I also think adding a new notation in Appendix A is not appropriate.
So I think a new precedent is needed. I think we need to explain these potentially conflicting duplicate attributes by description, not by enumeration. As a start, I wonder whether you find acceptable my current wording, using the device of "such as" to generalize and convert the following into simply a list of examples. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/265#issuecomment-742826763 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.
