[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
RE: CIF-JSON new draft
- Subject: RE: CIF-JSON new draft
- From: "Bollinger, John C" <John.Bollinger@xxxxxxxxxx>
- Date: Mon, 1 May 2017 13:33:18 +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=TFEyAiHxK7ASEW2FH3dpc37gN/9oUb3ZFTt/xVK/mhw=;b=hDVrhdxHj07itqNlU9Ece6nKOjh3DT+ajUYEc0zo3Nz3ND89YzAEYPtRmiL43MaFkDW4R5Hc1Oo77C3qzFah0XrUKAas/HkLEToYSbHRBaMYtQ7scvq9msRQGry9QP0BmBspnkO9ldaLiveeCSQLpeXoX6jZCm8rnsNetJU4NTU=
- In-Reply-To: <CACaHzQU-NPvorqZzARhnsTLaAU_tqpp9v56fJss9C9NG--ps0A@mail.gmail.com>
- References: <CAM+dB2ey9kKLoZY=WE7Uy-fiWTGhQaFx7fcgODcYfhrNPwXkQw@mail.gmail.com><CACaHzQU-NPvorqZzARhnsTLaAU_tqpp9v56fJss9C9NG--ps0A@mail.gmail.com>
- spamdiagnosticmetadata: NSPM
- spamdiagnosticoutput: 1:99
On Monday, May 01, 2017 4:12 AM, Marcin Wojdyr wrote, > I'd disagree with "CIF number values are represented as JSON string values". While it makes the conversion easier, the JSON doesn't look natural and is more difficult to use. It'd also make applications that use such JSON slower, and it looses information about type. I fully agree with representing all non-null, scalar values as strings. I am not concerned with whether it looks natural, as I do not consider the format to be intended for human consumption. In any event, both CIF's native serialization and any possible JSON serialization of CIF information convey numbers as strings, in the sense of text. Relative to native CIF, the only type information lost by using JSON strings for numeric data is a hint about whether to _consider_ a numeric interpretation of the data. This is not a big loss, because CIF-JSON is not intended as an archival format or high-fidelity data transfer format (that would be COD-JSON). I anticipate that applications will base decisions about numeric interpretation on items' names. Anyway, CIF-JSON should at minimum _permit_ numbers to be presented as strings, for otherwise, every application that proposed to transform CIF to CIF-JSON would need to be dictionary-aware. If CIF-JSON consumers will therefore accept numeric values in string form anyway, then I prefer the simplicity of specifying that numeric data values be represented that way uniformly. Since we are targeting this as a low overhead representation, which I associate with performance considerations, I am prepared to entertain arguments about performance impact. I am not, however, prepared to accept unsupported assertions about performance. I'm sure we all know that relative performance is notoriously hard to predict. It is by no means clear to me that making string/number conversion the application's responsibility instead of the JSON parser's will slow anything down, and it could even provide a speed *boost* by allowing the application to limit conversions to only the data it actually uses as numbers. John -- John Bollinger Computing and X-Ray Scientist John.Bollinger@StJude.org ________________________________ Email Disclaimer: www.stjude.org/emaildisclaimer Consultation Disclaimer: www.stjude.org/consultationdisclaimer _______________________________________________cif-developers mailing listcif-developers@iucr.orghttp://mailman.iucr.org/cgi-bin/mailman/listinfo/cif-developers
Reply to: [list | sender only]
- Follow-Ups:
- Re: CIF-JSON new draft (Marcin Wojdyr)
- References:
- CIF-JSON new draft (James Hester)
- Re: CIF-JSON new draft (Marcin Wojdyr)
- Prev by Date: Re: CIF-JSON new draft
- Next by Date: Re: CIF-JSON new draft
- Prev by thread: Re: CIF-JSON new draft
- Next by thread: Re: CIF-JSON new draft
- Index(es):