It's at the cost of human-readability, but it's still readable enough for debugging. Editor plugins could probably fix this issue entirely, by presenting the contents as a more "normal" Lispy syntax.
---
I think the Redis protocol is also a pretty good binary-safe-but-otherwise-text interchange format: https://redis.io/topics/protocol
One thing I'd do there, though, is to change CRLF at the end of a line to LF. Well, that and of course also drop support for the legacy protocol, unless one has a good reason to keep it for debugging.
regardless of exactly when this is from, it is nice to be reminded of that time when XML enthralled so many people as the best solution for structuring and communicating information, and to know that we're past that now
I'll probably be branded a heretic but I like xml as a config format. As long as you keep it simple it's fine. I definitely prefer it over yaml. It's when people start xslt'ing their config file and make it turing-complete is when the problems start.
I think the core concept of using `<>`-delimited tags to group items is sound for config and similar human-writable files. I.e. XML-like markup.
This means that XML subsets are actually pretty decent. Basically the subset of:
- `<!-- ... -->` comments
- `<foo>...</foo>` and `<foo/>` tags
- `>` and similar entities (basically, just the XML-builtin ones, no custom declarations)
- optionally: `<?xml ... ?>` tag at the start (just for compatibility)
- optionally: `<![CDATA[...]]>` (where required for the application)
- optionally: `<foo:bar/>` namespaces (but without needing to declare them like in XML; essentially, just adding ':' as a permitted character)
If I were to extend it, I'd probably also add HTML-like value-less parameters, like `<input readonly/>`. I'd also add an API to create custom entities (but no support within the file itself), to make it more adaptable to specific use-cases.
And this is it. The big issue with XML is all the complexities of DTDs and being able to declare new entities, etc. It was also woefully overused at some point, in not-really-XML ways --- such as by XMPP (which would work much better as a binary protocol).
---
I agree on YAML, by the way. It tries to do too much, and ends up being very unintuitive (here's one for you: what are the various ways of having a multiline string?).
It doesn't help that two different parsers won't generally agree on all the details of the format.
I think TOML (Tom's Obvious, Minimal Language) is a good compromise, if you're looking for something in a similar JSONy-but-human-writable vein.
10 comments
[ 3.2 ms ] story [ 31.4 ms ] threadIt's at the cost of human-readability, but it's still readable enough for debugging. Editor plugins could probably fix this issue entirely, by presenting the contents as a more "normal" Lispy syntax.
---
I think the Redis protocol is also a pretty good binary-safe-but-otherwise-text interchange format: https://redis.io/topics/protocol
One thing I'd do there, though, is to change CRLF at the end of a line to LF. Well, that and of course also drop support for the legacy protocol, unless one has a good reason to keep it for debugging.
It does say updated 2006 which explains how it can include GroovyMarukup.
This means that XML subsets are actually pretty decent. Basically the subset of:
- `<!-- ... -->` comments
- `<foo>...</foo>` and `<foo/>` tags
- `>` and similar entities (basically, just the XML-builtin ones, no custom declarations)
- optionally: `<?xml ... ?>` tag at the start (just for compatibility)
- optionally: `<![CDATA[...]]>` (where required for the application)
- optionally: `<foo:bar/>` namespaces (but without needing to declare them like in XML; essentially, just adding ':' as a permitted character)
If I were to extend it, I'd probably also add HTML-like value-less parameters, like `<input readonly/>`. I'd also add an API to create custom entities (but no support within the file itself), to make it more adaptable to specific use-cases.
And this is it. The big issue with XML is all the complexities of DTDs and being able to declare new entities, etc. It was also woefully overused at some point, in not-really-XML ways --- such as by XMPP (which would work much better as a binary protocol).
---
I agree on YAML, by the way. It tries to do too much, and ends up being very unintuitive (here's one for you: what are the various ways of having a multiline string?). It doesn't help that two different parsers won't generally agree on all the details of the format.
I think TOML (Tom's Obvious, Minimal Language) is a good compromise, if you're looking for something in a similar JSONy-but-human-writable vein.
Datapairs? (Face it - it can always be pairs) Objects? Properties? (JSON, but XML too) Layered Meanings? ((x)HTML)
You seek features, but you mire in the ssugars
All we needed, was additional whitespaces. (at least 3 spaces, maybe one based on how hard you press, and 3 modes for tab!)