Here is a different compromise approach, in respect of multiple requests for **`string`** arrays. If this were a new design, then both scalar and array **`string`** attributes would be natural. Also, **`string`** support of any flavor will require code upgrades. I would prefer to make code upgrades once rather than twice. Adding **`string`** array support is not much harder than **`string`** scalar support by itself. Therefore:
* Allow **`string`** scalar and array attributes. * State that **`char`** attributes are preferred for backward compatibility. * Don't mix parsing rules between **`char`** and **`string`** attributes. Require that CF simple lists be stored only as **`string`** arrays, not **`string`** scalars with delimiters. The no-mix rule should make it easy to make general purpose parsing functions for CF simple list attributes, such that they can blindly distinguish and process both data types. This approach sacrifices round trip generic conversions between attributes of the two data types. You would need to either have CF-aware utilities, or else simply don't convert. This restriction is not a problem for me. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/141#issuecomment-409730169
