31–40 of 64 posts
[1] https://en.wikipedia.org/wiki/Comparison_of_data-serializati... [2] https://rigaux.org/language-study/syntax-across-languages.ht...
=====
Forbidden Characters
Forbidden characters are Unicode scalar values with general category Control, Surrogate, and Unassigned. Forbidden characters must not appear in the source text.
White Space
White space characters are those Unicode characters with the Whitespace property, including line terminators.
I'd take Prolog without I/O and (some? all?) extra-logical predicates as configuration language. Maybe if there's a way to require recursion to terminate, that'd be great, but not essential.
Earlier quoted context omitted.
You're going to read the configuration in a target programming language So if the config format has its own type system you then have to convert between config types and language types If the config type doesn't map exactly onto the target lang type you either ignore it and accept some values won't round-trip cleanly or without error, or you fall back to using strings (e.g. various possible integer type sizes, signed…
I see your argument tho maybe im just not getting the real use case. Because when saying defaulting back to string and thatfor ignoring typing, wouldnt that just be the same as beeing typeless? Therefor doesn't every format support string therefor supporting typeless? Also, in how many cases do you need to parse the same configuration in multiple different languages? Im not saying its not useful - i just try to get t…
Neo4j uses 128 bit ids. The JSON API retrieves these ids as strings of digits, Python library reading this JSON decided to interpret these as double precision floats. And sometimes it works, other times: not so much...
The whole selling point of configuration formats is to allow multiple languages to access the same data. So, cases when multiple languages have to read the same configuration format are exceedingly common.
The fact that the format supports other types means that someone (probably not you) will use those types, and then (probably you) will have to deal with the mess created by that person. I don't trust programmers in general to write good code... if possible to prevent them from writing bad code, then why not?
XML still works well as a configuration format.
Is it verbose? Very much so, but it ticks all the boxes:
- No ambiguity
- Typed
- Quick to parse
- Has Schemas that allow validation
- Widespread tooling support
All we needed was for applications to publish their XML schema files and any XML tool could allow for friendly editing.
JSON, jsonc, json5, hcl, kdl, scfg, caddyfile... and that's just from earlier comments. After a brief search, puzzled, I ask: Is there really no more thorough comparison than wikipedia's[1]? No syntax-across-languages[2]? No design space characterization? [1] https://en.wikipedia.org/wiki/Comparison_of_data-serializati... [2] https://rigaux.org/language-study/syntax-across-languages.ht...
This allows really cool things, like modular configs where one "main" config file can include multiple specific-purpose configs. One file can contain the "default users" while another can contain additional users, for example. Or each user can get its own file.
So much continual effort wasted when for over 20 years we've had XML. XML still works well as a configuration format. Is it verbose? Very much so, but it ticks all the boxes: - No ambiguity - Typed - Quick to parse - Has Schemas that allow validation - Widespread tooling support All we needed was for applications to publish their XML schema files and any XML tool could allow for friendly editing.
eh ...
Okay, maybe it's quick. But it's also surprisingly hard to do "right". Just look at libexpat. Sure, many issues could be prevented with another programming language. But there are still regular updates because parsing custom entities is a minefield.
That said, I also like XML for all the other reasons you mentioned. Just don't do it like Maven.
> Confetti does not compete with JSON or XML, it competes with INI. It clearly competes with JSON. I think I would still much rather use JSON5 over this. It's quite similar in terms of structure and terseness, but I don't have to learn anything. // This is a comment. { probe_device: ["eth0", "eth1"], users: [ { user: "*", login: "anonymous", password: "${ENV:ANONPASS}", machine: "167.89.14.1", proxy: { try_ports: [58…
Blah blah blah it doesn't have a spec. Lack of a spec doesn't matter from the user's POV in this problem domain, as all configuration files are categorically application-specific anyway. It doesn't matter to the developer either, insofar as whatever implementation you use fits your needs. This isn't object notation, it's not data interchange, it's configuration.