Re: Draft JSON specification, round 2

I think you have it, James. One suggestion if we wanted to be flexible would be to have a key that is reserved for indicating CIF-JSON  ("JCIF2"? -- I prefer seeing that "2" there for emphasis) that indicates how numbers are handled and then let the reader beware. I recommend a key called metaData and have that as a place where encoding information could be placed.

Do you see these as having a serial array [...]  at the top level or an associative array {....}?

Bob

On Wed, Apr 19, 2017 at 1:32 AM, James Hester <jamesrhester@gmail.com> wrote:

Dear CIF developers,

Reviewing last weeks' discussion, there is a clear bifurcation in the approaches to CIF-JSON that have arisen in practice: (1) the 'high fidelity' approach of COD-JSON (2) the 'low overhead' approach of JMol and Marcin.  This suggests that a single JSON is unlikely to satisfy all users.  Given that COD-JSON is available, implemented and complete, with open-source tools available, I propose we continue to explore here the 'low overhead' approach to see whether it can be brought to a similar state.

First let me summarise the points where I see consensus arising out of the discussions last week:

(1)  No allowance needs to be made for expressing CIF numbers as JSON numbers, and therefore no "uncertainties" object is necessary

(2)  To round-trip a CIF, information about which datavalues were quoted must be preserved

(3)  Using an escape mechanism for CIF '?' is undesirable, instead \uFFFF or \u0001 would be suitable

So: I propose changing the draft so that (1) all datavalues are strings (2) an unquoted question mark is replaced by \uFFFF (3) the 'uncertainties' object is removed.  The resulting JSON would have the following properties:

(1) It would not be possible to (re)create conformant input CIFs unless dictionary definitions are available for all datanames

(2) CIF-JSON readers must parse numeric values as needed

(3) CIF-JSON writers must explicitly format newly-inserted numeric values as JSON strings

(4) A CIF containing numeric datavalues in delimited strings would be processed through a JSON application without detection of non-conformity. For example, JSON generated from the fragment

loop_

_atom_site.fract_x

_atom_site.fract_y

_atom_site.fract_z
"0.0" "0.5" "0.1234(4)"
"0.0" "0.0" "0.7500"

would be processed without error by a JSON application that plots atomic positions (e.g. JMol).

Point (1) should be spelled out in all documentation and COD-JSON suggested as an alternative
Point (2) imposes extra work compared to parsing the values once before passing around the resulting object, although as Bob points out, the difference between the built-in JSON parser parsing a non-delimited string and your custom parser parsing a number with optional uncertainty is slight
Point (3) is very little extra work as formatting of numbers with uncertainties is not a typical JSON library operation
Point (4) is not a problem for any software that manipulates specific datanames, as they must know what datatype to expect and thus will parse numbers as needed.  Any generic software that does rely on the meaning of specific datanames (e.g. a pretty printer) may have issues, although a suitable example doesn't come to mind.

If the consensus is that we would actually like to keep delimiter information, we can add a new object to the CIF JSON: "might-be-a-number" whose value is a list of datanames that were not delimited in the CIF file *and* match the regexp for a number. If there is a mixture in a loop column, that is not a number.

Thoughts?

James.

--

T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148

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

--

Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

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