Re: Draft JSON specification for CIF

Dear CIF-developers,

 

A JSON representation of CIF is absolutely something that can and should be done, and the proposal seems viable and fairly complete.  Nevertheless, there are some aspects of the proposal that bear discussion:

 

1. Which JSON are we talking about?  The one described within ECMA-262?  The one described by ECMA-404?  Presumably not RFC4627, but maybe its successor, RFC7159?  In fact, my vote would be for I-JSON, as described by RFC7493 (a restricted profile of RFC7159 JSON).   I-JSON handles several interoperability issues that otherwise we would either suffer or have to handle explicitly.

 

2. It would be useful to explicitly consider which CIF structural and semantic constraints are to be mapped to JSON language constraints.  In particular,

 

  a) The proposed representation may inherently enforce the uniqueness of data names within a data block / save frame (supposing that we’re using I-JSON; see also below), but it does not inherently enforce the constraint that every data name in the same loop has the same number of values.  I raise these together because it would be relatively straightforward to flip that, so that it is having the same number of values that is inherently enforced.  On the other hand, I think there are alternatives that would allow both to be enforced, at the cost of a more complex and / or opaque structure.  (I reserve further comment on such alternatives, pending interest from the group.)

 

 b) CIF requires not just that block names, frame names, and data names be unique within their respective scopes, but that their *normalized forms* be unique within their scopes.  That stronger constraint is alien to JSON; do we care about JSON-CIF enforcing that as an (I-)JSON constraint?

 

 c) I don’t see a particular value in placing stronger character encoding constraints on JSON-CIF than the underlying JSON standard places.  Selection of I-JSON would make this moot, however, for I-JSON in fact requires UTF-8 encoding, just as is proposed for JSON-CIF.

 

3. We have again run into the CIF quirk of having two distinct null values, whereas JSON has only one.  Although the two-character string "\\?" is certainly reminiscent of the special CIF ? value (as "\\." would be reminiscent of the . value), why not instead choose a value such as "\u0001" or "\uFFFF", which will never appear in a conforming instance of CIF’s native serialization?

 

4. The aspect of the proposal that I like least is the separate table of uncertainties.  CIF data conforming to a dictionary, such as mmCIF, that provides separate data names for SUs does not need it, and I don’t immediately see why the native serialization format (presented as a string) is not a suitable choice for uncertainty-bearing values of items without a separate SU item.