XML is a cheap DSL • Hacker News Board

Re: XML is a cheap DSL

#241

Post by pocksuppet » Sat, Mar 14, 2026, 11:42 PM UTC

da_chicken wrote: post #219

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…

I've said it before, but I maintain that XML has only two real problems: 1. Attributes should not exist. They make the document suddenly have two dimensions instead of one, which significantly increases complexity. Anything that could be an attribute should actually be a child element. 2. There should be one close tag: ` ` which closes the last element, which burns a significant amount of space with useless syntax. O…

XML is a Markup Language. The text is what is being marked up, and the attributes are how to mark it up. Try writing the equivalent of Hello world without attributes. I'll wait.

Using XML as a structured data interchange format is abuse. Of course the square peg doesn't fit in the round hole. You propose filing off the corners of the square, making it an octagon, so it will fit the round hole better.

Re: XML is a cheap DSL

#242

Post by pocksuppet » Sat, Mar 14, 2026, 11:45 PM UTC

quotemstr wrote: post #132

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…

> XML supports attributes, namespaces, CDATA, DTDs, QNames, xml:base, xml:lang, XInclude, etc etc. They gave it everything, including the kitchen sink. Ah, the old "throw a bag of nouns at the reader and hope he's intimidated" rhetorical flutist. These things are either non-issues (like QName), things a parser does for you, or optional standards adjacent to XML but not essential to it, e.g. XInclude.

The parser does everything for me. It helpfully loads the external URL in an inline entity definition for me. Oops! All /etc/passwd!

There are two kinds of XML parsers: those which are secure and those which are correct.

Re: XML is a cheap DSL

#243

Post by xorcist » Sat, Mar 14, 2026, 11:49 PM UTC

alexpetros wrote: post #47

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…

Author here. I agree with all this, and I think it's important to note that nothing precludes you from doing a declarative specification that looks like imperative math notation, but it's also somewhat besides the point. Yes, you could make your own custom language, but then you have created the problem that the article is about: You need to port your parser to every single different place you want to use it. That's…

But your XML document also has syntax! You just pushed it up one level of abstraction.

Your proto-math XML dialect of:

instead of:

5-3

still has higher level syntax. What does:

5i

mean? Is it a syntax error? Or does it subtract imaginary numbers? What about exponential notation?

You will have a parser anyway, whether you like it or not. Given that, perhaps "5-3" is the simpler notation after all, even though it requires a specialized (albeit trivial) parser to be carried along with it.

Re: XML is a cheap DSL

#244

Post by jacques_chester » Sun, Mar 15, 2026, 12:15 AM UTC

alexpetros wrote: post #47

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…

Author here. I agree with all this, and I think it's important to note that nothing precludes you from doing a declarative specification that looks like imperative math notation, but it's also somewhat besides the point. Yes, you could make your own custom language, but then you have created the problem that the article is about: You need to port your parser to every single different place you want to use it. That's…

Quick aside, some dutch folks did a more language-y DSL for tax codes, which might be of interest. I don't know if it is still being used, though.

https://resources.jetbrains.com/storage/products/mps/docs/MP...

Re: XML is a cheap DSL

#245

Post by neonstatic » Sun, Mar 15, 2026, 1:34 AM 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…

What do you think about Apache Arrow binary formats in this context?

Re: XML is a cheap DSL

#246

Post by phlakaton » Sun, Mar 15, 2026, 1:59 AM UTC

da_chicken wrote: post #237

phlakaton wrote: post #225

Earlier quoted context omitted.

I disagree on several points here: 1. I think attributes absolutely should exist. They're great for describing metadata related to the tag: e.g. element ID, language, datatype, source annotation, namespacing. They add little in complexity. 2. The point of a close tag with a name is to make it unambiguous what it's trying to close off. It sounds to me like what you want is not a better XML, but just s-exprs. Which is…

> 1. I think attributes absolutely should exist. They're great for describing metadata related to the tag: e.g. element ID, language, datatype, source annotation, namespacing. They add little in complexity. No, they're barely adequate for those purposes. And you could (and if you have a XSD you probably should ) still replace them with elements. If you argue that you can't, then you're arguing that JSON does not func…

1. I don't disagree that attributes have been abused – so have elements – but you yourself identified the right way to use them. Yes, you can inline attributes, but that also leads to a document that's harder to use in some cases. So long as you use them judiciously, it's fine. In actual text markup cases, they're indispensable, as HTML illustrates.

2. As far as JSON Schema, you're wrong on all acounts – wrong that I haven't seen Some Stuff, wrong that JSON schema doesn't get used (see Swagger/OpenAPI), and wrong that XML Schema doesn't also get underitilized when a group of developers get lackadaisical.

3. As far as what historical use has been, I'm less interested in exhuming historical practice than simply observing which of the many use cases over the last 20 years worked well (and still work) and which didn't. The answer isn't that none of them worked, and it certainly isn't that XML users had a better bead on how to use it 20 years ago – it went through a massive hype curve just like a lot of techs do.

4. Regarding tabular data exchange, I stand by my statement. Use XML or JSON if you must, and sometimes you must, but there are better tools for the job.

Re: XML is a cheap DSL

#247

Post by thaumasiotes » Sun, Mar 15, 2026, 2:34 AM UTC

lolive wrote: post #240

Someone1234 wrote: post #180

Earlier quoted context omitted.

And both are poor interchange formats. When things stay in their lane, there is no "problem." When you try to make an interchange format using a language with too many features, or comments that people abuse to add parsable information (e.g. "type information") then there is a BIG problem.

« HTML is a poor interchange format. » - quote of the century -

It caused all kinds of problems, though those tend to be more directly traceable to the "be liberal in what you accept" ethos than to the format per se.

Re: XML is a cheap DSL

#248

Post by pseudohadamard » Sun, Mar 15, 2026, 5:00 AM 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…

Many years ago I worked for a company that did EDI software. When XML was introduced they had to add support for that, just the primitive XML 0.1 that was around at the time with none of the modern complexities. With the same backend code, just switching the parsing, they found either a 100x slowdown in parsing and a 10x increase in memory use or the other way around (so 10x slower, 100x the memory). The functionality was identical, all they did was switch the frontend from EDI to XML.

Since EDI is meant for processing large numbers of transactions as quickly as possible, I hate to think what the move to XML did to that. I moved on years ago so I don't now whether they just threw more hardware at the problem to achieve the same thing that EDI already gave them but now with angle brackets, or whether the industry gave up on XML because of its poor performance.

Come to think of it I'm pretty sure they would have tried blockchain when that got trendy as well.

Re: XML is a cheap DSL

#249

Post by danhite » Sun, Mar 15, 2026, 6:05 AM UTC

pocksuppet wrote: post #241

da_chicken wrote: post #219

Earlier quoted context omitted.

I've said it before, but I maintain that XML has only two real problems: 1. Attributes should not exist. They make the document suddenly have two dimensions instead of one, which significantly increases complexity. Anything that could be an attribute should actually be a child element. 2. There should be one close tag: ` ` which closes the last element, which burns a significant amount of space with useless syntax. O…

XML is a Markup Language. The text is what is being marked up, and the attributes are how to mark it up. Try writing the equivalent of Hello world without attributes. I'll wait. Using XML as a structured data interchange format is abuse. Of course the square peg doesn't fit in the round hole. You propose filing off the corners of the square, making it an octagon, so it will fit the round hole better.

While XML/XHTML aren't spec'ed/evolved to support your fun font sans attribute challenge, certainly modern html does ...

  
  
  @scope { font-family: "Arial" ; }
  
  Prospero: Where in the world is my teapot? Hello? I'm waiting!

I know one could argue that that css rule property is essentially an attribute, but it illustrates, like XML plists[1], that one can define the tags arbitrarily to have their content be meta upon sibling/nested content, subsuming attributes' role.

To wit, it seems to me a style issue.

[1] Apple has long used XML plists for data ~ interchange or even archival storage such as .webarchive (ie just a plist flavor). Of course they soon added a simple binary version to compress out some redundancy and encoding waste.

They used an XML nested tag approach, not attributes. Maybe not well rounded pegs and holes but it has worked for them on a large scale over a long time.

Re: XML is a cheap DSL

#250

Post by pseudohadamard » Sun, Mar 15, 2026, 6:18 AM UTC

eastbound wrote: post #233

conartist6 wrote: post #117

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…

> that decision not to include comments in JSON, but I think while shocking it was and is totally correct. Yaml is fugly, but it emerged from JSON being unsupportive of comments. Now we’re stuck with two languages for configuration of infrastructure, a beautiful one without comments so unusable, the other where I can never format a list correctly on the first try, but comments are ok.

YAML also expanded to add arbitrary scripting via a pile of bolt-on capabilities so that it's now a serialisation language that's Turing-complete, or that includes Turing-complete capabilities within it, everything from:

  command:
    - /bin/sh    
    - -c
    - rm -rf $HOME

to:

  state: >
    {% set foo = states('...') %}
    {% set bar = states('...') %}
    {% if foo == FOO and bar == BAZ %} 
    ...

This makes it damn annoying to work with because everyone's way of doing it is different and since it's not a first-class element you have to rethink everything you want to do into strange patterns to work with how YAML does things.