Live data from Hacker News

JSON Schema bundling formalised

json-schema.org

181–188 of 188 posts

Re: JSON Schema bundling formalised

#181

Never had to learn the intimidating XML stack in depth but it seems clear that the (superficially definetely more digestible) JSON way of notating data must slowly and painfully reinvent the wheel. Reaching the same level of logical complexity (if it solves the same set of problems) seems unavoidable, no? So if the main advantage of JSON is human readability (not a machine oriented attribute btw :-) might be possible…

I think so too. JSON Schema enables very useful tooling such as validation, Swagger-style UIs for interacting with services, or declarative web forms that people would have to build again and again.

Re: JSON Schema bundling formalised

#182
post #119

Earlier quoted context omitted.

Well let's turn the statement around then: can you create a OpenAPI YAML by hand then? At least with XML and XSD you have proper auto complete. I really no need see the need to use a schema for JSON. The only thing it has going for it compared to SOAP/XML is the fact the it faster parsing and that it has no schema.

Yes, you can. Since OpenAPI itself has a JSON schema, you can get autocomplete from any editor that supports JSON schema. At my company, we found that the auto-OAS generation tools were too brittle and didn't communicate enough information, so we actually do write our own OAS and run automation to make sure it's accurate. That's also how our architects communicate with developers about an endpoint - create an OAS for…

> At my company, we found that the auto-OAS generation tools were too brittle and didn't communicate enough information, so we actually do write our own OAS and run automation to make sure it's accurate.

I found all OAS spec authoring tooling to be useless toys when building non-trivial real world specs.

The depths of depravity I’m forced to is as follows:

1. Data model in SparxEA because it’s the tool we have in the depths of govt. Generate XSD from tool

2. XSLT to turn the XSD into matching JSON Schema because I’m old and can still remember how.

3. Hand write the OAS with $ref into JSON schema as appropriate

4. Curate sample payloads to be educationally useful

5. Generate CURL and various code samples

6. Bundle it all into approx 80k lines of machine written wondrousness -

7. ReDoc and Mkdocs to build static website with more documentation

All the work is at data modeling, OAS sample curation and mkdocs documentation

Things I wish JSON and Schema had:

1. An equivalent of xs:decimal that JS would use number & double are just plain useless in real world commerce with dollars & cents and bulk item pricing with 3&4 decimal places

2. Has taken the time to fix rfc3399 and give Dates a Timezone suffix. Too many languages Marshall a date into datetime. How many bugs have I seen where it’s broken in the morning and works in the afternoon because the damn server is running in AU with UTC Timezone and we’re in NZ

Re: JSON Schema bundling formalised

#183
post #91
post #50

Earlier quoted context omitted.

I agree with you, I didn’t expect the amount of negative comments. Used in the past and it was a great tool to “avoid representing invalid states” and also as documentation to share between teams.

> I didn’t expect the amount of negative comments I did! It's been made clear time and time again on HN that "everyone" HATES XML and anything to do with it... especially XSD, WSDL, etc! I really don't see any difference between XML and JSON except the semantics (I lie, I see a lot of reasons why XML is more powerful). But I do get why people prefer JSON over XML for visual reasons alone. Since they're very similar l…

Amen brother (or sister)

Re: JSON Schema bundling formalised

#184

A possibly silly question about JSON Schema: What’s with the emphasis on full URLs to describe where to find related schema? Are developers really assembling a bunch of related schema over the Internet instead of just coalescing them in one place for local use? Maybe I just don’t understand the use case. Why would I ever want to make a client do a bunch of calls to URLs I don’t own rather than serving them up reliabl…

They don't have to be real URLs, but just URIs. That is -- the files don't have to be accessable on the network at those URIs -- you can just use these strings as identifiers, and load the files up manually as you need them.

In fact, the JSON Schema specification even says that identifiers are just URIs and the evaluator implementation need not be expected to have to load the documents from the network (ref. https://json-schema.org/draft/2020-12/json-schema-core.html#... and https://json-schema.org/draft/2020-12/json-schema-core.html#...)

Re: JSON Schema bundling formalised

#185

Article: > "Developers of platforms and libraries that use OpenAPI haven't had such a shake up before, and my feeling is it may take more than a few releases to correctly implement all the new shiny features full JSON Schema has to offer." Dear OpenAPI, please avoid the shiny features.

Like which? Or are you just knee-jerking at the term "shiny" and presuming it means "over-complicated and unnecessary"?

Re: JSON Schema bundling formalised

#187

I use jsonschema to validate my projects' output, and also generate the documentation from it. The python jsonschema support makes this possible: our testsuite is in Python already. But it's an awkward fit, and I despair of having anyone else in my team write schemas: the default of allowing additional unspecified fields must be continually overridden, otherwise your schema has no teeth, and things like "if this fiel…

> otherwise your schema has no teeth I don't disagree, but FWIW, this is common deliberate choice. E.g. Protobufs work exactly the same way. Except unlike JSONSchema, there's no way to disable it. The reasoning is to permit future extensibility.

For JSON itself, ignoring extra fields it makes sense. For validating my own output, it does not.

And validating someone else's output seems counterproductive?

Re: JSON Schema bundling formalised

#188
post #91

Earlier quoted context omitted.

> I didn’t expect the amount of negative comments I did! It's been made clear time and time again on HN that "everyone" HATES XML and anything to do with it... especially XSD, WSDL, etc! I really don't see any difference between XML and JSON except the semantics (I lie, I see a lot of reasons why XML is more powerful). But I do get why people prefer JSON over XML for visual reasons alone. Since they're very similar l…

> Something changes on the server-side, some edge case appears on the UI several weeks after release to prod. Schemas don’t fix this problem. The reason the thing probably broke is the change wasn’t backwards compatible with the clients calling the service. No schema will fix that. If the client hasn’t been updated to consume the breaking change it is gonna break, period. Schemas don’t get you out of handling breakin…

Just to clarify, I wasn't suggesting that schema validation will ever be able to "fix" a breaking change to an API, intentional or not.

And I'm not suggesting that you release new versions of server-side APIs without doing the same on the client-side. (although I understand there are a whole lot of deployments where that's the norm)

What I'm suggesting is that if there are changes made on the server-side that introduce breaking changes to the schema, should be easily picked up at build time (test phase, maybe even compilation).

Of course there are going to be exceptions to this when perhaps using a language's truthiness, or code that converts everything in the payload to a string... But I', pretty sure for 99% of the cases, esp if you use the schema and tools based on schema (code gen) you'll end up in a better place.

Post reply on HN