Re: CIF-JSON draft 2017-05-15

Two last comments:

1. This comment in the CIF1 spec:

13. The base CIF specification distinguishes between character and numeric values (see paragraph 15 of the document Common semantic features). Particular CIF applications may make more finely-grained distinctions within these types. The paragraphs immediately above have the corollary that a data value such as 12 that appears within a CIF may be quoted (e.g. '12') if, and only if it is to be interpreted and stored in computer memory as a character string and not a numeric value. For example '12' might legitimately appear as a label for an atomic site, where another alphabetic or alphanumeric string such as 'C12' is also acceptable; but it may not legitimately be used to represent an integer quantity twelve.

​suggests that CIF-JSON absolutely cannot be round-tripped back to CIF format.

2. One thing we are missing here is a magic number. I know, transport should not need that. But before you know it, someone is going to put a CIF-JSON data stream into a file and then pass that file to another program such as Jmol, expecting the program to know what it is reading. This has always been a nightmare for Jmol. The #\#CIF_2.0 header takes care of that for CIF. In the past all too often people have created formats that don't quickly identify themselves, causing all sorts of headaches. What would you think of this?

{"CIF-JSON":{....}}

This way a reader could  always know that it is reading CIF-JSON data immediately with just a 10-byte stream read. It would allow file saving and retrieval of the data.

_______________________________________________
cif-developers mailing list
cif-developers@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/cif-developers