Live data from Hacker News

The lost art of XML

marcosmagueta.com

121–130 of 179 posts

Re: The lost art of XML

#121
What I miss the most about the XML ecosystem is the tooling. And I think, this is what most people are sentimental about. There was a time it was so easy to generate contracts using XSDs and it made it easy to validate the data. OpenAPI slowly reaches parity to what I worked with in 2006.

But what I do not miss is the over-engineering that happened in the ecosystem, especially with everything SOAP. Yes, when it worked, it worked. But when it didn’t work, which was often the case when integrating different enterprise systems, then well… lord have mercy on me.

Sometimes I still use XSD to define a schema for clients, because in some areas there’s still better tooling for XML. And it gives me the safety of getting valid input data, if the XML couldn’t be validated.

And in the enterprise world, XML is far from being dead anyways.

Re: The lost art of XML

#122
Comparing the XML ecosystem to JSON is like comparing railroads to bicycles.

The main difference is that with enterprise companies and consultancies pushed complex XML solutions that differentiated them and created a moat (involving developer tools and compliance). JSON has always just been a way to sling data around, with a modicum of sanity. Hence the overbuilt/underbuilt split.

XML saved our axx. We had both internal and external API's with complex objects in JSON which failed constantly with mismatching implementations, causing friction with clients. Switching both to XML with schema solved that forever. But this was for complex B2B. We still used json for trivial web UI interactions.

Re: The lost art of XML

#123

Earlier quoted context omitted.

That doesn't match my memory, though its been a while now! I remember the arguments largely revolving around verbosity and the prevalence of JSON use in browsers. That doesn't mean bandwidth wasn't a consideration, but I mostly remember hearing devs complain about how verbose or difficult to work with XML was.

Your memory is correct. Once compression was applied, the size on the wire was mostly a wash. Parsing costs were often greater but that's at the endpoints.

But one of those endpoints is a client on a mobile phone, which when we started with Internet on mobile devices wasn't a particularly powerful CPU architecture.

Re: The lost art of XML

#124
post #8

XML was abandoned because we realized bandwidth costs money and while it was too late to do anything about how verbose HTML is, we didn't have to repeat the mistake with our data transfer protocols. Even with zipped payloads, it's just way unnecessarily chatty without being more readable.

OK, but XML is a pretty solid format for a lot of other stuff that doesn't necessarily need network transmission.

This is true, but if other formats work for those purposes and also network transmission, they'll start to edge out the alternative of supporting two different protocols in your stack.

Re: The lost art of XML

#125
post #29

I remember spending hours just trying to properly define the XML schema I wanted to use. Then if there were any problems in my XML, trying to decipher horrible errors determining what I did wrong. The docs sucked and where "enterprise grade", the examples sucked (either too complicated or too simple), and the tooling sucked. I suspect it would be fine now days with LLMs to help, but back when it existed, XML was a hu…

There are a lot of good arguments against the XML ecosystem, but "I'm too lazy or dumb to understand it" is not one of them.

It is called DevUx and it is certainly a thing.

If the tooling sucks and the entire ecosystem is hard to understand, people won't adopt a technology.

XML was forced down everyone's throat for a decade! The second something else came along literally everyone who could jumped ship.

Re: The lost art of XML

#126
I think the industry settled on pretty good answers, using lots of XML-like syntax (HTML, JSX) but rarely using XML™.

1. Following Postel's law, don't reject "invalid" third-party input; instead, standardize how to interpret weird syntax. This is what we did with HTML.

2. Use declarative schema definitions sparingly, only for first-party testing and as reference documentation, never to automatically reject third-party input.

3. Use XML-like syntax (like JSX) in a Turing-complete language for defining nested UI components.

Think of UI components as if they're functions, accepting a number of named, optional arguments/parameters (attributes!) and an array of child components with their own nested children. (In many UI frameworks, components literally are functions with opaque return types, exactly like this.)

Closing tags like `` make sense when you're going to nest components 10+ layers deep, and when the closing tag will appear hundreds of lines of code later.

Most code shouldn't look like that, but UI code almost always does, which is why JSX is popular.

Re: The lost art of XML

#127
My favorite quote about XML was something along the lines of:

"XML is a lot like violence. If it's not getting the job done, then you aren't using enough of it."

Re: The lost art of XML

#128
post #40

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…

XML grew from SGML (like HTML did), and it brought from it a bunch of things that are useless outside a markup language. Attributes were a bad idea. Entities were a so-so idea, which became unapologetically terrible when URLs and file references were allowed. CDATA was an interesting idea but an error-prone one, and likely it just did not belong. OTOH namespaces, XSD, XSLT were great, modulo the noisy tags. XSLT was…

I really like Clojure EDN. Its very simply, but adds just enough on-top that make a difference. Namespaces, a few more types and a way to add costume stuff in a reasonable standard way.

Re: The lost art of XML

#129
I def get it, but it just seems like a fight not worth fighting anymore, at least not in the areas I work I guess. I work in my languages' type system first and rely on things like serde when some sort of conversion is necessary. If I suddenly got told to switch from JSON to XML for some upstream API it would be annoying but still firmly in the "solved problem" territory. I guess I'm saying use whatever interchange formats you have to and maintain the primacy of your internal type definitions

I'm sure there are plenty of arenas where this doesn't make as much sense but I suspect it's common

Re: The lost art of XML

#130
post #40

Earlier quoted context omitted.

XML grew from SGML (like HTML did), and it brought from it a bunch of things that are useless outside a markup language. Attributes were a bad idea. Entities were a so-so idea, which became unapologetically terrible when URLs and file references were allowed. CDATA was an interesting idea but an error-prone one, and likely it just did not belong. OTOH namespaces, XSD, XSLT were great, modulo the noisy tags. XSLT was…

Don’t forget the whole DOM vs SAX processing mess. Big documents would routinely kill parsers by running out of Memory. XSLT was cool. Too bad XSL and Apache-FOP never took off.

If-I-Recall-Correctly, it was typically a 10x memory load to open an XML file in a DOM parser. Which could get really ugly, really fast when you were dealing with many files.
Post reply on HN