Hello @Dave-Allured, @JonathanGregory and all,
I agree with @JonathanGregory - spelling out the "active" attributes in the
appendix A table is a good idea. As long as it's permissable, software
providers and data creators will need to be able to unambiguously know the
exact list of active attributes, and the "such as" list in the text doesn't
really do that, I feel. If we don't know what they are, it is likely that
others won't, either! I suspect readers would see the "such as" list, but not
then check the rest of the conventions for any other attributes they're not
aware of that might be active.
If this is flagged in appendix A, then it is guaranteed that any new attributes
will be considered for activeness, as when they are added to table in Appendix
A, the author will see the "Active" column, and be forced to put in a value. It
is more likely that a list embedded in the text (like we had in 1.8) would be
overlooked.
I propose this rewording:
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, as the
boundary variable is assumed to inherit all of the attributes of its parent
coordinate variable (with the exception of the **`formula_terms`** attribute).
When a bounds variable attribute is provided, it takes precedence over any
inherited value. However, when duplicating "active" attributes which affect the
interpretation of values (such as **`units`** and **`standard_name`**, see
Appendix A for the complete list of active attributes described by this
standard), their string or numeric values must be exactly the same as the
parent variable attributes. Data types of these duplicated attributes do not
need to match, but must be compatible for comparing values. Duplication of such
active attributes on the boundary variable is permissible but not recommended.
Then the next short paragraph ("Purely descriptive attributes which do __not__
affect interpretation ...") is not needed.
Thanks,
David
--
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-743068067
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.
