The KDL Document Language

When my projects are posted publicly, I like attaboys, but I need constructive criticism. Asking pointed questions and questioning purported inconsistencies is not complaining.

Is this related to https://kaitai.io/?

  > The very first example is a document with metadata like title, author, etc. It's called a "document language".

Static sites generators often have content in markdown, but I also saw quite some use of YAML or JSON.

  > It seems to be straddling documents and configuration, which in my experience makes for a lot of awkwardness.

It seems to be for structured data, that can be both a document of some sorts or a configuration; just like YAML/JSON/XML is used for both.

  > There are two specifications for writing KDL that can be losslessly translated between it and JSON or XML.
  > These specifications define a stricter subset of KDL that, even if NOT entirely idiomatic, is still valid and fits into the data models of the other two languages: (emphasis mine)

Note that the author means two separate, additional specifications about how to losslessly translate (iow. convert) between KDL and JSON or XML, not that the actual KDL spec has provisions for reading JSON/XML as KDL. I mean, FWICT some JSON file may parse though, but it's not like YAML, which is an actual superset of JSON; now _that_ adds awkwardness.

One can also create a spec to transform JSON into XML, that does not mean it has anything directly to do with the XML spec.

I rather see this as effort to make it easier to switch to KDL, if one finds its characteristics nice(r).

Looks interesting enough to put it on my "to evaluate/play-around" pile.

I'd be interested to know what the author thinks about RON[0], it's not quite the same but also has some nice properties and wants to be a replacement for JSON (yes this is more one for XML or JSON, but still).

Sometimes I wonder if all those formats would never have got invented if JSON had just allowed comments and trailing commas in the first place. While there's JSON5[1] now, it just has not the same level of native (ecosystem) support as JSON has.

[0]: https://github.com/ron-rs/ron

[1]: https://json5.org/

> That sounds like a poorly designed configuration setup. If you've got a nested config that complex, by my reckoning, it should be reorganized into flatter data structures or broken down into more specific configuration files regardless of what the format is.

YAML isn’t just for config. It’s also a serialization format. If your internal data structures are deeply-nested, then the YAML serialization of them will also (properly) be deeply-nested.

Sometimes you need to hand-edit some data in a multi-megabyte YAML-serialized file. It’s possible, but it’s kind of awful. Editing a multi-megabyte KDL-serialized file sounds like it might be slightly less awful.

(Maybe I’m weird, but I see this format as being close to a textual analog of https://en.wikipedia.org/wiki/Interchange_File_Format, as used/inherited by file formats like AIFF, PNG, etc. Maybe picturing a PNG file or the like encoded in this format might make it clearer what the author is going for?)