Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Draft JSON specification for CIF

I'm going to go ahead and call this

JSON-CIF2

because I'm pretty sure that is implied, right?


On Wed, Apr 12, 2017 at 9:57 AM, Bollinger, John C <John.Bollinger@stjude.org> wrote:

Dear CIF-developers,

 

A JSON representation of CIF is absolutely something that can and should be done, and the proposal seems viable and fairly complete.  Nevertheless, there are some aspects of the proposal that bear discussion:

 

1. Which JSON are we talking about?  The one described within ECMA-262?  The one described by ECMA-404?  Presumably not RFC4627, but maybe its successor, RFC7159?  In fact, my vote would be for I-JSON, as described by RFC7493 (a restricted profile of RFC7159 JSON).   I-JSON handles several interoperability issues that otherwise we would either suffer or have to handle explicitly.

 


ECMA-404 adds allowance for white space. I think that allowance is critical. Nobody likes to read the original no-white-space JSON.

RHC7493 states:

   For applications that require the exact interchange of numbers with
   greater magnitude or precision, it is RECOMMENDED to encode them in
   JSON string values.  This requires that the receiving program
   understand the intended semantic of the value.

and whereas I understand the desire to use numbers, we really have to come up with a way to represent the uncertainties. Right now Jmol doesn't do a consistent job of this in the JSON that it creates from CIF file data.

 b) CIF requires not just that block names, frame names, and data names be unique within their respective scopes, but that their *normalized forms* be unique within their scopes.  That stronger constraint is alien to JSON; do we care about JSON-CIF enforcing that as an (I-)JSON constraint?


Absolutely. IMHO
 

 

 c) I don’t see a particular value in placing stronger character encoding constraints on JSON-CIF than the underlying JSON standard places.  Selection of I-JSON would make this moot, however, for I-JSON in fact requires UTF-8 encoding, just as is proposed for JSON-CIF.

 

3. We have again run into the CIF quirk of having two distinct null values, whereas JSON has only one.  Although the two-character string "\\?" is certainly reminiscent of the special CIF ? value (as "\\." would be reminiscent of the . value), why not instead choose a value such as "\u0001" or "\uFFFF", which will never appear in a conforming instance of CIF’s native serialization?


If using characters for numbers, you can just use the characters in CIF already. There is no need to escape. Maybe then to be consistent, all numbers need to be strings? I suppose that's a pain. But it would not be out of  the question. It would provide lossless CIF2 --> JSON-CIF2.
 

Bob

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

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Council for Science (admitted 1947). Member of CODATA, the ICSU Committee on Data. Member of ICSTI, the International Council for Scientific and Technical Information. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

ICSU Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.