[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bob
--
Reply to: [list | sender only]
Re: Draft JSON specification, round 2
- Subject: Re: Draft JSON specification, round 2
- From: Robert Hanson <hansonr@xxxxxxxxxx>
- Date: Wed, 19 Apr 2017 12:20:27 -0500
- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stolaf.edu; s=stolaf;h=mime-version:in-reply-to:references:from:date:message-id:subject:to;bh=UKlPmSOHGvXxGr6JOkjLYjHI2JUKp+Wwcl0DJziqp9k=;b=XJJQOUWJr/0SZqpK/hLKsmBCQurm7DcyW2Cja9dR90+rH0l19W46H37KtKlv30ODjyzVoAIsDPytZxU4fnCk8rel0jn0z8JCfyOzCSqWOvdaX0ZeBwYtvl2Pe3p+TdMSZt2AxaaQjpiCFnoXp7KYoBHft0kAlxitfpZne1rpXWU=
- In-Reply-To: <CAM+dB2d4HcnH7PZRC4jYO8KLyNxs4pws_baT7WKi6vRiD2z1ow@mail.gmail.com>
- References: <CAM+dB2d4HcnH7PZRC4jYO8KLyNxs4pws_baT7WKi6vRiD2z1ow@mail.gmail.com>
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 {....}?
On Wed, Apr 19, 2017 at 1:32 AM, James Hester <jamesrhester@gmail.com> wrote:
(2) To round-trip a CIF, information about which datavalues were quoted must be preserved(1) No allowance needs to be made for expressing CIF numbers as JSON numbers, and therefore no "uncertainties" object is necessaryDear 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:(3) Using an escape mechanism for CIF '?' is undesirable, instead \uFFFF or \u0001 would be suitableSo: 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.--
_______________________________________________
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
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
Reply to: [list | sender only]
- Follow-Ups:
- Re: Draft JSON specification, round 2 (Andrius Merkys)
- Re: Draft JSON specification, round 2 (James Hester)
- References:
- Draft JSON specification, round 2 (James Hester)
- Prev by Date: Draft JSON specification, round 2
- Next by Date: Re: Draft JSON specification, round 2
- Prev by thread: Draft JSON specification, round 2
- Next by thread: Re: Draft JSON specification, round 2
- Index(es):