Re: [RFC] New JSON representation for Poke values in MI

[Jose E. Marchesi]

Hi Kostas.

> Hello people of Poke,
>
> After long discussions, me and Mohammad decided that the current JSON
> schema and generally the implementation using this schema had many
> problems.
>
> Firstly, using the previous schema, we could not encode many poke
> values, like int[10][30].
>
> Moreover, the previous schema made the generated JSON too long, by
> repeating information again and again.  Mohammad presented an example
> that for a not very long Poke array they JSON generated was 117Kbs. As
> he said, this is not acceptable, and I totally agree.
>
> Finally, we also wanted to change the schema for simplicity reasons.

Thanks for working on this.

> The first main modification is that we included PokeType object which
> represents a pk(pvm)_type.  The second main modification is that we
> separated PokeType from PokeValue, in order to eliminate duplicate
> information.

Ok, so now JSON encodes values tagged with their type.

> The main drawback, however, of the new schema is that it is not very
> strict, and by that I mean that a validator will not be able to catch
> possible errors.  This means we have to make excessive error-checking
> in the C code that handles JSON data.

I think that is ok.  We are using the schema as a spec, not as a
validation tool.

> You can find attached:
>
> 1) The new JSON schema.
> 2) Previous JSONs that used the previous schema (_old)
> 3) Updated JSONs that use the schema attached (_new)
>
> Any comments are welcome!

I am a bit worried that this new schema, while more conceptually
correct, is actually more verbose for simple values like integrals,
offsets and strings.  Maybe that is not a problem in practice... it all
depends on what kind of values will be most often used in the MI.

Also, I would suggest s/PokeType/type, s/PokeValue/value.

Other than that, this certainly looks better to me than the previous
design.