6 ms·

A look at XSLT 3.0 (2017)

75 points by protomolecool 1y ago

roadside_picnic 1y ago
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.
- greggman65 1y ago
  Agreed. I tried XSLT once. I made an XSLT for RSS. Coding in XSLT really sucked.
  - _heimdall 1y ago
    Were you using XSLT 1.0 for native browser support? If so, yeah its pretty damn frustrating both in the APIs and the lack of browser support for basic debugging.
  - vgr-land 1y ago
    LLMs make it much easier. Then you get all the benefits with few of the frustrations
    - xyz_opinion 1y ago
      !
- wrs 1y ago
  Sure, it's so much better to be writing massive blobs of YAML. There just seems to be some misguided human impulse to take every data serialization language and force it to be a programming language, instead of just using a programming language.
- hackrmn 1y ago
  Current state of things is a mixed bag, in my opinion. XSLT wasn't perfect, and XML required a lot of repetition and neither got the amount of scrutiny both deserved to advance past their own inconvenience. But a lot of what we have today has just as many drawbacks, and that _despite_ WHATWG and Google hawking over it all. XML had namespaces, which alone were quite a potent feature that allowed to manage _semantics_ of data with more rigor and flexibility -- compared to the in my opinion amateur-ish "custom elements" HTML 5 approach, and how Apple refuses to implement parts of the spec., because they "don't believe in inheritance" (I am being liberal but those who know know). Then there is the HTML 5 parser itself -- "for the masses" -- with its idiotic and incomprehensible rules that are element specific, for which reason noone ever remembers these. Forgot a `</p>`? No problem, you can discover your omission after you've shipped! HTML 5 parser never aborts!
- jact 1y ago
  It is “just code.” It’s good at what it does too. Although for my purposes, I find myself reaching for xquery a lot more often which is a very good and elegant programming language and template language although it was billed as “SQL for XML.”
- _heimdall 1y ago
  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.
  - Telemakhos 1y ago
    If you’re only using XML for AJAX style communication of fragments of data between a model and view, sure, use JSON or whatever. If, on the other hand, you’re encoding a representation of a text and need to mark it up to indicate bibliographic features and textual variation between editions, you need TEI XML. If you want a dataset to be available in a machine-readable format at a particular address and also have that data look good for humans, you want XML. XML is for more than passing messages from a backend to a frontend.
    - _heimdall 1y ago
      I wasn't meaning to imply that XML is only for backend to frontend communication. I only mentioned they as it seems to be the most common task in web jobs today and is usually what a person does most often when I hear the complaint that XML is pointless and we should just use JSON.
- lenkite 1y ago
  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.
  - arcfour 1y ago
    Hell, you can parse XML and infer complex types! Good luck doing that with JSON though.
hackrmn 1y ago
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".
- deleted 1y ago
  [deleted]
- Klonoar 1y ago
  It’s a parallel universe Lisp/Rust as far as HN goes.
- tptacek 1y ago
  It wasn't Google. The original proposal came from Mozilla, and apparently all the browser vendors want to be rid of it.
  - josefx 1y ago
    > came from Mozilla Maybe they should stop wasting money on pointless, proprietary side tangents before they set out to break standards.
  - chrismorgan 1y ago
    Browser makers trying to kill XSLT is not new: Chrome had intents to deprecate and remove XSLT in 2013 and 2015 (which both failed). Each time so far, there’s been movement for a while, significant pushback, and the one who was championing removal realises it’s hard, and quietly drops it. Smaug from Mozilla bringing it up at a WHATNOT meeting a few months ago looked like it was heading the same way, a “yeah, we’d kinda like to do this, but… meh, see what happens”. Then a few months later Mason Freed of Google decided to try championing it. We’ll see where things go.
    - tptacek 1y ago
      Which part of what I said was false?
therealmarv 1y ago
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 https://github.com/Paligo/xee
- _zagj 1y ago
  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.
poshmosh 1y ago
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.
- satyrnein 1y ago
  I'm on the distributor side, I used to fantasize about using XSLT to produce all the different XML formats (beyond DDEX, like Apple, etc) from one house format, but that was probably a bad idea!
- oever 1y ago
  XSLT and XQuery 3.0 can have type annotations and implementations can even type check based on a XSD schema. That should help with adapting to version changes in input and output formats.
diegof79 1y ago
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.)
- _heimdall 1y ago
  > 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 I wonder if react would be popular today if it started out with the UX/DX we have today. It started out as a comparatively simple component-based library for rendering templates in the browser. It got popular and built a huge community before becoming the complete DX mess that it is today.
- calmbonsai 1y ago
  I lived and breathed XSLT back in the day for 3 projects over 2 years. Hell, I was the company's "XML evangelist" and spoke at XMLConf in San Diego. I would never go back. XSLT's "coding UX" is atrocious. Simple things "look complex" and complex things "look obfuscated". As mentioned in the parent post, there's also this consistent "low leverage" to the code so you feel as if you're typing a lot for little impact.
JoshTriplett 1y ago
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.
- mcswell 1y ago
  Well said. I once had the displeasure of trying to write some code in XSLT (it had to fit in with existing XSLT code). It had to be the worst programming language I'd ever seen, with the possible exception of assembler. First, who decided that XML was a good format to write a programming language in? Punch cards would have been better. And second, trying to debug it was embarrassingly difficult.
  - aleph_minus_one 1y ago
    > And second, trying to debug it was embarrassingly difficult. I remember that in the past Visual Studio had a pretty decent debugger for XSLT.
  - xyz_opinion 1y ago
    XSLT is not a programming language. It's a declarative transform for XML, and when you need such a thing, it is extremely useful.
    - peterhunt 1y ago
      Let's see: - Variable scoping https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Reference/Element/variable https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere... - Function definition and application https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Reference/Element/template https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere... - Flow control https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Reference/Element/if https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere... - Loops https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Reference/Element/for-each https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere... - Module system https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Reference/Element/import https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere... Yep, it's a programming language. And not a great one!
zzo38computer 1y ago
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).
Devasta 1y ago
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.

75 points by protomolecool 1y ago

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.

greggman65 1y ago
Agreed. I tried XSLT once. I made an XSLT for RSS. Coding in XSLT really sucked.
- _heimdall 1y ago
  Were you using XSLT 1.0 for native browser support? If so, yeah its pretty damn frustrating both in the APIs and the lack of browser support for basic debugging.
- vgr-land 1y ago
  LLMs make it much easier. Then you get all the benefits with few of the frustrations
  - xyz_opinion 1y ago
    !
wrs 1y ago
Sure, it's so much better to be writing massive blobs of YAML. There just seems to be some misguided human impulse to take every data serialization language and force it to be a programming language, instead of just using a programming language.
hackrmn 1y ago
Current state of things is a mixed bag, in my opinion. XSLT wasn't perfect, and XML required a lot of repetition and neither got the amount of scrutiny both deserved to advance past their own inconvenience. But a lot of what we have today has just as many drawbacks, and that _despite_ WHATWG and Google hawking over it all. XML had namespaces, which alone were quite a potent feature that allowed to manage _semantics_ of data with more rigor and flexibility -- compared to the in my opinion amateur-ish "custom elements" HTML 5 approach, and how Apple refuses to implement parts of the spec., because they "don't believe in inheritance" (I am being liberal but those who know know). Then there is the HTML 5 parser itself -- "for the masses" -- with its idiotic and incomprehensible rules that are element specific, for which reason noone ever remembers these. Forgot a `</p>`? No problem, you can discover your omission after you've shipped! HTML 5 parser never aborts!
jact 1y ago
It is “just code.” It’s good at what it does too. Although for my purposes, I find myself reaching for xquery a lot more often which is a very good and elegant programming language and template language although it was billed as “SQL for XML.”
_heimdall 1y ago
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.
- Telemakhos 1y ago
  If you’re only using XML for AJAX style communication of fragments of data between a model and view, sure, use JSON or whatever. If, on the other hand, you’re encoding a representation of a text and need to mark it up to indicate bibliographic features and textual variation between editions, you need TEI XML. If you want a dataset to be available in a machine-readable format at a particular address and also have that data look good for humans, you want XML. XML is for more than passing messages from a backend to a frontend.
  - _heimdall 1y ago
    I wasn't meaning to imply that XML is only for backend to frontend communication. I only mentioned they as it seems to be the most common task in web jobs today and is usually what a person does most often when I hear the complaint that XML is pointless and we should just use JSON.
lenkite 1y ago
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.
- arcfour 1y ago
  Hell, you can parse XML and infer complex types! Good luck doing that with JSON though.

hackrmn 1y ago

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".

deleted 1y ago
[deleted]
Klonoar 1y ago
It’s a parallel universe Lisp/Rust as far as HN goes.
tptacek 1y ago
It wasn't Google. The original proposal came from Mozilla, and apparently all the browser vendors want to be rid of it.
- josefx 1y ago
  > came from Mozilla Maybe they should stop wasting money on pointless, proprietary side tangents before they set out to break standards.
- chrismorgan 1y ago
  Browser makers trying to kill XSLT is not new: Chrome had intents to deprecate and remove XSLT in 2013 and 2015 (which both failed). Each time so far, there’s been movement for a while, significant pushback, and the one who was championing removal realises it’s hard, and quietly drops it. Smaug from Mozilla bringing it up at a WHATNOT meeting a few months ago looked like it was heading the same way, a “yeah, we’d kinda like to do this, but… meh, see what happens”. Then a few months later Mason Freed of Google decided to try championing it. We’ll see where things go.
  - tptacek 1y ago
    Which part of what I said was false?

therealmarv 1y ago

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 https://github.com/Paligo/xee

_zagj 1y ago
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.

poshmosh 1y ago

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.

satyrnein 1y ago
I'm on the distributor side, I used to fantasize about using XSLT to produce all the different XML formats (beyond DDEX, like Apple, etc) from one house format, but that was probably a bad idea!
oever 1y ago
XSLT and XQuery 3.0 can have type annotations and implementations can even type check based on a XSD schema. That should help with adapting to version changes in input and output formats.

diegof79 1y ago

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.)

_heimdall 1y ago
> 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 I wonder if react would be popular today if it started out with the UX/DX we have today. It started out as a comparatively simple component-based library for rendering templates in the browser. It got popular and built a huge community before becoming the complete DX mess that it is today.
calmbonsai 1y ago
I lived and breathed XSLT back in the day for 3 projects over 2 years. Hell, I was the company's "XML evangelist" and spoke at XMLConf in San Diego. I would never go back. XSLT's "coding UX" is atrocious. Simple things "look complex" and complex things "look obfuscated". As mentioned in the parent post, there's also this consistent "low leverage" to the code so you feel as if you're typing a lot for little impact.

JoshTriplett 1y ago

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.

mcswell 1y ago
Well said. I once had the displeasure of trying to write some code in XSLT (it had to fit in with existing XSLT code). It had to be the worst programming language I'd ever seen, with the possible exception of assembler. First, who decided that XML was a good format to write a programming language in? Punch cards would have been better. And second, trying to debug it was embarrassingly difficult.
- aleph_minus_one 1y ago
  > And second, trying to debug it was embarrassingly difficult. I remember that in the past Visual Studio had a pretty decent debugger for XSLT.
- xyz_opinion 1y ago
  XSLT is not a programming language. It's a declarative transform for XML, and when you need such a thing, it is extremely useful.
  - peterhunt 1y ago
    Let's see: - Variable scoping https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Reference/Element/variable https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere... - Function definition and application https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Reference/Element/template https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere... - Flow control https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Reference/Element/if https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere... - Loops https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Reference/Element/for-each https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere... - Module system https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Reference/Element/import https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere... Yep, it's a programming language. And not a great one!

zzo38computer 1y ago

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).

Devasta 1y ago

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.