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

81–90 of 99 posts

Re: Don't Invent XML Languages (2006)

#81

Post by messe »

nocombination wrote: post #77
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…

> Seriously, get rid of YAML, TOML, JSON. We already had INI, XML/XPATH/XSD

I agree with you on YAML/JSON, but isn't TOML more or less INI with more data types and an actual specification?

Re: Don't Invent XML Languages (2006)

#82

Post by c-cube »

michaeljx wrote: post #55
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…

Even in HFT, they use a text based API (FIX)

FIX is old and really not great. Some exchanges are trying to move, or have moved, to things like SBE which is a zero-copy binary format. Of course it also improves performance dramatically. So maybe that's not the best example :-)

Re: Don't Invent XML Languages (2006)

#83

Post by dtech »

nocombination wrote: post #77
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…

The fact that XML External Entity Processing is a category of vulnerability indicates how wrong your comment is. There's a lot of things wrong with XML, mostly that it's hugely complicated and a nightmare to write parsers for. JSON won because all of that complexity wasn't in it nor needed.

Re: Don't Invent XML Languages (2006)

#85

Post by CharlesW »

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 still see people, in 2024, writing new software and using XML as the data format.

Because it's a pragmatic choice with a large, mature, proven ecosystem. (Not that there's anything wrong with TOML for INI-type use cases.)

I think some readers are missing the point of Tim's article. He's not saying "don't use XML" — he's saying "don't invent XML languages…unless you have to".

> "The smartest thing to do would be to find a way to use one of the perfectly good markup languages that have been designed and debugged and have validators and authoring software and parsers and generators and all that other good stuff. Here’s a radical idea: don’t even think of making your own language until you’re sure that you can’t do the job using one of the Big Five: XHTML, DocBook, ODF, UBL, and Atom."

Presumably, he'd recommend using RSS and OPML as well if those fit your use case.

Re: Don't Invent XML Languages (2006)

#88

Post by marcosdumay »

account-5 wrote: post #29

This is less about hating on XML and more about not reinventing the wheel. I quite like XML. Things like xpath make working with it, or getting data from it much easier than JSON; though I love jq syntax and can't wait until it starts being incorporated into languages. I don't even mind xslt provided it's not being over used.

The article makes no point about XML at all, it's really "don't invent languages, unless it's your last hope".

Re: Don't Invent XML Languages (2006)

#89

Post by marcosdumay »

nocombination wrote: post #77
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…

> We already had INI, XML/XPATH/XSD.

INI is not a defined language. TOML is the most popular attempt to define it.

XML doesn't really encode the same information as YAML and JSON. (It encodes more, but what is important, it encodes it differently.)

Exchanging your things on the left with your things on the right is guaranteed to make a day turn bad.

Re: Don't Invent XML Languages (2006)

#90

Post by lelanthran »

quonn wrote: post #73
lelanthran wrote: post #17

Earlier quoted context omitted.

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.

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

For some specific tasks, certainly.

A tool I am developing for myself cripples the input format even more, because the more reduced the input is the easier it is to use for a specific task.

Could I have used a more powerful format? Sure, but then a format that allows too much is harder to use (especially when those extra features aren't needed).

The scope of the input should match the scope of the problem. I was only pointing out that, at the highest level, the format that allows everything is Lisp s-expressions. Everything else is a less-abled form of s-expressions. Some of those formats would have been best served by simply being s-expressions instead (like XML), while others (like JSON) serve a different purpose and don't need all those extra features.

Post reply on HN