Il est difficile d'évaluer les technologies lorsque vous n'en avez pas une expérience approfondie, mais bien sûr, c'est exactement à ce moment-là que vous devez prendre vos décisions, il n'y a donc pas de réponse simple à ce dilemme.
Vous citez deux préoccupations: les performances et la convivialité. Je vais essayer de répondre aux deux ci-dessous.
Tout d'abord, la performance. Les performances dépendent bien sûr non seulement de la langue mais aussi de l'implémentation, et aussi de l'expertise des utilisateurs. Différents processeurs XSLT peuvent varier considérablement en termes de performances, et le même processeur peut varier considérablement en fonction de la façon dont il est utilisé (avec Saxon, par exemple, les personnes qui ont des problèmes de performances se retrouvent très souvent à l'utiliser avec DOM, qui est une mauvaise combinaison et les performances peuvent être multipliées par dix si vous utilisez plutôt le modèle d'arbre natif de Saxon). Donc, le premier conseil est de ne pas prendre la performance sur du ouï-dire, la mesurer; et le deuxième conseil est de s'assurer que la personne qui effectue la mesure a suffisamment d'expérience pour ne pas commettre d'erreurs idiotes. Plus facile à dire qu'à faire.
En gros, vous pouvez séparer les travaux de transformation en deux catégories: simples et complexes. Pour les transformations simples, avec un bon processeur XSLT, tout le temps est consacré à l'analyse et à la sérialisation et le temps de traitement XSLT entre à peine en ligne de compte. Étant donné que toute autre technologie va entraîner les mêmes coûts d'analyse et de sérialisation, le choix de la technologie de transformation ne fera pas une grande différence (sauf peut-être très pour le codage de très bas niveau utilisant le streaming, mais peu de gens peuvent se permettre la programmation temps et compétences nécessaires pour la mettre en œuvre). Pour les transformations complexes sur des documents volumineux, vous commencez à rencontrer les mêmes problèmes qu'avec la programmation SQL: atteindre de bonnes performances nécessite une bonne interaction entre les compétences et les connaissances du programmeur et les capacités de l'optimiseur. Comme avec SQL, c'est ' s très facile dans un langage aussi avancé d'écrire quelques instructions simples qui obligent le processeur à effectuer une très grande quantité de travail. Mais comme pour SQL, les programmeurs qui savent ce qu'ils font feront bien mieux que les novices.
Deuxièmement, la convivialité. La syntaxe basée sur XML pour XSLT est très rebutante pour beaucoup de gens lors de leur première rencontre avec le langage. Mais il y a de bonnes raisons et de réels avantages à le faire de cette façon: il y a l'argument "modèle", qu'une grande partie du code se compose de XML à écrire dans le document résultat, et la meilleure façon d'écrire XML est en XML. Et il y a l'argument de la "réflexion"; dans les grands systèmes complexes, il est très courant de trouver des feuilles de style qui génèrent des feuilles de style. Ensuite, il y a l'argument "tools"; si vous êtes dans une boutique XML, vous disposez probablement de nombreux outils XML tels que des éditeurs orientés syntaxe, et il est bon de pouvoir utiliser les mêmes outils pour gérer vos programmes et vos données. Les inconvénients se révèlent assez cosmétiques en comparaison: s le nombre de touches impliquées dans l'édition (facilement corrigé avec un bon outil d'édition), et il y a la verbosité du code (réduisant sa lisibilité). La verbosité est considérablement réduite dans XSLT 2.0 avec l'introduction de fonctionnalités telles que les expressions régulières et les fonctions de feuille de style: de nombreuses feuilles de style sont réduites de moitié ou d'un tiers lorsqu'elles tirent pleinement parti de XSLT 2.0.
Votre mention de DSSSL me laisse avec un sourire ironique. Je n'ai jamais utilisé DSSSL, mais les histoires que j'ai entendues étaient qu'il était inutile car sa syntaxe était obscure et sans rapport avec la syntaxe des données (SGML). L'utilisation d'une syntaxe XML pour XSLT était fortement motivée par l'expérience avec DSSSL.
Il y a des gens qui aiment le XSLT et il y a des gens qui le détestent. Sans surprise, ceux qui l'utilisent beaucoup ont tendance à tomber dans la première catégorie. Ceux qui ne l'aiment pas sont généralement ceux qui n'ont pas appris à "penser à la manière XSLT". Vous pourriez faire valoir qu'un langage de programmation ne devrait pas affecter votre façon de penser, mais c'est le cas: écrire dans un langage basé sur des règles prend un état d'esprit différent de l'écriture dans un langage impératif. La première réaction de nombreux programmeurs est qu'ils se sentent moins en contrôle (décrivant le problème plutôt que de dire à l'ordinateur quoi faire étape par étape). C'est très similaire à la réaction que vous aviez l'habitude de voir lorsque les gens ont été initiés à SQL. De nos jours, les gens apprennent SQL plus tôt dans leur carrière, donc il y a moins de réajustement mental requis.
En fin de compte, vous devez choisir une technologie basée sur des critères objectifs mesurables et non sur des réactions d'amour / haine. Il est difficile de faire ces mesures. Mais il y a beaucoup de gens qui utilisent XSLT de manière très intensive et très réussie, donc il ne fait aucun doute que cela peut être fait.