XML is a cheap DSL

wild_pointer

It's not so cheap, in terms of maintenance and mental load

exabrial

Given that that is had strong schema XSD verification built in, where you can tell in an instant whether or not the document is correct; it’s the right tool for a majority of jobs. My experience has been the people complaining about it were simply not using automated tools to handle it. It’s be like people complaining that “binaries/assembly are too hard to handle” and never using a disassembler.

jgalt212

> Tax logic needs a declarative specification preach. I'm convinced there are cycles in the tax code that can be exploited for either infinite taxes or zero taxes. Can Claude find them?

sgarland

While a great article, I actually found this linked post [0] to be even better, in which the author lays out how so much modern tooling for web dev exists simply because XML lost the browser war. EDIT: obviously, JSON tooling sprang up because JSON became the lingua franca. I meant that it became necessary to address the shortcomings of JSON, which XML had solved. 0: https://marcosmagueta.com/blog/the-lost-art-of-xml/

necovek

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 they make "list" a first class object, and nesting second class (by requiring "end" tags), and have two axes for adding metadata: one being the tag name, another being attributes. So while it is a suitable DSL for many things (it is also seeing new life in web components definition), we are mostly only talking about XML-lookalike language, and not XML proper. If you go XML proper, you need to throw "cheap" out the window. Another comment to make here is that you can have an imperative looking DSL that is interpreted as a declarative one: nothing really stops you from saying that totalOwed = totalTax - totalPayments totalTax = tentativeTaxNetNonRefundableCredits + totalOtherTaxes totalPayments = totalEstimatedTaxesPaid + totalTaxesPaidOnSocialSecurityIncome + totalRefundableCredits means exactly the same as the XML-alike DSL you've got. One declarative language looking like an imperative language but really using "equations" which I know about is METAFONT. See eg. https://en.wikipedia.org/wiki/Metafont#Example (the example might not demonstrate it well, but you can reorder all equations and it should produce exactly the same result).

raverbashing

Honestly let's leave XML in that 90s drawer from where it should have never left

jaen

Or... you could just use a programming language that looks good and has great support for embedded domain-specific languages (eDSL), like Haskell, OCaml or Scala. Or, y'know, use the language you have (JavaScript) properly, eg. add a `sum` abstraction instead of `.reduce((acc, val) => { return acc+val }, 0)`. In particular, the problem of "all the calculations are blocked for a single user input" is solved by eg. applicatives or arrows (these are fairly trivial abstract algebraic concepts, but foreign to most programmers), which have syntactic support in the abovementioned languages. (Of course, avoid the temptation to overcomplicate it with too abstract functional programming concepts.) If you write an XML DSL: 1. You have to solve the problem of "what parts can I parallelize and evaluate independently" anyway. Except in this case, that problem has been solved a long time ago by functional programming / abstract algebra / category-theoretic concepts. 2. It looks ugly (IMHO). 3. You are inventing an entirely new vocabulary unreadable to fellow programmers. 4. You will very likely run into Greenspun's tenth rule if the domain is non-trivial.

baq

XML is better than yaml. …note this doesn’t really say much. Both are terrible.

sdovan1

Sometimes I wonder why we need to invent another DSL. (or when should we?) At work, we have an XML DSL that bridges two services. It's actually a series of API calls with JSONPath mappings. It has if-else and goto, but no real math (you can only add 1 to a variable though) and no arrays. Debugging is such a pain, makes me wonder why we don't just write Java.

Decabytes

S-expressions are a cheap dsl too. I use it in my desktop browser runtime that is powered by wasm that I’m developing As the “HTML”^1 and CSS^2 in fact it works so well I use it also reused it to do the styling for html exports in my markup language designed to fight documentation drift^3. 1. https://gitlab.com/canvasui/canvasui-engine/-/blame/main/exa... 2. https://gitlab.com/canvasui/canvasui-engine/-/blob/main/exam... 3. https://gitlab.com/sablelang/libcuidoc

Hackbraten

At the cost of a slightly more complex schema, the JSON representation can be made much more readable: { "path": "/tentativeTaxNetNonRefundableCredits", "description": "Total tentative tax after applying non-refundable credits, but before applying refundable credits.", "maxOf": [ { "const": { "value": 0, "currency": "Dollar" } }, { "subtract": { "from": "/totalTentativeTax", "amount": "/totalNonRefundableCredits" } } ] }

thatwasunusual

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.

librasteve

I have been playing with DSLs a little, here is the kind of syntax that I would choose: invoice "INV-001" for "ACME Corp" item "Hosting" 100 x 3 item "Support" 50 x 2 tax 20% invoice "INV-002" for "Globex" item "Consulting" 200 x 5 discount 10% tax 21% In contrast to XML (even with authoring tools), my feeling is that XML (or any angle-bracket language tbh) is just too hard to write correctly (ie XML syntax and XMl schema parsing is very unforgiving) and has a lot of noise when you read it that obscures the main intent of the DSL code.

cl0ckt0wer

The subtext here is that XML is a powerful tool when generating code with LLMs

mikkupikku

Yeah, but you get what you pay for.

jfengel

It's not a DSL. It's a generic lexer and parser. It takes the text and gives you an abstract syntax tree. The actual DSL is your spec, and the syntax you apply. It's one of many equivalent such parser tools, a particularly verbose one. As such it's best for stuff not written by hand, but it's ok for generated text. It has some advantages mostly stemming from its ubiquity, so it has a big tool kit. It has a lot of (somewhat redundant) features, making it complex compared to other options, but sometimes one of those features really fits your use case.

dale_glass

It kinda blows my mind that after XML we've managed to make a whole bunch of stuff that's significantly worse for any serious usage. JSON: No comments, no datatypes, no good system for validation. YAML: Arcane nonsense like sexagesimal number literals, footguns with anchors, Norway problem, non-string keys, accidental conversion to a number, CODE INJECTION! I don't know why, but XML's verbosity seems to cause such a visceral aversion in a lot of people that they'd rather write a bunch of boring code to make sure a JSON parses to something sensible, or spend a day scratching their head about why a minor change in YAML caused everything to explode. Actually my own problem with XML was annoyance that back when I had the thought of doing a complex config format in XML, the idea of modifying it programmatically while retaining comments turned out to be absolutely non-trivial. In comparison with the mess one can make with YAML that's just a trivial thing.

n_e

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(totalTax, totalPayments)); This way it's a lot terser, you have auto-completion and real-time type-checking. The code that processes the graph will also be simpler as you don't have to parse the XML graph and turn it into something that can be executed. And if you still need XML, you can generate it easily.

LastTrain

This looks fun but I’d rather have the free direct filing service they discontinued.

Sharlin

> It evokes memories of SOAP configs and J2EE (it’s fine, even good, if those acronyms don’t mean anything to you). Heh, a couple of years ago I walked past a cart of free-to-take discards at the uni, full of thousand-page tomes about exciting subjects like SOAP, J2EE and CORBA. I wonder how many of the current students even recognized any of those terms.