Hacker News Reader

Comment by smoyer | Hacker News Reader

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

View on HN

I 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.

Adding 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.

> 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.

I 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 }

And comments.

There’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.

Name "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.

CBOR (https://cbor.io/) allows custom types, but it's a binary format and not anywhere near as popular.

My 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.

> JSON schema never really took off

I see JSON Schemas used all over. Advertising, Medical, Banking, etc.

Reply on news.ycombinator.com