Thank you both for your comments. @Dave-Allured asks whether "such as" with examples is "acceptable". It feels harsh to say "No, it's unacceptable", but I'd really prefer us to specify them. You do have text which describes the characteristics of the variables concerned, and that's fine, but it's safer for the convention also to say explicitly which ones they are, since people using the convention would probably not always make the same decision. As @davidhassell shows, it doesn't make the text more complicated. If anything, it's a simplification.
I'd like to suggest a further rewording, to avoid introducing "active" as a CF jargon word, and put things in a slightly different order: > Since a boundary variable is considered to be part of a coordinate variable's > metadata it is generally not necessary to provide it with attributes, because > the boundary variable is assumed to inherit all of the attributes of its > parent coordinate variable (with the exception of the `formula_terms > attribute`, which may be required, as described in the next paragraph). It is > recommended not to include any attribute on a bounds variable which affects > the interpretation of values (such as `units` and `standard_name`, see > Appendix A for the complete list of such attributes), and it is permitted to > include such an attribute only if its string or numeric value is exactly the > same as the parent variable's attribute. The data types do not need to match, > but must be compatible for comparing values. If any other attribute is > provided on a bounds variable, it takes precedence over any corresponding > attribute of the parent variable. Which are the attributes concerned, apart from `units` `standard_name` `axis` `positive` `calendar` `leap_month` `leap_year` `month_lengths`, which @Dave-Allured has identified? Looking at Appendix A, I am unsure, so I think we do need to decide. Probably `computed_standard_name` should be in that list as well. Is it required that bounds must be packed in the same way as their parents with `add_offset` and `scale_factor`? Must they have the same valid range, `missing_value` and `_FillValue`? Do `cf_role` `compress` `geometry` `nodes` have any CF meaning for a bounds variable? Looking at all these, I incline more strongly than before to thinking we should add this to Appendix A. In the existing *Use* column, we could add an indicator for those coordinate variable attributes (marked as C) which are allowed but deprecated and must agree with the coordinate variable, and those which are allowed and may be different from the coordinate variable, such as `long_name`. It would be clearest if every C attribute was put in one of these two categories, except `formula_terms`, which has special rules. Jonathan -- 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-743275895 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.
