We plan to implement #JSON output in our #DNS investigation tool dnsi. There is informational RFC 8427 for representing DNS messages in JSON, but we’d like to see if there is a more ergonomic way of representing such a format. We'd love to hear about your use cases and wishes. https://github.com/NLnetLabs/dnsi/issues/12
@vrandecic yes of course! to be concrete - i am trying to fit one array specification's ability to use variables for shape constraints into JSON Schema specifically, so the encoding of the arrays themselves is not really the problem. Eg. it's no problem to specify an n-length array of n-length arrays, that's what i'm alreadydoing. It's also no problem to dynamically generate schemas for a given array spec, or even during validation. The problem is that I can't declare a relationship between the shape constraint based on another, unfortunately i just got confirmation on that from one of the maintainers :( https://github.com/orgs/json-schema-org/discussions/730#discussioncomment-9530451
Just encountered the #EDIFACT standard while in touch with our logistics firm. Why the hell is this nothing readable and yet another useless standard that could've been implemented in #protobuf#json or something modern....
And the best part is everyone uses a subset or has some customizarions which forces us to implement it again and again
#TechnicalWriting#APIs#APIDocumentation#AsynchronousAPIs#AsyncAPI#EventDrivenAPIs#ApacheAvro#JSON: "Luckily there's a specification similar to OpenAPI but directed at defining event-driven APIs. I'm talking about AsyncAPI. It's a specification that lets you define an API that's asynchronous in nature. By using AsyncAPI you can define, among other things, the different topics where events will be dropped, and the shape of the messages that represent each topic.
And this is where things get interesting. The shape of messages or, in other words, its payload, can adhere to specific standards. Without messages, there's no way to communicate events. And, following standards helps to guarantee the correct publishing, transport, and consumption of messages. If messages don't follow any standards, it's hard for developers to understand the shape of the messages. In addition, it's easy for consumers to stop working because, suddenly, messages are being shared in a slightly different format.
Among different message standards, there's one particularly interesting to me. Apache Avro isn't just a theoretical standard. It's also a serialization format. You can say it's a competitor to JSON but specialized in working with event-driven APIs. In the same way you can use JSON Schema to define the shape of JSON data you have Avro Schema to help you specify what Avro message payloads look like."
We've just published a series of 17 (!) posts on common patterns in JSON Schema; lots of these have been culled from questions asked in the JSON-Schema Slack channel.
They are written from the perspective of .NET developers who are used to JSON serialization as a code-first exercise, and want to migrate towards schema-first (with generated code examples from Corvus.JsonSchema).