Alternative serialization for JSON alternative serialization

In the first two versions of the JSON Alternative Serialization, the serialization has been driven by intimate knowledge of the Core Component Technical Specification (CCTS) model for UBL and the associated Core Component Type (CCT) for each BBIE. Only when the data type of the BBIE is known can the serialization successfully name the supplementary component property names using the CCT Supplementary Component names.

Feedback received today is that needing such knowledge is a burden to the programmer. Rather, a more direct transliteration option or change is needed where knowing the CCTS model for a given vocabulary is not required. The issue isn't when serializing the JSON from internal memory, rather, it is when transliterating an XML serialization of a UBL document into an equivalent JSON serialization.

This transliteration isn't simplistic, however, as so far there are data type constraints on the expression of values in JSON that are not in play in XML. But it can be made automatic.

One case is where "1" is a valid XML value for "true" and "0" is a valid XML value for "false" for an indicator, but "1" and "0" are not valid JSON values for an indicator. Thankfully, the NDR rules require the component names for indicators to be suffixed with "Indicator". But it does mean that round-tripping the XML to JSON back to XML will normalize indicator syntax values to be "true" and "false" irrespective of the source XML. The semantic values remain preserved.

The other case is where values of type Amount, Measure, Numeric, Percent, Quantity, and Rate must not be quoted in JSON, but values of elements other types must be quoted in JSON. Again, while this is found in the model information, the NDR rules require the component names for these types to be suffixed with the type names.

So it turns out that with those NDR rules already in play, a lossless transformation can be made between XML and JSON when there is no model information with semantic CCTS information.

Moreover, the feedback also indicates the abbreviated names used in XML for supplementary components offer advantages to the unabbreviated CCT Supplementary Component names used so far in our JSON serialization. So we could choose to use the CEFACT CCT XML serialization supplementary component attribute names in our JSON serialization for BBIE supplementary component names.

Attached are three files:

1. test3.xml - an example XML document using the UBL syntax,
2. test3.CCT.json - serialization using full CCT Supplementary Component names, and
3. test3.CCTXML.json - serialization using CCT XML Supplementary Component names.

The question becomes, do we:

1. wholesale abandon the "pure" CCT serialization that we've been advocating for years (albeit in a draft specification that is subject to change) replacing it with the new abbreviated CCTXML approach,
2. support two alternative serializations of the JSON alternative serialization, or
3. leave the "pure" CCT serialization alone as the only sanctioned serialization and abandon this new CCTXML serialization?

(Can anyone think of a better name than "CCTXML" to make reference to the abbreviated XML attribute names for CCT supplementary components? These abbreviated names are not found in the CCTS specification, only in the CEFACT-published CCTS_CCT_SchemaModule-2.1.xsd schema fragment.)