@JimBiardCics : thank you for that detailed response. I certainly agree that we should aim for unambiguous language, and that ambiguity in the present CF Conventions and NUG are a source of confusion, and that there is an opportunity here to clear up some of the confusion.
I'm generally in favour of spinning off discussion items which can be handled independently, but it some of us do not consider the question of `string x(x)` as a variable as an independent issue. This hangs on the interpretation of the current CF convention. Jonathan, you and I have all cited continuity as at least partial motivation for views taken, but with different interpretations of the status quo that should be taken as a basis for decisions. The NUG is, I believe, unambiguous on the definition of what is considered as a coordinate variable within the NUG: namely, "A variable with the same name as a dimension". The problems start with the definition of a coordinate variable in [section 1.2 (terminology)](http://cfconventions.org/cf-conventions/cf-conventions.html#terminology) of the CF Convention: > We use this term precisely as it is defined in the NUG section on coordinate > variables. It is a one-dimensional variable with the same name as its > dimension [e.g., time(time) ], and it is defined as a numeric data type with > values that are ordered monotonically. Missing values are not allowed in > coordinate variables. This is long-standing text, and I don't believe that we have access to records of any of the discussions where we might find evidence of the intent behind the words. [Hassel et al (2017)](https://www.geosci-model-dev.net/10/4619/2017/gmd-10-4619-2017.pdf) state, with admirable clarity, that "A one-dimensional variable that has the same name as its dimension (z, x, and y in Fig. 3) is regarded as a coordinate variable". This is also the interpretation taken by the CF Checker -- so any NetCDF variable of the form `string x(x)` will be interpreted as a coordinate variable by the CF Checker. These sources are not normative, but they give an indication of consistent and long-standing interpretation of this part of the CF Convention. I can see in you latest reply a further source of confusion which I had not previously noticed: you are suggesting that we might disallow `string x(x)` as a **data variable** and yet allow it as an **auxiliary coordinate variable**. I had not considered this possibility because it appears, as far as I can tell, that an **auxiliary coordinate variable** is, as far as the implementation of the Convention is concerned, currently treated as a specific form of **data variable** (that is, all the rules which apply to the latter automatically apply to the former). This is not expressed explicitly, but the [Appendix A (Attributes)](http://cfconventions.org/cf-conventions/cf-conventions.html#attribute-appendix) does not have a separate category for **auxiliary coordinate variables** and the usage in examples implies that, for the interpretation of this table at least, the **auxiliary coordinate variable** is a special case of a **data variable**. I'm puzzled as to how we might interpret the convention if **auxiliary coordinate variable** is it is not considered as being just a **data variable** which is referenced in a `coordinates` attribute. It looks to me as though this would be a substantial increase in complexity and potential for confusion. Have you thought how this would work out in practice, if we were to add a specific class of variables which are acceptable as **auxiliary coordinate variables** but not as **data variables**? -- 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/174#issuecomment-596758320 This list forwards relevant notifications from Github. It is distinct from [email protected], 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 [email protected].
