3 ms·

its because it demands to everything to be effectively processed in a one liner and is locked into its early version due to a licensing failure (I've yet to wor

its because it demands to everything to be effectively processed in a one liner and is locked into its early version due to a licensing failure (I've yet to work in an org that pays up). So if you work in XSLT, then you're stuck in 1999. IMHO the pattern to improve XSLT is to call out into more useful languages like javascript, which ofc somewhat defeats the point of using it, but it is a useful pattern to slowly move away from it, when encountering it in legacy projects.

lolive 1y ago
Reinventing XML traversal/transformation in JavaScript will lead really fast into abstracting away the recursive tree traversal, then mapping node marchers to functions. Which is 99% what XSLT provides off the shelf.
- Quarrelsome 1y ago
  many developers just want to have some space to do some extra logic and XSLT doesn't really accommodate for that. You have to deal with the input and create the output without pausing for breath. While this is fine in simple use-cases where the mapping is 1-1 but when the mapping gets more complicated then it becomes difficult to maintain.
  - willseth 1y ago
    That’s simply not true. Certainly it can be hard to wrap your head around architecting complex logic in XSLT 1.0, but it's not unlike how you have to change your thinking for functional programming generally. More ergonomic imperative logic and several other features in XSLT 2.0 made it a much more developer friendly language.
    - Quarrelsome 1y ago
      Most orgs don't transition to 2.0 which is a big part of why XSLT sucks. > but it's not unlike how you have to change your thinking for functional programming generally I'd write lisp any day of the week over XSLT. I don't think XSLT deserves a place alongside other functional languages because its bound so tightly to xml. Sure, one can argue it has its place when processing XML but I'd pick a general purpose language and process XML with that over XSLT every time.
      - willseth 1y ago
        You keep making assertions and generalizations without backing them up with anything concrete while simultaneously moving goalposts. In the cases where you do, you’re just wrong: XSLT is not held back by licensing, it doesn’t “require one liners”, and it has supported JSON since 3.0, which has been around for almost a decade.
        Quarrelsome 1y ago
        why the fuck would you want to use it with json. XSLT was held back by licensing, its why everything supports 1.0 and barely anything supports 2.0. If 2.0 was released for free then everything would use 2.0.
        willseth 1y ago
        Why wouldn’t you just Google instead of repeatedly insisting on things that are wrong? https://www.npmjs.com/package/saxon-js https://www.npmjs.com/package/saxon-js https://github.com/Saxonica/Saxon-HE https://github.com/Saxonica/Saxon-HE
        Quarrelsome 1y ago
        well then tell me why .NET's XSLT platform is rooted in 1.0 instead of just saying "no". From my understanding licensing was a factor that played into the reasons why .NET natively remains on 1.0. The transition to 2.0 appeared to have specific friction: why? for reference: I'm not talking about today, I'm talking about that point in time where (for example) .NET could have adopted XSLT 2.0 but chose not to.
        int_19h 1y ago
        .NET didn't transition to XSLT 2.0 for the simple reason that demand wasn't really there. The way they saw it, LINQ was a better all-around option, with XLINQ specifically being an adequate replacement for XPath, and VB even got a bunch of special syntax to work with XML that made it more concise than XSLT in many cases: https://learn.microsoft.com/en-us/dotnet/visual-basic/programming-guide/language-features/xml/overview-of-linq-to-xml https://learn.microsoft.com/en-us/dotnet/visual-basic/progra... That said, it is emphatically not true that XSLT 2+ was somehow license-restricted. I worked at a company that used XSLT 2.0 and XQuery for code generation back in 2006, and we used the free edition with Saxon with no issues - paid versions had some optimizations and features like static type checking which we simply didn't need. For the most part, XSLT 1.0 was "good enough" for most cases when XML was still the primary interchange format, and later JSON took over so there was less incentive for framework providers to spend resources on keeping up-to-date with the standard. Especially since XSLT 2.0 was such a massive leap in many ways, including a different data model that made many existing XSLT 1.0 processors incompatible in ways that required a massive redesign.
willseth 1y ago
Not sure what you mean by licensing failure or “one liner”. Browsers are natively limited to XSLT 1.0 not because of licensing, but because they simply didn’t want to implement the newer versions. However Saxon offers free XSLT 3.0 processors for JS, C, Java, and .NET, so there’s not really a limitation to doing modern XSLT development.
- Quarrelsome 1y ago
  Licensing is just another aspect of friction, contributing to everyone sticking on 1.0 and making it annoying for anyone trying to move forward with XSLT. One liner is a lack of procedural logic in its implementation. Its fine for 1-1 mapping but as it gets used in more complicated scenarios it can be hard to developers to architect a solution because there's no space to breathe.
  - willseth 1y ago
    What specific licensing problems are your referring to that supposedly hold back XSLT? It’s an open spec, anyone can implement it, and there a free processors under MPL license. And what specifically do you mean when you say everything has to be processed as a one liner? I’ve never used an XSLT processor where that was true.
    - Quarrelsome 1y ago
      To gain access to the better toolset you need v2 and v2 costs. Maybe the org doesn't have it, maybe getting a PO for it is annoying, maybe there's friction around getting it installed on a customer site. Perhaps its just a factor which resulted in everyone else sticking on 1.0. But it never took off in the way promised because of it. That it is a fiercely declarative language makes it hard to integrate. Often developers are placed within an architecture that gives them limited options and only being able to use XSLT while trying to integrate other network calls or services is non-trivial and a complete headfuck sometimes, compared with more general purpose languages like python or javascript.
      - 1y ago

lolive 1y ago

Reinventing XML traversal/transformation in JavaScript will lead really fast into abstracting away the recursive tree traversal, then mapping node marchers to functions. Which is 99% what XSLT provides off the shelf.

Quarrelsome 1y ago
many developers just want to have some space to do some extra logic and XSLT doesn't really accommodate for that. You have to deal with the input and create the output without pausing for breath. While this is fine in simple use-cases where the mapping is 1-1 but when the mapping gets more complicated then it becomes difficult to maintain.
- willseth 1y ago
  That’s simply not true. Certainly it can be hard to wrap your head around architecting complex logic in XSLT 1.0, but it's not unlike how you have to change your thinking for functional programming generally. More ergonomic imperative logic and several other features in XSLT 2.0 made it a much more developer friendly language.
  - Quarrelsome 1y ago
    Most orgs don't transition to 2.0 which is a big part of why XSLT sucks. > but it's not unlike how you have to change your thinking for functional programming generally I'd write lisp any day of the week over XSLT. I don't think XSLT deserves a place alongside other functional languages because its bound so tightly to xml. Sure, one can argue it has its place when processing XML but I'd pick a general purpose language and process XML with that over XSLT every time.
    - willseth 1y ago
      You keep making assertions and generalizations without backing them up with anything concrete while simultaneously moving goalposts. In the cases where you do, you’re just wrong: XSLT is not held back by licensing, it doesn’t “require one liners”, and it has supported JSON since 3.0, which has been around for almost a decade.
      - Quarrelsome 1y ago
        why the fuck would you want to use it with json. XSLT was held back by licensing, its why everything supports 1.0 and barely anything supports 2.0. If 2.0 was released for free then everything would use 2.0.
        willseth 1y ago
        Why wouldn’t you just Google instead of repeatedly insisting on things that are wrong? https://www.npmjs.com/package/saxon-js https://www.npmjs.com/package/saxon-js https://github.com/Saxonica/Saxon-HE https://github.com/Saxonica/Saxon-HE
        Quarrelsome 1y ago
        well then tell me why .NET's XSLT platform is rooted in 1.0 instead of just saying "no". From my understanding licensing was a factor that played into the reasons why .NET natively remains on 1.0. The transition to 2.0 appeared to have specific friction: why? for reference: I'm not talking about today, I'm talking about that point in time where (for example) .NET could have adopted XSLT 2.0 but chose not to.
        int_19h 1y ago
        .NET didn't transition to XSLT 2.0 for the simple reason that demand wasn't really there. The way they saw it, LINQ was a better all-around option, with XLINQ specifically being an adequate replacement for XPath, and VB even got a bunch of special syntax to work with XML that made it more concise than XSLT in many cases: https://learn.microsoft.com/en-us/dotnet/visual-basic/programming-guide/language-features/xml/overview-of-linq-to-xml https://learn.microsoft.com/en-us/dotnet/visual-basic/progra... That said, it is emphatically not true that XSLT 2+ was somehow license-restricted. I worked at a company that used XSLT 2.0 and XQuery for code generation back in 2006, and we used the free edition with Saxon with no issues - paid versions had some optimizations and features like static type checking which we simply didn't need. For the most part, XSLT 1.0 was "good enough" for most cases when XML was still the primary interchange format, and later JSON took over so there was less incentive for framework providers to spend resources on keeping up-to-date with the standard. Especially since XSLT 2.0 was such a massive leap in many ways, including a different data model that made many existing XSLT 1.0 processors incompatible in ways that required a massive redesign.

willseth 1y ago

Not sure what you mean by licensing failure or “one liner”. Browsers are natively limited to XSLT 1.0 not because of licensing, but because they simply didn’t want to implement the newer versions. However Saxon offers free XSLT 3.0 processors for JS, C, Java, and .NET, so there’s not really a limitation to doing modern XSLT development.

Quarrelsome 1y ago
Licensing is just another aspect of friction, contributing to everyone sticking on 1.0 and making it annoying for anyone trying to move forward with XSLT. One liner is a lack of procedural logic in its implementation. Its fine for 1-1 mapping but as it gets used in more complicated scenarios it can be hard to developers to architect a solution because there's no space to breathe.
- willseth 1y ago
  What specific licensing problems are your referring to that supposedly hold back XSLT? It’s an open spec, anyone can implement it, and there a free processors under MPL license. And what specifically do you mean when you say everything has to be processed as a one liner? I’ve never used an XSLT processor where that was true.
  - Quarrelsome 1y ago
    To gain access to the better toolset you need v2 and v2 costs. Maybe the org doesn't have it, maybe getting a PO for it is annoying, maybe there's friction around getting it installed on a customer site. Perhaps its just a factor which resulted in everyone else sticking on 1.0. But it never took off in the way promised because of it. That it is a fiercely declarative language makes it hard to integrate. Often developers are placed within an architecture that gives them limited options and only being able to use XSLT while trying to integrate other network calls or services is non-trivial and a complete headfuck sometimes, compared with more general purpose languages like python or javascript.
    - 1y ago