[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JSON Representation
From: |
Konstantinos Chasialis |
Subject: |
Re: JSON Representation |
Date: |
Sat, 9 May 2020 18:24:01 +0300 |
User-agent: |
SquirrelMail/1.4.23 [email.uoa.gr] |
> 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.
> I don't think we need a nullValue property. The "Null" object can have
> either an empty "properties" (if such a thing is allowed in the JSON
> thingie) or no properties at all.
>
I changed it.
The reason why I did it this way is to have consistency on our schema.
(all are objects)
>
> 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.
> 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).
> + "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!
> Why not just "fields"?
>
Done.
> 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.
> 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.
Sorry for the long reply, below is the commit.
Author: kostasch <address@hidden>
Date: Sat May 9 18:18:38 2020 +0300
More fixes on JSON Representation
libpoke/pvm-val.json | 125
++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------------
1 file changed, 83 insertions(+), 42 deletions(-)
diff --git a/libpoke/pvm-val.json b/libpoke/pvm-val.json
index 9cda2266..1ec1e29a 100644
--- a/libpoke/pvm-val.json
+++ b/libpoke/pvm-val.json
@@ -18,6 +18,7 @@
"maximum": 64
}
},
+ "maxProperties" : 2,
"required": [
"size",
"unsignedValue"
@@ -38,6 +39,7 @@
"maximum": 64
}
},
+ "maxProperties" : 2,
"required": [
"size",
"signedValue"
@@ -45,15 +47,7 @@
"title": "Integer"
},
"Null": {
- "type": "object",
- "properties": {
- "nullValue": {
- "type": "null"
- }
- },
- "required": [
- "nullValue"
- ],
+ "type": "null",
"title": "Null"
},
"Offset": {
@@ -61,7 +55,7 @@
"properties": {
"magnitude": {
"type": "object",
- "anyOf": [
+ "oneOf": [
{
"$ref": "#/definitions/UnsignedInteger"
},
@@ -72,14 +66,19 @@
},
"base": {
"type": "object",
- "oneOf": [
- {
- "$ref": "#/definitions/UnsignedInteger"
- }
+ "allOf" : [
+ {"$ref": "#/definitions/UnsignedInteger"},
+
],
- "size": 64
+ "properties" : {
+ "size" : {
+ "enum" : [64]
+ }
+ },
+ "required" : ["size"]
}
},
+ "maxProperties" : 2,
"required": [
"magnitude",
"base"
@@ -89,47 +88,86 @@
"String": {
"type": "object",
"properties": {
- "stringValue": {
+ "value": {
"type": "string"
}
},
+ "maxProperties" : 1,
"required": [
- "stringValue"
+ "value"
],
"title": "String"
},
- /*(Not sure about this one)
- Represent poke struct as an object a number of fields plus a Mapping
- */
- "Struct": {
- "type":"object",
- "properties":{
- "structFields": {
- "type" : "array",
- "items" : {
- "type" : "object",
- "anyOf" : [
+ "StructField" : {
+ "type" : "object",
+ "properties" : {
+ "offset" : {
+ "type" : "object",
+ "$ref" : "#/definitions/Offset"
+ },
+ "name" : {
+ "type" : "object",
+ "$ref" : "#/definitions/String"
+ },
+ "value" : {
+ "type" : "object",
+ "anyOf" : [
{"$ref": "#/definitions/String"},
{"$ref": "#/definitions/Struct"},
{"$ref": "#/definitions/Array"},
{"$ref": "#/definitions/UnsignedInteger"},
{"$ref": "#/definitions/Integer"},
{"$ref": "#/definitions/Offset"}
- ]
- },
- "default" : {
- "type" : "object",
- "$ref" : "#/definitions/Null"
+ ]
+ }
+ },
+ "required" : [
+ "offset",
+ "name",
+ "value"
+ ]
+ },
+ "Closure" : {
+ "type" : "object",
+ },
+ "Method" : {
+ "type" : "object",
+ "properties" : {
+ "name" : {
+ "type" : "object",
+ "$ref" : "#/definitions/String"
+ },
+ "value" : {
+ "type" : "object",
+ "$ref" : "#/definitions/Closure"
+ }
+ }
+ },
+ "Struct": {
+ "type":"object",
+ "properties":{
+ "fields": {
+ "type" : "array",
+ "items" : {
+ "type" : "object",
+ "$ref" : "#/definitions/StructField"
+ }
+ },
+ "methods" : {
+ "type" : "array",
+ "items" : {
+ "type" : "object",
+ "$ref" : "#/definitions/Method"
}
}
},
- /*Optionally, add a mapping after defining the struct*/
"additionalProperties": {
- "type" : "object",
- "$ref" : "#/definitions/Mapping"
+ "type" : "object",
+ "$ref" : "#/definitions/Mapping"
},
"required": [
- "structFields"
+ "fields",
+ "methods"
],
"title": "Struct"
},
@@ -137,7 +175,9 @@
"type": "object",
"properties": {
"IOS": {
- "type": "integer"
+ "type": "integer",
+ "minimum" : -2147483648,
+ "maximum" : 2147483647
},
"offset": {
"type": "object",
@@ -153,8 +193,7 @@
"Array": {
"type" : "object",
"properties" : {
- /*arrayItems is an array of all defined objects above, except
Mapping which is added at the end*/
- "arrayItems" : {
+ "elements" : {
"type": "array",
"items": {
"type": "object",
@@ -173,13 +212,12 @@
}
}
},
- /*Optionally, add a mapping after defining the array*/
"additionalProperties": {
"type": "object",
"$ref": "#/definitions/Mapping"
},
"required" : [
- "arrayItems"
+ "elements"
]
}
},
@@ -208,6 +246,9 @@
},
"Array": {
"$ref": "#/definitions/Array"
+ },
+ "Closure" : {
+ "$ref" : "#/definitions/Closure"
}
},
"additionalProperties": false
- JSON Representation, Konstantinos Chasialis, 2020/05/05
- JSON Representation, Konstantinos Chasialis, 2020/05/05
- Re: JSON Representation, Jose E. Marchesi, 2020/05/05
- Re: JSON Representation, Egeyar Bagcioglu, 2020/05/05
- Re: JSON Representation, Konstantinos Chasialis, 2020/05/06
- Re: JSON Representation, Jose E. Marchesi, 2020/05/06
- Re: JSON Representation, Konstantinos Chasialis, 2020/05/06
- Re: JSON Representation, Jose E. Marchesi, 2020/05/06
- Re: JSON Representation, Konstantinos Chasialis, 2020/05/07
- Re: JSON Representation, Jose E. Marchesi, 2020/05/07
- Re: JSON Representation,
Konstantinos Chasialis <=
- Re: JSON Representation, Jose E. Marchesi, 2020/05/09
- Re: JSON Representation, Konstantinos Chasialis, 2020/05/09
- Re: JSON Representation, Jose E. Marchesi, 2020/05/09
- Re: JSON Representation, Konstantinos Chasialis, 2020/05/10