{"action":"created","issue":{"url":"https://api.github.com/repos/cf-convention/cf-conventions/issues/141","repository_url":"https://api.github.com/repos/cf-convention/cf-conventions","labels_url":"https://api.github.com/repos/cf-convention/cf-conventions/issues/141/labels{/name}","comments_url":"https://api.github.com/repos/cf-convention/cf-conventions/issues/141/comments","events_url":"https://api.github.com/repos/cf-convention/cf-conventions/issues/141/events","html_url":"https://github.com/cf-convention/cf-conventions/issues/141","id":343680693,"node_id":"MDU6SXNzdWUzNDM2ODA2OTM=","number":141,"title":"Add support for attributes of type string","user":{"login":"JimBiardCics","id":17711910,"node_id":"MDQ6VXNlcjE3NzExOTEw","avatar_url":"https://avatars2.githubusercontent.com/u/17711910?v=4","gravatar_id":"","url":"https://api.github.com/users/JimBiardCics","html_url":"https://github.com/JimBiardCics","followers_url":"https://api.github.com/users/JimBiardCics/followers","following_url":"https://api.github.com/users/JimBiardCics/following{/other_user}","gists_url":"https://api.github.com/users/JimBiardCics/gists{/gist_id}","starred_url":"https://api.github.com/users/JimBiardCics/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JimBiardCics/subscriptions","organizations_url":"https://api.github.com/users/JimBiardCics/orgs","repos_url":"https://api.github.com/users/JimBiardCics/repos","events_url":"https://api.github.com/users/JimBiardCics/events{/privacy}","received_events_url":"https://api.github.com/users/JimBiardCics/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":21,"created_at":"2018-07-23T15:24:22Z","updated_at":"2018-07-26T18:02:39Z","closed_at":null,"author_association":"NONE","body":"Attributes with a type of string are now possible with netCDF-4, and many examples of attributes with this type are \"in the wild\". As an example of how this is happening, IDL creates an attribute with this type if you select its version of **`string`** type instead of **`char`** type. It seems that people often assume that **`string`** is the correct type to use because they wish to store strings, not characters.\r\n\r\nI propose to add verbiage to the Conventions to allow attributes that have a type of **`string`**. There are two ramifications to allowing attributes of this type, the second of which impacts string variables as well.\r\n\r\n1. A **`string`** attribute can contain 1D atomic string arrays. We need to decide whether or not we want to allow these or limit them (at least for now) to atomic string scalars. Attributes with arrays of strings could allow for cleaner delimiting of multiple parts than spaces or commas do now (e.g. flag_values and flag_meanings could both be arrays), but this would be a significant stretch for current software packages.\r\n2. A **`string`** attribute (and a **`string`** variable) can contain UTF-8 Unicode strings. UTF-8 uses variable-length characters, with the standard ASCII characters as the 1-byte subset. According to the Unicode standard, a UTF-8 string can be signaled by the presence of a special non-printing three byte sequence known as a Byte Order Mark (BOM) at the front of the string, although this is not required. IDL (again, for example) writes this BOM sequence at the beginning of every attribute or variable element of type **`string`**.\r\n\r\nAllowing attributes containing arrays of strings may open up useful future directions, but it will be more of a break from the past than attributes that have only single strings. Allowing attributes (and variables) to contain UTF-8 will free people to store non-English content, but it might pose headaches for software written in older languages such as C and FORTRAN.\r\n\r\nTo finalize the change to support **`string`** type attributes, we need to decide:\r\n\r\n1. Do we explicitly forbid string array attributes?\r\n2. Do we place any restrictions on the content of **`string`** attributes and (by extension) variables?\r\n\r\nNow that I have the background out of the way, here's my proposal.\r\n\r\nAllow **`string`** attributes. Specify that the attributes defined by the current CF Conventions must be scalar (contain only one string).\r\n\r\nAllow UTF-8 in attribute and variable values. Specify that the current CF Conventions use only ASCII characters (which are a subset of UTF-8) for all terms defined within. That is, the controlled vocabulary of CF (standard names and extensions, cell_methods terms other than free-text elements of comments(?), area type names, time units, etc) is composed entirely of ASCII characters. Free-text elements (comments, long names, flag_meanings, etc) may use any UTF-8 character.\r\n\r\nTrac ticket: [#176](https://cf-trac.llnl.gov/trac/ticket/176#ticket)"},"comment":{"url":"https://api.github.com/repos/cf-convention/cf-conventions/issues/comments/408183727","html_url":"https://github.com/cf-convention/cf-conventions/issues/141#issuecomment-408183727","issue_url":"https://api.github.com/repos/cf-convention/cf-conventions/issues/141","id":408183727,"node_id":"MDEyOklzc3VlQ29tbWVudDQwODE4MzcyNw==","user":{"login":"JonathanGregory","id":8126248,"node_id":"MDQ6VXNlcjgxMjYyNDg=","avatar_url":"https://avatars3.githubusercontent.com/u/8126248?v=4","gravatar_id":"","url":"https://api.github.com/users/JonathanGregory","html_url":"https://github.com/JonathanGregory","followers_url":"https://api.github.com/users/JonathanGregory/followers","following_url":"https://api.github.com/users/JonathanGregory/following{/other_user}","gists_url":"https://api.github.com/users/JonathanGregory/gists{/gist_id}","starred_url":"https://api.github.com/users/JonathanGregory/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JonathanGregory/subscriptions","organizations_url":"https://api.github.com/users/JonathanGregory/orgs","repos_url":"https://api.github.com/users/JonathanGregory/repos","events_url":"https://api.github.com/users/JonathanGregory/events{/privacy}","received_events_url":"https://api.github.com/users/JonathanGregory/received_events","type":"User","site_admin":false},"created_at":"2018-07-26T18:02:39Z","updated_at":"2018-07-26T18:02:39Z","author_association":"CONTRIBUTOR","body":"Dear Jim\r\n\r\nThanks for addressing these issues. In fact you've raised two issues: the use of strings, and the encoding. These can be decided separately, can't they?\r\n\r\nOn strings, I agree with your proposal and subsequent comments by others that we should allow `string`, but we should *recommend* the continued use of `char`, giving as the reason that `char` will maximise the useability of the data, because of the existence of software that isn't expecting `string`. *Recommend* means that the cf-checker will give a warning if `string` is used. However it's not an error and a given project could decide to use `string`.\r\n\r\nFor the attributes whose contents are standardised by CF e.g. `coordinates`, if `string` is used we should require a scalar string. This is because software will not expect arrays of strings. These attributes are often critical and so it's essential they can be interpreted. For CF attributes whose contents aren't standardised e.g. `comment`, is there a strong use-case for allowing arrays of strings?\r\n\r\nI recall that at the meeting in Reading the point was made that arrays would be natural for `flag_values` and `flag_meanings`. I agree that the argument is stronger in that case because the words in those two attributes correspond one-to-one. Still, it would break existing software to permit it. Is there a strong need for arrays?\r\n\r\nBest wishes\r\n\r\nJonathan\r\n"}}
{"actor":{"display_login":"JonathanGregory"}}