5 ms·

Interesting to see the history here: XML was created and solved a lot of problems. So on the bandwagon everybody jumps. Then it became bloated and fragmented

Interesting to see the history here: XML was created and solved a lot of problems. So on the bandwagon everybody jumps. Then it became bloated and fragmented, so the world switches mostly to JSON. But on the XML side, the baby was thrown out with the bath water, while JSON started developing its own abuses. TOML and YAML come in and muddy the waters a bit more. This is only 1 article, but maybe the world is ready to discuss the possibility that the pendulum swung too far?

weberc2 7y ago
I’ve been around long enough to use them all. I’m pretty happy with JSON as a debuggable serialization format for machine-to-machine or light machine-to-human use cases. YAML works well for human-to-machine (JSON could fill this use case as well if it would support comments and multi line strings). I don’t use TOML much, and good riddance to XML.
- ChrisSD 7y ago
  TOML is simply the old INI format except with a single concrete specification instead of many adhoc ones. YAML is the "kitchen sink included" of serialization formats, so much so that most only use a small subset of its features. In that case I think TOML is usually the better choice unless you really do need some of the power and complexity offered by YAML.
  - weberc2 7y ago
    I agree that less power is better, but I find TOML pretty cryptic. Like I said, JSON with comments and multi line strings is my ideal. :)
    - yellowapple 7y ago
      What do you feel is cryptic about TOML? I always felt it was pretty straightforward, especially if you're coming from INI (you could feed INI files into a TOML parser and most of the time end up with something somewhat sane, especially if you're using octothorpes instead of semicolons as comments). That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this. It's one of the things I really like with OpenBSD's various subprojects like PF¹ and OpenSMTPD² and relayd/httpd³, and I'm semi-actively working on a way to do similar things in Erlang/OTP applications⁴. The only alternative that matches that level of expressiveness (besides just doing all configuration directly in the host language) is s-expressions. ¹: https://man.openbsd.org/pf.conf https://man.openbsd.org/pf.conf ²: https://man.openbsd.org/smtpd.conf https://man.openbsd.org/smtpd.conf ³: https://man.openbsd.org/relayd.conf.5 https://man.openbsd.org/relayd.conf.5 / https://man.openbsd.org/httpd.conf.5 https://man.openbsd.org/httpd.conf.5 ⁴: https://otpcl.github.io https://otpcl.github.io
      - weberc2 7y ago
        I'm not coming from INI files. :) I actually always felt they did a poor job of representing anything more than key value pairs and they weren't standardized, so I always managed to avoid learning the grammar(s). I'm sure if I put much effort into it, I could figure out TOML, but I don't want to ask my users to figure out yet another configuration language. If I'm going to make them learn another configuration language, it's going to have something more to offer than just 'simpler than YAML'. Maybe Starlark for more powerful configuration applications (think infra-as-code where YAML/JSON/etc clearly isn't powerful enough) or if someone ever builds it, "JSON with comments and multiline strings" which offers simplicity without compromising familiarity. Actually, it would be really interesting to hear what people's ideal configuration languages would look like. > That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this. I'm not really familiar with this. I'll have to read up.
    - com2kid 7y ago
      TOML is what I'd naturally write as notes if I wanted to document how something is working. YAML is all sorts of strange. JSON needs comments and support for trailing commas. Since that isn't going to happen.... TOML!
- TravHatesMe 7y ago
  "Good riddance to XML" is a bit much. Did you read the article? XML is ideal for representing tree structures. Pick the tool for the job. For example, XAML does an excellent job in declaring your UI. Its use of namespacing, and how you can use child nodes to declare properties of an object, makes it highly flexible albeit slightly verbose.
  - BubRoss 7y ago
    Years of experience > "the article" JSON is a tree structure. It is dictionaries and arrays mixed together in a hierarchy.
    - TravHatesMe 7y ago
      Your opinion != Everyone's opinion Don't get me wrong, I prefer JSON in most cases. But XML does have many valid use cases. Perhaps you haven't had an opportunity to see its beauty. You can't blindly say JSON > XML or JSON < XML, or "XML sucks" -- this shows ignorance.
      - BubRoss 7y ago
        I didn't say any of that. JSON is a tree structure, that isn't an opinion.
        TravHatesMe 7y ago
        My bad, I think I was responding to another comment.
  - dec0dedab0de 7y ago
    Using child nodes to declare properties of an object is the main reason I dislike XML. Because some people use children, and some use attributes, and some use both. Granted, that isn't XMLs fault, but every time I to have get XML data into a usable format it feels like a struggle.
  - weberc2 7y ago
falcolas 7y ago
The moment we added JSON schema (not to mention JSON transforms) and started to create a JSON version of XPath, we started down the same path that hurt XML. Throw in parsers that all act differently (some parse comments, some don’t), and processing directives, and it becomes clear that yes, the pendulum has swung too far.
- com2kid 7y ago
  > The moment we added JSON schema There is an amazing JSON schema syntax out there, 100% better than the official one. It is called TypeScript, and I am sad that the TS compiler can't be made to pop out JSON validators (their philosophy being nothing at all runtime). There is a project (I forget its name) that will insert itself into your build steps and use TS type definitions to validate JSON. Seriously the TS syntax is great, why is anything else being used to write a schema? The only thing I'd add to the TS syntax is the proposals to add field validation using regexs, or some type of field name validation format. There are times when TS can't model my JS objects, e.g. I have a bunch of GUID field names that map to objects of a certain type, and I have some other field names that are 100% not GUIDs, I promise, mapping to some other stuff.
- Mikhail_Edoshin 7y ago
  Imagine you're Amazon and you receive data from vendors. It's not enough to authenticate the sender, you still need to check that the payload is at least syntactically valid before starting to process it. You can write custom code, of course, but after writing lots of it you're likely to start naturally splitting it into a declarative part and a universal processor that checks incoming data against the declaration. It's harder to come up with a declarative way from the start, but it's a natural tendency, because declarative form is much simpler than procedural: declarations are data, and data are easier to understand than a process. This is what schema, transforms, and paths are: they're a declarative way to address these tasks in XML. It's natural there will be attempts to reinvent them for JSON.
patsplat 7y ago
YAML predated / was concurrent with JSON. Both were in reaction to the bloat of XML.
- Mikhail_Edoshin 7y ago
  It's funny that YAML spec is three times as long as XML 1.0.
  - patsplat 7y ago
    The XML bloat is on the processing side.
    - patsplat 7y ago
      Or rather, was. At the time one could either: - write a sax event based parser that scaled but was low level - use a DOM parser with a fairly convoluted API. The combination of attributes and children makes for wordy accessors. Both YAML and JSON provide formats that more readily deserialize into native map / list / string / number types which at the time was quite convenient.

weberc2 7y ago

I’ve been around long enough to use them all. I’m pretty happy with JSON as a debuggable serialization format for machine-to-machine or light machine-to-human use cases. YAML works well for human-to-machine (JSON could fill this use case as well if it would support comments and multi line strings). I don’t use TOML much, and good riddance to XML.

ChrisSD 7y ago
TOML is simply the old INI format except with a single concrete specification instead of many adhoc ones. YAML is the "kitchen sink included" of serialization formats, so much so that most only use a small subset of its features. In that case I think TOML is usually the better choice unless you really do need some of the power and complexity offered by YAML.
- weberc2 7y ago
  I agree that less power is better, but I find TOML pretty cryptic. Like I said, JSON with comments and multi line strings is my ideal. :)
  - yellowapple 7y ago
    What do you feel is cryptic about TOML? I always felt it was pretty straightforward, especially if you're coming from INI (you could feed INI files into a TOML parser and most of the time end up with something somewhat sane, especially if you're using octothorpes instead of semicolons as comments). That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this. It's one of the things I really like with OpenBSD's various subprojects like PF¹ and OpenSMTPD² and relayd/httpd³, and I'm semi-actively working on a way to do similar things in Erlang/OTP applications⁴. The only alternative that matches that level of expressiveness (besides just doing all configuration directly in the host language) is s-expressions. ¹: https://man.openbsd.org/pf.conf https://man.openbsd.org/pf.conf ²: https://man.openbsd.org/smtpd.conf https://man.openbsd.org/smtpd.conf ³: https://man.openbsd.org/relayd.conf.5 https://man.openbsd.org/relayd.conf.5 / https://man.openbsd.org/httpd.conf.5 https://man.openbsd.org/httpd.conf.5 ⁴: https://otpcl.github.io https://otpcl.github.io
    - weberc2 7y ago
      I'm not coming from INI files. :) I actually always felt they did a poor job of representing anything more than key value pairs and they weren't standardized, so I always managed to avoid learning the grammar(s). I'm sure if I put much effort into it, I could figure out TOML, but I don't want to ask my users to figure out yet another configuration language. If I'm going to make them learn another configuration language, it's going to have something more to offer than just 'simpler than YAML'. Maybe Starlark for more powerful configuration applications (think infra-as-code where YAML/JSON/etc clearly isn't powerful enough) or if someone ever builds it, "JSON with comments and multiline strings" which offers simplicity without compromising familiarity. Actually, it would be really interesting to hear what people's ideal configuration languages would look like. > That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this. I'm not really familiar with this. I'll have to read up.
  - com2kid 7y ago
    TOML is what I'd naturally write as notes if I wanted to document how something is working. YAML is all sorts of strange. JSON needs comments and support for trailing commas. Since that isn't going to happen.... TOML!
TravHatesMe 7y ago
"Good riddance to XML" is a bit much. Did you read the article? XML is ideal for representing tree structures. Pick the tool for the job. For example, XAML does an excellent job in declaring your UI. Its use of namespacing, and how you can use child nodes to declare properties of an object, makes it highly flexible albeit slightly verbose.
- BubRoss 7y ago
  Years of experience > "the article" JSON is a tree structure. It is dictionaries and arrays mixed together in a hierarchy.
  - TravHatesMe 7y ago
    Your opinion != Everyone's opinion Don't get me wrong, I prefer JSON in most cases. But XML does have many valid use cases. Perhaps you haven't had an opportunity to see its beauty. You can't blindly say JSON > XML or JSON < XML, or "XML sucks" -- this shows ignorance.
    - BubRoss 7y ago
      I didn't say any of that. JSON is a tree structure, that isn't an opinion.
      - TravHatesMe 7y ago
        My bad, I think I was responding to another comment.
- dec0dedab0de 7y ago
  Using child nodes to declare properties of an object is the main reason I dislike XML. Because some people use children, and some use attributes, and some use both. Granted, that isn't XMLs fault, but every time I to have get XML data into a usable format it feels like a struggle.
- weberc2 7y ago

falcolas 7y ago

The moment we added JSON schema (not to mention JSON transforms) and started to create a JSON version of XPath, we started down the same path that hurt XML. Throw in parsers that all act differently (some parse comments, some don’t), and processing directives, and it becomes clear that yes, the pendulum has swung too far.

com2kid 7y ago
> The moment we added JSON schema There is an amazing JSON schema syntax out there, 100% better than the official one. It is called TypeScript, and I am sad that the TS compiler can't be made to pop out JSON validators (their philosophy being nothing at all runtime). There is a project (I forget its name) that will insert itself into your build steps and use TS type definitions to validate JSON. Seriously the TS syntax is great, why is anything else being used to write a schema? The only thing I'd add to the TS syntax is the proposals to add field validation using regexs, or some type of field name validation format. There are times when TS can't model my JS objects, e.g. I have a bunch of GUID field names that map to objects of a certain type, and I have some other field names that are 100% not GUIDs, I promise, mapping to some other stuff.
Mikhail_Edoshin 7y ago
Imagine you're Amazon and you receive data from vendors. It's not enough to authenticate the sender, you still need to check that the payload is at least syntactically valid before starting to process it. You can write custom code, of course, but after writing lots of it you're likely to start naturally splitting it into a declarative part and a universal processor that checks incoming data against the declaration. It's harder to come up with a declarative way from the start, but it's a natural tendency, because declarative form is much simpler than procedural: declarations are data, and data are easier to understand than a process. This is what schema, transforms, and paths are: they're a declarative way to address these tasks in XML. It's natural there will be attempts to reinvent them for JSON.

patsplat 7y ago

YAML predated / was concurrent with JSON. Both were in reaction to the bloat of XML.

Mikhail_Edoshin 7y ago
It's funny that YAML spec is three times as long as XML 1.0.
- patsplat 7y ago
  The XML bloat is on the processing side.
  - patsplat 7y ago
    Or rather, was. At the time one could either: - write a sax event based parser that scaled but was low level - use a DOM parser with a fairly convoluted API. The combination of attributes and children makes for wordy accessors. Both YAML and JSON provide formats that more readily deserialize into native map / list / string / number types which at the time was quite convenient.