Discussion List Archives

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

Re: CIF-JSON draft 2017-05-08

  • Subject: Re: CIF-JSON draft 2017-05-08
  • From: Marcin Wojdyr <wojdyr@xxxxxxxxx>
  • Date: Mon, 8 May 2017 12:03:46 +0100
  • DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;h=mime-version:in-reply-to:references:from:date:message-id:subject:to;bh=YBZ2jrJrCYqoPnYh4l1gGhSM/u1M789wi1wmwbrCZ0k=;b=rvlJ+/0r7qo6Ts5KpP2OBPcSi7azFAUdt5XGGu20kqtc8slyAGFsoOPtr89/WnwWLlXdBPs4KuHCMpOGZZjQSqjX6yEjCessEaFO5ZS8eFhWFz6eExCyLh+2wvbdbECQ2TyrEo5K/LCtJhLMiL9UfenzZ77I9YwSKhJUnz/zsCp7REP5b6JwNROLJ2dcH5kKbms5yMlEgN64Pi6zx3UCNAgqeQ+0bqVcSoxy1OPtPWcMoh0zzZe+CD0Iv1BiDVYzNWqvQQ/MYTGCp/2NBTGLATeMl9gWR4PJfHYiekAzh8xzDjTFpjqOLfSRfbxV/PWQNS0FU5NVf1gbNQVrf7s/Ug==
  • In-Reply-To: <CAM+dB2cwoCG6LhPUePRup_hQtM9mXqwL4tULTPf-WGwJGtKrOA@mail.gmail.com>
  • References: <CAM+dB2cwoCG6LhPUePRup_hQtM9mXqwL4tULTPf-WGwJGtKrOA@mail.gmail.com>
Thanks for updating the draft!
Some notes after reading it:
It states that "the CIF <Number> production is identical to the JSONnumber format."Actually valid JSON numbers are a subset of valid CIF numbers (forexample: 00 or .5 or 5. are not valid in JSON).
From what I understood, the argument to disallow numbers as numbers isto simplify/unify number handling.I'd only note that many CIF files (mmCIF, also DDL dictionariesthemselves I think) are guaranteed to not have s.u. in brackets, andin such case disallowing numbers doesn't really simplify the reader.Using in Python float(some["property"]) will also work if the propertyis a number. Similarly in JS. In C++ JSON values are usually stored inunion/variant and one is normally expected to check the type beforeattempting to access a value anyway.So allowing JSON numbers at least when they don't have s.u. would be helpful.
As I wrote once or twice, I don't think that representing one of ?/.as a magic string is optimal. I'd rather have it not truthy (in JSspeak) and encoding independent (even if I-JSON is guaranteed to be inutf8 where \uFFFF is '\xef\xbf\xbf'). Which is to say that I'd preferfalse to \uFFFF.
As Bob wrote, some people prefer to have properties without spaces. Ithink it was me who proposed "loop tags", but given that we have"Metadata" and "frames" in the draft, it'd be a nice touch to unifythe naming of special objects. Maybe have them all start withuppercase letter (Meta, Frames, Loops)?
A typo in the example: a comma before } above "another_block" should be removed.
In general, the draft is a good work. Thanks for pushing it forward.
Marcin
On 8 May 2017 at 07:58, James Hester <jamesrhester@gmail.com> wrote:> 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> F +61 (02) 9717 3145> M +61 (04) 0249 4148>> _______________________________________________> cif-developers mailing list> cif-developers@iucr.org> http://mailman.iucr.org/cgi-bin/mailman/listinfo/cif-developers>_______________________________________________cif-developers mailing listcif-developers@iucr.orghttp://mailman.iucr.org/cgi-bin/mailman/listinfo/cif-developers

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links