4 ms·
Why muddy up the actual values where you will have to parse that value with "t:" where t is type? Why stuff it in one key/val? why not separated where it looks
by drawkbox 10y ago
Why muddy up the actual values where you will have to parse that value with "t:" where t is type?
Why stuff it in one key/val? why not separated where it looks to see if type is present, if so it converts to it/validates against it (you can also place other validations/constraints on it like min/max values, length etc -- that will fall apart if you are trying to stuff it all in one key/value).
Like this:
{
"val":"Hello, world!",
"type":"string",
"validation": "[regex]"
}
Instead of:
{
"s:string":"s:Hello, world!"
}
This is typically how we type fields in JSON when needed as there is no parsing needed on the value. If you need to check type and it is present you can act on it.
- jerf 10y agoStoring validation next to the type like that is a bad idea in general. If you can't trust the incoming data to be valid, then for the same reasons, you can't trust the incoming data's claim for what would make it valid.
- drawkbox 10y agoPossibly out in the wild but if it comes from a server you control and systems you validate then both this and TJSON or any JSON type system would have that same issue. Typically typing/schemas are system to system and not necessarily filled by users or in areas they can be edited. Same issue with XML validation, any schema info needs to be enforced by the server/backend/api.
- wojcikstefan 10y agoThat's a lot of extra bytes you have to send over the wire. Also, I don't think validation makes sense. When sent by the server, it's too limited (would lead to situations where you're doing half the validation in TJSON and half in the client code). When sent by the client, it can't be trusted anyway.
- drawkbox 10y agoTrue if validation is on there. I just put it in to show you could have other easily added validations aside from type (TJSON is locked to just type as it is concat/mashed in one value colon separated). If you just take the "val" and "type" it is really no extra bytes or very minimal but cleaner. { "val":"Hello World", "type":"string" } OR { "s:string":"s:Hello, world!" } Pretty much the same. I guess my personal preference is I don't like to mash values and parse values out of key/value values. In the end all validation is done on the server anyways so types/schemas for JSON are really just a nice to have and should not be relied on unless you control both ends of the pipe.
- imtringued 10y ago>That's a lot of extra bytes you have to send over the wire. Redundant data is not a problem if you combine JSON with gzip. JSON with gzip is basically good enough for everything except fast serialization or deserialization. If you care about that then you should use something like Protocol Buffers or Cap'n Proto.
- bascule 10y agoCompactness. TJSON expresses in 2 characters what you're taking another roughly 24 to do (omitting the "validation", which I think is unhelpful and pointless)
- drawkbox 10y agoTrue, a few bytes more. But less processing on the flipside not having to parse every key/value for the colon concatenated tag.
- uryga 10y agoI don't how the "less processing" argument works. In your version, parsing a value also requires additional work - there's a whole { } to go through.
- weego 10y agoYou've just reinvented XML
- drawkbox 10y agoOr made it closer to current schemas for JSON like JSON Schema[1] TJSON type tagging "t:" looks eerily like XML namespace prefixes. Personally not a big fan of typed JSON and hate XML/SOAP/bloat but also not a fan of mashed/concatenated values which is reminiscent of CSV days, most protocol buffers are reminiscent of binary data exchange days, those were even more fun /s. You can apply constraints on an instance by adding validation keywords to the schema. For instance, the "type" keyword can be used to restrict an instance to an object, array, string, number, boolean, or null: { "type": "string" } [1] http://json-schema.org/ http://json-schema.org/