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

31–40 of 99 posts

Re: Don't Invent XML Languages (2006)

#31

Post by lolive »

lolive wrote: post #28
greenyoda wrote: post #7

Another standardized XML language that the article doesn't mention is RDF: https://en.wikipedia.org/wiki/Resource_Description_Framework

FYI, RDF transports graph data, where nodes MUST have a unique ID, where relationships MUST be typed, and nodes can optionally be typed. RDF has several serializtion format, one of them being XML. A binary format also exist. And the most convenient one to generate, read and understand is (imho) Turtle, aka TTL).

I have never understood why RDF (especially TTL) has never become the format of choice for data exchange.

XML and JSON are usually sending connected data (:graphs), and there are very inconvenient at doing that (being tree-structured).

Re: Don't Invent XML Languages (2006)

#32

Post by Sn0wCoder »

mrweasel wrote: post #22
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…

> 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 still better than binary… I love applying for jobs that ask if I know JASON because the answer is always yes when its XML I don’t know anyone by that name

Re: Don't Invent XML Languages (2006)

#34

Post by philipswood »

scoofy wrote: post #23
joshlk wrote: post #9

Side question: when did XML start to loose favour to JSON? Did this happen because of something in particular or was it a gradual transition?

When I was writing an xbrl-to-json library I suddenly realized that they are not perfectly transferable. XML comes from spreadsheets, and so it was the first mover. Whereas json came from key-value pairs. I think key-value pairs are much easier to picture in your mind, and for the vast majority of work people are doing, it's just simpler. I think XML is wildly complicated for simply APIs.

XML comes from spreadsheets?

Re: Don't Invent XML Languages (2006)

#35

Post by rlv-dan »

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…

A problem with binary formats is not now, it's tomorrow when tools have changed and documentation is lost (if there ever was any).

Re: Don't Invent XML Languages (2006)

#36

Post by lolive »

joshlk wrote: post #9

Side question: when did XML start to loose favour to JSON? Did this happen because of something in particular or was it a gradual transition?

JSON can be translated into a structure of arrays, maps and primitive types. It can be traversed with functional programming.

That matches 100% the skillset/mindset of developpers.

Whereas XML has too many quirks and tricks, that it requires a dedicated API [aka DOM API] that you must learn and master.

XPath is the tool of choice for XML traversal. VERY versatile and super readable, but it cannot beat the ultimate flexibility of the functional programming.

Re: Don't Invent XML Languages (2006)

#37

Post by eggdaft »

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…

The Pragmatic Programmer explains why plain text is the way to go.

Biggest issue with binary is the difficulty reading / manipulating it long-term.

Re: Don't Invent XML Languages (2006)

#39

Post by lolive »

rosywoozlechan wrote: post #19
joshlk wrote: post #9

Side question: when did XML start to loose favour to JSON? Did this happen because of something in particular or was it a gradual transition?

JSON is basically a subset of JavaScript. Parsing XML sucks, everyone rolled their own RSS and it was basically a nightmare having to deal with invalid XML. JSON has always been really strict and simple. If JavaScript in a browser couldn't parse it it just didn't work. libxml was also a nightmare, XSLT pages looked terrible and honestly there where just a lot of bad XML ideas out there despite gems like SVG. SOAP was…

Funnily I use Javascript in Chrome to deal with XML data. And the support of X[HT]ML is still top-notch.

Re: Don't Invent XML Languages (2006)

#40

Post by simpaticoder »

If you squint at XML, JSON, or YAML you see a kind of lispy data-structure shape, an n-arry tree. The reader has a context stack that they are pushing and popping from as they read. The real problem is that every problem space is isomorphic to one that has successively tighter context. And a format that is applicable to every problem is one that is applicable to no problem. I believe that computer languages must get worse at some things to get better at others in a zero-sum way. Any attempt to avoid this trade-off leaves you with a very powerful mush.
Post reply on HN