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

RE: Draft JSON specification, round 2

• Subject: RE: Draft JSON specification, round 2
• From: "Bollinger, John C" <John.Bollinger@xxxxxxxxxx>
• Date: Thu, 20 Apr 2017 15:14:00 +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=hWv+LYezyV/iHT9HbQpndCr6OB/CfecSCaVHejFjGkA=;b=XQgZtqug+GCQEYssTrqdUorwbI7WbHX4BzvYBs3ofcOHCcDhWuxkWtC+CCEFXF81dphWfM6pmecxftDmHSvomxSPiXecawwNrbEuwNsD/RgPH7UlCyzCx7amLcnVba75lkJknlAtVmYTWcGq5sV6gfQKr8zSLYikPklqYCTPzus=
• In-Reply-To: <CAM+dB2d4HcnH7PZRC4jYO8KLyNxs4pws_baT7WKi6vRiD2z1ow@mail.gmail.com>
• References: <CAM+dB2d4HcnH7PZRC4jYO8KLyNxs4pws_baT7WKi6vRiD2z1ow@mail.gmail.com>
• spamdiagnosticmetadata: NSPM
• spamdiagnosticoutput: 1:99

On Wednesday, April 19, 2017 1:32 AM, James Hester wrote:
> Reviewing last weeks' discussion, there is a clear bifurcation in the approaches to CIF-JSON that have arisen in practice: (1) the 'high fidelity' approach of COD-JSON (2) the 'low overhead' approach of JMol and Marcin.  This suggests that a single JSON is unlikely to satisfy all users.  Given that COD-JSON is available, implemented and complete, with open-source tools available, I propose we continue to explore here the 'low overhead' approach to see whether it can be brought to a similar state.

I'm game, but I think we may be jumping the gun, as indeed the observed bifurcation seems to indicate: in order to design an appropriate JSON serialization for CIF data, it seems we need to first consider the question, "Appropriate for what?"

> First let me summarise the points where I see consensus arising out of the discussions last week:
> (1)  No allowance needs to be made for expressing CIF numbers as JSON numbers, and therefore no "uncertainties" object is necessary
> (2)  To round-trip a CIF, information about which datavalues were quoted must be preserved
> (3)  Using an escape mechanism for CIF '?' is undesirable, instead \uFFFF or \u0001 would be suitable

But those points of consensus arose from a somewhat different set of assumptions, most importantly that we were looking for a single, presumably general-purpose JSON form.  If we're now rejecting that premise then it's not safe to assume that the apparent consensus on those points remains intact.  Again, what do we want this for?  What properties of this representation are important?  For example, if we are now focusing on minimizing overhead (which kind?) and are willing to sacrifice some fidelity, then perhaps we embrace the fidelity loss, and say,
(1) Uncertainties are not conveyed by CIF2-Low_Overhead-JSON, therefore (a) there is no "uncertainties" object, (b) any uncertainties expressed in data values are not meaningful, and perhaps even (c) known-numeric data values *may* be expressed as JSON numbers;
(2) We don't support full-fidelity round tripping anyway, so we assume that all data values presented as JSON strings and interpreted as strings can be treated as quoted CIF values;
(3) We don't care about the difference between the two flavors of null, so we represent both via JSON null.

As it stands now, I'm not sure on what grounds to evaluate those alternatives relative to the other proposed set.

John


________________________________

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: Draft JSON specification, round 2 (James Hester)

• References:
  • Draft JSON specification, round 2 (James Hester)

• Prev by Date: Re: Treatment of Greek characters in CIF2
• Next by Date: RE: Treatment of Greek characters in CIF2
• Prev by thread: Re: Draft JSON specification, round 2
• Next by thread: Re: Draft JSON specification, round 2
• Index(es):
  • Date
  • Thread