SOML – A Config Format for Humans

paulddraper

> Top-level arrays. A TOML file is always a table, so a list of records needs a wrapper key. I'm curious for example configs that are top-level lists?

esafak

Can you add README sections for the schema and supported types?

jll29

Looks like Windows *.ini format except ":" instead of "="...

arionmiles

See also: HUML [1] 1: https://huml.io/

drvd

So a stripped down variant of cue? Why not use cue directly?

CodesInChaos

What I'm missing: 1. The readme doesn't make it clear what its "float" type is. A double, a decimal, implementation defined. I'm generally not a fan of restricting numbers to what a double can represent, like toml does. 2. It doesn't have a good way to model key-value pair like types such as tagged unions, polymorphic types, or function invocations. Simply allowing a key-value pair as a value (right associative) where the key is a string matching the keys of an object would fix this. Alternatively a function call syntax would fix this, which would also enable tuples as a concept distinct from arrays.

lightandlight

Ironically the project seems LLM-generated. I don't want to read Claude's interpretation of why your project matters. I want you to tell me directly.

james_marks

From the title, I thought this was a specification for configuring humans. I don't quite know what that means, and I'm disappointed still not to know.

petre

We already have TOML and it's great. I can seamlessly upgrade from ini to toml.

priomsrb

Looks nice! It would be great if you had a simple website that allowed you to enter SOML and see the JSON side-by-side (similar to typescript playground https://www.typescriptlang.org/play/ ).

catlifeonmars

There are numerous inaccuracies in the “Why not TOML” section of the README. Here are a few: > CVE-2026-44244 injected a [core] section into .git/config for code execution. Git config is not TOML. It’s an ini-based bespoke syntax > SOML needs quotes for a literal dot. So does TOML, the dot notation is for nested keys. You use quotes for a literal dot. —— FWIW I like the decision to have a first class duration type.

joshheitzman

From the comments here I can infer that it has a schema and in turn I can extrapolate that this is as much "for humans" as many other config formats that are deterministically parseable. A GUI is a config format for humans as it can you show what all of the configuration options are along with text that tells you what they do. A GUI can also ensure that there are no invalid settings that are discovered separately from the edit session (sure it may not do so, but it has the possibility unlike whatever random text editor the user opens the config in).

Yasuraka

> no key needs quotes > 'the name': 'quotes are the escape hatch, when a key needs spaces' To quote David Fincher: > They know you have computers and can show a Tyrannosaurus Rex eat a car, so they know you can do anything. The question is: what don't you do, not what do you do. Constraints liberate; I wish people tended to more strictness. I had plenty of stumbling over "features", asking myself who couldve ever needed them. This particular one also irked me about CUE. But that's just a nit.

ActionHank

Gotta be honest, any time there's a solution like there that makes it more "human" they've just removed the structure / syntax. I'm guessing so you don't need to learn them, so then anyone off the street can edit the files, but it will break so bad without those guardrails, usually in some non-obvious way. Leading us back to inventing some new "human" thing, but with more implicit rules, and the cycle continues.

layer8

> what you see is what you get: […] '10.20' and 10.20 are a string and a float, exactly as written. This seems both underspecified and incorrect. Assuming a single-precision binary IEEE 754 floating-point number, 10.20 is actually 10.19999980926513671875. With double precision, it would be 10.199999999999999289457264239899814128875732421875. So what you see is not what you get, and it’s also unclear what exactly you’ll get. > A value's type comes from its syntax, never from its content […] allowed-origins: [ ' https://example.com ' ' https://example.org ' ] This looks like URLs, but are strings. What if you had: > allowed-origins: [ 'httpș://example.com' 'ħttps://example.org' ] Still strings and therefore fine for the SOML parser, but probably not a valid configuration in terms of the application-level types of the values. The syntax telling you the types is of limited utility as soon as the application schema has more specific ideas about the types than the configuration language.

sscaryterry

We really don't need yet another format.

umvi

> durations like 30s are real values, so nobody has to guess the unit of timeout: 30 Pet peeve of mine, but I would argue that it's better to always keep units baked into the key. If you have: timeout_s: 30 Then unit information will never be lost, because the unit is always marshalled as a part of the key name and you don't have to worry if the target language has a duration type or not. If you have: timeout: 30s Then unit information probably won't be lost, but could in the following scenarios: - Target language doesn't have duration types (looking at the list - Ruby?) - If you ever need to convert to/from a data format without durations like JSON So basically you have to use SOML across your entire stack and always use languages that have native duration types, and also you have to be careful never to convert SOML to/from JSON (which is highly likely if you ever have to interface with external APIs). Do any of those things and you'll likely run into a unit confusion scenario at some point. But there are going to be lots of configs that won't have native type like size. Again, just include units in key: max_size_bytes: 30000000 In conclusion, my opinion is to KISS by including units in the key name and by sticking to bool/number/string primitives, hence why I almost always use JSON for everything (though if I could be granted one wish, it would be for JSON spec to allow for dangling commas)

sedatk

People who research new configuration formats should take a look at PSD1 too: https://ssg.dev/powershell-accidentally-created-a-nice-confi...

stonyrubbish

https://xkcd.com/927/

hk1337

yet another format? https://xkcd.com/927/