Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The lost art of XML

marcosmagueta.com

Post reply on HN
Print view View original

171–179 of 179 posts

Re: The lost art of XML

#171

Post by imtringued »

in_a_society wrote: post #13

Smells like an article from someone that didn’t really USE the XML ecosystem. First, there is modeling ambiguity, too many ways to represent the same data structure. Which means you can’t parse into native structs but instead into a heavy DOM object and it sucks to interact with it. Then, schemas sound great, until you run into DTD, XSD, and RelaxNG. Relax only exists because XSD is pretty much incomprehensible. Then…

SOAP is the biggest mindfuck I've ever interacted with. You have a complex and verbose XML based format where you repeat the tag name, but then you realize that the implementations don't care what the parameters are named and just read them in a fixed order. Coming from JSON based APIs this took me extremely long to realize.

Re: The lost art of XML

#172

Post by imtringued »

EdwardDiego wrote: post #138
pjmlp wrote: post #83

Earlier quoted context omitted.

I used it, and agree 100% with the author. Hence why in 2026, I still hang around programming stacks, like Java and .NET, where XML tooling is great, instead of having to fight with YAML format errors, Norway error, or JSON without basic stuff like comments.

> YAML format errors This is why I hate (HATE. LET ME TELL YOU HOW MUCH I'VE COME TO HATE YAML SINCE I BEGAN TO WORK WITH K8S) working with Helm charts. As an example from the Helm docs... https://helm.sh/docs/chart_template_guide/yaml_techniques#in... > Note how we do the indentation above: indent 2 tells the template engine to indent every line in "myfile.txt" with two spaces. Note that we do not indent that templa…

YAML is meant to be written by humans. If some lunatic insists on some expression evaluation system, then it should be ${expression} where the YAML file is parsed as is without a template, and the software that reads the YAML file interprets the expression.

If you hate YAML instead of Helm for their insane choices, then enjoy barking at the wrong tree for the rest of your life.

I've been using application.yml files for 9 years without experiencing a single YAML related issue and I see no reason to switch to any other format.

https://www.baeldung.com/spring-boot-yaml-vs-properties

Re: The lost art of XML

#174

Post by EdwardDiego »

imtringued wrote: post #172
EdwardDiego wrote: post #138

Earlier quoted context omitted.

> YAML format errors This is why I hate (HATE. LET ME TELL YOU HOW MUCH I'VE COME TO HATE YAML SINCE I BEGAN TO WORK WITH K8S) working with Helm charts. As an example from the Helm docs... https://helm.sh/docs/chart_template_guide/yaml_techniques#in... > Note how we do the indentation above: indent 2 tells the template engine to indent every line in "myfile.txt" with two spaces. Note that we do not indent that templa…

YAML is meant to be written by humans. If some lunatic insists on some expression evaluation system, then it should be ${expression} where the YAML file is parsed as is without a template, and the software that reads the YAML file interprets the expression. If you hate YAML instead of Helm for their insane choices, then enjoy barking at the wrong tree for the rest of your life. I've been using application.yml files f…

Did you miss this bit in my comment?

> That said, Helm's approach of "YAML, but with Go templating" is the main source of my hatred

Re: The lost art of XML

#175

Post by imtringued »

_heimdall wrote: post #69
locknitpicker wrote: post #52

Earlier quoted context omitted.

Your comment doesn't sound well researched or thought all the way through. REST by definition is used nowhere at all, and virtually all RESTful APIs are RPC-over-HTTP that are loosely inspired in REST. There is virtually zero scenarios where anyone at all ever said "This thing we're using JSON for would be easier if we just used XML". JSON was the undisputed winner of a competition that never was in a great part beca…

Your argument isn't researched either, if your metric is based on including sources. You seem to be arguing that REST lost because if you look around today you will only find RPC. I agree. My point wasn't that REST won. Part of my point, though, was that REST lost and the industry has tried multiple times to bolt don't JSON RPC solutions to the same problems REST already addressed. If you would like to see some of th…

Swagger, OpenAPI have nothing to do with REST. In fact, they are the antithesis of REST, because they are the very out of band information that a REST client isn't allowed to depend on. A REST client for a pizza delivery restaurant isn't allowed to know that the "order" action is called "order", because that is out of band information. If the server is replaced by a hotel booking server with a completely different workflow, the client is supposed to continue working.

Only MCP is loosely related to REST and it's because one of the defining characteristics of REST is that the API can be discovered at runtime, which is useful if you have a pseudo human level intelligence such as an LLM, but not if you have a dumb static application that has finite capabilities.

Re: The lost art of XML

#176

Post by imtringued »

hackrmn wrote: post #116

I am one of those people who will call out those patronisingly asserting something like "Oh, god, XML! So happy we could finally evolve past _that_". And yeah, XML wasn't perfect -- people harping on it are literally flogging a dead horse. Had the horse been given a pasture, it would have recovered. Instead we have very tiny pig-horses like JSON and YAML and three dozen other "weekend project candidates to someone's…

JSON and YAML are almost as old as XML (20+ years) so saying "fashion" as a counter argument just makes you look out of touch. XML was fashionable when it came out and arguably, it relied more on its fashion status than JSON or YAML.

Re: The lost art of XML

#177

Post by _heimdall »

imtringued wrote: post #175
_heimdall wrote: post #69

Earlier quoted context omitted.

Your argument isn't researched either, if your metric is based on including sources. You seem to be arguing that REST lost because if you look around today you will only find RPC. I agree. My point wasn't that REST won. Part of my point, though, was that REST lost and the industry has tried multiple times to bolt don't JSON RPC solutions to the same problems REST already addressed. If you would like to see some of th…

Swagger, OpenAPI have nothing to do with REST. In fact, they are the antithesis of REST, because they are the very out of band information that a REST client isn't allowed to depend on. A REST client for a pizza delivery restaurant isn't allowed to know that the "order" action is called "order", because that is out of band information. If the server is replaced by a hotel booking server with a completely different wo…

I was trying to say the same thing - Swagger and OpenAPI were attempts to solve problems that only exist because we didn't stick with REST. We wouldn't have needed Swagger if APIs were discoverable and self documenting.

Re: The lost art of XML

#178

Post by Mikhail_Edoshin »

mkozlows wrote: post #22
in_a_society wrote: post #13

Smells like an article from someone that didn’t really USE the XML ecosystem. First, there is modeling ambiguity, too many ways to represent the same data structure. Which means you can’t parse into native structs but instead into a heavy DOM object and it sucks to interact with it. Then, schemas sound great, until you run into DTD, XSD, and RelaxNG. Relax only exists because XSD is pretty much incomprehensible. Then…

The part where it favorably mentioned namespaces also blew my mind. Namespaces were a constant pain point!

Namespaces give you human readable GUIDs as element names. This is important. I agree their implementation and integration is a bit inconvenient.

Re: The lost art of XML

#179

Post by PantaloonFlames »

mkozlows wrote: post #10

This is performance art, right? The very first bullet point it starts with is extolling the merits of XSD. Even back in the day when XML was huge, XSD was widely recognized as a monstrosity and a boondoggle -- the real XMLheads were trying to make RELAX NG happen, but XSD got jammed through because it was needed for all those monstrous WS-* specs. XML did some good things for its day, but no, we abandoned it for very…

XSD was (is) not so easy to adopt, but I don't agree that it's a monstrosity.

Schema are complicated. XSD is a response to that reality.

The XML ecosystem is messy. But people don't need to adopt everything. Ignore Relax-NG, ignore DTD, use namespaces sparingly, adopt conventions around NOT using attributes. It generally works quite well.

It's a challenge to get comfortable with XSD but once that happens, it's not a monstrosity. Similarly, XSLT. It requires a different way of thinking, and once you get that, you're productive.

Post reply on HN