Currently, when the input file is JSON and one of the requested test formats is Ion, the data is converted to Ion via simple re-write using ion-java. This does basic numeric type conversions (numbers without decimal points are Ion integers, numbers with a decimal point but no exponent are Ion decimals, and all other numbers are Ion floats). Additionally, field names are automatically added to a local symbol table.
However, there are additional opportunities for up-conversion that would more closely match how you'd write JSON data using Ion's types. For example, because JSON does not have a native timestamp type, timestamps are often tunneled via strings. Timestamp-formatted strings could be detected and written as Ion timestamps. Recurring string values could be detected and added to the symbol table. Base-64 strings could be written as Ion blobs.
This should be added as an option named something like --json-to-ion-upconvert <bool> to allow users to control the behavior.
Currently, when the input file is JSON and one of the requested test formats is Ion, the data is converted to Ion via simple re-write using ion-java. This does basic numeric type conversions (numbers without decimal points are Ion integers, numbers with a decimal point but no exponent are Ion decimals, and all other numbers are Ion floats). Additionally, field names are automatically added to a local symbol table.
However, there are additional opportunities for up-conversion that would more closely match how you'd write JSON data using Ion's types. For example, because JSON does not have a native timestamp type, timestamps are often tunneled via strings. Timestamp-formatted strings could be detected and written as Ion timestamps. Recurring string values could be detected and added to the symbol table. Base-64 strings could be written as Ion blobs.
This should be added as an option named something like
--json-to-ion-upconvert <bool>to allow users to control the behavior.