> My original observation was that we can absolutely split off some of these 
> issues.
Agreed. 

Have these been started? I can't find them if they have.

There is also the question of what to do with CHAR types -- the same as STRING?

And what about encoding of CHAR and STRING variables? I can't find anything 
about that in the current CF document, so it doesn't seem to be settled.

Maybe this should go in a new issue, but for now, I had a (not well formed) 
thought:

CHAR variables and attributes should only be encoded in a 1-byte per character 
ascii compatible encoding: e.g. ascii, latin-1

STRING variables and attributes should only be encoded in utf-8 (of which ascii 
is a subset)

My justification is that there will be little software in the wild that 
supports Unicode, but does not support String. Setting this standard will make 
it less likely that older software that assumes a 1byte per character text 
representation will get handed something it can't deal with. And the string 
type is better suited to  Unicode anyway, as the "length" of a string is less 
well defined.


-- 
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-599262170

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].

Reply via email to