Re: [PATCH] Updated JSON Schema, pk_mi_val_to_json, pk_mi_json_to_val and a test file

[Jose E. Marchesi]

    >In this email I'm reviewing the schema part only.  In the future, please
    >split patches among domains, i.e. use a separated commit for the JSON
    >schema update, and another for work in pk-json.
    
    Noted, thank you.

Thanks :)
    
    > By the way, did you find out whether libjson-c supports validating data
    > against json-schemas?  Or any other C library?  If so, we could write
    > schemas for all the MI JSON and then rely on correct input in the json
    > conversion routines.
    
    Unfortunately, after searching through libjson-c I didn't manage to find
    any validator.
    However, I have found a validator that is based on this library.
    
    https://github.com/helmut-jacob/jsonschema-c

Hmm, it is a pity that functionality is not available in json-c itself:
as far as I can see this jsonschema-c library is not packaged in Debian
or any other major distro.  It has also been untouched since 2015.

On the bright side, it is small and distributed under the MIT license,
so I think we could incorporate it to poke's sources if we wanted to.

Have you tried it?  Does it actually work well enough so we could lift
many/most/all of the integrity checks from the msg<->json conversion
routines given an schema has been applied and the data is ok?
    
    > Hmm, can you show an example of an encoded offset?
    >
    
    {
      "PokeValue":{
        "type":"Offset",
        "magnitude":{
          "type":"UnsignedInteger",
          "value":150,
          "size":32
        },
        "unit":{
          "type":"UnsignedInteger",
          "value":10,
          "size":64
        }
      }
    }

    > Are the properties of the "unit" object the properties of the referred
    > UnsignedInteger plus the "size"?  Or how does it work?
    
    It specializes the "size" of the "UnsignedInteger" to be strictly 64.

Oh I see.  I thought that was creating another nesting level, but the
offset encoded above looks good.

    > Also, can the "allOf" with a single alternative be simply replaced with
    > a "$ref"?
    >
    
    The difference between "allOf" with a single alternative and a "$ref" is
    that by using "$ref" json ignores all the properties that you might want
    to define afterwards for this object.
    If you do it with allOf, you are allowed to define more properties. In
    this example, we need to specialize size to be 64, which means we need to
    define new properties, thus the "allOf".
    
    Please note that in the newer version of json-schemas (e.g. draft 09) they
    removed this need to do it with "allOf" and now using "$ref" doesnt make
    json ignore all other properties defined.
    
    However, I strongly believe that we will not be able to find and validator
    in C for newer json-schemas.

How so?  Is it not popular/widely used?
In that case we may want to use a different method to formalize the
structure of our JSON objects...
    
    > Isn't this replicating the PokeValue of the top-level object defined
    > below?  Isn't there a way to refer to it recursively?
    
    Hmm, you might be right, I am not sure if this will work if I put
    "PokeValue" there but it would be cleaner and I will try to do it.

Ok :)