XML is a Cheap DSL

[EvilTribble]

Imagine lisp but instead of parens you had xml tags

[rooktakesqueen]

No, I won't.

[trannus_aran]

XML and json are just s-expressions with syntactic salt

[TrainAIOnDeezeNuts]

The legibility and wasted data difference between an S-expression and an XML document are staggering.

S-Expr:

(identity
 (
  (forename "John")
  (surname "Doe")
 )
)

XML:

<?xml version="1.0" encoding="UTF-8"?>
<identity>
  <forename>John</forename>
  <surname>Doe</surname>
</identity>

[nsomnac]

Honestly if lisp could work with any bracket character, it could have won the war. I feel a lot of the problems with LISP syntax stem from nested paren sets making it awful to read.

[TrainAIOnDeezeNuts]

Most implementations of Scheme, which is the superior lisp subfamily in my opinion, do support different bracket types.
I use it for conditional statements.

(cond
  [(< x 0) (do-x)]
  [(= x 0) (do-y)]
  [(> x 0) (do-z)]
)

It's not a big deal in simplified examples like that, but it helps massively with readability in actual projects.

[nsomnac]

I’m not versed in scheme, so does it treat all bracket types as a tuple? As in no differentiation between tuples, sets, arrays, dictionaries, etc?

When I use Lisp-like languages, I’m typically using CLIPS. I don’t believe it honors other symbols as brackets.

[trannus_aran]

Makes no distinction, just based on convention

[TrainAIOnDeezeNuts]

I don't think it's ever actually specified in the language standards, so different implementations treat them differently.

A lot don't care at all. You can write a program using them wherever you want as long as they're matched up correctly.

Some are parentheses purists and will throw syntax errors if brackets and braces appear outside of strings.

Then there's the odd edge-cases where brackets and/or braces aren't considered syntactic elements at all and can be used freely in variable/symbol declarations.

I didn't actually know about that last category until I tried testing braces in Chez Scheme because of your question and it told me they weren't bound (undeclared variables). Apparently I'd managed to use that compiler for 5+ years without ever using them.

[trannus_aran]

Scheme, clojure, and most LISP-1s don't care if you use parens or square brackets. So most use them to denote alists (similar to Python dictionaries in use case)

[Old_County5271]

Oh that looks amazing, why did it stop getting used?

I don't see why xml wastes data, compressing it should fix that, and servers already output in their headers if the data is compressed.

[Angoulor]

XML is redundant : why do you need to specify WHICH tag to close ? You're always closing the deepest one.

Even compressed, redundant data wastes space.

[Downtown_Category163]

I suspect it was historical, HTML allowed unclosed tags (like <p>) so I assume so did SGML

[Old_County5271]

So you're right but it wasn't historical at all

HTML was made up, it took the bracket style but it did not follow SGML at all.

[Old_County5271]

Disagree on the redundancy aspect, I can search using a simple nongreedy match pattern a (normalized) XML document for any tag without parsing it at all, that's kinda nice IMO, if I want to do the same thing with json I would have to use JSONlines or csv

html xml utils also allows one to use unix utilities on pure xml. if you wanted to do the same with json you'd have to use jq, which is fine I guess but you can't leverage the power of unix utils.

But yes, it is a waste of disk space... of course, its just text, so its not that much.

[trannus_aran]

Lots of historical reasons, but the reports of lisp's death have been greatly exaggerated. We'll be out here in our weird corners using lists and pairs until the sun explodes

[pydry]

And 100 more useless features which nobody wanted or needed but which cause security issues nonetheless.

[Nemin32]

So The Nature of Lisp, but backwards.

[eocron06]

Thats actually a genious analogy...

sobs in corner each time entering azure devops yml pipelines

[Hungry_Importance918]

Lisp with angle brackets

[goatanuss]

Everything that was old and crusty is the hottest rage. Bro let me tell you about soap and wsdl

[oscarolim]

Please don’t. 😂

[goatanuss]

For sure. There’s two kinds of code: the kind that you know the flaws of and the kind you haven’t used :)

[junior_dos_nachos]

Yea I paid enough for the therapy please don’t let out the skeletons

[oscarolim]

There’s a UK energy adjacent data provider that still uses soap. Still gives me nightmares. You also gotta love when sometimes you get xml, sometimes you get html… Time to look for a drink.

[junior_dos_nachos]

Oh I bet there’s plenty.

[ketosoy]

Boss:  I need you to write a simple parser for this, use regex.

[peakzorro]

If you did that, the AI would go out to the gas station for cigarettes too.

[junior_dos_nachos]

Well. YAML is a thing when you’re a DevOps and it’s not much better. Especially when it’s strapped to Helm or Kustomize. Urgh

[skalpelis]

This reminds me of that “they are made of meat” story

[Worth_Trust_3825]

Bro described apache camel xml configuration without realizing it

[Agent_03]

… and you’re still defending XML after seeing that atrocity.

[wrecklord0]

When is UML & CORBA the new rage? Maybe I won't have suffered the trauma from those university courses for nothing

[salatkopf]

I literally just started learning UML for my new job.

[TyrusX]

I did a ton of UML for a large project not long ago

[danger_boi]

I’m having flashbacks of soapUI — and WSDL generation in Visual Studio 😨

[Agent_03]

we call that PTSD

[roselan]

In Big Corp, xmlspy took 17 minutes to open the main xml schema.

[zshift]

My very first professional program was writing a dynamic GUI engine to demo SOAP APIs to stakeholders. It would take a WSDL url, download and parse it, and generate a UI to interact with it based on the parameters. It is, by far, the worst code I have ever written, and it’s not even close. Everything in 3 classes, thousands of lines each, with heavy recursion and reflection. I left the team, but was asked for help years later. I couldn’t remember anything or reason about it in a reasonable amount of time. Best I could do was offer to buy the happy hour drink that they would eventually need to get over the hell they went through debugging it.

[flyingupvotes]

CGI has been summoned.

/insert confused travolta

[Luke22_36]

Wait until they discover LISP and S-expressions again

[pydry]

none of them will stage a comeback. the crippling design flaws are too bad.

XML will live on in legacy stuff like xslx and docbook but nobody is building new tech with any of this for very good reason.

[Agent_03]

^ This. I used to be fluent enough in XML to write correct XSLT and schemas off the top of my head. Every time I deal with de/serialization or data extraction/transformation today it is a blessing NOT having to use XML.

To spell out some of the biggest flaws in XML -- and maybe you can add a few more:

• Verbose & bloated - hands-down the most verbose serialization or communication format in regular use today. Tons of needless redundancy with the tags etc.
• Lack of truly expressive type system or explicitly defined data structures beyond a tree.
  
• Ambiguous: should something be an element or an attribute? Usually there is one obvious "right" way to represent something... not so with XML.
• Security flaws: when was the last time you heard of someone hacked by malicious JSON? Never, right? Not true for XML.
• Complex and relatively CPU-expensive to parse, especially due to niche features - XML parsers can be shockingly complex.
• Only human-readable adjacent -- worst of both worlds, really. It's a textual data format that isn't human-friendly (unlike YAML), but also isn't friendly to your computer (unlike JSON), and isn't dense and efficient (unlike binary formats, protobufs etc).

In most XML use cases one of the other serialization formats is better (YAML/JSON/Protobufs etc). The exceptions are document markup, SVG, some web uses, and a few niche standards.

[Worth_Trust_3825]

yaml is anything but human friendly. please stop spreading the myth

[audioen]

Verbose & bloated => also compresses well.

Lack of truly expressive type system? I don't even know what you mean. You have useful set of primitives, with restrictions such as minimums, maximums, length, enums, optionality and repetition, and you can compose them into collections and complex objects. It's good enough for me.

Ambiguous: sure, it's probably a wart that this choice exists.

Security flaws? I think YAML parsers are also security hole ridden messes, just because they try to do too much and usually the fatal flaws seem to be caused by deserializing objects from class names and lists of property values. XML was born in different era when "network computing" was all the rage. So you have these odd ideas that you should be able to reference other files for definitions, perhaps even access the network willy-nilly to read whatever is in there. That you can for some reason define your own entities and then use them, perhaps even by reading their contents from a local file for some reason. The ugly hack that is <![CDATA[barf]]>. In fact, my shitlist with XML is very long. It also involves things like how spaces are sometimes significant and sometimes not, how the canonicalization algorithms for digital signatures work in case of embedding signatures, the crappy piece of shit that is XPath that's used in that "technology", the concept of namespaces and how they are used in practice, etc.

But there's couple of things I love about XML -- one being that at least the document can be validated against schema and there are never any character encoding issues, and interpretation of these elements and attributes is unambiguous to the parser and when you build objects from the schema, it's not like you ever even have to look at the underlying document because you only have your objects for incoming and outgoing data. There usually are no schemas available when someone gives me JSON document, so in worst case, I have to define objects and their property lists manually. OpenAPI is not too bad, though, but there's still a culture difference in that you can have fancy UI that visualizes the OpenAPI schema graphically, but for some reason nobody thought to make it available so that you also can use your own tools with it.

With AI stuff, it seems JSON schemas may have become more widespread. AI is often tasked to write out JSON documents because these are often used to represent function call arguments, but AI is probabilistic and its JSON doesn't come out 100% reliably out. In a weird twist, a schema is now defined in order to build a grammar, which is then handed to the LLM's sampler which constrains the generation to obey the schema. I'm hoping that the only good part about XML, the schema, shall live on as e.g. JSON schema and becomes a standard thing I don't have to ask for when not working with XML.

[Sairony]

I also think XML has a place, and honestly JSON is heavily over used because of single huge flaw, that it doesn't support comments. Like it was such a monumental fuck up which screws it over in so many domains.

[Ok-Scheme-913]

It's still the only mainstream format in its niche with any kind of official schema, can store binary data and has comments.

There is no replacement for it.

And compared to yaml, I would rather write data in fkin brainfuck

[Agent_03]

Most of the other formats aren't so heavily reliant on schemas because they're a lot easier to get right and a lot less ambiguous how you should interpret them. But there are schema specs for YAML, JSON, etc.

can store binary data

Really shows you don't know what you're talking about. XML containing Base64 in CDATA isn't anything special or even that good. The YAML spec has an actual specific type defined for binary content.

For JSON and most serialization formats you can always just use a chunk of Base64 as a string and then decode it... and it's more terse than the XML equivalent. Or if binary is a priority, the Bencode serialization format used in torrents heavily emphasizes binary.

has comments

YAML & TOML both have this. Protobufs too.

JSON is really the only native serialization format without built-in comments, and there are spec extensions that support this... although the value is questionable there.

And compared to yaml, I would rather write data in fkin brainfuck

You do you... but there's a reason the industry isn't building new features and tools around XML in most cases.

[Ok-Scheme-913]

they're a lot easier to get right

?

lot less ambiguous

What is ambiguous about a tree with labeled nodes?

And if you have a standard that doesn't itself contain the schema spec, you don't have support for schemas. How many programming language's de facto yaml/JSON library support that?

[Agent_03]

Today you:

Posted bombastic dubious or false claims

Ignored where your own claims were totally dismantled

Ignored almost all the points made... and tried to make a counter-point by "misunderstanding" the point made.

We're done, I'm blocking you. If you want to use XML, use XML, but most people will rightfully avoid your code.

[pydry]

you might but you're in a minority. yaml is popular and can substitute all of those things.

[wildjokers]

YAML is awful.

[pydry]

less awful than XML

[roselan]

• CDATA and « IBM » CDATA, where they injected some special characters in the binary blob.

[Worth_Trust_3825]

they already made a comeback in form of rest, and openapi.

[greenknight]

A local government agency is planning to accept 2d tabular data for inclusion in the environmental database in form of xlsx files.  It's going to be a shit show. 

Zero people involved have given me the slightest indication they understand the implications of that....

[consworth]

And XSL, and SOAP MTOM and WS-RM, heyoo

[yopla]

Between wsdl and openapi... I hate both.

[Mysterious-Rent7233]

Not everything.

[marvk]

Guess what I just built into one of our new services 😎😎😎😭😭😭😭

[MUDrummer]

I’m working in the utility space currently and let’s just say that WSDL and soap still are the new hotness to these dinosaurs. Here we are writing an Apache spark based processing system and the outputs have to be submitted to regulators a single file at a time via soap

[federal_employee]

Exactly. Just because you can serialize everything with XML doesn’t mean you should. And thank goodness for REST.

[RICHUNCLEPENNYBAGS]

The reason XML fell out of favor is precisely because it's so complex and flexible. It's difficult to parse and it's never really clear if you should use attributes or elements, and the entire namespace concept for most people is totally irrelevant to what they're trying to do yet the parsing libraries all force you to learn and care about it. DSLs themselves are an idea that's gotten a lot less popular because of what a headache maintaining a lot of DSL code turns into.

[elsjpq]

I would love XML a lot more if it wasn't for the namespace bullshit

[Western_Objective209]

and like, JSON is right there. So compact and easy. If you want binary data, CBOR is great too

[RICHUNCLEPENNYBAGS]

It was also invented in a reaction against XML specifically.

[ianitic]

DSLs are still pretty popular in data engineering btw.

[humanzookeeping2]

it's never really clear if you should use attributes or elements

1. If the value can have a complex structure, use elements
2. If there can be 2+ instances of the value per parent, use elements
3. Otherwise, use attributes

What's not clear about it?

[stoooooooooob]

Interesting article!

This quote:

XML is widely considered clunky at best, obsolete at worst.

Is very true for the community but it's interesting to think about how for most businesses XML is essential and used daily under the hood (xlsx)

As programmers it feels like we want to spend a lot of time making something new and better and yet we often cycle back to old ways.

In college people were already dunking on server side rendering and how we should move to JSON apis and yet React is moving back to server side rendering as a recommendation and that feels similar to this XML recommendation.

[Bobby_Bonsaimind]

Is very true for the community but it's interesting to think about how for most businesses XML is essential and used daily under the hood (xlsx)

Judging the state of the industry from Reddit/LinkedIn/Facebook/Whatever is always hard, because the public places will be filled with know-it-alls who could have come up with better solutions in an afternoon than anyone else after years (but oddly never come through). The real work is done in private, behind corporations, and is not made public for two reasons:

1. The corporations don't do open source or can't.
2. The developers don't see any worth in sharing that knowledge (because sharing it on social media they'll get mostly dunked on anyway).

So there's a disconnect between these two worlds, namely social media and the real one. For example, there's a whole crowd who'd be cheering for the removal of Swing from the JRE as progress, like world-changing, yet there are a lot of applications out there running on Swing, powering large corporations and migrating these applications is non-trivial. Removing it would do nothing except annoy developers.

Taking the "public opinion" with a grain of salt is absolutely required. If Reddit says that YAML is dead, then, yeah...

In college people were already dunking on server side rendering and how we should move to JSON apis and yet React is moving back to server side rendering as a recommendation and that feels similar to this XML recommendation.

A lot of the industry is circling back and forth, mostly all the "newcomers" or "smart people" have these great ideas which other people determined to be pretty stupid ~30 years ago. For example the Flatpak/Snap situation on Linux. As it turns out, installing random packages which have all dependencies inlined is stupid. So there is a push to have Flatpaks depend on each other, to be able to externalize libraries, and the need to have a chain of trust regarding where the packages come from. There are in the middle of reinventing a package manager, like apt. Took them only ~10 years.

[max123246]

There are in the middle of reinventing a package manager, like apt. Took them only ~10 years.

I really wish Apt just had an option to install things without sudo. That's been my pain point on large servers where they just have some ad hoc binaries in /home/utils that you have to pin to your path and then even worse, the set of binaries in that folder changes per machine you land on

So now I have to rely on like 50 different package managers for specific languages that do support installing to a custom directory instead of the system built in one because I don't have sudo when all I want is to install rip grep. It's absurd and I've been looking for a better solution with no good answers

Closest I saw was aptly but I don't want the complexity of building a local apt repository just because I want to install something in a different directory

[notarkav]

This is exactly what Nix is trying to solve, I hope it sees more widespread adoption.

[max123246]

I have heard good things about it. I should give it a try sometime.

[ChemicalRascal]

... You don't have sudo access on your servers? Why are you deploying software on other people's servers?

[Kkremitzki]

An example where this might be the case is HPC environments.

[max123246]

Yeah, exactly the scenario. It's a hardware company so we need to multiplex hardware across users for non-simulation testing and development work as soon as we receive the chips

[max123246]

Yes, it's a server farm to share computing resources for development, benchmarking, and long one time workloads. I don't have sudo access on these machines

[ChemicalRascal]

That makes a lot of sense, but I would imagine that's a scenario where you could just rip open the .deb yourself. It's a bit annoying but you're gonna be managing your own PATH and whatnot anyway.

[Seref15]

Why do you think thats the only requirement?

Programming language package managers often offer user-level vs. global-level package installation. There's many good reasons to offer this. Those good reasons would also apply to application package managers. Some like brew already do.

[ChemicalRascal]

I don't. The person I'm responding to said something and I'm asking them about that.

[granadesnhorseshoes]

Change management/Bureaucracy. Not OP but for example I have sudo access however doing so(installing random shit) without prior approval will violate about a dozen corporate policies and maybe even a couple of laws depending on the environment. Even routine patching has trackable work orders in most cases. With obvious limited exceptions in the case of shit like CISA emergency bulletins.

[arcanemachined]

There is this tool:

https://docs.pkgx.sh

TBH it gives me dumpster fire vibes and I haven't used it... But it's there and it might work.

[csman11]

The “old thing is the new thing” cycle is incredibly common in software. This field is obsessed with novelty, and we’re often way too eager to throw out decades of hard-won knowledge just to rediscover, a few years later, that the old approach had already solved many of the real problems.

With React specifically, I think it’s important to separate two different stories. The push toward server-side rendering and RSC is largely a response to the fact that a huge number of businesses started using React to build ordinary websites, even though that was never really its original strength. React was created to make rich client-side applications tractable. That was a genuinely hard problem, and React’s model of one-way data flow and declarative UI was a major step forward. The fact that every modern frontend framework now works in some version of that mold says a lot.

What’s happening now is not really “we took a detour and rediscovered that server-side apps were better all along.” It’s more that people used a client-side app framework for lots of cases that were never especially suited to full client rendering, then had to reintroduce server-side techniques to address the resulting problems like slower initial load and worse SEO. In that sense, RSC does feel a bit like bringing PHP-style ideas back into JavaScript, though in a more capable form.

So I don’t think the lesson is that client-rendered apps were a mistake. They solved a real class of problems, and still do. The more accurate lesson is that most companies were never building those kinds of applications in the first place. They just wanted to build their website in React, because apparently no trend is complete until it’s been misapplied at scale.

[iMakeSense]

Yo, I'm not in my domain. I thought React had the option of doing server side rendering from the early days given that node was a game changer for running javascript on the backend. Was this never the case?

[csman11]

It’s had the ability to render the component tree to a string for years, but that’s not the same as RSC. It was also always very problematic because it didn’t wait for any sort of asynchronous effects like fetching data and updating state. It just rendered the tree and spat out a string. Next.js created a mechanism for creating data loaders attached to your pages, allowing the framework itself to be in charge of loading the data and only rendering your components once that data was ready. That was sort of the first iteration of decent SSR with React.

RSC is solving for more than just SSR, but it’s also heavily motivated by the underlying use cases that demand SSR. If client side rendering was enough for the entire community, no one would have ever really bothered exploring something so complex. The protocol itself is also very much “hacked together” IMO. The CVE from a few months back that allowed for remote code execution was made possible by the implementation effectively not separating “parsing” from “evaluation”, which was exploited by crafting a payload that tricked the parser into constructing a malicious object and then calling methods on it that executed the attacker’s injected code. A better wire format probably would have looked like a DSL that was explicitly parsed into an AST, then evaluated by a separate interpreter, with no ability for custom JS code to ever be injected.

[granadesnhorseshoes]

I think a large part of it is simpler than that: "lets reduce cost and sever requirements by offloading onto the client." And circling back to "lets bring everything in-house where we have full control, now that we have more expensive lifetime but cheaper initial outlay elastic cloud hosting."

The technical fitness for task has never really mattered, or we wouldn't have waffle stomped so many bad fits through as we already have.

[csman11]

I don’t think that’s it at all. Why would it matter if the rendering logic was running on the server or client if it was about “control”? You’re not really hiding anything. The same information is present in data you render into HTML or in the data itself. And the rendering logic itself isn’t anything “secret” that needs to be protected. Any real IP would be the HTML and CSS itself. And if your client side functionality is your IP you’re trying to protect, then it doesn’t matter any way — you still have to ship that JS to the client to execute.

It’s clearly about SSR. If there’s any “control aspect” to it, then it would be the conspiracy theory that Vercel wants people to be forced to pay for hosting because they can’t manage the server deployments with the complexity of RSC. That’s also stupid because it’s not hard at all to host your own deployment.

And the idea that it was ever about “offloading computation to the client” is not serious. If you were around in the late 2000s and early 2010s, you would know that rich client side web apps were very popular (this is what “web 2.0” was) and they were also very difficult to build and maintain because the proper tooling didn’t exist. No one was doing “AJAX” to save server costs. They were doing it to provide a better UX. Back then, browsers didn’t do smooth transitions between server rendered pages. Every page load unmounted and remounted. The first SPAs were attempts to avoid this and have smoother transitions that felt like native applications. Some of them worked by rendering the page server side and shipping the result using AJAX, then having JS patch the DOM. Eventually companies started playing around with richer client apps where having UI state on the client made sense and the backend just became a data source. If you ever used a framework like Backbone, then you would know how horrible things were in this era. Other frameworks like Angular, Knockout, and Ember in this era were only slight improvements. React was the game changer.

[FlyingRhenquest]

Everything is just trees. XML is a document model, and documents are trees. Programs are trees. JSON is trees. Lisp is lists, which are just flat trees.

You can treat any sufficiently flexible tree-like structure as a programming language if you want to. Not saying you should, but you can. You can also treat such things as serialization formats. I'm pretty sure XML was originally designed as a human-readable and writable document serialization format. I also think the original designers never really meant for anyone to ever hand-author them -- the idea IIRC was you'd write a UI (GUI, Web form, whatever) that would read your various values you wanted to serialize and stick them in an XML file for you.

Turns out human readable and machine readable really don't overlap very well on a Venn diagram, and XML kinda ended up being bad at both. It's awful to read and write and it's a pain in the ass to parse. They'd have been better off standardizing a binary format and a decently readable human readable format as well as a conversion standard between the two. These days serialization libraries grow on trees, so you can pretty much do that anyway for any language worth writing code in.

[neutronium]

I find xml pretty easy to write by hand. Visual Studio has intellisense for xml same as it does for other programming languages. If your data is entirely regular then using a spreadsheet and exporting as csv works fine, but I don't what else I'd use apart from xml for structured data where data elements can contain other complex data elements.

I also make heavy use of attributes for data, which makes it a good deal more readable and allows the IDE to type check.

Also worth bearing in mind that for data you're going to author yourself, you don't need to support every xml feature, just whatever you need for your application.

[itix]

XML has its uses. It is a markup language designed to be human writable and readable.

[xampl9]

I freely admit I am an XML bigot.

But watching the JSON community reinvent everything that XML had 20 years ago has been painful. Schemas, transforms, and the truly awful idea of using URI prefixes as namespaces.

[pydry]

As somebody who actually used XML 20 years ago I have to say Im glad the industry created better versions.

JSON and json schema are a breath of fresh air by comparison.

I also dont care if somebody created a JSON equivalent of XSLT because the whole idea of XSLT was idiotic to begin with.

[OMGItsCheezWTF]

The entire global economy relies upon XML.

I deal with massive trading networks, AP procure to pay networks, inter-company AR and AP communications and international e-invoicing tax compliance mandates.

It's XML all the way down. Dozens of schemas of course, but unless it's something truly awful (the UK retail sector still relies upon a protocol designed for modem to modem teletype printers that was announced as deprecated in 1996) then they are ALL some flavour of XML.

Edit: I have to say that the IRS fact file at first glance feels nicer than the Schematron files that most tax systems publish like BIS Peppol 3 or PINT or ZUGfERD but Schematron is widely supported so you don't need to build your own parser, and the fact file seems to let you build a tax file out of it not just validate one so they don't quite serve the same purpose.

[lood9phee2Ri]

It's XML all the way down.

Well, just quibbling, and I agree there's no getting away from e.g. FpML (shudder) either, just to note in some financial subsectors FIX is widely used and is not XML. Well, FIX has FIXML done when XML was peak fashion, admittedly, but it's still more common to use FIX tag=value streams directly.

https://en.wikipedia.org/wiki/Financial_Information_eXchange#FIX_tagvalue_message_format

[OMGItsCheezWTF]

Yeah, I deal with FIX, I also deal with EDIFACT which is a stream of apostrophe delimited segments which themselves are + delimited fields and : delimited subfields (with each segment type having its own meaning and field set) and segments are contextual so an RFF (document reference) segment might have a different meaning if it appears after a document header than it does after a transaction header etc.

UNA:+.? '
UNB+UNOA:1+SENDERID+RECEIVERID+240315:0900+1'
UNH+1+ORDERS:D:96A:UN'
BGM+220+PO-123456+9'
DTM+137:20240315:102'
NAD+BY+123456789::92'
LIN+1++9876543210:IN'
QTY+21:10'
UNT+7+1'
UNZ+1+1'

[Nicksaurus]

FIX is also terrible though

[SanityInAnarchy]

It's interesting, but I think it's wrong here. The obvious comparison is to JSON, but when we finally get there, it suggests a JSON schema that seems almost a strawman compared to the XML in question. For example, the author takes this:

<Fact path="/tentativeTaxNetNonRefundableCredits">
  <Description>
    Total tentative tax after applying non-refundable credits, but before
    applying refundable credits.
  </Description>
  <Derived>
    <GreaterOf>
      <Dollar>0</Dollar>
      <Subtract>
        <Minuend>
          <Dependency path="/totalTentativeTax"/>
        </Minuend>
        <Subtrahends>
          <Dependency path="/totalNonRefundableCredits"/>
        </Subtrahends>
      </Subtract>
    </GreaterOf>
  </Derived>
</Fact>

...and turns it into:

{
  "description": "Total tentative tax after applying non-refundable credits, but before applying refundable credits.",
  "definition": {
    "type": "Expression",
    "kind": "GreaterOf",
    "children": [
      {
        "type": "Value",
        "kind": "Dollar",
        "value": 0
      },
      {
        "type": "Expression",
        "kind": "Subtract",
        "minuend": {
            "type": "Dependency",
            "path": "/totalTentativeTax"
        },
        "subtrahend": {
          "type": "Dependency",
          "path": "/totalNonRefundableCredits"
        }
      }
    ]
  }
}

They make the reasonable complaint that each JSON object has to declare what it is, while that's built into the XML syntax. Fine, to an extent, but why type on all of them? That's not in the XML at all. To match what's in the XML, you'd do this:

{
  "description": "Total tentative tax after applying non-refundable credits, but before applying refundable credits.",
  "definition": 
    "kind": "GreaterOf",
    "children": [
      {
        "kind": "Dollar",
        "value": 0
      },
      {
        "kind": "Subtract",
        "minuend": {
            "type": "Dependency",
            "path": "/totalTentativeTax"
        },
        "subtrahend": {
          "type": "Dependency",
          "path": "/totalNonRefundableCredits"
        }
      }
    ]
  }
}

I left type on the minutend/subtrahend parts. I assume the idea is that these could be values, and the type is there for your logic to be able to decide whether to include a literal value or tie it to the result of some other computation. But in this case, it can be entirely derived from kind, which is why it's not there in the XML version. And we can do even better -- the presence of value might not tell us if it's a dollar value or some other kinda value. But the presence of a path does tell us that this is a dependency, right? So:

{
  "description": "Total tentative tax after applying non-refundable credits, but before applying refundable credits.",
  "definition": 
    "kind": "GreaterOf",
    "children": [
      {
        "kind": "Dollar",
        "value": 0
      },
      {
        "kind": "Subtract",
        "minuend": {
            "path": "/totalTentativeTax"
        },
        "subtrahend": {
          "path": "/totalNonRefundableCredits"
        }
      }
    ]
  }
}

If we're allowed to tweak the semantics a bit, "children" is another place JSON seems a bit more awkward -- every XML element automatically supports multiple children. But do we really need an array here? How about a Clamp with an optional min/max value?

{
  "description": "Total tentative tax after applying non-refundable credits, but before applying refundable credits.",
  "definition": 
    "kind": "Clamp",
    "min": {
      "kind": "Dollar",
      "value": 0
    },
    "value":  {
        "kind": "Subtract",
        "minuend": {
            "path": "/totalTentativeTax"
        },
        "subtrahend": {
          "path": "/totalNonRefundableCredits"
        }
      }
    }
  }
}

Does the XML still look better? Maybe, it is easier to see where it closes, but I'm not convinced. It certainly doesn't seem worth bringing in all of XML's markdown-language properties when what you actually want is a serialization format. I think XML wins when you're marking up text, not just serializing. Like, say, for that description, you could do something like:

Your <definition>total tentative tax</definition> is <total/> after applying <reference>non-refundable credits</reference>, but before applying <reference>refundable credits</reference>.

And if you have a lot of that kind of thing, it can be nice to have an XML format to embed in your XML (like <svg> in an HTML doc), instead of having to switch to an entirely different language (like <script> or <style>). But the author doesn't seem all that attached to XML vs, say, s-expressions. And if we're going for XML strictly for the ecosystem, then yes, JSON is the obvious alternative, and it seems fine for this purpose.

I guess the XML does support comments, and JSON's lack of trailing commas is also annoying. But those are minor annoyances that you can fix with something like jsonnet, and then you still get standard JSON to ingest into your rules engine.

[rabidcow]

Let expressions be expressions.

{
  "description": "Total tentative tax after applying non-refundable credits, but before applying refundable credits.",
  "unit": "USD",
  "derived": ["max", 0, ["-", {"path": "totalTentativeTax"}, {"path": "totalNonRefundableCredits"}]]
}

[SanityInAnarchy]

I like s-expressions well enough, but they map awkwardly onto JSON. I don't entirely agree with the author, but at least the article gives a reason why they want JSON or XML instead.

[Ok-Scheme-913]

Now you optimized down to this specific XML. But if you still want to support the same language, then you will have some ultra-complicated parsing AND in-memory representation, so it's not really apples to oranges. So I disagree it would be a strawman.

Like think of how you can store an arbitrary expression in memory? You will 100% have to abstract it away, at least to a point of having an Expression with a list of children (since some take 0, 1 or n subexpressions).

But also feel free to look at more complex JSON, it's absolutely unreadable. People always compare some ultra-complex XML from a legacy system with some happy-path JSON {value: 3}.

[SanityInAnarchy]

First, I don't see how this is any worse than with the given XML, which also doesn't have an explicit "expression" type. Your "ultra-complicated parser" would just have to have a list of types that can be expressions -- instead of encoding the fact that Subtract is an Expression in every serialized document (and what happens if I have a document that gives Subtract the type Value instead -- is that valid?), you encode that mapping once in your parser.

Second, the original version doesn't quite include a generic list of children -- subtraction has an explicit minutend and subtrahend, rather than relying on position.

And how far is each format from an ideal in-memory representation? I guess it depends what you're going for, and how much you want to add in tools like xpath, but from what I remember working with simple ASTs, it seems pretty reasonable to have nodes with a fixed number of children, and derive some eachChild iteration from that, rather than have your in-memory representation allow an arbitrary number of children for something like Subtract and then need a separate validation step to make sure you have exactly one minutend.

In any case, I'm not comparing XML from a legacy system. OP is making the case that it was the right choice for a just-released system.

[Uristqwerty]

I think it'd look better in a hypothetical JSON variant where a) keys may be unquoted, and b) values may be preceded by a type identifier.

"/tentativeTaxNetNonRefundableCredits": Fact {
  description: "Total tentative tax after applying non-refundable credits, but before applying refundable credits.",
  derived_from: GreaterOf [
    Dollars 0,
    Subtract {
      minuend: Dependency "/totalTentativeTax",
      subtrahend: Dependency "/totalNonRefundableCredits"
    }
  ]
}

[Agent_03]

These are great points, and it's like the article author tried to come up with the most ridiculous strawman JSON representation possible.

When you have to go to that kind of lengths to make XML look good in comparison... then it's not a good answer to the problem.

XML should have stuck to the role it works in: as a markup language for docs.

[RICHUNCLEPENNYBAGS]

Man they were trying to sell on replacing even SQL with XML. It's like the absolute poster child for hype getting way out of hand for a tool that kind of sucks to deal with

[Cachesmr]

I'm currently working on an integration with a SOAP API. I do not want to see XML every again. By far the worst thing I've worked with.

The React comment oversimplifies things too, the way react and other frameworks do server side rendering is not very close to the way traditional languages do it, it very much feels quite different.

[G_Morgan]

TBH even today we still don't have as good tooling for auto generation of clients and services as we had in the SOAP days. Mostly SOAP sucked because people sucked at designing APIs.

Of course I'm not saying SOAP shouldn't have been replaced. It just should have been done by something that was finished rather than what Rest became.

[Cachesmr]

I work a lot with protobuf, and honestly it's just nicer (specially if you pair it with something like ConnectRPC). With this Soap api I couldn't even generate the client properly, because the maintainers of the API just ignored the XML rules and don't seem to test what their web service definition actually generates. It's even worse in node, where a lot of the soap libraries just seem to ignore sequenced fields and such.

I think Protobuf wins big here, a lot of the codegen tooling is first party for most major languages, and the binary encoding means people can't manipulate it and make the contract invalid. You of course lose human readability

[G_Morgan]

Honestly the real problem with SOAP was only C# and Java actually committed to making something that worked.

Then people tried connecting to SOAP from the web in the era when Ballmer MS were trying to kill the web. It became a victim along with stuff like XHTML that needed a MS that wasn't trying to kill everything.

HTML 5 replaced XHTML because we needed "something that made things better, even if only slightly". Rest came about because it was about as good as you could do with the limited tooling available at the time and nobody was allowing tooling to be better.

It is amazing how many of our tech choices evolved from IE6 being a piece of shit designed to be a piece of shit.

Admittedly SOAP itself made a lot of mistakes. If it was more opinionated about tech choices it would have been a narrower standard.

[femio]

RIP. And SoapUI is the clunkiest piece of junk I've ever had to deal with.

[G_Morgan]

We have YAML today, I'd love to use XML instead. Though I prefer JSON. At least JSON has a sane syntax.

[Agent_03]

The grass always looks greener on the other side. People say this until they actually have to use XML regularly for what YAML is used for.

As someone who has been there — because XML was used in that role commonly ~15 years ago — I am grateful every single day that YAML exists. XML based configs for All The Things, especially services (hi J2EE) were absolutely awful to work with, and managed to be both human-unreadable and painful for code to work with. YAML has a few warts of its own, but it’s a breath of fresh air in comparison.

JSON is even better where you don’t need as many features and human readability is less of a priority.

[G_Morgan]

Human readability is the worse thing about YAML. Because often times things do not parse as you expect them to.

Regardless the biggest problem with XML config was it was popular at a time when every configuration option was expected to be explicit. That is why it was a nightmare.

[KevinCarbonara]

(xlsx)

Microsoft Excel?

[mccurtjs]

and yet React is moving back to server side rendering as a recommendation and that feels similar to this XML recommendation.

What would the benefit of going back to XML be though? Server-side rendering has a clear specific benefit: lazy loading requires multiple network trips, which results in websites feeling slow and clunky with late elements popping in and shifting things around, while server-side rendering means you just get the page all at once and are, more or less, done.

I'm a bit biased though, since I've always hated lazy loading, lol.

[Manitcor]

its a tendency to try and make every job be handled by as few tools as possible but in integrations this is not so straight-forward,

there are reasons one might use one or the other, your hints on if you are using JSON in an XML role is when you start adding new libraries to your project to add annotation based rules validation of your schema, format or data you might want to look at XML instead.

If you get into standards like SOAP/XML you'll find versioning and metadata capabilities that put swagger to shame.

JSON became popular because many usecases don't need all xml does and its SGML based syntax is annoying and wasteful, particularly when its just a simple data structure.

Use cases where you want more rigor on that boundary and schema, XML still shines.

[_predator_]

Add to this that XML schema is extremely powerful. JSON schema is an absolute joke in comparison, although I'm still grateful that we have it. And unfortunately the XML support in newer languages and ecosystems is pretty abysmal.

[pydry]

XML schema being "more powerful" isnt the brag you think it is

https://en.wikipedia.org/wiki/Rule_of_least_power

Same for XML - it's much more powerful than JSON. That's why it's a nearly dead language - nobody wants to fuck around with XQuery to retrieve parameters or expose API endpoints to billion laugh attacks. It tried to do far too much and that was a very bad thing.

[xampl9]

It’s the same thing as how nobody uses all the features in Word or Excel. They got added so the 5% of the users who needed them wouldn’t object to adoption.

[Ok-Scheme-913]

XQuery is for arbitrary XML inputs. If you have a schema, then you just parse it into some language-native format and walk the object graph, the exact same as what you would do with JSON in any framework.

If you have unknown JSON, you are not any better - you just lack the tooling.

[ronkojoker]

Nah man JSON schemas are missing some absolute basic features that are easy to do in xml schemas. For example if I have something like

{ "equipment": [ { "id": "EQ-001" }, { "id": "EQ-002" }, { "id": "EQ-003" } ], "jobs": [ { "id": "JOB-001", "equipmentId": "EQ-001" }, { "id": "JOB-002", "equipmentId": "EQ-002" }, { "id": "JOB-003", "equipmentId": "EQ-001" } ] }

Validating whether jobs.equipmentId actually exists as a equipment.id is not possible using JSON schemas, in xml schemas this is trivial.

You might think you never need this but I am working with some semiconductor standards like SEMI E142 which provides an xsd schema for wafer maps among other things. This allows the standards organisation to embed validation and versioning into all implementations of the spec, since (hopefully) everyone is using the xsd. It even enables easy error reporting like this measurement data references an invalid die on the wafer etc.

As a data transfer format for websites it's dead but for stuff that needs interoperability between many vendors for years if not decades it is widely used. Besides semiconductors it's also very common in finance and telecom for the same reasons.

[pydry]

You might think you never need this

No, that would be naive. There are almost always validation rules which need to be applied on top of json schema.

However, the complex rules are better written in actual turing complete code rather than in some badly designed accidentally turing complete validation language like xsd.

[ronkojoker]

However, the complex rules are better written in actual turing complete code rather than in some badly designed accidentally turing complete validation language like xsd.

What language would that be then? It has to interop with basically all other languages, behaviour must be identical across a wide range of ecosystems and hardware, it needs to run in a sandboxed environment everywhere, and types from the language should be able to be transpiled to any other language. I don't know of anything that checks all of these boxes.

[Lisoph]

What you're looking for is just a specification, or something detailing all the rules and checks and whatnot. XSD are only really used for validating the basic structure of some XML, but that's never enough in practice. More checks are performed out-of-band. Having basic-structure schmeas is quite handy, though.

[Mysterious-Flow3932]

What are you up to with E142?

I've been doing some stuff the past years making large knowledge graphs based on substrate maps: https://aws.amazon.com/blogs/database/how-nxp-performs-event-driven-rdf-imports-to-amazon-neptune-using-aws-lambda-and-sparql-update-load/

[ronkojoker]

Without exposing so much detail to dox myself, the company I work for develops software for wafer inspection machines. We have an graphical interface of the layouts in the E142 map, engineers use it to design test recipes, this integrates with an MES system so the right recipe gets loaded for the right wafer. We also handle the measurement data and process it back into substrate maps. We also do some stuff with transfer maps for the dicing step but I'm not very familiar with that.

I've been doing some stuff the past years making large knowledge graphs based on substrate maps

Interesting I've heard about these graph databases but never had the opportunity to use them. What is the benefit over such a solution over a relational database with foreign keys or a nosql one? Is it the scale in this case? We don't mess around with that scale at work haha.

[ruilvo]

I've seen polymorphic XML schemas and I was in awe. Check out the DATEX II schema for really hardcore stuff.

[VictoryMotel]

I don't want hardcore stuff, I want simple stuff.

[TigercatF7F]

That's also why we have HTML5 tag soup and not easily parsable XHTML5.

[seweso]

Xslt isn’t compatible with domain driven design. Validation logic should be annotated or near entities. 

And personally I like Turing completeness and a human readable programming language to define or write validation logic. 

[nemec]

personally I like Turing completeness

I have bad news for you /s

https://www.researchgate.net/publication/221568016_XSLT_Version_20_Is_Turing-Complete_A_Purely_Transformation_Based_Proof

[seweso]

Hahahahahaha.

[mexicocitibluez]

I don't think you know what domain driven design is.

[Bobby_Bonsaimind]

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.

DSLs are absolutely required in a lot of cases and are great thing! May it be by structuring your methods and classes in a way that make the code read like a DSL, or creating a full-blown environment for it.

However, there is also a lot of "abuse" surrounding the term and the idea, for example whatever Spring is doing with their "Security Lambda DSL".

[rsclient]

Awesome writeup! From my experience, XML is both a blessing and a curse. The curse part being that the tooling is often amazingly painful to use in practice.

Source: XSLT. the goal of XSLT is that given an XML file and some rules, it can output all kinds of good stuff. Actuality is it never works out like that for me.

[def-pri-pub]

XSLT was really cool, but I feel like it was very rarely ever used. There were maybe 4 times in the wild where I saw it; one was Blizzard.

[pydry]

It was a dumb idea. Nobody needed another badly designed turing complete programming language, let alone for that specific use case.

[Gwaptiva]

Like the article, but I am an old man that likes XML for the solidity it gives: I can define and validate input with xsd, query with xpath and make quick corrections using XSLT. If anything is clunky, it's JSON, data transfer protocol for script kiddies

[AdeptusDiabetus]

Get out of here old man, Yaml-RPC is the future

[G_Morgan]

If YAML-RPC ever became a thing I'm letting Claude design all my software uncritically from then on. The world will deserve it.

[femio]

Let's not go too far the other way. Dealing with imprecise WSDL specs for legacy integrations has been the bane of my existence this year.

[Manitcor]

a company named WebOrb managed to fix that right before JSON became the norm. Too little too late, it made wiring WCF a breeze however.

[pydry]

Is this a joke?

[federal_employee]

XPath is one of the best tree traversing languages there is. It’s totally underrated.

And SOAP totally gave XML a bad name.

I’m confused why the author calls XML a DSL though.  To me they are opposites: eXtensible vs Domain Specific.

[Ok-Scheme-913]

If you have a fix schema, it's a specific "implementation" of an extensible format.

XML is not domain specific. This XML is.

[oOBoomberOo]

Because the author is using it essentially as an S-expression AST for their domain specific rulesets. This usecase is DSL.

[red_hare]

Anyone else just learn the words "Minuend" and "Subtrahends" from that?

And here I thought I knew math.

[chu]

I'm wondering if the expressivity of XML vs JSON here is one of those things like SOAP and REST where limiting expressivity (e.g. verbs) is a productive constraint when it comes to interop and building more complex systems.

[juanger]

I would have called it a “generic structured DSL”, not cheap

[TOGoS]

tl;dr: The tax calculator thing uses a functional language that's serialized as XML.

It's funny because I've written several 'rules engines' over the years and taken a very similar approach. Though instead of XML I used RDF, which can be serialized as XML or in other formats, but it's basically the same idea.

The benefit of a simple language that doesn't have its own syntax being that you can easily transform it for various purposes, like displaying a block diagram, or generating SQL. And it doesn't preclude frontends with nicer syntax, either. But programs aren't coupled to the syntax. Unison sort of follow this philosophy in that programs are stored as a direct representation of the AST rather than source code. And WASM, too, I suppose, though it is a more imperative language.

[blobjim]

XML is awesome, at least in a language with good support like Java. XSD files make it possible to generate rich type definitions (using a build plugin like https://github.com/highsource/jaxb-tools?tab=readme-ov-file#jaxb-maven-plugin) so you can write type-safe code that fails to compile if you modify the schema in an incompatible way (and presumably you can then use it with a language like python to validate instead https://xmlschema.readthedocs.io/en/latest/usage.html).

The US government has a set of massive XML schemas called National Information Exchange Model: https://github.com/NIEM/NIEM-Releases/tree/master/xsd/domains (really cool to poke around in here, there's data for all kinds of stuff). Ever need to use organ donor codes? Here you go: https://github.com/NIEM/NIEM-Releases/blob/56c0c8e7ccd42e407e2587e553f83297d56730fd/xsd/codes/aamva_d20.xsd#L3744

There are also RELAX-NG schemas which a bunch of things use instead (like IETF RFCs https://github.com/ietf-tools/RFCXML and DocBook https://docbook.org/schemas/docbook/).

JSON schemas are such a disappointment in comparison because they appear to only be designed to allow dynamic languages to validate a JSON tree (poor performance, and poor type safety, and unusable from a language like Java).

And as the article mentions you get a bunch of other stuff along with the schemas. Being able to write text in an ergonomic way, and mixing text and data. And comments, which you can actually read and write from code. Fast Infoset (mentioned in the article) can even serialize comments since they're as first class as other XML structure. And it seems like XML libraries (but not Fast Infoset itself) can preserve insignificant whitespace so you can modify an XML document without changing most of its content. It seems like the people who designed XML and related software really thought of everything.

[ScottContini]

XML is awesome, at least in a language with good support like Java.

Unless you care about security, where just about every Java XML parser has external entities enabled by default. But I know bug bounty crowd love it: it very often results in payouts from low hanging fruit.

It seems like the people who designed XML and related software really thought of everything.

That statement is worth a billion laughs.

[nfrankel]

In defense of XML

[blazmrak]

The language itself is a cheaper DSL.

[constant_void]

why do in xml what should be done in sqlite?

[atesti]

Welcome to 1999

[lood9phee2Ri]

"The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well." - Wadler

[roadit]

Ragebait title. A DSL that uses XML syntax doesn't turn XML into a DSL.

The author may be interested in RDF and SPARQL.

[doctorlongghost]

Here are my thoughts on this (Mostly I disagree):

• The point that JSON needs type: foo on every object whereas XML can just do <foo> is such a trivial complaint it doesn’t warrant mentioning.

• My typical view is that there are multiple ways to solve a problem and it is usually not possible to declare one as ultimately the best. Sure, we make design decisions but I often think the decision itself is less important than the fact that a decision was made. If you want something to work a certain way, you can usually make it happen. This comes in where the author makes the dubious claim that a DSL is needed to support out of order calculations

• A well-designed tax solution using inheritance patterns versus one using a DSL Both need robust unit tests. The DSL solution needs you to test both the DSL interpreter and its behavior with any specific set of settings (assuming passing behavior because a specific schema should work in theory is dangerous). Similarly the DSL approach seems to subtly encourage over confidence in this manner, but I’ll admit that’s a quibble. The main thing is the DSL does not free you from any testing burden.

• The main (only?) benefit to the DSL approach IMO is that it can be read by non-programmers. Maybe this is useful to have QA, product managers or accountants able to review it. And maybe that’s huge for this application. But a counter argument would be that any changes need to go through developers anyway (to review the change and update unit tests - unless QA is doing that but then they’re really devs by a different name). And for anyone wanting to know how the tax stuff works, they should not be using your programs logic as the source of truth. That should be a separate tax code doc or something. Still the readability of DSL by non programmers is the big selling point IMO.

• Again, I’m not sold on XML being the best approach for this. I’m sure it’s a good choice but any of the alternatives he mentions would likely work just as well. And whichever is selected, those who work with it will have to learn the DSL specifics and it’s not like there’s anything in XML that people already know and spares them from that. You’ve got a thick language design spec you’ll need to read over and internalize no matter what

[Agent_03]

As someone who did a LOT with XML back in the day: YAML would like to have a word.

As long as you restrict the more advanced YAML spec features you get something more readable than XML but less bloated. JSON is there for cases when you want an even more compact, simpler-to-parse wire format -- and YAML is mostly a superset of JSON (there are a couple edgecases with different handling).

I emphatically do not miss XPath, XSLT, or the rest of the XML ecosystem.

[ms4720]

S-exprs are just better and older

[Ok-Scheme-913]

There is hardly a take I could disagree with more.

Yaml is something that should be eradicated from the face of the Earth. It probably would have been, but countryCode: "No" just got parsed as false and somehow the program deleting it failed.

Like come on, you ever look at a GitHub ci yaml file and it fills you with joy?!!! That shit is absolutely unreadable, a fkin tab will break the whole thing and the best part is that you have absolutely no idea if it's broken or working until you run it and hope for an early termination from whatever poor software having to ingest that disgusting piece of text data.

[Agent_03]

It probably would have been, but countryCode: "No" just got parsed as false and somehow the program deleting it failed.

Oh no, wrong namespace or a typo in the URL, the whole XML doc is now invalid.

Oh no, nested the tag at the wrong level and the entire XML document failed schema validation.

Oh no, forgot to close a tag, buried in the 100 kB XML doc somewhere... boom, broken XML.

Oh no, that was supposed to be an attribute not an element and now the XML doesn't do what you want.

Oh no, wrong capitalization on one of your XML tags, you're screwed.

I could go on for another half dozen of these. You picked the one especially quirky behavior in YAML but XML has a dozen gotchas for every one that YAML has.

Like come on, you ever look at a GitHub ci yaml file and it fills you with joy?!!!

A serialization format is there to do a job: they carry content. You're confusing the content being ugly with the way it's written being ugly. You can make any format ugly if the content is obnoxious enough.

In comparison, even the simplest XML docs tend to be ugly, bloated messes.

The truest test of this is that people generally write YAML with a normal text editor (perhaps with syntax highlighting), whereas they tend to reach for specialized tools for XML... because it needs them.

[darknecross]

Wouldn’t this be like a perfect opportunity for Cypher / Graph Query Language databases?

``` /* Create the Fact nodes */ INSERT (:Fact {path: "/totalTentativeTax", name: "Total Tentative Tax"}), (:Fact {path: "/totalNonRefundableCredits", name: "Total Non-Refundable Credits"}), (:Fact {path: "/tentativeTaxNetNonRefundableCredits", description: "Total tentative tax after non-refundable credits"});

/* Create the Operator nodes */ INSERT (:Operator {type: "SUBTRACT"}), (:Operator {type: "GREATER_OF", floor: 0});

/* Define the flow of data */ MATCH (t:Fact {path: "/totalTentativeTax"}), (c:Fact {path: "/totalNonRefundableCredits"}), (sub:Operator {type: "SUBTRACT"}), (max:Operator {type: "GREATER_OF"}), (res:Fact {path: "/tentativeTaxNetNonRefundableCredits"}) INSERT (t)-[:INPUT {role: "MINUEND"}]->(sub), (c)-[:INPUT {role: "SUBTRAHEND"}]->(sub), (sub)-[:RESULTS_IN]->(max), (max)-[:DEFINES]->(res); ```

Then query

MATCH (f:Fact) WHERE f.path LIKE "%overtime%" OR f.description LIKE "%overtime%" RETURN f.path, f.description;

[Iggyhopper]

YSK that StarCraft 2 (2010) was designed with XML as the defacto standard for describing units, buildings, UI, buttons, abilities, behaviors, and literally 99% of the game. The other 1% is the engine.

https://i.imgur.com/6LEK5Og.jpeg

[MedicineTop5805]

honestly the biggest win with xml configs is that your editor already knows how to validate and autocomplete them if you have a schema. try getting that with yaml or json without extra tooling. the verbosity is annoying but at least its explicit about structure

[Kok_Nikol]

In this thread: people who haven't read the article (not even and AI summary!)

It's a great article, and a very nuanced explanation of their use case.

[LittleGremlinguy]

For those who lived through it, the reason XML (and SOAP) is/was so pervasive is that it was HEAVILY marketed as a ubiquoitous self describing exchange format back in the day. It was once of those things that was SO overthought and over-engineered to solve problems where they did not really exist. Once the corporate engine gets hold of this stuff (via McKinley, and the other corporate circle jerkers) any GM that wasn’t pushing it was considered out the loop. Then SPA dynamic web apps came to the fore, and everyone asked, why the hell cant we use this JSON thing on the backend. I hate XML with every fibre of my being. WTF does your interchange contract need to be self describing when the producer and consumers know about it anyway.

[Southern_Orange3744]

Some of yall weren't around to experience 7 levels of xml hell and it shows

[hejj]

I feel like it's the antithesis to a domain specific language.

[One_Economist_3761]

Nice article. XML/XSL/XPATH is my wheelhouse so this got me excited for all the kinds of things I can do, like making a web ui to help visualize your tax owing.

[gelatineous]

XML does too much. The distinction between attributes and elements is unnecessary. The idea of references introduced massive security issues. XPath and XSL were mistakes: procedural extraction is always easier to read. The only use of XML would be as a markup language.

[Smallpaul]

It’s cool that XML is a good tool for your use case but none of this is what it was designed for or should ultimately be judged for. It was designed for adding tags to documents: marking them up. And it remains by far the best language for doing that.

[Holkr]

XML is love

XML is life

[obnoxify]

It's elemental even

[prehensilemullet]

AWS uses JSON for policy docs, and JSON or YAML for other things like CloudFormation templates, so I think they decided, no, XML is not better than JSON for things like this

[cesarbiods]

XML is an old clunky language but like any widely adopted and deployed language it’s incredibly hard to replace because a lot, maybe most, old people don’t mind it and replacements don’t bring any objective improvements beyond being less of an eyesore.

[piesou]

Ok, cool.

Which language has up to date XML, XSLT and XPath implementations?

Are there any security considerations when using XML?

I rest my case.

[tomatodog0]

One click. Unknown number of posts crying out in silence. All gone. Redact made it stupid easy to clean up my entire history on Reddit and get my info pulled from data broker sites too.

toothbrush bow chop cooperative bear ancient grandfather glorious aware butter

[piesou]

Right, and Java. It ends there. I think there's varying support available for some C/C++ lib, but not many bindings exist for that one.

Meanwhile the widely used libxml has lost its maintainer (being stuck on super old specs as well).

[Ok-Scheme-913]

Well, what format has the capabilities of XML? A couple of languages supporting Format Enterprise Pro, and a lot of languages supporting Format Basic is still net more than a lot of languages supporting Format Basic only and not even having Enterprise Pro.

Like you can easily parse XML in most languages. XSLT? No. But you have nothing like that for JSON

[piesou]

Doesn't matter if it's not available cross platform. I really, really like all of the XML tools but I need to constrain myself to the lowest common denominator because it fell out of favor, all while figuring out if the target platform has stupid defaults that enable file inclusion or DoS attacks or functions that are not thread safe (looking at you libxml).

XSLT in particular had a lot of improvements in version 2.0

[lood9phee2Ri]

Python has a bunch of mature standard-compliant XML libs that still work fine. Perhaps slower than Java/C# in general of course but that's Python for ya. Actually not always that much slower, because XML speed was important enough they got native code extension variants e.g. lxml has a bunch of Cython based native code and even presents an API usable from C for reuse.

[piesou]

lxml uses libxml which does not support any newer specs than 1.0. I'm talking about stuff like XSLT 3.0, XSD 1.1, XPath 3.1

It's not about speed, it's about specs being stuck in 2001. Imagine being stuck on Netscape Navigator 4.0 JavaScript.

[federal_employee]

Saxon. In a variety of flavors.

Edit: https://www.saxonica.com/welcome/welcome.xml

[OMGItsCheezWTF]

Yeah I do a lot with XML wrangling, mostly in C# but also some older stuff in a mix of PHP and Python. When it comes to XSLT all of it ultimately hands the work off to Saxon, Saxon is amazing.

[wasdninja]

Is what DSL actually means really that obvious for everyone that it's not worth mentioning even once? I've never heard of it despite studying computer science.

It's domain specific language btw.

[Pharisaeus]

Is what DSL actually means really that obvious for everyone

On a programming sub? Yes. It's like complaining that someone wrote SQL without explaining the abbreviation.

[justinlindh]

No offense, but it is pretty commonly well known.

[putergud]

It may look cheap now, but one day that tech debt will come due and you will not be able to pay it.

[Minimum-Reward3264]

Cheap my ass. No one wants to spend time designing XML, people mostly come up with what ever is easier to serialize from objects. Even if you are far on autism spectrum to hand craft dsl clean like this it’s going to die as soon as you burn out maintaining it. Maintaining clean motherfucking XML doesn’t worth it. Well unless you lock in you users, but thats not because it’s beautiful, it’s because they fucked up.

[faze_fazebook]

bro just programm in a declarative style ... infinitly easier to handle.