3 ms·

Calling XML human readable is a stretch. It can be with some tooling, but json is easier to read with both tooling and without. There's some level of the schema

by ongy 1y ago

Calling XML human readable is a stretch. It can be with some tooling, but json is easier to read with both tooling and without. There's some level of the schema being relevant to how human readable the serialization is, but I know significantly fewer people that can parse an XML file by sight than json. Efficient is also... questionable. It requires the full turing machine power to even validate iirc. (surely does to fully parse). by which metric is XML efficient?

bayindirh 1y ago
By efficiency, I mean it's text and compresses well. If we mean speed, there are extremely fast XML parsers around see this page [0] for state of the art. For hands-on experience, I used rapidxml for parsing said 3D object files. A 116K XML file is parsed instantly (the rapidxml library's aim is to have speed parity with strlen() on the same file, and they deliver). Converting the same XML to my own memory model took less than 1ms including creation of classes and interlinking them. This was on 2010s era hardware (a 3rd generation i7 3770K to be precise). Verifying the same file against an XSLT would add some milliseconds, not more. Considering the core of the problem might took hours on end torturing memory and CPU, a single 20ms overhead is basically free. I believe JSON and XML's readability is directly correlated with how the file is designed and written (incl. terminology and how it's formatted), but to be frank, I have seen both good and bad examples on both. If you can mentally parse HTML, you can mentally parse XML. I tend to learn to parse any markup and programming language mentally so I can simulate them in my mind, but I might be an outlier. If you're designing a file format based on either for computers only, approaching Perl level regular expressions is not hard. Oops, forgot the link: [0]: https://pugixml.org/benchmark.html https://pugixml.org/benchmark.html
StopDisinfo910 1y ago
> Calling XML human readable is a stretch. That’s always been the main flaw of XML. There are very few use case where you wouldn’t be better served by an equivalent more efficient binary format. You will need a tool to debug xml anyway as soon as it gets a bit complex.
- bayindirh 1y ago
  A simple text editor of today (Vim, KATE) can real-time sanity check an XML file. Why debug?
  - StopDisinfo910 1y ago
    Because issue with XML are pretty much never sanity check. After all XML is pretty much never written by hand but by tools which will most likely produce valid xml. Most of the time you will actually be debugging what’s inside the file to understand why it caused an issue and find if that comes from the writing or receiving side. It’s pretty much like with a binary format honestly. XML basically has all the downside of one with none of the upside.
    - bayindirh 1y ago
      I mean, I found it pretty trivial to write parsers for my XML files, which are not simple ones, TBH. The simplest one of contains a bit more than 1700 lines. It's also pretty easy to emit, "I didn't find what I'm looking for under $ELEMENT" while parsing the file, or "I expected a string but I got $SOMETHING at element $ELEMENT". Maybe I'm distorted because I worked with XML files more than decade, but I never spent more than 30 seconds while debugging an XML parsing process. Also, this was one of the first parts I "sealed" in the said codebase and never touched it again, because it worked, even if the coming file is badly formed (by erroring out correctly and cleanly).
      - StopDisinfo910 1y ago
        > It's also pretty easy to emit, "I didn't find what I'm looking for under $ELEMENT" while parsing the file, or "I expected a string but I got $SOMETHING at element $ELEMENT". I think we are actually in agreement. You could do exactly the same with a binary format without having to deal with the cumbersomeness of xml which is my point. You are already treating xml like one writing errors in your own parsers and "sealing" it. What’s the added value of xml then?
int_19h 1y ago
It's kinda funny to see "not human readable" as an argument in favor of JSON over XML, when the former doesn't even have comments.
- queenkjuul 1y ago
  And yet, it's still easier for me to parse with my eyes

by ongy 1y ago

bayindirh 1y ago

By efficiency, I mean it's text and compresses well. If we mean speed, there are extremely fast XML parsers around see this page [0] for state of the art. For hands-on experience, I used rapidxml for parsing said 3D object files. A 116K XML file is parsed instantly (the rapidxml library's aim is to have speed parity with strlen() on the same file, and they deliver). Converting the same XML to my own memory model took less than 1ms including creation of classes and interlinking them. This was on 2010s era hardware (a 3rd generation i7 3770K to be precise). Verifying the same file against an XSLT would add some milliseconds, not more. Considering the core of the problem might took hours on end torturing memory and CPU, a single 20ms overhead is basically free. I believe JSON and XML's readability is directly correlated with how the file is designed and written (incl. terminology and how it's formatted), but to be frank, I have seen both good and bad examples on both. If you can mentally parse HTML, you can mentally parse XML. I tend to learn to parse any markup and programming language mentally so I can simulate them in my mind, but I might be an outlier. If you're designing a file format based on either for computers only, approaching Perl level regular expressions is not hard. Oops, forgot the link: [0]: https://pugixml.org/benchmark.html https://pugixml.org/benchmark.html

StopDisinfo910 1y ago

> Calling XML human readable is a stretch. That’s always been the main flaw of XML. There are very few use case where you wouldn’t be better served by an equivalent more efficient binary format. You will need a tool to debug xml anyway as soon as it gets a bit complex.

bayindirh 1y ago
A simple text editor of today (Vim, KATE) can real-time sanity check an XML file. Why debug?
- StopDisinfo910 1y ago
  Because issue with XML are pretty much never sanity check. After all XML is pretty much never written by hand but by tools which will most likely produce valid xml. Most of the time you will actually be debugging what’s inside the file to understand why it caused an issue and find if that comes from the writing or receiving side. It’s pretty much like with a binary format honestly. XML basically has all the downside of one with none of the upside.
  - bayindirh 1y ago
    I mean, I found it pretty trivial to write parsers for my XML files, which are not simple ones, TBH. The simplest one of contains a bit more than 1700 lines. It's also pretty easy to emit, "I didn't find what I'm looking for under $ELEMENT" while parsing the file, or "I expected a string but I got $SOMETHING at element $ELEMENT". Maybe I'm distorted because I worked with XML files more than decade, but I never spent more than 30 seconds while debugging an XML parsing process. Also, this was one of the first parts I "sealed" in the said codebase and never touched it again, because it worked, even if the coming file is badly formed (by erroring out correctly and cleanly).
    - StopDisinfo910 1y ago
      > It's also pretty easy to emit, "I didn't find what I'm looking for under $ELEMENT" while parsing the file, or "I expected a string but I got $SOMETHING at element $ELEMENT". I think we are actually in agreement. You could do exactly the same with a binary format without having to deal with the cumbersomeness of xml which is my point. You are already treating xml like one writing errors in your own parsers and "sealing" it. What’s the added value of xml then?

int_19h 1y ago

It's kinda funny to see "not human readable" as an argument in favor of JSON over XML, when the former doesn't even have comments.

queenkjuul 1y ago
And yet, it's still easier for me to parse with my eyes