3 ms·
One thing I'm guilty of is designing a document format as JSON, thus the need to formally verify it. Passing data works well as JSON but documents works better
by tored 5y ago
One thing I'm guilty of is designing a document format as JSON, thus the need to formally verify it.
Passing data works well as JSON but documents works better as XML where you can use XML Schema.
- ChrisMarshallNY 5y agoThis is where I would also develop an XML variant, even if it is never to be used, simply so that I can have a Schema to go along with it. I'll start with a data structure/class, in the code, then use a built-in transformer, to turn it into JSON or XML. That way, I know that the "kernel" of the data is the same, between them. Even though JSON is a "natural" for scalar types, it can get weird, there. For example, let's say we have a float: { "kids": 1.0 } It needs to be parsed as a float, because we could have: { "kids": 2.3 } But I often see these sent as: { "kids": 1 } or { "kids": "1.0" } or even { "kids": "1" } And I have differing results, based on the parser.
- matja 5y agoEven with integers (comes up often for large numeric IDs): JSON.stringify(JSON.parse('{"kids":10000000000000001}')) -> '{"kids":10000000000000000}' How do JSON schemas handle "must be an integer", and having to pass a string to get the necessary value?
- tored 5y agoI think you can use a string type with a regexp pattern.
- Someone 5y agoThat’s not an issue with json, but with json libraries. For better or (IMO) for worse {“kids”: 12345678901234567890123456789012345678901234567890} is perfectly legal json.
- matja 5y agoIf every JSON library actively chooses not to implement the JSON spec, that sounds like an issue with JSON to me.
- HelloNurse 5y agoMore precisely, an issue with different literal types instead of one like in XML. In XML, every attribute or text fragment is a string, to be POSSIBLY parsed as a string, integer, date etc. according to what applications choose to do (usually according to an explicit schema). In JSON, YAML, etc. there are at least integers, strings and floating point numbers, introducing arbitrary representation choices (1, 1.0, "1", "1.0") and implementation artifacts (e.g. numerical limits).
- matja 5y agoSeparate types is fine, but JSON doesn't specify a minimum range or precision of the number type that a implementation must have, so the number type is unreliable (and string has to be used instead). To handle any number, a JSON library needs to use an arbitrary-precision number type, which no common one does because of the huge performance hit. So, no better than XML really :D
- Too 5y agoLook at MongoDBs "extended json". They serialize this as { "$numberLong": "10000000000000001" }. With a custom extension to the json-schema adding property bsonType:long, instead of type:int. Along with a few other data types like datetimes, uuid, regex. It can be integrated with custom hooks in many schema validators.
- tored 5y agoPerhaps create your own custom type floatable that can be either be of type float, integer or string with a regexp pattern.