@JimBiardCics et al, I think **`string`** arrays for simple list attributes are the best single choice for the long term. It is likely that CF2 and other conventions will favor **`string`** arrays in the future. If you choose scalar **`strings`** for CF1, this will probably commit two different ways to handle **`string`** attributes later, in addition to the existing delimited **`character`** type. This is a messy future scenario that I want to avoid.
I assert without proof that the necessary upgrades to languages and user code for **`string`** arrays will be simple and straightforward. Add a function to detect the attribute's file data type, as needed. Use the data type, and nothing else, to decide when to parse on delimiters, and when to assume array. This way, there will be no future need to involve the convention version for this purpose. There will be some short term inconveniences to adapt to **`string`** arrays. Code can be adapted gradually as **`string`** arrays are encountered in new data sets. Also as I said earlier, this entire process can be encapsulated in a CF aware function for the specific list attributes, to simplify user code upgrades. My "vote" is I am abstaining from the consensus on this. Please take my comments as suggestions, and I leave the choice up to the rest of this capable group. -- 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-420360207
