Re: JSON Test suite status

[Kai Torben Ohlhus]

On 6/23/20 2:43 PM, Andrew Janke wrote:
> On 6/23/20 1:25 AM, Andreas Weber wrote:
>> Am 22.06.20 um 19:47 schrieb Abdallah Elshamy:
>>> On Mon, Jun 22, 2020 at 2:24 PM Andreas Weber <octave@josoansi.de
>>> <mailto:octave@josoansi.de>> wrote:
>>>     I had a look at jsonencodetest.m and wonder I you are really trying to
>>>     create the exact same JSON output (byte identical for example same
>>>     whitespace and so on) as the other software does or "identical parsed
>>>     JSON" where whitespace doesn't matter.
>>>
>>> Thanks for providing feedback. This script is intended to run on MATLAB
>>> to test compatibility so producing the same output in it is a core goal
>>> of it.
>>
>> Just to be clear: You want to create byte-identical JSON output which
>> possibly means patching/modifying rapidjson?
>>
>> -- Andy
>>
> 
> "Patching/modifying rapidjson" sounds a little extreme here: the compact
> "minified" form that Matlab's jsonencode produces is probably achievable
> without such extreme measures. It's just all whitespace elided. (Whether
> this can be practically achieved without violating the Matlab license is
> another question.)
> 
> Given that the JSON spec is kind of loose and there are a lot of
> extensions to it, but the base spec is pretty simple, IMHO
> byte-identical JSON output is a worthy and maybe achievable goal here.
> (Identical decoding behavior on arbitrary inputs is a whole nother ball
> game, and I wouldn't suggest pursuing that.)
> 
> Cheers,
> Andrew
> 

@Andy: thanks for the pointer to whitespace issues.  Did you experience
differences while implementing octave-rapidjson regarding whitespace?  I
think Abdallah would be interested to hear about your experience.

Regarding the JSON test suite of Abdallah, I think it is a first good
step have unit tests for genuine Matlab input and output in first place
(it might also change with the next Matlab release ...).

If in the second GSoC block (own implementation) we notice whitespace
differences, Abdallah can judge how to handle them, e.g. strtrim(), etc.
 In general I think white space is not that much an issue with JSON
itself.  Like Andrew says, patching RapidJSON for byte-identical JSON
seems a high price to pay at the start of the implementation.  I vote
for getting things started first, before thinking about fixing
nonexistent issues yet ;-)

Kai