On Mar 28, 2013, at 17:54, Steve Hankin <steven.c.hankin at noaa.gov> wrote:
> netCDF files are in every sense "binary" files. They cannot be read except by custom-built utilities. (Or is there a constituency that wants to access CF using the unix "strings" command?) In all cases except the present discussion, it is the job of those custom-built utilities to generate formatted string representations of the information contained in the CF binary encoded variables.
>
> The entire current discussion would not be happening, if the custom-built utilities and standard code libraries supported the ability to get time information into and out of our binary files using formatted ISO 8601 strings.
This is arguably not true. I gave two use cases, one was the derided equivalent of your Unix strings command (call me crazy, it fits in this case!); the other was the desire to store an ASCII string of particular structure and meaning into the binary netCDF file, and then to label the information in that binary file with what it is. No more, and no less. (Uh, unless I think of another use case. :->)
Seriously, I think some use cases, partly including my first one, go directly to your point -- "my tool can't print this timestamp as ISO 8601 so I'm going to duplicate the data as ASCII, in that ISO format, as a workaround" -- but the second one remains a real use case regardless of existing tool support for representations. And it goes beyond time, now that we're on this topic.
The fact that most use netCDF as a strict binary encoding does not mean it must exclude those who want to use it to store ASCII strings. That is perhaps the key criterion -- the community can say "No ASCII string representations of anything!", or "No standard names for ASCII strings", if either is a constraint they really want.
So, for those who want to be able to store strings, however different that may sound, and then label them with standard names when that's appropriate -- is the tent open to that? Nothing in the standard suggested to me it was not, though it often seems to offend practitioners, so maybe I've missed something.
John
---------------
John Graybeal
Marine Metadata Interoperability Project:
http://marinemetadata.org
graybeal at marinemetadata.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130328/1296420c/attachment-0001.html>
Received on Thu Mar 28 2013 - 10:36:07 GMT
