Hacker News Reader

Comment by Exoristos | Hacker News Reader

That's my whole point. The tools for navigating, transforming, streaming, parsing, etc. XML are genuinely terrific, like nothing else, and it's demoralizing to see younger devs throw it all away because they prefer not to have to learn anything with more than trivial complexity.

View on HN

As modern xquery and xslt support JSON, maybe there's scope for an x* tool like jq that makes working with JSON pleasant?

I've not used xquery enough to know if it can be succinct enough to be used as jq's language can.

For sure the Saxon cli could be made a lot more user friendly if it followed normal conventions.

XMLs downfall was not providing built-in serialization/de-serialization. If XML had started with libraries like https://pydantic-xml.readthedocs.io/en/latest and people understood that this was the way to produce and consume XML -- that if you're using something like xpath or touching the raw tree with getChildElement and the like for more than one-off scripts something has gone wrong. And that xslt is at best an optimization and at worst staring into the abyss so don't start with it.

But now it doesn't matter because the backing format doesn't really matter and JSON was there at the right place right time.

It's not really because they don't want to have to learn it, it's because XML is fundamentally the wrong data model for most data. JSON is great because it matches the object structure used in 99% of programming languages - for JS it is the object structure.

Find me a programming language where objects have attributes, the order of members is significant and can be interleaved, everything is stringly typed etc...

It's a shame because I agree the tooling for XML is still better than JSON. But not better enough that it's worth fighting the data model mismatch.

I'm not sure if there is any open source XSLT tool as complete as jq is for JSON. There is xsltproc but IIRC it does not support streaming scenarios (jq has some support for streaming processing)

Though, personally, I prefer JSON. Probably due to superior tools (thanks to its popularity) and less-bloated syntax (it is somewhat easier for me to read raw JSON file than raw XML file).

Saxon is where it's at.

When XSLT 3.0 tells a joke, it starts with "a JSON walks into a bar..."

https://github.com/Saxonica/Saxon-HE

Now that is just aggressively dumb: https://github.com/Saxonica/Saxon-HE/tree/SaxonHE12-3/12#sou... and https://github.com/Saxonica/Saxon-HE/tree/SaxonHE12-3/12/sou... (not even the decency to use .gitattributes so it knows the files are binary)

FWIW https://saxonica.plan.io/projects/saxonmirrorhe/repository seems to be the for-real source repo

I do not see license in either repository and it seems that this tool only has 30 day evaluation tier for free. Anyway, using this means that you have dependency on a single vendor and you accept their future pricing changes.

Now compare this with JSON ecosystem

Their "home" edition is open source and way more capable than anything I've seen for other formats.

Saxonica, the company behind it, has been critical for the evolution of the XML ecosystem.

I agree that lack of alternatives sucks but the breadth of options you refer to is backed by an army of open source volunteers.

I think XPath would be the XML analog to jq.

It would be cool to be able to use XPath to query JSON. Of course you'd need to come up with a good mapping between JSON nodes and XML nodes.

If XML tools aren't open enough for certain needs, then sure, I get it. But it's tragic to see highly-engineered, pro solutions just die out because younger devs don't like the learning challenge or because business owners are cheapskates.

Sure, but not everything uses XML. Lots of things use JSON, so even if you do not like it, presumably you will have to work with it at some point. So this is a tool that lets you do that. I do not think it is reasonable to expect that everyone uses XML, or should use XML, even if it is your favorite.

Reply on news.ycombinator.com