XML is almost always misused

Re:XML is almost always misused by jeremyjh on Tuesday October 29, 2019 @04:54PM (#21391896)

You aren't responding to the comment here, you are just reasserting the article's position. I'd argue there is not another format that is obviously better for every data storage or exchange use case, or that surpasses all of XML's benefits while minimizing all of its downsides. I don't want to look at XML, but I do understand why it is being used.

[ Parent | on HN ]

Re:XML is almost always misused by gambler on Tuesday October 29, 2019 @06:02PM (#21392572)

Abuse of XML killed it a format. JSON is absolutely shit for semantic markup, and yet developers today routinely use it for documents because "XML is bad". They contrive ridiculous schemes for adding metadata and type information. They use it to generate HTML even when HTML takes less space. Finally, we regressed from XTML to HTML5. Buy-buy namespaces and parsing consistency.

[ Parent | on HN ]

Re:XML is almost always misused by redwall_hp on Tuesday October 29, 2019 @10:53PM (#21394278)

> They use it to generate HTML even when HTML takes less space.

The fact that MobileDoc exists makes me physically ill. Something that can be expressed with one line containing a paragraph element and an italic tag is over a dozen lines of JSON spam.

[ Parent | on HN ]

Re:XML is almost always misused by sedachv on Tuesday October 29, 2019 @09:11PM (#21393737)

SGML being replaced by XML being replaced by JSON is great proof that the idea of progress in tech is at best a myth and at worst a lie.

[ Parent | on HN ]

Re:XML is almost always misused by barberousse on Thursday October 31, 2019 @11:59AM (#21410167)

I mean, the idea of progress in general is barely agreeable outside of recent strides in the physical sciences

[ Parent | on HN ]

Re:XML is almost always misused by myrryr on Tuesday October 29, 2019 @09:11PM (#21393741)

Right, but, if given a choice of what to use, between XML and JSON, I'll pick JSON every time.

XML is a complete mess. Have you SEEN it's spec?

You can put JSONs spec in a single page. XMLs spec, not so much. Hell, most of the XML parsers don't support the spec, and the ones which do, historically have been riddled with security holes.

JSON over XML was simplicity over a crazy spec built by a bunch of companies all wanting to shove their own crazyness into it.

[ Parent | on HN ]

Re:XML is almost always misused by sedachv on Tuesday October 29, 2019 @09:43PM (#21393894)

http://seriot.ch/parsing_json.php

https://en.wikipedia.org/wiki/JSON#Data_portability_issues

XML has XSD and RELAX NG for more than 15 years now. https://json-schema.org/ is still a draft.

[ Parent | on HN ]

Re:XML is almost always misused by Mikhail_Edoshin on Wednesday October 30, 2019 @05:03AM (#21395752)

XML spec is longer than one page, granted, but it's about three times shorter than YAML spec. And XML spec describe not only the XML syntax, but also a basic form of validation (DTD), which include references. Basic XML has only five special symbols (<, >, ', ", and &) and can be parsed in linear time. (Namespaces complicate things somewhat.)

[ Parent | on HN ]

Re:XML is almost always misused by jackcviers3 on Wednesday October 30, 2019 @08:47AM (#21397076)

That's because json's spec isn't complete. It is predicated on the language interpreting it to be able to just eval the structure and work with the data [1]

1. http://seriot.ch/parsing_json.php

[ Parent | on HN ]

Re:XML is almost always misused by alkonaut on Wednesday October 30, 2019 @03:00AM (#21395237)

For a non human-edited data storage or exchange that’s fine. Json is worse for human editable data though. Xml might not be the best alternative there but it beats json for things like small configs.

It’s not as simple as saying “everywhere xml is used, json would be a better choice”.

[ Parent | on HN ]

Re:XML is almost always misused by jackcviers3 on Wednesday October 30, 2019 @08:38AM (#21396998)

Your data storage format shouldn't be human readable. The data transferred over the wire shouldn't be human readable. It should be a binary serialized data format, probably encrypted, definitely compressed.

Yes, storage is cheap. Bandwidth is not. Also, you really don't want a human that intercepts your data to be able to read it. Additionally, your data structue only makes sense in the context of your domain, which usually has been modeled in your program(s) that work in that domain, and thus it will be better if you deserialize it within tools that understand that domain.

If you feel the need for a general purpose deserialization protocol, there are several available - Avro/Protobuf, etc.

Binary encoded data can often be decoded without consuming the entire document. Sax-paparser-like reading requires at least reading an open and a close before the data is useful.

String serialization is a wasteful endeavor. It makes life easy for devs because it takes one less step to read the data in a text editor or log message, but quite often requires hacks to model things like recursive or self-referential data structures, and wastes space by repeating property names constantly for every item within the serialized structure. It's predicated on four of the fallacies of distributed computing, namely - bandwidth is infinite, the network is secure, transport cost is zero, and latency is zero. It is a solution looking for a problem, and because we are lazy, we don't build tools that would make binary serialized formats just as easy to use as json/yaml/xml.

[ Parent | on HN ]