[Drdrdrq]

> NestedText only supports three data types (strings, lists and dictionaries)...

No numbers? Looks nice otherwise, but this seems like a very weird decision.

That said, JSON with its "I might overflow your number" attitude is not much better in this regard.

[firearm-halter]

The issue with YAML is that it does not unambiguously distinguish between number/booleans and strings. JSON does, but only for numbers, booleans, and nulls. But there are many data types that need to be conveyed. For example, dates and quantities (numbers with units, such as $3.14 or 47kΩ). Such things are left to the application to interpret. Even JSON does not unambiguously distinguish between integers and reals. Even so, JSON pays for its lack of ambiguity by requiring all strings to be quoted, which adds clutter and the requirement for quoting and escaping. Thus, supporting those extra types comes at a cost.

I think NestedText is unique in leaving all leaf values as strings, so it does not need quoting or escaping.

Everything involves a compromise. YAML provides a lack of clutter at the cost of ambiguity. JSON is unambiguous, but comes with visual clutter. In both cases there are still lots of types they cannot handle and so must be passed on to the application.

The compromise with NestedText is that it provides simplicity and a lack of clutter by not supporting any data types for leaf values other than string. Thus, all interpretation of the text is deferred to the application. But fundamentally that is the best place for it, because only the application understands the context and knows what is expected.

[mongol]

Yes but I can understand the rationale. There are many numeric types and settling on some excludes use with others. If letting the application handle that, the configuration language can remain simple. His example where a version number 1.10 was round trip converted to 1.1 was enlightening.