XML is a cheap DSL • Hacker News Board

Re: XML is a cheap DSL

#161

Post by MarkSweep » Sat, Mar 14, 2026, 4:49 PM UTC

There is a middle ground between using XML and imperative code for representing tax forms. Robert Sesek’s ustaxlib [0] uses JavaScript to encode the forms in a way that is reasonably statically analyzable. See the visualizer [1]. My approach uses XML to represent the forms with an embedded DSL to represent most expressions tersely. See for example Form 8960 in ustaxlib [2] and my TaxStuff program [3]. The main thing that the XML format from the article has going for it is that it is easy to write a parser for. But it is a bit verbose for my taste.

[0]: https://github.com/rsesek/ustaxlib

[1]: https://github.com/rsesek/ustaxviewer

[2]: https://github.com/rsesek/ustaxlib/blob/master/src/fed2019/F...

[3]: https://github.com/AustinWise/TaxStuff/blob/master/TaxStuff/...

Re: XML is a cheap DSL

#162

Post by phlakaton » Sat, Mar 14, 2026, 4:49 PM UTC

SoftTalker wrote: post #104

johnbarron wrote: post #54

Earlier quoted context omitted.

Why did you hardly engaged in the article on the subject of schema driven validation?

I used xml and xpath a lot in the early 2000s when it was popular, and I never wrote or learned about schema validation. It's totally optional and I never found a need for it. It's probably helpful for "standard data interchange between separate parties" use cases, in what I was doing I totally controlled the production and the interpretation of the xml.

For this application, where you might have a lot of authors and apps working with the rule data, I think schema-based validation at some level is going to be a must if you don't want to end in sorrow.

Re: XML is a cheap DSL

#163

Post by phlakaton » Sat, Mar 14, 2026, 4:53 PM UTC

twic wrote: post #100

FWIW you can do a better job with the JSON structure than in the article: {"GreaterOf": [ {"Value": [0, "Dollar"]}, {"Subtract": [ {"Dependency": ["/totalTentativeTax"]}, {"Dependency": ["/totalNonRefundableCredits"]} ]} ]} Basically, a node is an object with one entry, whose key is the type and whose value is an array. It's a rather S-expressiony approach. if you really don't like using arrays for all the contents,…

Aesthetically, I consider such JSON structures degenerate. It's akin to building a ECMAScript app where every class and structure is only allowed to have one member.

If you want tagged data, why not just pick a representation that does that?

Re: XML is a cheap DSL

#164

Post by brabel » Sat, Mar 14, 2026, 4:54 PM UTC

moron4hire wrote: post #77

Someone1234 wrote: post #50

Earlier quoted context omitted.

I keep seeing people make the same mistake as XML made over and over; without learning from it. I will clarify the problem thusly: > The more capabilities you add to a interchange format, the harder that format is to parse. There is a reason why JSON is so popular, it supports so little, that it is legitimately easy to import. Whereas XML supports attributes, namespaces, CDATA, DTDs, QNames, xml:base, xml:lang, XIncl…

I consider CSV to be a signal of an unserious organization. The kind of place that uses thousand line Excel files with VBA macros instead of just buying a real CRM already. The kind of place that thinks junior developers are cheaper than senior developers. The kind of place where the managers brow beat you into working overtime by arguing from a single personal perspective that "this is just how business is done, son…

> The kind of place that thinks junior developers are cheaper than senior developers…

Unless the junior developers start accepting lower salaries once they become senior developers, that is a fact. Do you mean that they think junior developers are cheaper even when considering the cost per output, maybe?

Re: XML is a cheap DSL

#165

Post by elophanto_agent » Sat, Mar 14, 2026, 4:57 PM UTC

[dead]

Re: XML is a cheap DSL

#166

Post by SoftTalker » Sat, Mar 14, 2026, 4:57 PM UTC

thatwasunusual wrote: post #156

SoftTalker wrote: post #121

Earlier quoted context omitted.

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…

A Norwegian "ENK" ("enkeltmannsforetak"; self-employment) deals with a more integrated state reporting environment, stricter cash-sale controls, more emphasis on formal bookkeeping and VAT/cash-register infrastructure, and a more pre-filled tax ecosystem. You can get a long way cheating the system if you deal with cash only, as banks etc. are required to report everything about everyone to the government, but these d…

If you have only W2 income ("W2" is the name of the form the employer reports your income and tax witholding on) and no unusual other credits or deductions, then US tax filing is very simple. It is not much more than:

Taxable income = Total income - Standard deduction

Look up tax due in a table.

Subtract taxes already witheld, pay (or refund) the difference.

In most states you also have to file, but this is normally just transcribing a few totals from your federal filing and then computing the state tax due, normally just a simple percentage multiple.

Re: XML is a cheap DSL

#167

Post by jauntywundrkind » Sat, Mar 14, 2026, 4:58 PM UTC

MarkSweep wrote: post #161

There is a middle ground between using XML and imperative code for representing tax forms. Robert Sesek’s ustaxlib [0] uses JavaScript to encode the forms in a way that is reasonably statically analyzable. See the visualizer [1]. My approach uses XML to represent the forms with an embedded DSL to represent most expressions tersely. See for example Form 8960 in ustaxlib [2] and my TaxStuff program [3]. The main thing…

Also, the IRS open source Direct File and their Fact Graph too. https://news.ycombinator.com/item?id=45599567 https://news.ycombinator.com/item?id=44131901 https://github.com/IRS-Public/direct-file/blob/main/direct-f...

The graph is xml.

Re: XML is a cheap DSL

#168

Post by conartist6 » Sat, Mar 14, 2026, 4:59 PM UTC

Chaosvex wrote: post #159

conartist6 wrote: post #60

Earlier quoted context omitted.

Just gonna drop this here : ) https://docs.bablr.org/guides/cstml CSTML is my attempt to fix all these issues with XML and revive the idea of HTML as a specific subset of a general data language. As you mention one of the major learnings from the success of JSON was to keep the syntax stupid-simple -- easy to parse, easy to handle. Namespaces were probably the feature to get the most rework. In theory it could also r…

I realised the other day that some of my test code has 'jumped' rather than 'jumps' for the intended panagram. Glad to see I'm not alone. :^)

Haha yeah someone pointed that out to me and I decided to leave it. I just needed a sentence, I'm not actually trying to show off every glyph in a font.

Re: XML is a cheap DSL

#169

Post by quotemstr » Sat, Mar 14, 2026, 5:00 PM UTC

conartist6 wrote: post #117

GuB-42 wrote: 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…

No, it was obviously and flagrantly incorrect, as evidenced by the success of interchange formats that do allow for comments, including many real world systems that pragmatically allow comments even when JSON says they shouldn't. This is Stockholm Syndrome.

But what can we expect from a spec that somehow deems comments bad but can't define what a number is?

Re: XML is a cheap DSL

#170

Post by bluebxrry » Sat, Mar 14, 2026, 5:01 PM UTC

bluebxrry wrote: post #106

As someone who knows exactly as much COBOL as everyone else here, XML is what comes out of Java tooling as the handicap for the office that demands Windows tools; of course, it's barbaric. The real crime is sending me this article in HTML, AKA the Super Weenie Hut Jr of generalized markup languages. Adobe FrameMaker is the real text editor used to forge your generalized markup language. Rumor has it that when FrameMa…

Look, my fellow smug lisp weenies, I love Emacs too, but FrameMaker is the standard. If I pay $100 for Times New Roman Pro from Monotype, my DSL is automatically more expensive. I select Times New Roman Pro in Adobe's tools, and it prints it.

Emacs, LuaTeX et al, GhostScript, and PDF take the liberty of upgrading my $100 Times New Roman Pro to Libre New Roman (from the LibreOffice typesetting subsystem) without my consent, and I have to link it using configs like a C library and hope the path environment variable is clobbered together in the right order.

Or you can use the Weenie Hut Junior HTML-V8 infused PDFium, where I basically have to manipulate a tamper-resistant DOM to print a post on most social media sites. Then Chrome uses whatever font it feels like for the timestamp and header. It's almost easier to hardcode my Times New Roman Pro font file into their source code and recompile Chromium, and last time I attempted that, my computer BSOD'd since I forgot only the bourgeoisie can actually use open source, not just look at it.

That's why FrameMaker is the standard generalized markup editor.

Things ahead aren't looking too good, especially after Xerox drivers had that glitch that replaced numbers with different-looking ones. Don't get me started on my recent HP all-in-one fax machine nightmare. Maybe the smug LISP weenie that joked about stapling his s-expr onto the IRS worksheet was right.

If anyone finds this comment, tell my family I died trying to find a way to share the best version of the Times New Roman font for them to read the XML in.