È difficile valutare le tecnologie quando non ne hai una profonda esperienza, ma ovviamente è esattamente quando devi prendere le tue decisioni, quindi non c'è una risposta semplice a quel dilemma.
Citi due preoccupazioni: prestazioni e usabilità. Proverò ad affrontare entrambi sotto.
Innanzitutto, le prestazioni. Le prestazioni ovviamente dipendono non solo dalla lingua ma anche dall'implementazione e anche dalla competenza degli utenti. Processori XSLT diversi possono variare notevolmente nelle prestazioni e lo stesso processore può variare ampiamente a seconda del modo in cui viene utilizzato (con Saxon, ad esempio, si scopre molto spesso che le persone che hanno problemi di prestazioni lo usano con DOM, che è una combinazione scadente e le prestazioni possono aumentare di dieci volte se si utilizza invece il modello ad albero nativo di Saxon). Quindi il primo consiglio è di non prendere le prestazioni per sentito dire, misurale; e il secondo consiglio è quello di assicurarsi che la persona che effettua la misurazione abbia abbastanza esperienza per non commettere errori sciocchi. Più facilmente a dirsi che a farsi.
In modo grossolano, puoi separare i lavori di trasformazione in due categorie: semplici e complessi. Per trasformazioni semplici, con un buon processore XSLT il tempo è tutto dedicato all'analisi e alla serializzazione e il tempo di elaborazione XSLT difficilmente entra in scena. Poiché qualsiasi altra tecnologia comporta gli stessi costi di analisi e serializzazione, la scelta della tecnologia di trasformazione non farà una grande differenza (tranne forse per la codifica di livello molto basso che utilizza lo streaming, ma non molte persone possono permettersi la programmazione tempo e competenze necessarie per implementarlo). Per trasformazioni complesse su documenti di grandi dimensioni, inizi a riscontrare gli stessi problemi della programmazione SQL: raggiungere buone prestazioni richiede una buona interazione tra le competenze e le conoscenze del programmatore e le capacità dell'ottimizzatore. Come con SQL, è ' È molto facile in un linguaggio di così alto livello scrivere alcune semplici affermazioni che comportano che il processore debba svolgere una grande quantità di lavoro. Ma anche come con SQL, i programmatori che sanno cosa stanno facendo faranno molto meglio dei principianti.
Secondo, usabilità. La sintassi basata su XML per XSLT è molto scoraggiante per molte persone al primo incontro con la lingua. Ma ci sono buone ragioni e vantaggi reali per farlo in questo modo: c'è l'argomento "template", secondo cui gran parte del codice è costituito da XML da scrivere nel documento di risultato e il modo migliore per scrivere XML è in XML. E c'è l'argomento "riflessione"; in grandi sistemi complessi, è molto comune trovare fogli di stile che generano fogli di stile. Poi c'è l'argomento "strumenti"; se ti trovi in un negozio XML, probabilmente hai molti strumenti XML come gli editor diretti dalla sintassi, ed è bene poter usare gli stessi strumenti per gestire i tuoi programmi e i tuoi dati. Gli svantaggi si rivelano piuttosto estetici rispetto: s il numero di sequenze di tasti coinvolte nella modifica (facilmente risolvibile con un buon strumento di modifica) e la verbosità del codice (che riduce la sua leggibilità). La verbosità è notevolmente ridotta in XSLT 2.0 con l'introduzione di caratteristiche come le espressioni regolari e le funzioni del foglio di stile: molti fogli di stile sono ridotti della metà o di un terzo quando sfruttano appieno XSLT 2.0.
La tua menzione di DSSSL mi lascia con un sorriso ironico. Non ho mai usato DSSSL, ma le storie che ho sentito sono state insensate perché la sua sintassi era arcana e non correlata alla sintassi dei dati (SGML). L'uso di una sintassi XML per XSLT è stato fortemente motivato dall'esperienza con DSSSL.
Ci sono persone che adorano XSLT e ci sono persone che lo odiano. Non sorprende che coloro che lo usano molto tendano a rientrare nella prima categoria. A chi non piace è generalmente chi non ha imparato a "pensare in modo XSLT". Si potrebbe sostenere che un linguaggio di programmazione non dovrebbe influenzare il modo in cui si pensa, ma lo fa: scrivere in un linguaggio basato su regole richiede una mentalità diversa dalla scrittura in un linguaggio imperativo. La prima reazione di molti programmatori è che si sentono meno in controllo (descrivendo il problema, piuttosto che dire al computer cosa fare passo dopo passo). È molto simile alla reazione che hai visto quando le persone sono state introdotte per la prima volta a SQL. In questi giorni, le persone imparano SQL in precedenza nella loro carriera, quindi è necessario un minor riaggiustamento mentale.
Alla fine, dovresti scegliere una tecnologia basata su criteri misurabili oggettivi, non su reazioni di amore / odio. È difficile effettuare tali misurazioni. Ma ci sono molte persone che usano XSLT in modo molto intenso e con grande successo, quindi non c'è dubbio che possa essere fatto.