Show Dev: A Data Interchange Format

Link: https://github.com/HyaenaTechnologies/configuration/blob/main/documentation/data-interchange.md

I have designed a Data Interchange Format to replace JSON, YAML, TOML, XML, Protocol Buffers, SQL and HTTP. This was achieved by splitting the design between a Dynamically Typed Syntax and a Statically Typed Syntax. The Dynamically Typed Syntax is for Configuration, Dynamic Data Storage and Low-Performance Network Communication (HTTP). The Statically Typed Syntax is for Inter-Process Communication, Remote Procedure Calls, Static Data Storage and High-Performance Network Communication with Binary Serialization (Protobuf). The Syntax of the design introduces Delimiters, Scoping, Optional Schemas and Optional Static Typing. Data Interchange Formats are critical and the ones that we have been using are poorly designed because they fail to understand Dennis Ritchie, Ken Thompson and Rob Pikes principles at Bell Labs, in cooperation with Niklaus Wirth. A header file for Definition, a Source File for Implementation, or Wirth's Module Systems in Modula. My Data Interchange Format embraces the C-Style Syntax, Delimiters, Scopes and C-Style Header Files, while allowing extensions if Modules, Functions and Control Flow are needed. No ambiguous Indentation-Based Parsing from YAML or TOML. It has Proper Data Structures instead of Object Literals from JSON, YAML, TOML and XML. A Better Type System than Protocol Buffers and SQL. It is easier to implement than HTTP because a Message is a Data Structure with Initialized Fields. This prevents the usage of Domain Specific Language. Allowing teams to require either a Configuration File or a Library for a General Purpose Programming Language, no more "JSON with If Statements".

Comments

[PEACEBINFLOW]

This is actually a really interesting middle ground between JSON, protobuf, and a proper type system. What stands out to me is that you’re not just defining a data format — you’re defining intent about data. The dynamic version feels like a cleaner, more explicit JSON, but the static side is where it gets spicy: fixed-width ints, option vs optional, array dimensions, and enum semantics all baked into the format itself.

I especially like the split between .schema and .data. That’s a smart move. It makes the format usable both as “just shove some data around” and as a contract between systems, which is where most interchange formats fall apart or get bolted-on validation later.

The option/optional distinction is subtle but powerful too — that’s the kind of thing that saves you from silent bugs in distributed systems. Same with array shape declarations; that’s very “stop pretending everything is a blob and start respecting structure.”

Big question for me (in a good way): what’s the target audience — config files, wire format, or human-authored schemas for APIs? Because this feels like it could be a legit alternative to JSON+Schema if tooling (parser, validator, serializer) comes along.

Overall: this doesn’t feel like a toy syntax experiment. It feels like someone actually thought about how data breaks in the real world and tried to design around it. That alone makes it worth paying attention to.

[John Matthias Wabwire]

Thank you so much for providing feedback. I have been looking for feedback since I completed the Specification.