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.
show comments
hackrmn
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".
show comments
roadside_picnic
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.
show comments
diegof79
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.)
show comments
therealmarv
If somebody wants to help XSLT 3.0...
This open source Rust implementation needs more help of integrating the full XSLT 3.0 standard into their engine
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.
show comments
Devasta
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.
zzo38computer
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).
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.
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".
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.
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.)
If somebody wants to help XSLT 3.0...
This open source Rust implementation needs more help of integrating the full XSLT 3.0 standard into their engine
https://github.com/Paligo/xee
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.
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.
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).