[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JSON Test suite status

From: Andrew Janke
Subject: Re: JSON Test suite status
Date: Tue, 23 Jun 2020 02:11:07 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0

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 <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.

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]