new | ask | show | jobs
msylvest 20 hours ago  [ - ]

I remember admiring the intent of XSLT when it was born. And how difficult it turned out to be to write; using XML framing makes it terse/verbose/arcane, eg. when compared to the compactness of regex/subs.

It is 2025 and now we've got LLMs to write our code - that may actually be a strong argument in favor of keeping XSL(T): It is a useful browser mechanism and LLMs makes it easier to harvest.

Does anybody have experience with LLM-generated XSL(T)?

reacweb 18 hours ago  [ - ]

I have 1 "big" xsl file in a project I maintain. I have fixed an issue this year. I have tried to use chatgpt prompt. The scope was perfect: I had the buggy xsl, the buggy result, the expected result and a clear explanation. It generated syntactically correct code (almost) that did not work because chatgpt does not understand. This was not a complete loss: a good refresher of the syntax, but I had to do the thinking fully alone and found alone how to use "node-set".

My previous change in this file was in 2017 when I replaced xalan by the xslt processor built in java. I was very surprised I had to make the following changes:

    -<xsl:if test="string(serverName)=$sName">
    +<xsl:if test="string(serverName)=string($sName)">

    -<xsl:for-each select="attributeList/attribute[self::attribute!='']">
    +<xsl:for-each select="attributeList/attribute[text()!='']">

    -<xsl:if test="preceding-sibling::Connection[featureType='Receptacle'][position() = 1]/@Name!=@Name or not(preceding-sibling::Connection[featureType='Receptacle'][position() = 1]/node()) ">
    +<xsl:if test="preceding-sibling::Connection[position() = 1]/@Name!=@Name or position()=1">
These incompatibility issues with something I considered to be standard greatly damaged my opinion on xslt.