Discussion List Archives

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

RE: Draft JSON specification for CIF

  • Subject: RE: Draft JSON specification for CIF
  • From: "Bollinger, John C" <John.Bollinger@xxxxxxxxxx>
  • Date: Wed, 12 Apr 2017 14:57:06 +0000
  • Accept-Language: en-US
  • authentication-results: iucr.org; dkim=none (message not signed)header.d=none;iucr.org; dmarc=none action=none header.from=STJUDE.ORG;
  • DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SJCRH.onmicrosoft.com; s=selector1-stjude-org;h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;bh=uN6FWOqRUommU7B2LMrugZD7g1+ZqLB21Whe49jxm0w=;b=UO2XKKGKif+N7tYwpyD25Wb4fwQx/mSh5EM7p0456UC7fc21GG1sJ5QHyKa5XPXlssTOCPKRNr96qBX2JEI6hkMsZ1eekAVMX5ELJPFjLxrXKJwKwEJ+reFzM2S0J8GOiQ71vcB0qcKfQx4/XfS4kWuVev+M0RHL/KbuWKYFRTA=
  • In-Reply-To: <CAM+dB2fszww=4A_w6evqg=5O9KKLnujajmg_SPSX=hCRQiBPtg@mail.gmail.com>
  • References: <CAM+dB2fszww=4A_w6evqg=5O9KKLnujajmg_SPSX=hCRQiBPtg@mail.gmail.com>
  • spamdiagnosticmetadata: NSPM
  • spamdiagnosticoutput: 1:99

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.

 

2. It would be useful to explicitly consider which CIF structural and semantic constraints are to be mapped to JSON language constraints.  In particular,

 

  a) The proposed representation may inherently enforce the uniqueness of data names within a data block / save frame (supposing that we’re using I-JSON; see also below), but it does not inherently enforce the constraint that every data name in the same loop has the same number of values.  I raise these together because it would be relatively straightforward to flip that, so that it is having the same number of values that is inherently enforced.  On the other hand, I think there are alternatives that would allow both to be enforced, at the cost of a more complex and / or opaque structure.  (I reserve further comment on such alternatives, pending interest from the group.)

 

 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?

 

 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?

 

4. The aspect of the proposal that I like least is the separate table of uncertainties.  CIF data conforming to a dictionary, such as mmCIF, that provides separate data names for SUs does not need it, and I don’t immediately see why the native serialization format (presented as a string) is not a suitable choice for uncertainty-bearing values of items without a separate SU item.

 

 

Best regards,

 

John

 

--

John C. Bollinger, Ph.D.

Computing and X-Ray Scientist

Department of Structural Biology

St. Jude Children's Research Hospital

John.Bollinger@StJude.org

www.stjude.org

 



Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
_______________________________________________
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.