Re: JSON Representation

[Jose E. Marchesi]

    > Why having "unsignedValue" and "signedValue" instead of just "value" in
    > both "UnsignedInteger" and "SignedInteger"?
    
    The reason behind this is that when we define offset if we use "value" and
    value is > 0 it has no clue on how to say if its singed integer or
    unsigned integer.
    
    For example :
    {
     "Offset" : {"magnitude" : {"value" : 15, "size" : 1},
       "base" : {"value" : 15, "size" : 1}}
    }
    
    Yields the following error:
    JSON is valid against more than one schema from 'oneOf'. Valid schema
    indexes: 0, 1.
    
    I would like to use "value" on all types but I think it will not work due
    to conflicts.

Oh I see.  Doesn't that mean that we ought to tag the values (every
value) with a "type" property?

An unsigned int value would then be:

  {"type" : "UnsignedInt", "value" : 15, "size" : 1}

And a signed value:

  {"type" : "Int", "value" : 15, "size" : 12}
    
    >
    > Do we need an "oneOf" if there is just one alternative?
    >
    
    oneOf / allOf etc with one alternative is a wrapper. When you use $ref in
    JSON schemas all other properties are ignored (took me a while to figure
    out).
    However, if you wrap a $ref inside allOf / anyOf etc you are free to
    define more properties for your object.

I'm not sure I follow, but sounds like you have got it under control so
ok :)
    
    > Also, with this definition, is `"size": 64' really referring to the size
    > of the size of the $ref-erred object above?
    >
    > Yeah I have no clue about JSON schemas 8-)
    >
    
    Fixed so when we create an Offset object size cannot be another value
    other than 64 (e.g. Offset with size = 32 now correctly yields
    error).

Ok thanks.
    
    
    >     +    "String": {
    >     +      "type": "object",
    >     +      "properties": {
    >     +        "stringValue": {
    >     +          "type": "string"
    >     +        }
    >
    > Why not just "value"?
    
    Consider the following data :
    
    {
     "Array" : {
       "elements" : [ {"value" : "kostas"}, {"unsignedValue" : 15, "size" : 1}],
    
       "Mapping" : {
         "IOS" : 15, "offset" : {
                   "magnitude" : {"unsignedValue" : 15, "size" :1}, "base" :
    {"unsignedValue" :
    15, "size" : 15}
                 }
         }
       }
    }
    
    "value" will refer to our string, but it would be more expressive to call
    it "stringValue" in order to express that its a string.
    
    There are other ways, such us including a "name" field on every JSON
    Object that describes the name of this object. Whatever you prefer!
    
This is basically the "type" I am proposing above right?

    > Why not just "fields"?
    >
    
    Done.

Thanks.
    
    > Using an array for the struct elements seems appropriate: the order
    > matters!
    >
    > However, each struct field should be a JSON object by itself, containing
    > the several properties you can see in pvm_struct_field in pvm-val.h:
    > offset, name, value and modified.  See the comment before the definition
    > of the struct in order to determine what kind of values these properties
    > can hold (they are all pvm_vals, which should map to your JSON objects.)
    >
    > Struct values also should have an array of methods.  Each method is a
    > closure, you can look at their properties in the pvm_cls boxed value in
    > pvm-val.h.
    >
    
    Done, tell me what you think.
    
    > Does the order in the definition of the properties matter?  I'm a bit
    > confused about the "after defining the struct" comment.
    >
    
    Yes, from what I understood, you wanted the "Mapping" object defined after
    defining
    the fields of the array. Please consider the following data example.
    
    {
     "Array" : {
       "elements" : [ {"value" : "kostas"}, {"unsignedValue" : 15,
    "size" : 1 }
         ],
    
       "Mapping" : {
         "IOS" : 15, "offset" : {
                   "magnitude" : {"unsignedValue" : 15, "size" :1}, "base" :
    {"unsignedValue" :
    15, "size" : 15}
                 }
         }
       }
    }
    
    "Mapping" is part of the array, but its not contained on the "elements" 
part.
    
Right.

    > The IOS should be a 32-bit signed integer.  Don't you need to define
    > minimum and maximum?
    >
    
    Done.
    
    > Call them elements please, not items.
    >
    
    Done.
    
    > I got lost: what are the definitions below for? :)
    
    These definitions are references to our objects, so we can instansiate them.
    

Oh ok.
Thanks!