Re: JSON Test suite status

On 6/23/20 2:03 AM, Kai Torben Ohlhus wrote:
> 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 <[email protected]
>>>> <mailto:[email protected]>> 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.

When implementing octave-jsonstuff [1] (not octave-rapidjson! [2] That's
a different project by a different Andy!), I did not care about
whitespace. :) All I cared about is whether the outputs resulted in the
same data model when parsed back in by a "conformant" JSON parser
(whatever that is). In fact, one of my priorities in implementing
jsonstuff was to add support for pretty-printing, because I find
"compact" JSON to be unreadable and hard to debug.

So I guess I'm suggesting that this project have higher standards than I
did. :)

> 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

I vote with Kai here. Perfect is the enemy of good.

Cheers,
Andrew

[1] https://github.com/apjanke/octave-jsonstuff
[2] https://github.com/Andy1978/octave-rapidjson