[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: Draft JSON specification for CIF
- Subject: Re: Draft JSON specification for CIF
- From: Robert Hanson <hansonr@xxxxxxxxxx>
- Date: Thu, 13 Apr 2017 10:03:14 -0500
- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stolaf.edu; s=stolaf;h=mime-version:in-reply-to:references:from:date:message-id:subject:to;bh=15ZnpEafT9ibST0orbgiQ4v/eCOdAEF5ZQ6sarFNENc=;b=brAGoYAYNSvMtqpOPQypOcKv/jnK0tCS8l6PsXLIAP/hXekaNlM5vM87W2uVm9LIkYrPYpNPVMIgEYsi25Dxk2boWq4/KFq8RfrTXbjgUJDJatIySIX/on/J/VGmBZcnztdUQcbt2cZVTqpgN+hRpFDEF/+z4dmYT31AQGI7JPw=
- In-Reply-To: <CAM+dB2fszww=4A_w6evqg=5O9KKLnujajmg_SPSX=hCRQiBPtg@mail.gmail.com>
- References: <CAM+dB2fszww=4A_w6evqg=5O9KKLnujajmg_SPSX=hCRQiBPtg@mail.gmail.com>
On Wed, Apr 12, 2017 at 2:34 AM, James Hester <jamesrhester@gmail.com> wrote:
5. Datavalues are converted as follows: 1. CIF string values are represented as JSON string values. The code-point sequence obtained *after* the text prefix protocol and line ending protocols have been applied to the CIF value will be the code-point sequence presented in the JSON file 2. If the CIF datavalue should be interpreted as a number, it is that number obtained by parsing the character string found in the CIF according to the `<Number>` production in International Tables for Crystallography, Volume G, Section 2.2.7.3 paragraph 57. It is not an error to instead represent such a datavalue as a JSON string. Note that the CIF `<Number>` production is identical to the JSON number format.
After reading the discussions of the past 24 hours, I am going to argue that CIF datavalues should not be interpreted as numbers. Reasons:
- This adds the unnecessary complication of what to do with uncertainties.
- This adds the unnecessary complication of what to do with "." and "?"
- This will result in irreversible conversion, since String->Value highly depends upon choice of double or float, and the invariable nuances of rounding that that parsing involves, and String->Value->String is never lossless.
- Not converting to "numbers" is an illusion. JSON is a string-based method of communication. All you have done is convert a string representing a number to another string representing a number. True, it means the browser (or whatever) can internally convert the incoming (CIF)string-to-(program)number-to-(JSON)string to a number, who cares? If I am an implementer, I will know what is a number and what is not, and then I can decide for myself (as I do now for CIF files) what I want to do with "." and "?". And if I am a CIF-to-JSON converter, I will simply never do the (CIF)string-to-(program)number business in the first place, and instead simply faithfully convert (CIF)string to (JSON)string, because in that case it is no my job to interpret CIF data as anything. My job as a CIF-to-JSON converter algorithm is simply to do the conversion without regard to author intent.
Bob
_______________________________________________ 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: Draft JSON specification for CIF (Marcin Wojdyr)
- References:
- Draft JSON specification for CIF (James Hester)
- Prev by Date: Re: Standard uncertainties (SU) in the DDLm dictionary
- Next by Date: Re: Draft JSON specification for CIF
- Prev by thread: Re: Draft JSON specification for CIF
- Next by thread: Re: Draft JSON specification for CIF
- Index(es):