I agree with the original rationale of CF section 2.6.2, embed newline characters into long strings to break them into lines, for readability whenever possible.
Now there is a complication. **Full netcdf-4** format offers two different string data types; **character** and **string**. I think with introduction of the formal **string** data type, **ncdump** was changed for **both** data types, so that visual line breaks would be used **only to separate elements of an array of strings**. I think the new intent was that if you want to display multiple lines, you are supposed to use an **array of strings**, rather than newline delimiters. The traditional **character** data type supports only a 1-dimensional array of single characters. Therefore the **original** intent of **ncdump** was to provide use of newlines to embed visual line breaks. The result was a developer's choice to switch the display style based on the file format type. At this time there is not much to be done to change that. This dichotomy creates some challenges for standards, and for conversions between the two data types. Note that writing formal **string** data type with embedded newlines is still perfectly legal according to basic netcdf-4 rules. I have not looked up how CF handles this. I advise not making any reading code that depends specifically on one or the other of these two newline strategies. It would be reasonable to have code that knows how to digest both strategies in a smart way, so that the application does the right thing and gets an equivalent result for both cases. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/347*issuecomment-1009442635__;Iw!!G2kpM7uM-TzIFchu!hilH89d3tuh6cSFEO_liII1lRtrbC9kz3EyQ-uxhZCHP0WGlzImm42Tk1-vxqTmf84JhX58SXLI$ You are receiving this because you are subscribed to this thread. Message ID: <cf-convention/cf-conventions/issues/347/[email protected]> 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].
