[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: "Bollinger, John C" <John.Bollinger@xxxxxxxxxx>
- Date: Fri, 14 Apr 2017 13:47:38 +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=gpNwJ629fBsO8YBNnpeYNCvLY03jmDa7PMktt/lScAQ=;b=CuTpry+DMmuI5Z6E+1oVrrvU589Afww0tBZJ9pYQEbo+GwZJ1pxNGNUd9dwuWI79w18Qya+YK5QZniuhbmOeC6be0IPtDtqhcrYI0RMhi4yXgoUzpqO6gs3ASSM7sEKcwhRqPRLabsWFr/xGbYb0qLf7LBPStwCVmWZYkbHbCks=
- In-Reply-To: <3a456373-cdf3-229f-f4c8-3a7271575d92@gmail.com>
- References: <CAM+dB2fszww=4A_w6evqg=5O9KKLnujajmg_SPSX=hCRQiBPtg@mail.gmail.com><CAF_YUvWgON8Z3JS1TePu3K=SRErN4TBhNTP1Q3GfdJeoLnymMw@mail.gmail.com><CACaHzQU+25tZQXe1EKUFi4y+UJfa+rA6z7F7Y2EvWhX=Jg6P8g@mail.gmail.com><3a456373-cdf3-229f-f4c8-3a7271575d92@gmail.com>
- spamdiagnosticmetadata: NSPM
- spamdiagnosticoutput: 1:99
Dear CIF Developers, I think I have come around to a position similar to Andrius's (below), but I'm going to approach it from a different direction. One of the longtime CIF gotchas is that strings can be presented unquoted, and that leaves some ambiguities. In particular, it is easy to misinterpret strings that have a form that could be interpreted as a number, but are meant to be interpreted as text. Treating such a value as a number can corrupt or lose information, as Bob also observed. One ultimately has to rely on item definitions to know how to interpret CIF data -- whether by reading definitions dynamically from a dictionary file, or simply by writing knowledge of specific items of interest directly into the program. It is to be expected that JSON-CIF will frequently be handled with the help of general-purpose JSON libraries or even directly by JavaScript, which will not be prepared to make this kind of distinction. Overall, whether a value is presented in quoted or unquoted form is significant in CIF, and therefore must be represented in some way in JSON-CIF (though the type of quoting used is unimportant). Only some of that significance can be determined from a CIF itself, so in the general case, a program serializing CIF to JSON-CIF cannot be expected to have enough information to convey that information via data types alone. If we solve that problem by choosing a JSON form that preserves information about whether values are quoted, then we get natural representations of the two null values as well. This does make JSON-CIF a slightly lower-level representation, but I think that's appropriate. Additional fun fact: CIF can express numeric values that cannot be represented in any native numeric format available on a given machine. Regards, John -----Original Message----- From: cif-developers [mailto:cif-developers-bounces@iucr.org] On Behalf Of Andrius Merkys Sent: Thursday, April 13, 2017 10:43 AM To: cif-developers@iucr.org Subject: Re: Draft JSON specification for CIF Dear Marcin, that's why I suggest retaining CIF value types. CIF parser knows the type of each value read (here is the difference between ? and '?') and I suggest storing this bit of information inside JSON explicitly. An alternative would be to use JSON boolean datatype and/or null value, or "\u0001" and "\uFFFF" as suggested by John. I personally recommend against using any escaping as this would add another layer of complexity. Best, Andrius On 13/04/17 18:13, Marcin Wojdyr wrote: > Bob, > >> - This adds the unnecessary complication of what to do with "." and "?" > I think you imply that . and ? should be expressed in JSON as "." and "?". > But this would be ambiguous: JSON "?" could mean either unknown or string "?". > > Marcin > _______________________________________________ > cif-developers mailing list > cif-developers@iucr.org > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailma > n.iucr.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcif-developers&data=01%7C0 > 1%7CJohn.Bollinger%40stjude.org%7C4838d8c366934d3909f608d48283c332%7C2 > 2340fa892264871b677d3b3e377af72%7C0&sdata=2qlXb418bpe7CulOGIAWEX2tCAbD > 8Z6K4DdSCX1o%2FDk%3D&reserved=0 -- Andrius Merkys PhD student at Vilnius University Institute of Biotechnology, Saulėtekio al. 7, V325 LT-10257 Vilnius, Lithuania Lecturer at Vilnius University Faculty of Mathematics and Informatics, Naugarduko g. 24 LT-03225 Vilnius, Lithuania _______________________________________________ cif-developers mailing list cif-developers@iucr.org https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.iucr.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcif-developers&data=01%7C01%7CJohn.Bollinger%40stjude.org%7C4838d8c366934d3909f608d48283c332%7C22340fa892264871b677d3b3e377af72%7C0&sdata=2qlXb418bpe7CulOGIAWEX2tCAbD8Z6K4DdSCX1o%2FDk%3D&reserved=0 ________________________________ 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]
- References:
- Draft JSON specification for CIF (James Hester)
- Re: Draft JSON specification for CIF (Robert Hanson)
- Re: Draft JSON specification for CIF (Marcin Wojdyr)
- Re: Draft JSON specification for CIF (Andrius Merkys)
- Prev by Date: RE: Draft JSON specification for CIF
- Next by Date: Draft JSON specification, round 2
- Prev by thread: Re: Draft JSON specification for CIF
- Next by thread: Re: Draft JSON specification for CIF
- Index(es):