|
|
Log in / Subscribe / Register

Development quotes of the week

[Posted June 2, 2026 by jzb]

Please, drive-by commenters... please, read the commit log yourself, audit the commits yourself, investigate what changes are being made and why, and only complain reply to this topic further if you actually understand the work since the beginning of March. Don't fall into the trap of "Every mention of AI is vibe-slop" because social media told you it must be so.

Are you truly arguing that rsync shouldn't receive fixes for a large number of bugs and identified security flaws? Are you arguing against defence-in-depth hardening aimed at reducing the viable attack surface for bugs not found yet? Are you petitioning to keep a test and release engineering setup that apparently wasn't fit for purpose if these bugs have evaded notice for so long and regressions have slipped through, as mentioned?

— "kaithar" (Worth reading in full)

Last month, on the "xml-dev" mailing list, Elliotte Rusty Harold remarked, on the subject of XML generally: "Count me as one of the people who thinks it's mostly obsolete and ultimately a failed experiment. People don't want or need markup that's designed to make documents easier for computers to read but harder for humans to write."

I replied and here's an expanded version of what I wrote:

Irrespective of the current uptake, and seen as an experiment, XML has been a success. It proved that:

  1. You can have a data interchange format that is radically independent of your computer architecture, operating system, programming language, and application.
  2. The only sane text standard for modern computing is Unicode, which in practice is affordable and reasonably straightforward to use.

Prior to 1996, neither of these things were widely believed. The only "interoperable" data format was ASN.1, which is horrible and lacked quality software support. The resistance to Unicode was significant and widespread, and adoption was disappointing. Today, #1 and #2 above are the (low) bar to entry for any data packaging technology.

— Tim Bray


to post comments

That XML and JSON article…

Posted Jun 4, 2026 7:02 UTC (Thu) by mirabilos (subscriber, #84359) [Link]

… it amuses me to note that one of the errata marked as accepted is factually wrong (slash is allowed in both escaped and unescaped form), and others are wrong from misinformation (the “Unicode codepoint” in the original spec translates as “BMP codepoint, including surrogates; valid surrogate pairs encode an SMP codepoint”). But the page displaying an erratum has no way to respond.

I like XML...

Posted Jun 4, 2026 9:27 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

I actually like XML. It's verbose and clumsy to type, but it's extremely powerful, and the tooling around XML is superb.

Don't believe me? Try to round-trip a YAML file, changing a couple of values and preserving the comments. Go on, I'll wait. Yet it is trivial with XML. JSON doesn't even _support_ comments, so I can't comment out a dependency in NPM's package.json when doing experiments.

We also had XSD schemas that could even sometimes be fetched directly. You could then use these schemas to generate the code for your document model.

Was it _all_ good? No. It was decidedly a technology from the 90-s. It has too _much_ stuff. Like XSDs and DTDs that have a lot of overlap but function differently. There are complications with encodings, BOMs, and other scars of the early Unicode. Oh, and I would just get rid of attributes entirely.

The problem with XML is the M part

Posted Jun 6, 2026 13:35 UTC (Sat) by tau (subscriber, #79651) [Link] (3 responses)

XML and SGML syntaxes are designed for complicated rich text, but XML was mostly used for object serialization and configuration files, which are two tasks where its rich text oriented syntax is an active hindrance. Even for rich text something like Markdown or RST is easier to work with until your rich text starts to have nontrivial semantics attached to it that can't be encoded by just abusing a single punctuation character. Migrating from HTML to XHTML was never going to work because you can never break compatibility with the vast body of existing HTML documents, so the only widespread uses of XML that actually play to its strengths are, I dunno, the file formats for Microsoft Office and LibreOffice?

The problem with XML is the M part

Posted Jun 6, 2026 21:16 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

XML was really the first _sane_ widespread format for cross-language RPC (Remote Procedure Calls). Before XML, there were abominations like CORBA and SUN RPC.

It arguably is still more powerful than many of its replacements. For example, you can encode integer limits for parameters using XSD and validate them in a generic mapping layer. JSON Schema now exists, but it's not used consistently.

The problem with XML is the M part

Posted Jun 7, 2026 9:32 UTC (Sun) by mbunkus (subscriber, #87248) [Link]

There are a lot of very relevant data interchange formats out there in active use in the business world that're based on XML. A lot of the banking world uses it, e.g. for SEPA transactions. Or businesses in at least Germany & France for their electronic invoicing standards (Factur-X/ZUGFeRD). Both mature implementations and new standards. Neither of those types are object serialization, nor configuration files.

Most of it is invisible to the consumer & most coders, but don't think there isn't wide-spread use of XML.

The problem with XML is the M part

Posted Jun 8, 2026 12:33 UTC (Mon) by jpfrancois (subscriber, #65948) [Link]

I would add SVG to the list of XML success.
Generating SVG image programmatically is something I enjoy with for instance python XML API (ElementTree)
It maps very well to the group and layer concepts of Inkscape.

S-Expressions?

Posted Jun 17, 2026 22:05 UTC (Wed) by jch (guest, #51929) [Link] (2 responses)

> Prior to 1996

S-Expressions¹ were designed in 1951, if memory serves.

¹ https://en.wikipedia.org/wiki/S-expression

S-Expressions?

Posted Jun 18, 2026 13:10 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

I think Relational Theory has a lot to answer for. It has single-handedly taught most CS graduates that there is no such thing as a list or an array :-( - the only valid data structure is the set :-(

Most data structures prior to that were probably based on S-Expressions - but because Relational structures were much simpler ("too simple" in Einsteinian terms) Relational swept the board - which is why I can express in a one line query what SQL takes two pages to express!

Okay, I can only think of Hierarchical and MultiValue, but that's two alternatives to Relational, both based on S-Expression style structures, and I'm sure there are more ...

Cheers,
Wol

S-Expressions?

Posted Jun 19, 2026 8:30 UTC (Fri) by taladar (subscriber, #68407) [Link]

More importantly, a lot of these systems have taught people that there is no such thing as sum types even though the world is full of things that are in entirely different states with entire different parameters at different times.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds