Dear Jim Thanks 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?
On 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`. For 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? I 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? Best wishes Jonathan -- 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/141#issuecomment-408183727
