There are many things I don't love about how tech has evolved, but when I look at a massive blob of XML and a lengthy explanation of "why this is better than just writing code!" I feel a little a bit more accepting of the current state of things.
XML and XSLT are a bad fit in many common uses, that's why the argument is frustrating. If you are almost always working with projects where you own the frontend and the backend, just stick with JSON and RPC.
I find massive blobs of XML easier to grok than massive blobs of JSON, esp well-designed XML with namespaces and use of attributes. XML is self documenting.
JSON is just a homogeneous unnamed bunch of braces and key-val pairs that you loose yourself in once you are several MB in and deeply nested. Need to resort to CLI tools like jq or hunt for the schema or docs.
Massive blobs of YAML, well - they should be simply categorized as a war-crime.
Is XSLT enjoying the equivalent of Streisand Effect? Ever since news came out of Google wanting to rid Chrome of XSLT support, there has been a number of XSLT-related news here. I am not complaining, I think XSLT deserves a second life, it hasn't had the scrutiny it deserves, nor its "15 years of fame".
That’s basically what happened with MathML a decade ago. Chromium had briefly had an implementation (M24 alone!), Firefox had an excellent implementation, and Safari had a decent implementation; there was very little usage. Chromium proposed removing it. There was much kerfuffle. When the dust settled, MathML won. MathML Core was defined, Igalia contributed a robust MathML implementation to Chromium, Safari tightened their implementation up, and people started actually using it a lot more.
Around the same time, Google tried to deprecate SMIL (SVG animation tech), which would probably have led to its removal after some time. This also failed, and it’s used more than it was then (though CSS animations are probably quite a bit more popular, and have over time become more capable), probably because now all engines support it robustly (MSHTML and EdgeHTML never did).
I hope that we’ll get a more formal commitment to XML and XSLT, and XSLT 3 in browsers, out of this.
So does every other open source XSLT implementation, along with XPath/XQuery 3x. Most of them at best support 2x or 1x with some 2x-compatible extensions, but I'm not aware of any that fully support the 3x variants, besides Xidel (XPath/XQuery 3.0). The proprietary Saxonica is the go-to at the moment.
I worked in the music streaming industry, which involves ingesting 10's of millions of XML files. Absolutely do not use XSLT. Schema changes between different versions of DDEX were a nightmare for all the legacy XSLT we had.
The article's example shows the main reason (besides having old libraries shipped with Java) why XSLT didn’t have a significant adoption: UX/DX.
The JSON transformation example is quite simple, and you can accomplish it with one or two lines of JS. But the XLST is unreadable, starting with tons of namespace imports.
The usual argument is that a good UI can fix that, but that’s false. So using XSLT for general data transforms is very problematic: it's hard to read, with no debugging tools, and it’s also hard to build a UI tool that simplifies that for the “citizen integrator” (the segment of people who have technical knowledge and take care of doing integrations but are not experienced with programming).
(Around 2017, I worked for a company that created its own data transformation tool, so I designed the UI editor and did user research of people using transformation languages in different scenarios.)
Decades ago, I worked on the XCB library (the replacement for Xlib). I replaced the M4 macros used to generate all the X protocol bindings with XML protocol definitions and XSLT to do code generation.
The XML turned out extremely well, and it's still being used today, such as for bindings in several other languages.
Someone rewrote my XSLT in Python, and I cheered them on, because the result was much more readable, not least of which because the fundamentally procedural steps could be written in a procedural language with a good syntax, rather than XSLT's pure-functional language that suffered from being embedded in XML.
The ability to use XSLT to convert JSON to HTML may be useful when making extensions for working with web sites that internally use JSON. Converting XML to JSON might also be useful for some things.
However, XSLT would be useful with command-line programs too, and not only in a web browser, anyways. (A standalone implementation might also be made to have the ability to load extensions written in C.)
There are problems with XML and with JSON, as well as with XSLT, but when dealing with XML and JSON formats anyways, XSLT can be helpful. (One problem is that XML does not deal very well with types other than Unicode text (JSON has a few additional types but still not very good). XSLT does add some types, though.)
They also mention RDF, but the standard XML format for RDF is not very good in my opinion (although I think someone did make up a better XML format for RDF, for the help of being used with XSLT better).
XSLT rocks. I have a team who come from business analyst and accounting backgrounds, we manage hundreds of reports for client data to their banks and could never manage it without something simple like XSLT to deal with it all.
You give the employee IntelliJ or some IDE of your choice and a way of uploading the transforms into your application and they'll work away. All the complaints about namespaces and the like that your hear online? Never hear from them, they dont think about it, just stick the declarations up in the top of the file and work away.
Abandoning XML has been one of softwares biggest mistakes.
15 comments
[ 3.7 ms ] story [ 34.6 ms ] threadJSON is just a homogeneous unnamed bunch of braces and key-val pairs that you loose yourself in once you are several MB in and deeply nested. Need to resort to CLI tools like jq or hunt for the schema or docs.
Massive blobs of YAML, well - they should be simply categorized as a war-crime.
Around the same time, Google tried to deprecate SMIL (SVG animation tech), which would probably have led to its removal after some time. This also failed, and it’s used more than it was then (though CSS animations are probably quite a bit more popular, and have over time become more capable), probably because now all engines support it robustly (MSHTML and EdgeHTML never did).
I hope that we’ll get a more formal commitment to XML and XSLT, and XSLT 3 in browsers, out of this.
This open source Rust implementation needs more help of integrating the full XSLT 3.0 standard into their engine
https://github.com/Paligo/xee
The JSON transformation example is quite simple, and you can accomplish it with one or two lines of JS. But the XLST is unreadable, starting with tons of namespace imports.
The usual argument is that a good UI can fix that, but that’s false. So using XSLT for general data transforms is very problematic: it's hard to read, with no debugging tools, and it’s also hard to build a UI tool that simplifies that for the “citizen integrator” (the segment of people who have technical knowledge and take care of doing integrations but are not experienced with programming).
(Around 2017, I worked for a company that created its own data transformation tool, so I designed the UI editor and did user research of people using transformation languages in different scenarios.)
The XML turned out extremely well, and it's still being used today, such as for bindings in several other languages.
Someone rewrote my XSLT in Python, and I cheered them on, because the result was much more readable, not least of which because the fundamentally procedural steps could be written in a procedural language with a good syntax, rather than XSLT's pure-functional language that suffered from being embedded in XML.
However, XSLT would be useful with command-line programs too, and not only in a web browser, anyways. (A standalone implementation might also be made to have the ability to load extensions written in C.)
There are problems with XML and with JSON, as well as with XSLT, but when dealing with XML and JSON formats anyways, XSLT can be helpful. (One problem is that XML does not deal very well with types other than Unicode text (JSON has a few additional types but still not very good). XSLT does add some types, though.)
They also mention RDF, but the standard XML format for RDF is not very good in my opinion (although I think someone did make up a better XML format for RDF, for the help of being used with XSLT better).
You give the employee IntelliJ or some IDE of your choice and a way of uploading the transforms into your application and they'll work away. All the complaints about namespaces and the like that your hear online? Never hear from them, they dont think about it, just stick the declarations up in the top of the file and work away.
Abandoning XML has been one of softwares biggest mistakes.