5 ms·

Yes. As a tree structure, basic xml is fine. There are lots of other ways to do it, but there's really not much difference. For communication, agreement on a co

Yes. As a tree structure, basic xml is fine. There are lots of other ways to do it, but there's really not much difference. For communication, agreement on a common language is more important than its intrinsic merits. (and xml partly attained that because it looks like html, which was still new at the time). But the xml ecosystem is horrible. Sensible ideas, horrific execution; like namespaces and schema. Probably the single worst problem was using xml syntax itself: it's like, a programming language that uses JSON for its syntax. But also, there's guilt-by-association, people hate the enterprise culture that uses xml - similar happened to java. Though xpath is not so bad, and many people seem to quite like it. Finally... json is a better match for data, basically by being c-like. However, an ecosystem tumour is also growing, around JSON. Some even use json syntax itself... I wonder, if perhaps, a root issue is that the world is complex, and youthful simplicity is corrupted as it adapts to cope with the real world... There is hope, however; tools like `jq` never existed for xml.

jandrese 9y ago
JSON and XML aren't really equivalent though. XML is a markup language, JSON is a data serialization format. Of course a lot of hate for XML comes from people trying to use it to serialize data, which it can do but only in a clunky way. JSON is just plain better suited for what most people need.
- hyperpallium 9y ago
  s/serialization format/object notation/
xelxebar 9y ago
Thank you (and @marcoperaza) for unpacking things a bit. I was mostly unaware of the sideband technologies that go along with the basic tag and attribute structure, and your comments about the community and "guilt by association" got me thinking about library support and other practicalities which I hadn't been considering. Thanks :) This also got me reading up on various structured-data formats: XML, YAML, JSON, TOML, HCL, etc. I'd really like some big table comparing various features but can't seem to find anything of the sort. I found a link [0] that has comparisons between JSON, TOML and YAML representations for various types of data. It's neat to see how each becomes more or less verbose depending on the kind of data getting encoded. [0]: https://gohugohq.com/howto/toml-json-yaml-comparison/ https://gohugohq.com/howto/toml-json-yaml-comparison/ edit: I found a table: https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats https://en.wikipedia.org/wiki/Comparison_of_data_serializati...
- rusk 9y ago
  JSON should only really be used in a machine-to-machine context i.e. for serialization. If you want something that's easily editable with a text-editor then use YAML. XML is horrible for hand-editing, but is easier to read than either YAML or JSON and is super flexible, and has heaps of support in terms of tooling and libraries, and is well understood, so it's great for information interchange. Issues around verbosity aren't a huge issue for machines and again this verbosity is actually helpful when doing data-integration. Concerns about wasting space are spurious since any redundancy in data can easily be done away with with some basic data compression, and as somebody else mentioned, xpath is actually pretty good, and makes the verbosity actually a net positive for certain applications.
djeikyb 9y ago
I think `jq` is more powerful, but for those afflicted with xml instead of json, there is `xmllint`. In a pinch, one can use it to hack something together (along with xpath and xslt).

jandrese 9y ago

JSON and XML aren't really equivalent though. XML is a markup language, JSON is a data serialization format. Of course a lot of hate for XML comes from people trying to use it to serialize data, which it can do but only in a clunky way. JSON is just plain better suited for what most people need.

hyperpallium 9y ago
s/serialization format/object notation/

xelxebar 9y ago

Thank you (and @marcoperaza) for unpacking things a bit. I was mostly unaware of the sideband technologies that go along with the basic tag and attribute structure, and your comments about the community and "guilt by association" got me thinking about library support and other practicalities which I hadn't been considering. Thanks :) This also got me reading up on various structured-data formats: XML, YAML, JSON, TOML, HCL, etc. I'd really like some big table comparing various features but can't seem to find anything of the sort. I found a link [0] that has comparisons between JSON, TOML and YAML representations for various types of data. It's neat to see how each becomes more or less verbose depending on the kind of data getting encoded. [0]: https://gohugohq.com/howto/toml-json-yaml-comparison/ https://gohugohq.com/howto/toml-json-yaml-comparison/ edit: I found a table: https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats https://en.wikipedia.org/wiki/Comparison_of_data_serializati...

rusk 9y ago
JSON should only really be used in a machine-to-machine context i.e. for serialization. If you want something that's easily editable with a text-editor then use YAML. XML is horrible for hand-editing, but is easier to read than either YAML or JSON and is super flexible, and has heaps of support in terms of tooling and libraries, and is well understood, so it's great for information interchange. Issues around verbosity aren't a huge issue for machines and again this verbosity is actually helpful when doing data-integration. Concerns about wasting space are spurious since any redundancy in data can easily be done away with with some basic data compression, and as somebody else mentioned, xpath is actually pretty good, and makes the verbosity actually a net positive for certain applications.

djeikyb 9y ago

I think `jq` is more powerful, but for those afflicted with xml instead of json, there is `xmllint`. In a pinch, one can use it to hack something together (along with xpath and xslt).