Configuration only? Really?

[ksze]

I find the TOML format better than both YAML and JSON. Should it really be marketed specifically as a minimal configuration file format? I'm thinking it's superior even as a general data serialisation/exchange format.

[eksortso]

If you want to make it big, you gotta start small.

TOML was conceived as a configuration format. I'd be happy with just that. I'd be thrilled if more projects used it for their own purposes, and designed their schemas for it. In fact, I've seen TOML in use as a data exchange format.

But it can't contain arbitrary data types. Everything's in one table. Values cannot exist without identifying keys. No explicit nulls are permitted.

I wouldn't want to market it as something that it isn't quite yet. Quite yet. It'll be a config format, first and foremost, no matter how it evolves.

[ChristianSi]

Well, values can exist in key/value pairs or in lists – just as in JSON.

I agree with @ksze: TOML can be used for many purposes, data serialization certainly included.

[eksortso]

@ChristianSi True, but those arrays are still bound to their names. Even an array of tables in the root has a name attached to it. The values inside don't have keys.

But you can't just put ["whiskey", "tango", "foxtrot"] alone in a file. That would be invalid, not to mention confusing if you didn't know about [tables].

[pradyunsg]

TOML’s main goal is to be a good configuration language. The fact that it’s a good choice for certain styles of data serialisation is an expected coincidence. (those follow the same structure/approach as what TOML’s design incentivises).

Not advocating for that use case is intentional on my end (I’ve thought about this a while back) — trying to cover too many “needs”/use cases results in complexity that I don’t really think we should have in TOML. And, arguably, TOML’s already pretty high on the complexity front for something that uses obvious to describe itself.

There’s no one saying TOML can’t be used for data exchange or whatever. OTOH, if someone comes around asking for accommodations/changes that better fit such use cases, it’s way easier to say “no” when the language isn’t marketed to solve those use cases. And, that’s making my life that tad bit easier. :)

[eksortso]

We'll want to follow developments by other projects to extend TOML for data markup. We may be excluding ourselves from ideas that could make their way into TOML proper in the future. We'd likely see the introduction of JSON-like nulls, which are off the table for us. But other data-related niceties could work for us as well as for them. Like, say, lossless decimal types. Or explicitly ordered tables. Let a thousand flowers bloom.

Any new feature added to a TOML-like language could potentially break users' TOML intuitions. But the burdens those features add won't fall upon us to carry, unless we choose to carry them.