XML is a cheap DSL • Hacker News Board

Re: XML is a cheap DSL

#151

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

conartist6 wrote: post #60

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…

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 unfortunately disagree that your syntax is "stupid-simple." But it highlights an impedance mismatch between XML users and JSON users.

JSON treats text as one of several equally-supported datatypes, and quotes all strings. Great if your data is heavily structured, and text is short and mixed with other types of data. Awful if your data is text.

XML and other SGML apps put the text first and foremost. Anything that's not text needs to be tagged, maybe with an attribute to indicate the intended type. It's annoying to express lots of structured, short-valued data. But it's simple and easy for text markup where the text predominates.

CSTML at first glance seems to fall into the JSON camp. Quoting every string literal makes plenty of sense in JSON, but not in the HTML/text-markup world you seem to want to play in.

Re: XML is a cheap DSL

#152

Post by foltik » Sat, Mar 14, 2026, 4:38 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,…

Agreed. Any language that wants to use the fact graph is going to have to “interpret” the chosen DSL anyways, and JSON is more ubiquitous and far simpler to parse than XML. Also way cheaper in the sense that the article uses it (how many langs can you parse and walk an XML document in off the top of your head? what about JSON?)

To see why JSON is simpler, imagine what the sum total of all code needed to parse and interpret the fact graph without any dependencies would look like.

With XML you’re carrying complex state in hash maps and comparing strings everywhere to match open/close tags. Even more complexity depending on how the DSL uses attributes, child nodes, text content.

With JSON you just need to match open/close [] {} and a few literals. Then you can skim the declarative part right off the top of the resulting AST.

It’s easy to ignore all this complexity since XML libs hide it away, and sure it will get the job done. But like others pointed out, decisions like these pile up and result in latency getting worse despite computers getting exponentially faster.

Re: XML is a cheap DSL

#153

Post by necovek » Sat, Mar 14, 2026, 4:39 PM UTC

Someone1234 wrote: post #50

necovek wrote: 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…

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…

Funnily enough, XML was an attempt to simplify SGML so it is easier to parse (as SGML only ever had one compliant parser, nsgml).

Re: XML is a cheap DSL

#154

Post by catlifeonmars » Sat, Mar 14, 2026, 4:41 PM UTC

n_e wrote: post #142

catlifeonmars wrote: post #131

Earlier quoted context omitted.

Yet. You’re adding one other thing that authors need to keep in mind when developing the product, fixing bugs, and adding features. The fact that the input must be trusted is not an intrinsic part of the business logic, it’s an additional caveat that humans need to remember.

What exactly do the developers need to keep in mind?

Well think about this from a product perspective. A natural extension of this is to be able to simulate tax code that hasn’t been implemented yet. “Bring your own facts” is practically begging to be a feature here.

Re: XML is a cheap DSL

#155

Post by necovek » Sat, Mar 14, 2026, 4:45 PM UTC

PantaloonFlames wrote: post #102

necovek wrote: 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…

Your first counterpoint seems unnecessarily picky. > 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. But the TWE did not embrace all that stuff. It’s not required for its purpose. And to call it “xml lookalike” on that bas…

As discussed in the thread, the author has not dove deep into schema validation, but the org does use it.

Ignoring that part of schema definition and subsequent validation is exactly why it seems "cheap" on the surface.

So, TWE is not using an XML lookalike language, but someone has done the expensive part before the author joined in.

Re: XML is a cheap DSL

#156

Post by thatwasunusual » Sat, Mar 14, 2026, 4:46 PM UTC

SoftTalker wrote: post #121

thatwasunusual wrote: post #21

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…

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 days it can only take you so far.

My understand is that the US is much more depending on self-reporting.

But given that the US has its own industry involving tax reporting, and having lived there myself, I don't believe you when you say it's "simple." ;)

Re: XML is a cheap DSL

#157

Post by phlakaton » Sat, Mar 14, 2026, 4:46 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…

LOL, I chose a Google Sheet and CSV for my current project, and I'm very serious about it. It's a short-term solution, and it fits my needs perfectly.

Re: XML is a cheap DSL

#158

Post by python-b5 » Sat, Mar 14, 2026, 4:46 PM UTC

Someone1234 wrote: post #50

necovek wrote: 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…

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've been working on an XML parser of my own recently and, to be honest, as long as you're fine with a non-validating parser (which are still compliant), it's really not that bad. You have to parse DTDs, but you don't need to actually _do_ anything with them. Namespaces are annoying but they're not in the main spec. CDATA sections aren't all that useful, but they're easy to parse. As far as I'm aware, parsers don't actually need to handle xml:lang/xml:space/etc themselves - they're for use by applications using the parser. Really the only thing that's been particularly frustrating for me is entity expansion.

If you want to support the wider XML ecosystem, with all the complex auxiliary standards, then yes, it's a lot of work, but the language itself isn't that awful to parse. It's a little messy, but I appreciate it at least being well-specified, which JSON is absolutely not.

Re: XML is a cheap DSL

#159

Post by Chaosvex » Sat, Mar 14, 2026, 4:47 PM UTC

conartist6 wrote: post #60

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…

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. :^)

Re: XML is a cheap DSL

#160

Post by necovek » Sat, Mar 14, 2026, 4:48 PM UTC

gchamonlive wrote: post #68

necovek wrote: 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…

That's a strange comment... Cheap here is semantically different from cheap in the article. Here it means "how hard it hits the CPU" and in the article is "how hard it is to specify and widely support your DSL". You also posted a piece of code that the author himself acknowledged that is not bad and ommited the one pathological example where implementation details leak when translating to JavaScript. It just seems li…

Nope, not cheap in my comment means expensive to implement: defining the XML schema, which has been done by someone else, and then using that schema properly, is what makes use of XML expensive (it is a lot of things to learn for more than one engineer in the team).