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.
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 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.
From: cif-developers [mailto:email@example.com]
On Behalf Of James Hester
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
See points (8) and 5(ii) of the original draft for the alternative treatment of numbers.
T +61 (02) 9717 9907
Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
_______________________________________________ cif-developers mailing list firstname.lastname@example.org http://mailman.iucr.org/cgi-bin/mailman/listinfo/cif-developers
Reply to: [list | sender only]
- Re: CIF-JSON draft 2017-05-08 (Robert Hanson)
- CIF-JSON draft 2017-05-08 (James Hester)