3 ms·
You know, I never understood why people consider JSON better than XML. Yes, any particular use of XML can be overengineered (namespaces, I'm looking at you), bu
by pferde 8y ago
You know, I never understood why people consider JSON better than XML. Yes, any particular use of XML can be overengineered (namespaces, I'm looking at you), but as long as you control the format or scheme or however you want to call it, it's exactly the same thing as JSON, but encoded differently. In the end, it's all just keys and values or lists of values, arranged in a tree-like hierarchy.
And frankly, I would rather be looking at a well-designed XML format than at a well designed JSON format, with its braces and brackets and commas.
- tannhaeuser 8y agoI don't like XML namespaces either (and neither is the original authors of the namespace spec very proud of it [1]). They're greeting you with verbose and rather ugly pseudo-URLs (another bad and confusing concept IMO) and xmlns:xyz boilerplate on page one when you're interested in quickly gleaning XML data. But arguably, chat log data is actually an appropriate use cases for namespaces, given that you would want a text format that can evolve over time in a heterogenous client and server ecosystem, yet provide a baseline functionality supported by all clients. It's also very helpful if you want to keep chats for archival rather than treating chat as an ephemeral medium. OTOH people have said the excessive use of namespaces and other XML modularization features, and too many XEPs/RFC specs is turning them away from developing XMPP software. There are valid use cases for JSON though such as ad-hoc data protocols where you own both the server and (JavaScript) client and maintain those in the same repo, and when dealing with simple app data that doesn't benefit from using markup constructs. [1]: https://www.tbray.org/ongoing/When/201x/2010/01/17/Extensible-JSON https://www.tbray.org/ongoing/When/201x/2010/01/17/Extensibl...