3 ms·

Hmm... Not really sure I get what problem this schema is the best solution for. It seems like the author was more interested in implementing a model they felt w

Hmm... Not really sure I get what problem this schema is the best solution for. It seems like the author was more interested in implementing a model they felt was more conceptually sound than other solutions, but aren't solving any significant problems, and don't seem to have any big functional improvements over more established contenders. Just going through the section for why they think it beats YAML: > YAML can be ambiguous about what types the data written into it is. If you're worried about data types, that sounds like a job for a proper data storage format rather than putting it into a configuration file, no? > There's also a persistent issue where very large YAML files become unmanageable, especially due to the significant indentation feature. 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 is a great, widespread language. Unlike KDL, which is node-based (like XML or HTML), it's based on map and array data structures, which can provide an easier serialization experience in some cases. Saying that processing node-based formats is more difficult in 'some cases' is a particularly charitable take, especially when they're touting their ability to handle very large, complex configurations. > KDL is designed to avoid these particular pitfalls by always being explicit about types, and having clearly-delimited scope (and the ability to auto-indent/auto-format). Syntax errors are easier to catch, and large files are (hopefully!) much more manageable. It seems like it adds significant complexity over YAML to mitigate abuse of YAML... but wouldn't it just be better to do a better job using YAML? I do tend to be biased towards conforming to the usage practices of existing tools rather than adopting new tools for edge cases or minor conflicts because learning new tools tends to have a slightly higher cognitive toll for me than some others— but as a general rule, I don't see a problem with only switching tools because you have a problem that's significantly more difficult or less efficient to solve with the old tool. Maybe there's some really clear use cases that aren't obvious to me for whatever reason.

hbeckpdx 5y ago
I felt similarly when I first saw it, but I saw that there was no java impl, and I'd been looking for a project, so I wrote one. I've been playing with it for more than 6 months and I think it's better than YAML in a number of ways. The syntax is very clear and mostly simple and the noted ability to autoformat is no small thing. I think it aims for a niche, and hits its target pretty well.
- chefandy 5y ago
  Fair enough— not my niche, I guess. After dealing with a bunch of really hairy, complex, node-based data processing for a few years, I'd sooner roll around in a dusty sandbox with my eyes taped open than purposefully invite that into my life again... but if I suppose if you're doing something that dumb in your config files then the config format isn't the problem, anyway. Cheers.
derefr 5y ago
> 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 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?)
cormacrelf 5y ago
> It seems like it adds significant complexity over YAML to mitigate abuse of YAML On the complexity axis I think you're talking about, yes, having clear scopes and no ambiguity about whether something is a string means there are more bits of syntax to type, but I don't think that adds complexity. JSON has more curly braces and quotes but it is a much simpler and much more reliable format than YAML. KDL is the same. KDL does not "add significant complexity over YAML" in really any sense. The KDL specification is 1/10th the size of YAML's. Being extraordinarily complex and impossible to fully implement is is what YAML is famous for.[0] Asking people to do a better job writing YAML is a tough ask when even computers can barely do it correctly. [0]: https://www.arp242.net/yaml-config.html https://www.arp242.net/yaml-config.html

hbeckpdx 5y ago

I felt similarly when I first saw it, but I saw that there was no java impl, and I'd been looking for a project, so I wrote one. I've been playing with it for more than 6 months and I think it's better than YAML in a number of ways. The syntax is very clear and mostly simple and the noted ability to autoformat is no small thing. I think it aims for a niche, and hits its target pretty well.

chefandy 5y ago
Fair enough— not my niche, I guess. After dealing with a bunch of really hairy, complex, node-based data processing for a few years, I'd sooner roll around in a dusty sandbox with my eyes taped open than purposefully invite that into my life again... but if I suppose if you're doing something that dumb in your config files then the config format isn't the problem, anyway. Cheers.

derefr 5y ago

> 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 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?)

cormacrelf 5y ago

> It seems like it adds significant complexity over YAML to mitigate abuse of YAML On the complexity axis I think you're talking about, yes, having clear scopes and no ambiguity about whether something is a string means there are more bits of syntax to type, but I don't think that adds complexity. JSON has more curly braces and quotes but it is a much simpler and much more reliable format than YAML. KDL is the same. KDL does not "add significant complexity over YAML" in really any sense. The KDL specification is 1/10th the size of YAML's. Being extraordinarily complex and impossible to fully implement is is what YAML is famous for.[0] Asking people to do a better job writing YAML is a tough ask when even computers can barely do it correctly. [0]: https://www.arp242.net/yaml-config.html https://www.arp242.net/yaml-config.html