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 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 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]
- Follow-Ups:
- Re: CIF-JSON draft 2017-05-08 (Robert Hanson)
- References:
- CIF-JSON draft 2017-05-08 (James Hester)
- Prev by Date: Re: CIF-JSON draft 2017-05-08
- Next by Date: Re: CIF-JSON draft 2017-05-08
- Prev by thread: Re: CIF-JSON draft 2017-05-08
- Next by thread: Re: CIF-JSON draft 2017-05-08
- Index(es):