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

Don't Invent XML Languages (2006)

tbray.org

Post reply on HN
Print view View original

71–80 of 99 posts

Re: Don't Invent XML Languages (2006)

#71

Post by jeremyjh »

jiggawatts wrote: post #49

I love listening to young developers guess at the history of XML, and why it was "complex" (it wasn't), and then turn around an reinvent that wheel, with every bit of complexity that they just said they didn't like... because it's necessary. So a bit of history from someone who was already developing for over a decade when XML was the new hotness: The before times were bad. Really bad. Everybody and everything had th…

This is an excellent summary and expresses many things I've thought about when these topics come up. I entered industry in 1998 and didn't understand as well what was happening while it was happening, but came to similar conclusions looking back on it.

> I'm a developer used to simply clicking a button in Visual Studio to have it instantly bulk-generate entire API client libraries from a WSDL XML API schema, documentation and all. So when I hear REST people talk about how much simpler JSON is, I have no idea what they're talking about.

One issue with that was a lot of developers never had any understanding of what was actually happening when they used wsdl.exe or the Visual Studio GUI to do that. Funny story: a partner we work with now gave us a SOAP API to consume that just about had to have been developed by one of these idiots. Most of the payload was XML content that fit different schemas depending on the transaction type. They didn't know how to model this properly so they just had a content node whose contents were a string that contained escaped XML; exactly what would happen if you were told to make content dynamic and didn't know anything about XML but only how to use the serialized objects in C#: you have an object with a content property that is a string, and you just put arbitrary XML into that string.

So you'd get these API responses that were clearly formatted SOAP envelope and then Bespoke Envelope and then unreadable gibberish littered with > < etc.

Re: Don't Invent XML Languages (2006)

#72

Post by tootie »

userbinator wrote: post #8

2006, well into the era of XML being the trendy fad that every piece of Serious Business software was supposed to use. Now 18 years later, JSON seems to have displaced it. Personally, I've never found text-based formats to be a good choice for data that humans will rarely need to read or write; I much prefer simple and efficient binary formats, which can be just as extensible without the additional inefficiency and n…

On the flip side, XML is by far the superior choice for documents people will have to read. Paired with XSD it makes it a lot easier to created valid, well-formed documents that conform to expected input. Ideal for anything that isn't required to be transmitted over the wire frequently. Like config files. I feel like we could save the world thousands of hours of head-scratching if things like web server config or deployment descriptors were done in rigorously-defined XML formats instead of made-up formats like Dockerfile.

Re: Don't Invent XML Languages (2006)

#73

Post by quonn »

lelanthran wrote: post #17
otabdeveloper4 wrote: post #4

Earlier quoted context omitted.

XML is a document markup language. As in, articles and books n stuff. How in hell is that comparable to anything "Lisp-syntax"?

Because lisp syntax (s expressions) are a cleaner and terser superset of all markup languages, and even of JSON-like representations. IOW, if you take Lisp expressions, add cosmetic syntactical changes like angle brackets and closing tags, then remove about 90% of functionality and cripple what's left, you'll have XML. Cripple it further and you'll have JSON.

What you call crippling is what makes JSON easy to work with and universally adopted.

Re: Don't Invent XML Languages (2006)

#74

Post by freedomben »

dkersten wrote: post #67

I still see people, in 2024, writing new software and using XML as the data format. I don't have an example offhand, but I recently saw a hobby game engine using XML to store its engine-specific game object/scene data. Personally, I like to use TOML for anything that is likely to also be edited by humans and JSON or binary for something that will only ever be used by machines.

in the Java world? I've seen a couple XMLs on newer software but all from Java ecosystem, where there are substantial libraries in existence and the authors are already super familiar with it to the point where it's basically "free"

Everything else is YAML, JSON, or TOML (especially in the rust world)

Re: Don't Invent XML Languages (2006)

#75

Post by tootie »

jiggawatts wrote: post #49

I love listening to young developers guess at the history of XML, and why it was "complex" (it wasn't), and then turn around an reinvent that wheel, with every bit of complexity that they just said they didn't like... because it's necessary. So a bit of history from someone who was already developing for over a decade when XML was the new hotness: The before times were bad. Really bad. Everybody and everything had th…

Back in 2005-10 era, we used to use stuff like XMLBeans to define an entire, consistent domain model include type constraints (enums, valid integer ranges, regex) in XML and generate code at build-time that we never had to look at. The XSD made sure it would be valid. So many years into the future and things are just worse than that.

Re: Don't Invent XML Languages (2006)

#76

Post by novagameco »

dkersten wrote: post #67

I still see people, in 2024, writing new software and using XML as the data format. I don't have an example offhand, but I recently saw a hobby game engine using XML to store its engine-specific game object/scene data. Personally, I like to use TOML for anything that is likely to also be edited by humans and JSON or binary for something that will only ever be used by machines.

I like to use XML for UI markup, similar to html

Re: Don't Invent XML Languages (2006)

#77

Post by nocombination »

userbinator wrote: post #8

2006, well into the era of XML being the trendy fad that every piece of Serious Business software was supposed to use. Now 18 years later, JSON seems to have displaced it. Personally, I've never found text-based formats to be a good choice for data that humans will rarely need to read or write; I much prefer simple and efficient binary formats, which can be just as extensible without the additional inefficiency and n…

Generally there is misunderstanding of these markups. JSON came along because the JavaScript people found it convenient and more network-efficient (the irony being it's not really). But a million years later followed the schema-validation logic to back-fill deficiencies.

In my opinion, one should go for XML when writing a portable document format of any variety to allow a vast array of schema validators, linters, and so-forth. This makes writing plugins which target a given schema much more portable and easier to write.

It's kind of ridiculous how many times web folks reinvent the wheel. Seriously, get rid of YAML, TOML, JSON. We already had INI, XML/XPATH/XSD.

There's nothing wrong with XML, people are just lazy and so is JSON. It's the lazy, sloppy cousin of XML which was a well-thought-out standard to fill a deficiency in HTML for data.

Honestly though, we should be using something like this: http://openddl.org/

Re: Don't Invent XML Languages (2006)

#78

Post by novagameco »

Sn0wCoder wrote: post #32
mrweasel wrote: post #22

Earlier quoted context omitted.

> I've never found text-based formats to be a good choice for data that humans will rarely need to read or write; A computer may need to read the data millions of times, but humans only need to read it when things goes wrong. If you take the route of using a binary format, then you need to provide a robust set of tools to view, edit, debug that format. It can absolutely work, journald is binary, but has the tooling t…

Gotta agrees here. How many times a day do you get asked what data did your API send to my API? For me it’s daily. Need a format that is logged and able to be displayed in an admin UI somewhere, so a DB query is not needed to prove yes A was sent to you so if A is not in your system, then it’s an issue on the other side. I would not want to debug an API that talked to another API in binary…. I mean XML or JSON is sti…

At my last company we had billions of lines of logs to go through every day. Most logs were in an ELB (Elastic Load Balancer; basically each log was a set of HTTP headers and GET params) format which were dumped to S3. We then used Athena queries to build a timeline of events as they passed through our various microservices. The benefit of Athena is that it's insanely fast to mount on top of S3 logs since it's AWS->AWS and you don't have to download hundreds of megabytes of logs to do your queries

Re: Don't Invent XML Languages (2006)

#79

Post by _a_a_a_ »

userbinator wrote: post #8

2006, well into the era of XML being the trendy fad that every piece of Serious Business software was supposed to use. Now 18 years later, JSON seems to have displaced it. Personally, I've never found text-based formats to be a good choice for data that humans will rarely need to read or write; I much prefer simple and efficient binary formats, which can be just as extensible without the additional inefficiency and n…

Easy human readability is a massive win when you have to diagnose problems.
Post reply on HN