Discussion List Archives

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

RE: CIF-JSON new draft


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]
International Union of Crystallography

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

ICSU 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.