XSLT et alternatives possibles [fermé]

J'ai jeté un œil à XSLT pour transformer un fichier XML en un autre (HTML, etc.). Maintenant, même si je vois qu'il y a des avantages à XSLT (étant un outil standardisé et utilisé), je suis réticent pour plusieurs raisons

• Les processeurs XSLT semblent être assez énormes / gourmands en ressources
• XML est une mauvaise notation pour la programmation et c'est à cela que sert XSLT.

Il ne veut pas troller XSLT ici même si je veux juste souligner ce que je n'aime pas à ce sujet pour vous donner une idée de ce que j'attendrais d'une alternative.

Ayant quelques antécédents en Lisp, je me demande s'il existe de meilleures façons de transformer les arborescences basées sur un lisp. J'ai vu des références à DSSSL, malheureusement la plupart des liens sur DSSSL sont morts, il est donc déjà difficile de voir du code qui l'illustre. Le DSSSL est-il toujours utilisé? Je me souviens que j'avais installé openjade une fois lors de la vérification des trucs docbook.

Le billet de blog de Jeff Atwood semble faire allusion à l'utilisation de Ruby au lieu de XSLT.

Existe-t-il des moyens sensés de faire des transformations XML similaires à XSLT dans un langage de programmation non xml? Je serais ouvert pour entrée sur

• Bibliothèques utiles pour les langages de script qui facilitent les transformations XML
• en particulier (mais pas exclusivement) des langages de transformation de type lisp, ou Ruby, etc.

Quelques choses que j'ai trouvées jusqu'à présent:

• Quelques endroits sur le Web ont indiqué Linq comme une alternative possible. De manière générale, j'ai tout type de classifications, également de ceux qui ont eu la meilleure expérience XSLT.
• Pour le schéma http://cs.brown.edu/~sk/Publications/Papers/Published/kk-sxslt/ et http://www.okmij.org/ftp/Scheme/xml.html

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.

Sans informations supplémentaires sur le contexte, il est difficile de répondre.

Pourtant, je ne comprends pas pourquoi vous ne voulez pas utiliser XSLT. C'est le bon outil pour le travail et puissant. Il est fait spécifiquement pour transformer un XML en un autre.

Les processeurs XSLT semblent être assez énormes / gourmands en ressources

Avez-vous des données solides pour soutenir cela? Avez-vous implémenté la solution à l'aide de XSLT et constaté que XSLT est le goulot d'étranglement qui rend impossible la livraison du produit tout en remplissant toutes les exigences non fonctionnelles liées aux performances?

Sans données statistiques et sans profilage, vous ne pouvez pas raisonnablement affirmer qu'une solution donnée ne fonctionnera pas. Les exigences non fonctionnelles sont-elles suffisamment raisonnables? Préféreriez-vous perdre, disons, dix jours de travail de développeurs pour gagner quelques centaines de millisecondes en remplaçant XSLT par une autre alternative? Cela en vaut-il la peine?

XML est une mauvaise notation pour la programmation et c'est à cela que sert XSLT.

Vous voulez donc transformer un XML en un autre, mais vous ne voulez pas utiliser XSLT parce que "XML est une mauvaise notation"?

Si c'est le fait que vous utilisez XML comme une sorte de langage de programmation qui vous ennuie tellement, ne le voyez pas comme une programmation, mais plutôt comme un tas de règles de transformation.

Vous n'avez même pas besoin d'écrire XSLT à la main. Il existe de nombreux éditeurs ETL qui peuvent vous permettre de mapper graphiquement un XML dans un autre: aucune programmation requise. Certains d'entre eux utilisent XSLT en sortie.

Si vous utilisez XSLT pour générer du XML sur la base du XSLT brut et de certains paramètres que vous transmettez au moteur XSLT, l'utilisation d'une approche XML de modèle est beaucoup plus facile à comprendre et à gérer.

J'ai été sur un projet où Moustache était utilisé pour remplacer XSLT et le résultat était des fichiers XML de base beaucoup plus simples que tout le monde pouvait éditer et ajuster, plutôt que ce travail de projet soit passé à une ou deux âmes courageuses, qui s'asseyaient dans un silence total avec des gouttes de sueur qui coulent ...

L'approche par modèle ne convient pas lorsque le XML de base est également des données valides à part entière et que XSLT est utilisé pour fournir une autre représentation ou un extrait du XML source.

XML n'est pas un langage de programmation

XML est un moyen de transférer / transporter des données.
une instruction XSLT utilise Xpath pour interroger les données d'une manière spécifique et les placer dans un autre objet / document de transport de données.

ET / OU

XSLT peut transformer votre XML en HTML, qui est une autre façon d'afficher / transporter les données contenues dans un document XML.

si vous cherchez à changer le XML ou à créer un document XML, vous pouvez utiliser n'importe quel nombre de langues: C #, VB, Ruby, Etc.

généralement, lorsque vous utilisez un fichier XSLT pour transformer un document XML, vous avez toujours le document XML d'origine, vous ne modifiez pas réellement le document d'origine, vous en créez vraiment un nouveau.

J'ai travaillé sur plusieurs systèmes de traitement XML qui combinent des bibliothèques XSLT avec Java ou C ++ pour les parties où XSLT n'est pas aussi bon. Il existe des bibliothèques qui obtiennent de très bonnes performances XSLT même sur des fichiers XML de 20 Mo. Cependant, XSLT a certaines limitations avec le contexte, les variables et les modèles de chaînes vraiment complexes. Chaque système sur lequel j'ai travaillé avait quelques tâches effectuées en Java / C ++ parce que le contexte était important ou qu'une expression regex complexe était utile. Ma conclusion est que XSLT plus du code supplémentaire dans la langue de votre choix est un bon moyen de transformer XML.