@martinjuckes said:
> ... the last sentence in the 2nd paragraph (line 14) of your text reads
> "Their data types do not need to be an exact match." I think that "Their"
> refers to the parent variable and the bounds variable, but grammatically, as
> written, it appears to refer to the
Um, @martinjuckes **did** literally say there are existing files with this
conflict. First paragraph under **Status Quo** above: "Some CMIP6 data, for
example, has been provided with time coordinates using one form and the bounds
variable using the other."
Presumably such files are labeled
I assume that @martinjuckes meant that some CMIP files might say `noleap` and
others `365_day`. I don't think he meant that there are existing files in which
`noleap` was used on the coordinate variable and `365_day` on the bounds, for
example, but he was concerned that this might currently be
To be sure, is the change in text backward compatible or will it make some
datasets that were considered conformant with CF now non-conformant? (nb. It
is stated in
https://github.com/cf-convention/cf-conventions/issues/265#issue-614215549 that
"Some CMIP6 data, for example, has been provided
Hi @Dave-Allured , @JonathanGregory : Dave is right, the main motivation for
raising this was to see if something of the form:
```
double time(time) ;
time:bounds = "time_bnds" ;
time: calendar = "noleap" ;
double time_bnds(time,nb) ;
time_bnds: calendar = "365_day" ;
```
should be
@JonathanGregory, thanks for the feedback. Your help with the wording is
appreciated.
I thought the term "functional attributes" might be understood from context. I
was looking for a short collective term that means "attributes that are
functionally active in the CF interpretation of the
@JonathanGregory said:
* You mention `long_name` as an example but it's not one of the attributes
"controlled" by this restriction. The reader might wonder about it. Perhaps it
would be better not to mention `long_name` in this paragraph. We could add a
final paragraph, after `formula_terms`,
