XML is a Cheap DSL

2026-03-13T00:00:00+00:00
Yesterday, the IRS announced the release</a> of the project I’ve been engineering leading since this summer, its new Tax Withholding Estimator</a> (TWE). Taxpayers enter in their income, expected deductions, and other relevant info to estimate what they’ll owe in taxes at the end of the year, and adjust the withholdings on their paycheck. It’s free, open source, and, in a major first for the IRS, open for public contributions</a>.
TWE is full of exciting learnings about the field of public sector software. Being me, I’m going to start by writing about by far the driest one: XML.
(I am writing this in my personal capacity, based on the open source release, not in my position as a federal employee.)
XML is widely considered clunky at best, obsolete at worst. It evokes memories of SOAP configs and J2EE (it’s fine, even good, if those acronyms don’t mean anything to you). My experience with the Tax Withholding Estimator, however, has taught me that XML absolutely has a place in modern software development, and it should be considered a leading option for any cross-platform declarative specification.
The Fact Graph</a></h2>
TWE is a static site generated from two XML configurations. The first of these configs is the Fact Dictionary, our representation of the US Tax Code; the second will be the subject of a later blog post.
We use the Fact Graph, a logic engine, to calculate the taxpayer’s tax obligations (and their withholdings) based on the facts defined in the Fact Dictionary. The Fact Graph was originally built for IRS Direct File</a> and now we use it for TWE. I’m going to introduce you to the Fact Graph the way that I was introduced to it: by ~~fire</s> example.~~
~~Put aside any preconceptions you might have about XML for a moment and ask yourself what this fact describes, and how well it describes it.~~
<</span>Fact</span> path</span>="</span>/totalOwed</span>"></span></span>
  <</span>Derived</span>></span></span>
    <</span>Subtract</span>></span></span>
      <</span>Minuend</span>></span></span>
        <</span>Dependency</span> path</span>="</span>/totalTax</span>"/></span></span>
      </</span>Minuend</span>></span></span>
      <</span>Subtrahends</span>></span></span>
        <</span>Dependency</span> path</span>="</span>/totalPayments</span>"/></span></span>
      </</span>Subtrahends</span>></span></span>
    </</span>Subtract</span>></span></span>
  </</span>Derived</span>></span></span>
</</span>Fact</span>></span></span></code></pre>
This fact describes a /totalOwed</code> value that’s derived by subtracting /totalPayments</code> from /totalTax</code>.
In tax terms, this is the amount you will need to pay the IRS at the end of the year.
That amount, “total owed,” is the difference between the total taxes due for your income (“total tax”) and the amount you’ve already paid (“total payments”).</p>
My initial reaction to way of representing taxes was that it’s quite verbose, but also reasonably clear.
That’s more or less how I still feel.</p>
You only need to look at a few of these to intuit the structure.
Take the refundable credits calculation, for example.
A refundable credit is a tax credit that can lead to a negative tax balance—if you qualify for more refundable credits than you owe in taxes, the government just gives you some money.
TWE calculates the total value of refundable credits by adding up the values of the Earned Income Credit, the Child Tax Credit (CTC), American Opportunity Credit, the refundable portion of the Adoption Credit, and some other stuff from the Schedule 3.</p>

  This blog is about programming interfaces and paradigms, but the application is about taxes.
  So yes, this section is going to involve a lot of talk about taxes.
</aside>
<</span>Fact</span> path</span>="</span>/totalRefundableCredits</span>"></span></span>
  <</span>Description</span>></span></span>
    Form 1040 Line 32. Schedule 3 Line 15 + EITC,ACTC, AOTC,</span></span>
    refundable portion of Adoption</span></span>
  </</span>Description</span>></span></span>
  <</span>Derived</span>></span></span>
    <</span>Add</span>></span></span>
      <</span>Dependency</span> path</span>="</span>/earnedIncomeCredit</span>"/></span></span>
      <</span>Dependency</span> path</span>="</span>/additionalCtc</span>"/></span></span>
      <</span>Dependency</span> path</span>="</span>/americanOpportunityCredit</span>"/></span></span>
      <</span>Dependency</span> path</span>="</span>/adoptionCreditRefundable</span>"/></span></span>
      <</span>Dependency</span> path</span>="</span>/schedule3OtherPaymentsAndRefundableCreditsTotal</span>"/></span></span>
    </</span>Add</span>></span></span>
  </</span>Derived</span>></span></span>
</</span>Fact</span>></span></span></code></pre>
These facts are only lightly edited from the actual facts</a> in TWE.
I just removed some descriptions and placeholders.
This is real code that's handling real complexity.
</aside>
By contrast, non-refundable tax credits can bring your tax burden down to zero, but won’t ever make it negative.
TWE models that by subtracting non-refundable credits from the tentative tax burden while making sure it can’t go below zero,
using the <GreaterOf></code> operator.</p>
<</span>Fact</span> path</span>="</span>/tentativeTaxNetNonRefundableCredits</span>"></span></span>
  <</span>Description</span>></span></span>
    Total tentative tax after applying non-refundable credits, but before</span></span>
    applying refundable credits.</span></span>
  </</span>Description</span>></span></span>
  <</span>Derived</span>></span></span>
    <</span>GreaterOf</span>></span></span>
      <</span>Dollar</span>>0</</span>Dollar</span>></span></span>
      <</span>Subtract</span>></span></span>
        <</span>Minuend</span>></span></span>
          <</span>Dependency</span> path</span>="</span>/totalTentativeTax</span>"/></span></span>
        </</span>Minuend</span>></span></span>
        <</span>Subtrahends</span>></span></span>
          <</span>Dependency</span> path</span>="</span>/totalNonRefundableCredits</span>"/></span></span>
        </</span>Subtrahends</span>></span></span>
      </</span>Subtract</span>></span></span>
    </</span>GreaterOf</span>></span></span>
  </</span>Derived</span>></span></span>
</</span>Fact</span>></span></span></code></pre>
While admittedly very</em> verbose, the nesting is straightforward to follow.
The tax after non-refundable credits is derived by saying “give me the greater of these two numbers: zero, or the difference between tentative tax and the non-refundable credits.”</p>
Finally, what about inputs?
Obviously we need places for the taxpayer to provide information, so that we can calculate all the other values.</p>
<</span>Fact</span> path</span>="</span>/totalEstimatedTaxesPaid</span>"></span></span>
  <</span>Writable</span>></span></span>
    <</span>Dollar</span>/></span></span>
  </</span>Writable</span>></span></span>
</</span>Fact</span>></span></span></code></pre>
Okay, so instead of <Derived></code> we use <Writable></code>.
Because the value is… writable.
Fair enough.
The <Dollar/></code> denotes what type of value this fact takes.
True-or-false questions use <Boolean/></code>, like this one that records whether the taxpayer is 65 or older.</p>
<</span>Fact</span> path</span>="</span>/primaryFilerAge65OrOlder</span>"></span></span>
  <</span>Writable</span>></span></span>
    <</span>Boolean</span>/></span></span>
  </</span>Writable</span>></span></span>
</</span>Fact</span>></span></span></code></pre>
There are some (much) longer facts, but these are a fair representation of what the median fact looks like.
Facts depend on other facts, sometimes derived and sometimes writable, and they all add up to some final tax numbers at the end.
But why encode math this way when it seems far clunkier than traditional notation?</p>
Tax logic needs a declarative specification</a></h2>
Countless mainstream programming languages would instead let you write this calculation in a notation that looks more like normal math.
Take this JavaScript example, which looks like elementary algebra:</p>
const</span> totalOwed = totalTax - totalPayments</span></span></code></pre>
That seems better!
It’s far more concise, easier to read, and doesn’t make you explicitly label the “minuend” and “subtrahend.”</p>
Let’s add in the definitions for totalTax</code> and totalPayments</code>.</p>
const</span> totalTax = tentativeTaxNetNonRefundableCredits + totalOtherTaxes</span></span>
const</span> totalPayments = totalEstimatedTaxesPaid +</span></span>
                      totalTaxesPaidOnSocialSecurityIncome +</span></span>
                      totalRefundableCredits</span></span>
</span>
const</span> totalOwed = totalTax - totalPayments</span></span></code></pre>
Still not too bad.
Total tax is calculated by adding the tax after non-refundable credits (discussed earlier) to whatever’s in “other taxes.”
Total payments is the sum of estimated taxes you’ve already paid, taxes you’ve paid on social security, and any refundable credits.</p>
The problem with the JavaScript representation is that it’s imperative</em>.
It describes actions you take in a sequence, and once the sequence is done, the intermediate steps are lost.
The issues with this get more obvious when you go another level deeper, adding the definitions of all the values that totalTax</code> and totalPayments</code> depend on.</p>
// Total tax calculation</span></span>
const</span> totalOtherTaxes = selfEmploymentTax + additionalMedicareTax + netInvestmentIncomeTax</span></span>
const</span> tentativeTaxNetNonRefundableCredits = Math.</span>max</span>(totalTentativeTax - totalNonRefundableCredits,</span> 0</span>)</span></span>
const</span> totalTax = tentativeTaxNetNonRefundableCredits + totalOtherTaxes</span></span>
</span>
// Total payments calculation</span></span>
const</span> totalEstimatedTaxesPaid =</span> getInput</span>()</span></span>
const</span> totalTaxesPaidOnSocialSecurityIncome = socialSecuritySources</span></span>
  .</span>map</span>(</span>source</span> =></span> source.totalTaxesPaid)</span></span>
  .</span>reduce</span>((</span>acc</span>,</span> val</span>)</span> =></span> {</span> return</span> acc+val },</span> 0</span>)</span></span>
const</span> totalRefundableCredits = earnedIncomeCredit +</span></span>
                               additionalCtc +</span></span>
                               americanOpportunityCredit +</span></span>
                               adoptionCreditRefundable +</span></span>
                               schedule3OtherPaymentsAndRefundableCreditsTotal</span></span>
const</span> totalPayments = totalEstimatedTaxesPaid +</span></span>
                      totalTaxesPaidOnSocialSecurityIncome +</span></span>
                      totalRefundableCredits</span></span>
</span>
// Total owed</span></span>
const</span> totalOwed = totalTax - totalPayments</span></span></code></pre>
We are quickly arriving at a situation that has a lot of subtle problems.</p>

One problem is the execution order.
The hypothetical getInput()</code> function solicits an answer from the taxpayer, which has to happen before the program can continue.
Calculations that don’t depend on knowing “total estimated taxes” are still held up waiting for the user;
calculations that do</em> depend on knowing that value had better be specified after it.</p>

You can't just ask all the questions up top either, because it might not make sense to ask certain questions based on your earlier answers.
The application doesn't need to know your spouse's income if you don't have a spouse or are Married Filing Separately.
</aside>
Or, take a close look at how we add up all the social security income:</p>
const</span> totalTaxesPaidOnSocialSecurityIncome = socialSecuritySources</span></span>
  .</span>map</span>(</span>source</span> =></span> source.totalTaxesPaid)</span></span>
  .</span>reduce</span>((</span>acc</span>,</span> val</span>)</span> =></span> {</span> return</span> acc+val },</span> 0</span>)</span></span></code></pre>
All of a sudden we are really in the weeds with JavaScript.
These are not complicated code concepts—map and reduce are both in the standard library and basic functional paradigms are widespread these days—but they are not tax math concepts.
Instead, they are implementation details.</p>
Compare it to the Fact representation of that same value.</p>
<</span>Fact</span> path</span>="</span>/totalTaxesPaidOnSocialSecurityIncome</span>"></span></span>
  <</span>Derived</span>></span></span>
    <</span>CollectionSum</span>></span></span>
      <</span>Dependency</span> path</span>="</span>/socialSecuritySources/*/totalFederalTaxesPaid</span>"/></span></span>
    </</span>CollectionSum</span>></span></span>
  </</span>Derived</span>></span></span>
</</span>Fact</span>></span></span></code></pre>
This isn’t perfect—the *</code> that represents each social security source is a little hacky—but the meaning is much clearer.
What are the total taxes paid on social security income?
The sum of the taxes paid on each</em> social security income.
How do you add all the items in a collection?
With <CollectionSum></code>.</p>
Plus, it reads like all the other facts; needing to add up all items in a collection didn’t suddenly kick us into a new conceptual realm.</p>
The philosophical difference between these two is that, unlike JavaScript, which is imperative</em>, the Fact Dictionary is declarative</em>.
It doesn’t describe exactly what steps the computer will take or in what order;
it describes a bunch of named calculations and how they depend on each other.
The engine decides automatically how to execute that calculation.</p>

Besides being (relatively) friendlier to read, the most important benefit of a declarative tax model is that you can ask the program how it calculated something.
Per the Fact Graph’s original author, Chris Given</a>:</p>

The Fact Graph provides us with a means of proving that none of the unasked questions would have changed the bottom line of your tax return and that you’re getting every tax benefit to which you’re entitled.</p>
</blockquote>

Suppose you get a value for totalOwed</code> that doesn’t seem right.
You can’t ask the JavaScript version “how did you arrive at that number?” because those intermediate values have already been discarded.
Imperative programs are generally debugged by adding log statements or stepping through with a debugger, pausing to check each value.
This works fine when the number of intermediate values is small;
it does not scale at all for the US Tax Code, where the final value is calculated based on hundreds upon hundreds of calculations of intermediate values.</p>

"The actual problem is that the US Tax Code is too complicated."
Your Nobel is in the mail.
</aside>
With a declarative graph representation, we get auditability and introspection for free, for every single calculation.</p>
Intuit, the company behind TurboTax, came to the same conclusion, and published a whitepaper about their “Tax Knowledge Graph”</a> in 2020.
Their implementation is not open source, however (or least I can’t find it).
The IRS Fact Graph</a> is open source and public domain, so it can be studied, shared, and extended by the public.</p>

Do not use the Tax Withholding Estimator's facts to file your taxes, though.
Those facts are intended for estimating your withholdings.
(It's in the name.)
</aside>
XML is much better at this than JSON</a></h2>
If we accept the need for a declarative data representation of the tax code, what should it be?</p>
In many of the places where people used to encounter XML, such network data transfer and configuration files, it has been replaced by JSON.
I find JSON to be a reasonably good wire format and a painful configuration format, but in neither case would I rather be using XML (although it’s a close call on the latter).</p>
The Fact Dictionary is different.
It’s not a pile of settings or key-value pairs.
It’s a custom language that models a unique and complex problem space.
In programming we call this a domain-specific language, or DSL for short.</p>

People sometimes deride the creation of a DSL as over-engineering.
I'm sure that's true in many cases—this is not one of them.
</aside>
As an exercise, I tried to come up with a plausible JSON representation of the /tentativeTaxNetNonRefundableCredits</code> fact from earlier.</p>
{</span></span>
  "description"</span>: "</span>Total tentative tax after applying non-refundable credits, but before applying refundable credits.</span>",</span></span>
  "definition"</span>: {</span></span>
    "type"</span>: "</span>Expression</span>",</span></span>
    "kind"</span>: "</span>GreaterOf</span>",</span></span>
    "children"</span>: [</span></span>
      {</span></span>
        "type"</span>: "</span>Value</span>",</span></span>
        "kind"</span>: "</span>Dollar</span>",</span></span>
        "value"</span>:</span> 0</span></span>
      },</span></span>
      {</span></span>
        "type"</span>: "</span>Expression</span>",</span></span>
        "kind"</span>: "</span>Subtract</span>",</span></span>
        "minuend"</span>: {</span></span>
            "type"</span>: "</span>Dependency</span>",</span></span>
            "path"</span>: "</span>/totalTentativeTax</span>"</span></span>
        },</span></span>
        "subtrahend"</span>: {</span></span>
          "type"</span>: "</span>Dependency</span>",</span></span>
          "path"</span>: "</span>/totalNonRefundableCredits</span>"</span></span>
        }</span></span>
      }</span></span>
    ]</span></span>
  }</span></span>
}</span></span></code></pre>
This is not a terribly complicated fact, but it’s immediately apparent that JSON does not handle arbitrary nested expressions well.
The only complex data structure available in JSON</a> is an object, so every child object has to declare what kind of object it is.
Contrast that with XML, where the “kind” of the object is embedded in its delimiters.</p>

I'm sure there are more-precise academic terms for what I'm trying to describe here and I would welcome an email pointing me in the direction of relevant scholarship.
</aside>
<</span>Fact</span> path</span>="</span>/tentativeTaxNetNonRefundableCredits</span>"></span></span>
  <</span>Description</span>></span></span>
    Total tentative tax after applying non-refundable credits, but before</span></span>
    applying refundable credits.</span></span>
  </</span>Description</span>></span></span>
  <</span>Derived</span>></span></span>
    <</span>GreaterOf</span>></span></span>
      <</span>Dollar</span>>0</</span>Dollar</span>></span></span>
      <</span>Subtract</span>></span></span>
        <</span>Minuend</span>></span></span>
          <</span>Dependency</span> path</span>="</span>/totalTentativeTax</span>"/></span></span>
        </</span>Minuend</span>></span></span>
        <</span>Subtrahends</span>></span></span>
          <</span>Dependency</span> path</span>="</span>/totalNonRefundableCredits</span>"/></span></span>
        </</span>Subtrahends</span>></span></span>
      </</span>Subtract</span>></span></span>
    </</span>GreaterOf</span>></span></span>
  </</span>Derived</span>></span></span>
</</span>Fact</span>></span></span></code></pre>
I think this XML representation could be improved, but even in its current form, it is clearly better than JSON.
(It’s also, amusingly, a couple lines shorter.)
Attributes and named children give you just enough expressive power to make choices about what your language should or should not emphasize.
Not being tied to specific set of data types makes it reasonable to define your own, such as a distinction between “dollars” and “integers.”</p>
A lot of minor frustrations we’ve all internalized as inevitable with JSON are actually JSON-specific.
XML has comments, for instance.
That’s nice.
It also has sane whitespace and newline handling, which is important when your descriptions are often long.
For text that has any length or shape to it, XML is far more pleasant to read and edit by hand than JSON.</p>
There are still verbosity gains to be had, particularly with switch statements (omitted here out of respect for page length).
I’d certainly remove the explicit “minuend” and “subtrahend,” for starters.</p>
<</span>Fact</span> path</span>="</span>/tentativeTaxNetNonRefundableCredits</span>"></span></span>
  <</span>Description</span>></span></span>
    Total tentative tax after applying non-refundable credits, but before</span></span>
    applying refundable credits.</span></span>
  </</span>Description</span>></span></span>
  <</span>Derived</span>></span></span>
    <</span>GreaterOf</span>></span></span>
      <</span>Dollar</span>>0</</span>Dollar</span>></span></span>
      <</span>Subtract</span>></span></span>
        <</span>Dependency</span> path</span>="</span>/totalTentativeTax</span>"/></span></span>
        <</span>Dependency</span> path</span>="</span>/totalNonRefundableCredits</span>"/></span></span>
      </</span>Subtract</span>></span></span>
    </</span>GreaterOf</span>></span></span>
  </</span>Derived</span>></span></span>
</</span>Fact</span>></span></span></code></pre>
I believe that the original team didn’t do this because they didn’t want the order of the children to have semantic consequence.
I get it, but order is</em> guaranteed in XML and I think the additional nesting and words do more harm then good.</p>
What about YAML? Chris Given again</a>:</p>

whatever you do, don’t try to express the logic of the Internal Revenue Code as YAML</p>
</blockquote>
XML is cheap and universal</a></h2>
Finally, there’s a good case to made that you could build this DSL with s-expressions.
In a lot of ways, this is nicest syntax to read and edit.</p>
(Fact</span></span>
  (Path "</span>/tentativeTaxNetNonRefundableCredits</span>")</span></span>
  (Description "</span>Total tentative tax after applying non-refundable</span></span>
    credits, but before applying refundable credits.</span>")</span></span>
  (Derived</span></span>
    (GreaterOf</span></span>
      (Dollar </span>0</span>)</span></span>
      (Subtract</span></span>
        (Minuend (Dependency "</span>/totalTentativeTax</span>"))</span></span>
        (Subtrahends (Dependency "</span>/totalNonRefundableCredits</span>"))))))</span></span></code></pre>
HackerNews user ok123456 asks</a>: “Why would I want to use this over Prolog/Datalog?”
I’m a Prolog fan</a>!
This is also possible.</p>
fact</span>(</span></span>
  path(</span>"/tentativeTaxNetNonRefundableCredits"</span>),</span></span>
  description(</span>"Total tentative tax after applying non-refundable credits, but before applying refundable credits."</span>),</span></span>
  derived(</span></span>
    greaterOf(</span></span>
      dollar(</span>0</span>),</span></span>
      subtract(</span></span>
        minued(dependency(</span>"/totalTentativeTax"</span>)),</span></span>
        subtrahends(dependency(</span>"/totalNonRefundableCredits"</span>))))))</span></span></code></pre>
My friend Deniz couldn’t help but rewrite it in KDL</a>, a cool thing I had to look up.</p>
fact</span> /</span>tentativeTaxNetNonRefundableCredits</span> {</span></span>
  description</span> """</span></span>
    Total tentative tax after applying non-refundable credits, but before</span></span>
    applying refundable credits.</span></span>
    """</span></span>
  derived</span> {</span></span>
    greater-of</span> {</span></span>
        dollar</span> 0</span></span>
        subtract</span> {</span></span>
          dependency</span> /</span>totalTentativeTax</span></span>
          dependency</span> /</span>totalNonRefundableCredits</span></span>
        }</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>
At least to my eye, all of these feel more pleasant than the XML version.
When I started working on the Fact Graph, I strongly considered proposing a transition to s-expressions.
I even half-jokingly included it in a draft design document.
The process of actually building on top of the Fact Graph, however, taught me something very important about the value of XML.</p>
Using XML gives you a parser and a universal tooling ecosystem for free.</p>
Take Prolog for instance.
You can relate XML to Prolog terms with a single predicate</a>.
If I want to explore Fact Dictionaries in Prolog—or even make a whole alternative implementation of the Fact Graph—I basically get the Prolog representation out of the box.</p>
S-expressions work great in Lisp and Prolog terms work great in Prolog.
XML can be transformed, more or less natively, into anything.
That makes it a great canonical, cross-platform data format.</p>
XML is rivaled only by JSON in the maturity and availability of its tooling.
At one point I had the idea that it would be helpful to fuzzy search for Fact definitions by path.
I’d like to just type “overtime” and see all the facts related to overtime.
Regular searches of the codebase were cluttered with references and dependencies.</p>
This was possible entirely with shell commands I already had on my computer.</p>
cat facts.xml | xpath -q -e '//Fact/@path' | grep -o '/[^"]*' | fzf</span></span></code></pre>
This uses XPath</a> to query all the fact paths, grep</code> to clean up the output, and fzf</code> to interactively search the results.
I solved my problem with a trivial bash one-liner.
I kept going and said: not only do I want to search the paths, I’d like selecting</em> one of the paths to show me the definition.</p>
Easy. Just take the result of the first command, which is a path attribute, and use it in a second XPath query.</p>
path=$(cat facts.xml | xpath -q -e '//Fact/@path' | grep -o '/[^"]*' | fzf)</span></span>
cat facts.xml | xpath -q -e "//Fact[@path=\"$path\"]" | format</span></span></code></pre>
I got a little carried away building this out</a> into a “$0 Dispatch Pattern” script of the kind described by Andy Chu</a>.
(Andy is a blogging icon, by the way.)
I also added dependency search—not only can you query the definition of a fact, but you can go up</em> the dependency chain by asking what facts depend on it.</p>
</video></p>
Try it yourself by cloning the repo</a> and running ./scripts/fgs.sh</code> (you need fzf</code> installed).
The error handling is janky but it’s pretty solid for 60 lines of bash I wrote in an afternoon.
I use it almost daily.</p>
I’m not sure how many people used my script, but multiple other team members put together similarly quick, powerful debugging tools that became part of everyone’s workflow.
All of these tools relied on being able to trivially parse the XML representation and work with it in the language that best suited the problem they were trying to solve, without touching the Fact Graph’s actual implementation in Scala.</p>
The lesson I took from this is that a universal data representation is worth its weight in gold.
There are exactly two options in this category.
In most cases you should choose JSON.
If you need a DSL though, XML is by far the cheapest one, and the cost-efficiency of building on it will empower your team to spend their innovation budget elsewhere.</p>
Thanks to Chris Given</a> and Deniz Akşimşek</a> for their feedback on a draft of this blog.</em></p>
Notes</a></h1>

I had never heard of XPath before 2023, when Deniz figured out an XPath query</a> that made my first htmx PR</a> possible.</li>
Another reason to use XML is that humans who aren’t programmers can read it. They usually don’t like it, but, if you did a good-enough job designing the schema, they can read it in a pinch. Do them a favor and build an alternative view, though. Because you’re using XML, this is pretty easy.</li>
It’s probably just because I’ve started to use it—buy a Jeep Grand Cherokee and suddenly the roadways seem full of them—but lately I have noticed an uptick in XML interest.
Fellow Spring ’24 Recurser</a> Jake Low recently wrote a tool called grex</code></a> which turns XML documents into a flat, line-oriented representation.
Martijn Faassen has been working on a modern XPath and XSLT engine in Rust</a>.</li>
I’m not sure it’s fair to call JSON “lobotomized” but I thought this article</a> was largely correct about the problems XML can solve. The binary format is especially interesting to me.</li>
</ul>
Unplanned Obsolescence

XML is a Cheap DSL

Prolog Basics Explained with Pokémon
