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.

 

   For applications that require the exact interchange of numbers with
   greater magnitude or precision, it is RECOMMENDED to encode them in
   JSON string values.  This requires that the receiving program
   understand the intended semantic of the value.

 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?