Clarification of requirements on the attributes of a bounds variable

[martinjuckes]

Clarification of requirements on calendar attributes of a bounds variable

Moderator

None at present

Moderator Status Review [last updated: 2020/05/07]

Just posted

Requirement Summary

Express clearly what constitutes a valid value for the calendar attribute of a bounds variable.
During the discussion, the requirement was broadened to consider all attributes of bounds variables.

Technical Proposal Summary

Clarify the text in Section 7.1 expressing the requirement for equivalence of attributes between bounds and associated coordinate variables.

Benefits

People using the CF convention to describe coordinate bounds.

Status Quo

In Section 7.1 of the current standard it is stated that the calendar attribute of a bounds variable, together with other listed attributes, "must always agree exactly with the same attributes of its associated coordinate". This appears clear, but there is some ambiguity because noleap and 365_day values for the calendar attribute have exactly the same meaning. Some CMIP6 data, for example, has been provided with time coordinates using one form and the bounds variable using the other.

Does the reference to exact agreement in the standard mean agreement in string value, or agreement in meaning?

The other attributes referred to in the same sentence are units, standard_name and positive. The same issue could arise with the units attribute, in that it is possible, in many cases, to express the same logical unit with a range of different string values.

I do not have a strong preference here .. but it appears simplest, both in terms of the structure of the standard and the keeping things simplest for users, to insist on an exact match of the attribute values.

Detailed Proposal

Replace "must always agree exactly with" with "must exactly match the values of".

Pull request

#467

[davidhassell]

Hello Martin,

The intention, as I recall, was for agreement in meaning, rather agreement in the the exact strings, but that intent clearly didn't make it into the text.

If people agree, I would suggest the addition of some suitable wording to make this clear would make this a defect, rather than an enhancement.

Thanks,
David

[Dave-Allured]

Control attributes are fully redundant on bounds variables. The current standard already recommends against them, in two places. Why not simply deprecate them, rather than adding new requirements?

[martinjuckes]

@davidhassell : OK, I'd be happy to treat this as a defect issue -- do you recall where the intention you refer to was discussed? Or who was involved?

@Dave-Allured : I'm not sure why the original choice was made. It would certainly be simpler to ban these attributes on bounds variables, but doubt that it justifies changing the status-quo.

[davidhassell]

The original discussions took place on Trac ticket 140 (https://cf-trac.llnl.gov/trac/ticket/140), which was accepted for inclusion into CF-1.7. I'll mark this issue as a defect for now.

Deprecating (rather than banning) these attributes is, of course, possible, but I don't feel there is a use case for it at this time. I wonder if there are use cases for bounds variables having, for example, different but equivalent units, or for bounds variables being used independently of their parent coordinate variables (in which case having units, names, etc could be useful). In any event, that perhaps is a discussion for a separate issue, if anyone wants it.

[martinjuckes]

Hi @davidhassell : thanks.

There is a use case for providing attributes on bounds variables in the Trac ticket which you cited (140) : @taylor13 describes a usage where the user needs to know the units of the bounds variable and does not make use of the parent coordinate variable. However, the more important point, I think, is that the status quo is clearly that use of these attributes on the bounds variables is clearly deprecated and not forbidden. Changing that would, as you say, be a discussion for another issue.

@JonathanGregory , @taylor13 : can you help with the interpretation of the intention of the discussion in Trac 140 on the precise rule for calendar attributes on bounds variables? In particular, if a variable has calendar = noleap, would calendar = 365_day on the bounds be:

• (A) deprecated as being the same but redundant or
• (B) forbidden as being a different string (not exactly the same, even though it has exactly the same meaning)?

[JonathanGregory]

Evidently we didn't think of this problem. As far as I remember, I had in mind that the strings would have to be exactly the same (B), because it's simpler to check and consistent with them not being needed anyway, which is why they're deprecated in general.

[davidhassell]

OK - are these the three choices, then (in no particular order)?

i) Drop the word exactly from

"must always agree exactly with the same attributes of its associated coordinate, scalar coordinate or auxiliary coordinate variable" (7.1)

as rectifying a defect.

ii) Keep the word exactly but clarify it to mean "exact string match". This is also rectifying (a different) defect.

iii) Drop the word exactly from the sentence as an enhancement.

[Dave-Allured]

Reconsidering, and after briefly reviewing Trac 140, I favor a fourth choice:

iv) Martin's original wording, "must exactly match the values of", with no further changes. This rectifies a defect.

To me this is simple and sufficient. @davidhassel, I understand what you are trying to clarify in (ii) above, but I think the extra wording is not needed.

I retract my earlier comment about deprecating "control attributes". My true preference is to fully ban interpretive attributes on bounds variables, on the rationale that they are only an extension of the parent. This has been said before. But that is outside the scope of this ticket, so I will drop that for now.

[martinjuckes]

@davidhassell : David A. and Jonathon are both in favour of requiring an exact string match (my option (B), your option (ii)). Are you happy with this interpretation?

I agree with Jonathon that this is preferable in order to preserve clarity in the file metadata.

[davidhassell]

I don't particularly like the idea of insisting on "exact string match", because it is contrary to how the rest of CF works. For example, if output from one instrument has a data variable with units of 'watt' and the output from a model has a comparable data variable, in the same netCDF file, with units of 'meter^2-kilogram-second^-3', then that is fine, even though it may lack clarity for the user.

I think that it would useful to recommend that exact string matches are used, for clarity, but not to insist on it.

[JonathanGregory]

Dear @davidhassell
I agree that exact string match is unlike the rest of CF. It seems OK and appropriate to me in this case because providing exactly the same string is the nearest thing to not providing any string, and thus taking the default i.e. the value on the coordinate variable. It is transparent and easy to check that the attribute on the bounds is giving the same information if it must be the same or absent. I think that we would be better off if we had not allowed attributes on bounds variables.
However, you could argue there was a purpose or advantage in allowing a different string that meant the same. That would be an enhancement, as you say, for which we need a convincing use-case.
Best wishes
Jonathan

[Dave-Allured]

@davidhassell, please consider that bounds variables are unique in relation to ordinary data variables, thus the analogy to instruments with equivalent unit strings is not a very good comparison. A bounds variable should be nothing more than a close extension of the parent coordinate variable. Its only purpose is to provide explicit cell boundary values for each coordinate value.

A better analogy would be to actual_range attributes. By their structure alone, these can not have their own independent interpretive attributes, and always inherit from the parent. I see bounds variables in the same light.

IMO the practice of varying attribute string values on bounds should be discouraged or prohibited, thus I favor the original intent to prohibit non-exact string values. The message to dataset creators should be simply, "Don't do this."

[davidhassell]

Hello @JonathanGregory and all,

I don't have a use case for allowing a different string that means the same, and agree that providing exactly the same string is the nearest thing to not providing any string.

Therefore, I'm happy to agree with the the "exact string match" interpretation.

Thanks,
David

[Dave-Allured]

There seems to be a consensus. Please review my suggested changes in the above PR. Note that for consistency, I expanded this to all functional attributes on boundary variables, not just calendar.

[Dave-Allured]

Apologies, I made a github newbie mistake and failed to squash my commits. Please review changes in the next PR to follow. They will be easier to read.

[taylor13]

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 #265 (comment) that "Some CMIP6 data, for example, has been provided with time coordinates using one form and the bounds variable using the other.")

[JonathanGregory]

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 allowed. This proposal would disallow it. If there are any such datasets, they would be invalidated by the next version of the conventions, but not by the version they were written with, of course. In general we don't like even this sort of backward-incompatibility but I think it's harmless in this case. If software chose to rely on the new convention and assume that the bounds had the same calendar as the coordinates without checking, the outcome would still be OK if it's equivalent although not exactly the same string.

[JonathanGregory]

Dear @Dave-Allured

Thanks for the text. I have a couple of comments.

• I suggest omitting the word "functional", which occurs twice. It's not obvious (to me) what it might mean exactly, and I think that really you're defining what it means by going on to describe the two groups concerned. The word "functional" therefore doesn't add any information but might puzzle the reader.

• 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, to say something like, "Other attributes not mentioned above, such as long_name, may have different values for the coordinate and boundary variable, if present on both."

Jonathan

[Dave-Allured]

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 as Conventions = CF-1.8 or earlier. So I agree, they are technically conformant because of this label, but would be non-conformant if re-labeled to a later CF version.

My strict wording of this requirement was intentional, based on the discussion up to this point.

[martinjuckes]

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 considered as valid. My interpretation of the status quo is that the convention is ambiguous, so I don't personally think that a clarification would break with backward compatibility.

The strict interpretation, treating the above as an error, is in line with the current behavior of the cf-checker, which is how I became aware of the CMIP6 files which contain this syntax.

@Dave-Allured : 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 attributes. It might be clearer if placed at the end of line 12?

[Dave-Allured]

@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 variable".

On review, I notice that the original sentence in CF-1.8 is kind of puzzling in its own way.

Boundary variable attributes which determine the coordinate type (units, standard_name, axis and positive) or those which affect the interpretation of the array values (units, calendar, leap_month, leap_year and month_lengths) must always agree exactly with the same ...

Is it appropriate here to explain distinction between the first and second groups? What is the best way to describe the general intention here, yet try to remain concise?

For the purpose of this section, I think we only care about indicating which attributes are significant in some way to CF interpretation and processing. Let me tentatively merge the two groups, because the distinction may not be locally relevant, and try this simplified wording without "functional":

Boundary variable attributes which are significant to CF interpretation (units, standard_name, axis, positive, calendar, leap_month, leap_year and month_lengths) must always agree exactly with the same ...

Do you like this, or have another suggestion?

[Dave-Allured]

@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, to say something like, "Other attributes not mentioned above, such as long_name, may have different values for the coordinate and boundary variable, if present on both."

I added a new short paragraph for this, and expanded a little. Check out this commit: Dave-Allured@44fcdb1

I preserved the opening sentence because it was a general introduction to the concept, and also it was inherited like this from the original in CF-1.8.

[JonathanGregory]

I think that it would be OK to require the same data type as well the same value. In fact I slightly prefer identity of both type and value, because to me it seems that providing something which is exactly redundant is more like providing nothing at all, which is what we want.

[JonathanGregory]

Dear all

It would be good if we could conclude this issue, about the attributes of bounds variables, because it has been open for a long while. Considering the previous discussion, I propose the following wording (a revised version of earlier text), to replace the last sentence of the first paragraph of sect 7.1 ("Since a boundary variable ...") and the whole of the next paragraph ("Boundary variable attributes which ..."):

A boundary variable inherits the values of some attributes from its parent coordinate variable. If a coordinate variable has any of the attributes marked "I" (for "inherit") in the "Use" column of Table A.1, they are assumed to apply to its bounds variable as well. It is recommended not to include any of these attributes on a bounds variable. If such an attribute is included, its data type and its value must be exactly the same as the parent variable's attribute.

A bounds variable may have any of the attributes marked "O" for ("own") in the "Use" column of Table A.1. These attributes take precedence over any corresponding attributes of the parent variable. In these cases, the parent variable's attribute does not apply to the bounds variable, regardless of whether the latter has its own attribute.

It is recommended that a bounds variable should not have any attribute which is not marked either "I" or "O" in the "Use" column of Table A.1, even if it can be an attribute of the parent coordinate variable (those marked "C").

The "I" attributes are axis calendar cf_role computed_standard_name leap_month leap_year long_name month_lengths positive standard_name units. The "O" attributes are actual_range add_offset compress formula_terms missing_value scale_factor valid_max valid_min valid_range _FillValue. "C" attributes which are neither "I" nor "O" are bounds climatology nodes. geometry should not be marked "C" (that's a defect).

Although this began as a defect, I think that adding new "Use" values for attributes (for which some support was previously expressed) is an enhancement, so I'm changing the label. I hope that doesn't slow down the conclusion! What do you think?

Best wishes

Jonathan

[Dave-Allured]

Jonathan, those changes look good to me. I need to retire from this particular discussion, and abandon my pull request. Also I think this issue #265 should be re-titled to something like "Clarification of attributes on bounds variables". Best wishes for a good resolution.

[JonathanGregory]

Thanks, @Dave-Allured. I have generalised the title, as you suggest.

[Dave-Allured]

P.S. Whomever picks this up, this should be obvious, but please feel free to copy all any or draft wording out of my old pull request.

[davidhassell]

Hello,

Thanks for new text, Jonathan, which I like, but wonder if the I and O system could be simplified. Would it work to say that all attributes already marked C are inherited by bounds variables, but any bounds variable attribute that is also marked B overrides that inheritance? Then we only need one new usage type (B) on a smaller number of attributes.

Should compress be in the listed of "owned" bounds variable attributes? It can only appear on a coordinate variable that contains indices.

The new text doesn't mention that the bounds variable must be of the same data type as it's parent coordinate variable. Am I right in thinking that that was agreed?

Thanks,
David

[JonathanGregory]

Dear David

[I] wonder if the I and O system could be simplified. Would it work to say that all attributes already marked C are inherited by bounds variables, but any bounds variable attribute that is also marked B overrides that inheritance? Then we only need one new usage type (B) on a smaller number of attributes.

Actually, in my text, which I think is consistent with the discussion, there is no situation where the bounds attributes overrides the parent attribute. If it's inheritable, it should be omitted, and if included it must be exactly the same as the parent, so it's not overridden, just repeated. If it's not inheritable, and not present, it's undefined for the bounds, rather than inherited.

I think two new "Use" values are needed (rather than one) because there are three situations to distinguish. As well as the two just mentioned, there is also a group of attributes which should not be used for bounds, because they are inappropriate.

Should compress be in the listed of "owned" bounds variable attributes? It can only appear on a coordinate variable that contains indices.

As you said in your earlier comment, compress should be included only if the bounds are compressed. Hence, it can't be inheritable, because it would be implied to apply the bounds if it wasn't included as a bounds attribute, and that's not necessarily right. Hence it must be an "own" attribute. However, it's unusual because the "own" attribute, if present, must be identical to the parent attribute!

The new text doesn't mention that the bounds variable must be of the same data type as it's parent coordinate variable. Am I right in thinking that that was agreed?

Yes, it was agreed, and that's what the first paragraph says. "If such an attribute is included, its data type and its value must be exactly the same as the parent variable's attribute."

Best wishes

Jonathan

[davidhassell]

Having had a very useful offline conversation with Jonathan, I now see that some of my suggestions weren't at all right, for which apologies. Specifically, my suggestion about "B" usage type in appendix A, and my comments on the data type of bounds variable.

We did, however, also come up with a changes to the proposed text.

1. The last sentence ("It is recommended that a bounds variable should not have any attribute which is not marked either "I" or "O" in the "Use" column of Table A.1, even if it can be an attribute of the parent coordinate variable (those marked "C")" is not needed, as this notion is taken as read for all variables of all types.

2. The usage categories should be BI and BO, instead of "I" and "O" respectively, to highlight these categories relate to boundary variables.

3. We should disallow an inheritable attribute (BI) being set on the bounds variable but not on the parent coordinate variable.

4. The compress attribute should should not be in the BO selection, as it is only standardised for list variables used in compression by gathering. Whilst the list variable and its dimension have the same name it is not a coordinate variable in the CF sense, so C type attributes like bounds are not meaningful. We should mention something about this in section 8.2 Lossless Compression by Gathering.

The proposal then could then become (new text in bold)

A boundary variable inherits the values of some attributes from its parent coordinate variable. If a coordinate variable has any of the attributes marked "BI" (for "inherit") in the "Use" column of Table A.1, they are assumed to apply to its bounds variable as well. It is recommended not to include any of these attributes on a bounds variable. If such an attribute is included, its data type and its value must be exactly the same as the parent variable's attribute. A boundary variable can only have inheritable attributes if they are also present on its parent coordinate variable.

A bounds variable may have any of the attributes marked "BO" for ("own") in the "Use" column of Table A.1. These attributes take precedence over any corresponding attributes of the parent variable. In these cases, the parent variable's attribute does not apply to the bounds variable, regardless of whether the latter has its own attribute.

The "BI" attributes are axis calendar cf_role computed_standard_name leap_month leap_year long_name month_lengths positive standard_name units. The "BO" attributes are actual_range add_offset formula_terms missing_value scale_factor valid_max valid_min valid_range _FillValue.

---

For the compression by gathering sissue, I suggest appending to the second paragraph in section 8.2 Lossless Compression by Gathering, new text in bold:

The list is stored as the coordinate variable for the compressed axis of the data array. Thus, the list variable and its dimension have the same name. The list variable has a string attribute compress, containing a blank-separated list of the dimensions which were affected by the compression in the order of the CDL declaration of the uncompressed array. The presence of this attribute identifies the list variable as such. The list, the original dimensions and coordinate variables (including boundary variables), and the compressed variables with all the attributes of the uncompressed variables are written to the netCDF file. The uncompressed variables can be reconstituted exactly as they were using this information. Note that even though the list variable and its dimension have the same name, it is not acting as a coordinate variable, and so can not be associated with a boundary variable.

Thanks,
David

[JonathanGregory]

Dear David

Thanks for the discussion and for making the text simpler and better.

Regarding section 8.2, I don't think we can say it's not a coordinate variable, because formally it is one, and the paragraph you've quoted begins by saying that it is. I'd suggest we avoid this by not giving a reason for the prohibition. Instead of your bold sentence, I'd propose a shorter one: "The list variable must not have an associated boundary variable."

Best wishes

Jonathan

[davidhassell]

Thanks, Jonathan - your text for 8.2 is much better. In full we have:

The list is stored as the coordinate variable for the compressed axis of the data array. Thus, the list variable and its dimension have the same name. The list variable has a string attribute compress, containing a blank-separated list of the dimensions which were affected by the compression in the order of the CDL declaration of the uncompressed array. The presence of this attribute identifies the list variable as such. The list, the original dimensions and coordinate variables (including boundary variables), and the compressed variables with all the attributes of the uncompressed variables are written to the netCDF file. The uncompressed variables can be reconstituted exactly as they were using this information. The list variable must not have an associated boundary variable.

[davidhassell]

Hello - unless there are any objections, I shall write up these agreed changes in a PR, with the aim of meeting the CF-1.11 deadline.

Thanks,
David

[davidhassell]

Hello @martinjuckes, @Dave-Allured, @JonathanGregory, @taylor13, and @sethmcg,

As participants in this conversation, it would be great if you could look at the associated PR #467 and confirm if you are happy with it (or not). The deadline for getting changes into CF-1.11 is Monday 13th November 2023 (i.e. 3 weeks before the expected release date of 4th December), so if you are able to look at it please do so soon.

We welcome, of course, a review from anyone else who is interested.

Many thanks,
David

[taylor13]

I support the changes suggested. A couple questions regarding the text:

I had trouble understanding the last sentence regarding inherited attributes. I would suggest reordering the information in the last two sentences. Is the following better?

A boundary variable inherits the values of some attributes from its parent coordinate variable. If a coordinate variable has any of the attributes marked "BI" (for "inherit") in the "Use" column of Table A.1, they are assumed to apply to its bounds variable as well. It is recommended not to include any of these attributes on a bounds variable, but it is technically not forbidden to include a BI attribute as long as it is also present in the parent coordinate variable. If such an attribute is included, its data type and its value must be exactly the same as the parent variable's attribute (i.e., there must be an exact match).

I also found it odd that we even mention bound variables in conjunction with list variables. Aren't list variables invariably integer pointers to where the defined values of an array should be inserted into an array, skipping the elements that are missing? Why would indices of anything have bounds? If I understand this correctly, I'd rather we not muddy things by mentioning boundary variables here.

That being said, I support the proposal no matter what the wording.

[davidhassell]

Hi @taylor13,

Thank you for the review. I like your suggested change to chapter 7 ("It is recommended not to include any of these attributes on a bounds variable, but it is technically not forbidden to include a BI attribute as long as it is also present in the parent coordinate variable"), and will put it into the PR.

On list variable bounds, you are indeed right that bounds are nonsense, but currently the conformance checker has no rule on enforcing this, so we need to make it clear in the text.

[davidhassell]

I realise that I missed a bit of Karl's suggested text ("(i.e., there must be an exact match)"). I'd like to suggest a rewording around that:

If such an attribute is included then it must match exactly the parent variable’s attribute, i.e. the data type and value must be exactly the same.

[JonathanGregory]

Dear @davidhassell, Karl @taylor13 et al.

I support the intention and would like to suggest some further small changes to words.

I feel that it's not clear whether the "Use" sentence in Appendix A is talking about variables or attributes:

The "Use" values are G for global, Gr for applying to groups, C for variables containing coordinate data, D for data variables, M for geometry container variables, Do for domain variables, BI for for attributes inherited by boundary variables, BO for attributes owned by boundary variables, and - for variables with a special purpose.

I propose:

Each attribute may be used in any of the ways shown in its "Use" entry. G indicates it can appear as a global attribute, Gr as a group attribute, and all others as an attribute of a certain kind of variable, as follows: C for variables containing coordinate data, D for data variables, M for geometry container variables, Do for domain variables, BI for boundary variables when the attribute is inherited from the parent variable (which must have an exactly matching attribute, so the boundary variable attribute is redundant), BO for boundary variables when the attribute is owned by the boundary variable (and it is irrelevant whether the parent variable has such an attribute or what its value is), and - for variables with some other purpose.

In Chapter 7, I propose that we remove some duplication, and the word "technical", which I don't think makes the text clearer, and that we should use the phrase "boundary variable" consistently:

A boundary variable inherits the values of some attributes from its parent coordinate variable.
If a coordinate variable has any of the attributes marked "BI" (for "inherit") in the "Use" column of <>, they are assumed to apply to its bounds boundary variable as well.
It is recommended not to include a BI attribute of these attributes on a bounds boundary variable, but it is technically not forbidden to include a BI attribute provided that as long as it is also present in the parent coordinate variable and that it exactly matches If such an attribute is included then it must match exactly the parent variable's attribute, i.e. the data type and value must be exactly the same.
A boundary variable can only have inheritable attributes if they are also present on its parent coordinate variable.

A bounds boundary variable may have any of the attributes marked "BO" for ("own") in the "Use" column of <>.
These attributes take precedence over any corresponding attributes of the parent variable.
In these cases, the A parent variable's BO attribute does not apply to the its bounds boundary variable, regardless of whether the latter has its own attribute.

Best wishes

Jonathan

[taylor13]

Dear @JonathanGregory . I think your text is an improvement. I might further tweak the following:

In Appendix A, REPLACE your suggested text with:

WITH: Each attribute may be used in any of the ways shown in its "Use" entry. G indicates it can appear as a global attribute, and Gr as a group attribute; if use of an attribute is restricted to certain kinds of variables this is indicated as follows: C for variables containing coordinate data, D for data variables, M for geometry container variables, Do for domain variables, BO for boundary variables, BI for a variable that can be inherited by a boundary variable from a parent, and - for variables with some other purpose.

(I don't think it is necessary to mention here how the BI attributes might (contrary to our recommendations) might be also included explicitly with the boundary variable.)

In Chapter 7, REPLACE: It is recommended not to include a BI attribute on a boundary variable, but it is not forbidden to include a BI attribute provided that it is also present in the parent variable and that it exactly matches the parent variable's attribute, i.e. the data type and value must be exactly the same.

WITH: It is recommended that BI attributes not be included on a boundary variable, but this is not absolutely forbidden. If a BI attribute is included, it must also be present in the parent variable, and it must exactly match the parent attribute's data type and value.

[JonathanGregory]

Dear Karl @taylor13

For the sake of further simplicity:

Each attribute may be used in any of the ways shown in its "Use" entry. G indicates it can appear as a global attribute, and Gr as a group attribute; if use of an attribute is restricted to certain kinds of variables this is indicated as follows: C for variables containing coordinate data, D for data variables, M for geometry container variables, Do for domain variables, BI and BO for boundary variables (see <<cell-boundaries>> for the distinction between BI and BO), and - for variables with some other purpose.

and

It is recommended that BI attributes not be included on a boundary variable , but this is not absolutely forbidden. If a BI attribute is included, it must also be present in the parent variable, and it must exactly match the parent attribute's data type and value.

If it was absolutely forbidden, we would say it MUST NOT be included. I don't think we need to say what isn't the case as well as what is the case. 😄 Moreover, the next sentence implies that it's allowed, otherwise we wouldn't bother to stipulate these conditions.

Best wishes

Jonathan

[taylor13]

HI Jonathan, Yes, that is better still. Thanks. Best wishes, Karl From: JonathanGregory ***@***.***> Reply-To: cf-convention/cf-conventions ***@***.***> Date: Friday, November 17, 2023 at 5:32 AM To: cf-convention/cf-conventions ***@***.***> Cc: "Taylor, Karl E." ***@***.***>, Mention ***@***.***> Subject: Re: [cf-convention/cf-conventions] Clarification of requirements on the attributes of a bounds variable (#265) Dear Karl @taylor13<https://urldefense.us/v3/__https:/github.com/taylor13__;!!G2kpM7uM-TzIFchu!yBCdlWo3TC9ieKDvIM15VrummBOdzJVlKPWEcf4-DTdqz8Js-dtpb7Reg48doM4oGehSUzDnZ91nYIZ66OMxF8YYdqY$> For the sake of further simplicity: Each attribute may be used in any of the ways shown in its "Use" entry. G indicates it can appear as a global attribute, and Gr as a group attribute; if use of an attribute is restricted to certain kinds of variables this is indicated as follows: C for variables containing coordinate data, D for data variables, M for geometry container variables, Do for domain variables, BI and BO for boundary variables (see <<cell-boundaries>> for the distinction between BI and BO), and - for variables with some other purpose. and It is recommended that BI attributes not be included on a boundary variable , but this is not absolutely forbidden. If a BI attribute is included, it must also be present in the parent variable, and it must exactly match the parent attribute's data type and value. If it was absolutely forbidden, we would say it MUST NOT be included. I don't think we need to say what isn't the case as well as what is the case. 😄 Moreover, the next sentence implies that it's allowed, otherwise we wouldn't bother to stipulate these conditions. Best wishes Jonathan — Reply to this email directly, view it on GitHub<https://urldefense.us/v3/__https:/github.com/cf-convention/cf-conventions/issues/265*issuecomment-1816439011__;Iw!!G2kpM7uM-TzIFchu!yBCdlWo3TC9ieKDvIM15VrummBOdzJVlKPWEcf4-DTdqz8Js-dtpb7Reg48doM4oGehSUzDnZ91nYIZ66OMxXMnCnko$>, or unsubscribe<https://urldefense.us/v3/__https:/github.com/notifications/unsubscribe-auth/ABGDDH3AVXOJPSAEOIN43ZTYE5ROLAVCNFSM4M3QF632U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBRGY2DGOJQGEYQ__;!!G2kpM7uM-TzIFchu!yBCdlWo3TC9ieKDvIM15VrummBOdzJVlKPWEcf4-DTdqz8Js-dtpb7Reg48doM4oGehSUzDnZ91nYIZ66OMxVVjtMog$>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[davidhassell]

Dear Jonathan and Karl - thanks for your good suggestions. They are now in the PR: a711f7d.

[davidhassell]

Hello, 3 weeks have passed with the only comments being on presentation and clarity, which have been resolved. Could someone please merge PR #467?

Many thanks to everyone who took part in this discussion.

[JonathanGregory]

Thanks, @davidhassell. I have resolved a conflict and will merge it now.