3 ms·
I agree but I'd like the generic implementation of that. JSON schema never really took off and I believe that part of the reason is that there's not a way to i
by smoyer 7y ago
I agree but I'd like the generic implementation of that. JSON schema never really took off and I believe that part of the reason is that there's not a way to indicate what type might be contained in a string or number (I'm okay with JSON booleans and null). As ugly as it could get, adding XML Schemas to XML documents did in fact help the parser.
The reason I stated I'd like the generic version is that there are other types that we use consistently. There's a very nice RFC available for telephone numbers that we've started following and we can marshal/unmarshal pretty easily from strongly typed languages (where we control the code), but wouldn't it be nice if there was a standard way (within the JSON to let systems know it was a telephone number?
- https://tools.ietf.org/html/rfc3966 https://tools.ietf.org/html/rfc3966
- optimiz3 7y agoAdding a schema meta language just creates unnecessary complexity. Instead of 1 language now there's two. If you're going to invent a new language like json-schema, you might as well skip to json2. People who care about schemas already enforce this at the serialization layer where the objects being mapped to implicitly are the schema. Pushing the schema down to the protocol just adds complexity and bloat.
- hyperpallium 7y ago> the objects being mapped to implicitly are the schema Dynamic languages don't have an enforced schema. You can do it manually, but a schema is easier, special-purpose, declarative. Plus, data schema languages are typically far more expressive than programming languages. e.g. java doesn't even have nonnullable (which C had, as non-typedef structs). They're closer to a database schema.
- osmarks 7y agoCBOR (https://cbor.io/ https://cbor.io/) allows custom types, but it's a binary format and not anywhere near as popular.
- eropple 7y agoI dunno, JSON Schema seems to have certainly found a lot of traction where it makes sense--web responses, etc. That may to some extent be a POV thing, as I work on a lot of OpenAPI-consuming and -producing systems myself, but I never really have to dig around to find schemas and the like for stuff I really care about. VSCode even has JSON Schema support built in, which is cool. I use that a lot.
- hyperpallium 7y agoMy theory is that XML has got all the uglies you could ever want (and more), so why not just use that instead of defiling JSON? Also, thingo aggressively protected JSON's simplicity, banishing comments because people were using them as parser directives.
- silvestrov 7y agoI think it's time for a JSON version 2. a) no mandatory quotes for dicts keys b) date and time intervals in iso 8601 format. c) optional type-specifiers for strings, so we can add e.g. ip4 and ip6 addresses. Eg. { remote: "127.0.0.1"#ip4 } e.g. { guests: 42, arrival: @2020-02-17T17:22:45+00:00, duration: @@13:47:30 }
- alexis_fr 7y agoAnd comments.
- jnwatson 7y agoThere’s a corollary in there to Greenspun’s tenth. Any sufficiently complicated serialization technology contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of ASN.1.
- vbezhenar 7y agoName "JSON" would be weird, because it wouldn't be JavaScript-compatible syntax anymore. I know, that few people would agree with me, but I would propose `new Date(2020, 2, 17, 17, 22, 45)` syntax, even if nobody uses `eval` to parse JSON, keeping historical heritage is important. And if you need timezone, something like `Date.parse("2011-10-10T14:48:00.000+09:00")` could be used. Now it's not a real constructor or function calls, it's just a syntax, but it's still compatible with JavaScript.
- Supermancho 7y ago> JSON schema never really took off I see JSON Schemas used all over. Advertising, Medical, Banking, etc.