Discussion List Archives

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

RE: CIF-JSON draft 2017-05-08

  • Subject: RE: CIF-JSON draft 2017-05-08
  • From: "Bollinger, John C" <John.Bollinger@xxxxxxxxxx>
  • Date: Mon, 8 May 2017 14:23:09 +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=s5tmzHqg9rHyGcBkI6fPdH2LvDALy94E7fifzBiCHfU=;b=hW4RyfNi+zc4QtGAkGxpsMcjMbPTtTGAWXPiXOJFUauz9zYGRaEF2vgpyBBHqnnUYXmbQWOGvUJ/9xmoDbkqSpGIjDQrBOTru26MK2cd8OrfLoak/qGIVC6LH5YPu0skkqgqu9msOortaORkYSpBP51blaNCTY/pdW9noa3kzfU=
  • In-Reply-To: <CAM+dB2cwoCG6LhPUePRup_hQtM9mXqwL4tULTPf-WGwJGtKrOA@mail.gmail.com>
  • References: <CAM+dB2cwoCG6LhPUePRup_hQtM9mXqwL4tULTPf-WGwJGtKrOA@mail.gmail.com>
  • spamdiagnosticmetadata: NSPM
  • spamdiagnosticoutput: 1:99

Thanks, James, for the update.

 

I should perhaps clarify that my positions on details of CIF-JSON are based on my anticipation of its use as an _interchange_ format.  We have no need, nor indeed any business, to specify what any application should use as its internal data format, so I do not suppose that that’s what we’re trying to do.  Moreover, JSON is widely used in contexts where there is no JavaScript in sight, so I am not much swayed by arguments about the behavior of JavaScript implementations specifically.

 

From my perspective, the paramount issues are

 

1. to make CIF-JSON simple to both encode and decode (where "simple" implies lowest knowledge, not necessarily lowest effort)

2. to ensure that a CIF-JSON instance carries all the semantic information of the corresponding CIF

 

It is in service to point (1) that I continue to advocate to at least *allow* CIF numbers to be presented in CIF-JSON as strings, and to not convey SUs separately from their base numbers when they are presented in unified CIF1 form in the original data.  Supposing that is indeed allowed, I think it serves point (1) better to *require* numbers to be presented as strings.  The fewer alternatives must be taken into account at the encoding / decoding stage, the better.

 

It is in service to both points that I raised the issue of the ambiguity between CIF lists as values on one hand and multiple values in a loop on the other.  I am satisfied to have loop tags be required so as to enable that to be disambiguated, but the more I think about it, the more convinced I become that the best solution would be to present every item’s values, whether one or many, in a JSON array.  This serves point (1) considerably better, because it provides the added benefit that neither CIF-JSON encoders nor CIF-JSON decoders would then be obligated to care about the semantic equivalence in CIF between scalars and items in single-packet loops.  If that were accepted then "loop tags" could remain optional, and perhaps the constraints on it could even be loosened relative to the original proposal.

 

I am inclined to agree with Marcin, however, that the second null representation in the present proposal constitutes an ugly wart (and I acknowledge my contribution to the present state of the proposal in that area).  I would be fine with using JSON false to represent one of the null values.  I observe, however, that if we continue to require numbers to be presented as strings, then we also have the alternative of using a number – 0, or even NaN -- to represent one of the nulls.  That could satisfy Marcin’s criterion that the chosen value be falsey in JS, though I’m uncertain how valuable that is because empty strings, which are also falsey in JavaScript, are valid CIF data values, and some strings that are truthy in JS are falsey in other languages.

 

I also have no objection to Marcin’s suggestion to bring a consistency of form to the special property names in the proposal.  The specific names chosen are not of particular importance to me.

 

 

John

 

From: cif-developers [mailto:cif-developers-bounces@iucr.org] On Behalf Of James Hester
Sent: Monday, May 08, 2017 1:58 AM
To: Forum for CIF software developers <cif-developers@iucr.org>
Subject: CIF-JSON draft 2017-05-08

 

Dear CIF developers,

I have updated the draft as follows:

(1) Swapped the representations of "." and "?"

(2) Fixed some undelimited numbers

(3) Made loop tags compulsory

What I have not done is put back JSON numbers as an option for representing CIF numbers, as there seems to be little consensus on this one.  As far as I can tell, the best we could do is something like the first draft, where datavalues could optionally be JSON numbers, in which case uncertainties were tabulated separately.  Going this way would involve testing the first entry of every number-valued dataname for being a number before processing all values, but would be a bit of an efficiency win if the number transformation had already been done. Does anybody have a strong argument for or against the approach of the first draft or the approach of the latest draft?

Latest draft: https://comcifs.github.io/cif-json

Original draft: https://github.com/COMCIFS/comcifs.github.io/blob/030b54b5e519be8f0970707dabc7e4bee5fc31a0/cif-json.md

See points (8) and 5(ii) of the original draft for the alternative treatment of numbers.

James.


--

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



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 Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council 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.