[Seanny123]

What are some examples of the "enormous tool stack" required for XML? I ask, because I came into software development after everyone adopted JSON. When I do need to parse XML, there was a library I could use, although I will admit that needing xpath was a bit annoying.

[orthoxerox]

If your XML is written the way people write JSON, then the stack isn't enormous. But XML is usually wrapped in layers of additional complexity. SOAP envelopes and namespaces they require, XSLT that someone invariably used to write an XML transformer, etc.

[XorNot]

Also broken parsers. So many broken parsers. Honestly this is what keeps JSON going: the parser was simple because the language was simple, and as a result any JSON you got basically worked the same way.

Not so with XML: all the parsers were insanely complex with the namespacing and whatnot feature support and possible external URLs and everything else...and as a result however no XML library was ever adequate to interface with anything. On multiple occasions generally the best way to build XML for something was to take a working copy, and then glue text together so you would exactly replicate whatever that specific application wanted, rather then trying to use anyone's library for it.

[bryik]

This was before my time, but I believe the WS-* series of specifications is an example.

> Like with the original J2EE spec, which sought to complicate the basic mechanics of connecting databases via HTML to the internet, this new avalanche of specifications under the WS-* umbrella sought to complicate the basic mechanics of making applications talk to each other over the internet. With such riveting names as WS-SecurityPolicy, WS-Trust, WS-Federation, WS-SecureConversation, and on and on ad nauseam, this monstrosity of complexity mushroomed into a cloud of impenetrable specifications in no time. All seemingly written by and for the same holders of those advanced degrees in enterprisey gibberish.

https://world.hey.com/dhh/they-re-rebuilding-the-death-star-...

[WorldMaker]

> When I do need to parse XML, there was a library I could use, although I will admit that needing xpath was a bit annoying.

It sounds a bit like someone paved a garden path for you by that point. One of the reasons for the "enormous tool stack" wasn't just depth of tools needed ("tool X feeds tool Y which needs tool Z to process namespace A, but tool B to process namespace C, …"), but also the breadth. I recall there were at least six types of parsers to choose from with all sorts of trade-offs in memory utilization, speed, programming API: a complicated spectrum from forward-only parsers that read a node at a time very quickly but had the memory of a goldfish through to HTML DOM-like parsers that would slowly read an entire XML document all at once and take up a huge amount of memory for their XML DOM but you could query through the DOM beautifully and succinctly. (ETA: Plus or minus if you needed XSD validation at parsing time, and if you wanted the type hints from XSD to build type-safe DOMs, etc.)

A lot of XML history was standards proliferation in the xkcd 927 way: https://xkcd.com/927/

XPath tried to unify a lot of mini-DSLs defined for different DOM-style XML parsers.

XSLT tried to unify a bunch of XML transformation/ETL DSLs.

The things XPath and XSLT were designed to replace lingered for a while after those standards were accepted.

Eventually quite a few garden paths were paved from best practices and accepted "best recommended" standards and greenfield projects start to look easy and a simple number of well-coordinated tools. But do enough legacy Enterprise work and you can find all sorts of wild, brownfield gardens full of multiple competing XML parsers using all sorts of slightly different navigation and transformation tools.

[sgtnoodle]

The last time I worked with XML, using an external library wasn't really a great option. I ended up writing my own parser in C++. It took about a week to get all the features required for my purpose.

[tracker1]

Honestly, if you just need a one-off transformer, VB.Net is probably one of the better options. The .Net XML library is pretty good in the box, and VB.Net has XML literal support on the top... if you just need to read, then C# is a better language imo.

[Kwpolska]

VB.NET is masochism, and XML literals are a dumb, confusing, and unnecessary feature. Creating XML elements with regular code is quite easy, and at scale, you probably want templates.