XSLT et alternatives possibles
J'avais consulté XSLT pour transformer un fichier XML en un autre (HTML, etc.). Maintenant, alors que je vois qu'il y a des avantages à XSLT (un outil normalisé et utilisé), je suis réticent pour deux raisons
- Les processeurs XSLT semblent être assez énormes/affamés de ressources
- XML est une mauvaise notation pour la programmation et c'est ce que XSLT est tout à propos.
Il ne veut pas troll 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.
Avoir des antécédents Lisp, je me demande s'il existe de meilleurs moyens pour les transformations de structure arborescente basée sur certains LISP. J'ai déjà vu des références à DSSSL, malheureusement, la plupart des liens sur DSSSL sont morts, donc il est déjà difficile de voir du code qui l'illustre. DSSSL est-il toujours utilisé? Je me souviens que j'avais installé Openjade une fois lors de la vérification de la documentation.
Publication du blog de Jeff Atwood semble indiquer en utilisant Ruby au lieu de XSLT.
Y a-t-il des moyens sains de faire des transformations XML similaires à XSLT dans une langue de programmation non XML? Je serais ouvert à l'entrée sur
- Bibliothèques utiles pour les langages de script qui facilitent les transformations XML
- surtout (mais pas exclusivement) des langues de transformation de type LISP, ou rubis, etc.
Quelques choses que j'ai trouvées jusqu'à présent:
- Quelques endroits sur le Web ont souligné Linq comme une alternative possible. Tout à fait, je 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'avez pas d'expérience profonde d'entre eux, mais bien sûr, c'est exactement lorsque vous devez prendre vos décisions, il n'y a donc aucune réponse simple à ce dilemme.
Vous citez deux préoccupations: performance et convivialité. Je vais essayer de traiter ci-dessous.
Premièrement, performance. L'exécution bien sûr dépend non seulement de la langue, mais également de la mise en œuvre, ainsi que sur l'expertise des utilisateurs. Différents processeurs XSLT peuvent varier considérablement dans la performance, et le même processeur peut varier considérablement en fonction de la manière dont il est utilisé (avec Saxon, par exemple, les personnes qui ont des problèmes de performance sont très souvent trouvées à l'utiliser avec DOM, qui est une mauvaise combinaison et la performance peut augmenter dix fois si vous utilisez plutôt le modèle d'arborescence natif de Saxon). Donc, le premier conseil n'est pas de prendre des performances sur le dossier, de la mesurer; Et le deuxième conseil est de s'assurer que la personne qui fait la mesure a suffisamment d'expérience pour ne pas faire des erreurs stupides. Plus facilement dit que fait.
Crossely, vous pouvez séparer des emplois de transformation en deux catégories: simple et complexe. Pour des transformations simples, avec un bon processeur XSLT, l'heure est entièrement consacrée à l'analyse et à la sérialisation et le temps de traitement XSLT n'entre guère dans l'image. Étant donné qu'une autre technologie va engager les mêmes coûts d'analyse et de sérialisation, le choix de la technologie de transformation ne va pas faire une grande différence (sauf peut-être très pour le codage de très bas niveau à l'aide de streaming, mais pas de nombreuses personnes peuvent se permettre la programmation. temps et compétences nécessaires pour mettre en œuvre cela). Pour des transformations complexes sur des documents importants, vous commencez à obtenir les mêmes problèmes que la programmation SQL: la réalisation de bonnes performances nécessite une bonne interaction entre les compétences et la connaissance du programmeur et les capacités de l'optimiseur. Comme avec SQL, il est très facile dans une langue aussi de haut niveau d'écrire quelques déclarations simples qui entraînent le processeur qui devait faire une très grande quantité de travail. Mais aussi comme avec SQL, les programmeurs qui savent ce qu'ils font feront beaucoup mieux que les novices.
Deuxièmement, la convivialité. La syntaxe XML basée sur XSLT est très inactivée à beaucoup de personnes lors de la première rencontre avec la langue. Mais il y a de bonnes raisons et des avantages réels pour le faire de cette façon: il y a l'argument "modèle", que beaucoup de code consiste en XML à écrire dans le document de résultat, et le meilleur moyen d'écrire XML est en XML. Et il y a l'argument "reflet"; Dans de 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 "Outils"; Si vous êtes dans un magasin XML, vous avez probablement beaucoup d'outils XML, tels que les éditeurs dirigés par 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 être assez cosmétiques en comparaison: il y a le nombre de frappes de frappe impliquées dans la modification (facilement corrigée 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 des expressions ordinaires et des fonctions de la feuille de style: de nombreuses feuilles de style sont réduites à une moitié ou une troisième de taille 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 que cela n'était pas sacré parce que sa syntaxe était arcanique et non liée à la syntaxe des données (SGML). L'utilisation d'une syntaxe XML pour XSLT a été fortement motivée par l'expérience avec DSSSL.
Il y a des gens qui aiment 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 n'aiment pas que ce sont généralement ceux qui n'ont pas appris à "penser à la manière de XSLT". Vous pouvez faire valoir qu'un langage de programmation ne devrait pas affecter la façon dont vous pensez, mais cela fait: écrire dans une langue basée sur des règles prend une mentalité différente de l'écriture dans une langue impérative. 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). Il est très similaire à la réaction que vous aviez l'habitude de voir quand les gens ont été présentés pour la première fois à SQL. De nos jours, les gens apprennent SQL plus tôt dans leur carrière, il y a donc moins de réajustement mental.
En fin de compte, vous devez choisir une technologie basée sur des critères mesurables objectifs, pas sur les réactions d'amour/haine. Il est difficile de faire ces mesures. Mais il y a beaucoup de gens utilisant XSLT très intensément et très avec succès, il ne fait aucun doute que cela peut être fait.
Sans informations supplémentaires sur le contexte, il est difficile de répondre.
Néanmoins, je ne comprends pas pourquoi vous ne voulez pas utiliser XSLT. C'est le bon outil pour le travail et un puissant. Il est fait spécifiquement de transformer un XML en un autre.
Les processeurs XSLT semblent être assez énormes/affamés de ressources
Avez-vous des données difficiles à soutenir cela? Avez-vous mis en place la solution à l'aide de XSLT et a constaté que XSLT est le goulot d'étranglement qui empêche le produit tout en remplissant toutes les exigences non fonctionnelles liées à la performance?
Sans données statistiques et profilage, vous ne pouvez pas raisonnablement affirmer qu'une solution donnée ne fonctionnera pas. Les exigences non fonctionnelles sont-elles assez raisonnables? Voulez-vous vous gaspiller, dire dix jours de travail des développeurs pour gagner quelques centaines de millisecondes en remplaçant XSLT par une autre alternative? Ça vaut ça?
XML est une mauvaise notation pour la programmation et c'est ce que XSLT est tout à propos.
Donc, vous voulez transformer un XML en un autre, mais vous ne voulez pas utiliser XSLT car "XML est une mauvaise notation"?
Si c'est le fait que vous utilisiez XML comme une sorte de langage de programmation qui vous énerve tellement, ne vous voyez pas en programmation, mais plutôt 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 laisser mapper graphiquement un XML en another: aucune programmation n'est requise. Certains d'entre eux utilisent XSLT comme sortie.
Si vous utilisez XSLT pour générer XML basé sur le XSLT brut et certains paramètres que vous passez au moteur XSLT, vous utilisez une approche XML modèles, c'est beaucoup plus facile à comprendre et à entretenir.
J'ai été sur un projet où Moustache a été utilisé pour remplacer XSLT et que le résultat a été beaucoup plus simple des fichiers XML de base que tout le monde pouvait éditer et ajuster, plutôt que ce travail de projet étant transmis à une ou deux âmes courageuses , qui s'asseoirait au silence total avec des perles de sueur coulant ...
L'approche du modèle ne convient pas à une utilisation lorsque la base XML est également des données valides à part entière et que XSLT est utilisé pour fournir une représentation alternative, ou un extrait de la source XML.
J'ai travaillé sur plusieurs systèmes de traitement XML combinant des bibliothèques XSLT avec Java ou C++ pour les parties que XSLT n'est pas aussi bonne. Il existe des bibliothèques qui obtiennent une très bonne performance XSLT même sur 20 Les fichiers XML MB, Toutefois, XSLT a une limitation de contexte, de variables et de modèles de cordes vraiment complexes. Chaque système que j'ai travaillé a eu quelques choses en Java/C++, car le contexte était important ou une expression de regex complexe a contribué. My empreinte est que XSLT Plus un code supplémentaire dans votre langue de choix est un bon moyen de transformer XML.
XML n'est pas un langage de programmation
XML est un moyen de transférer/transport de données.
Quelle instruction XSLT utilise XPath pour interroger les données de manière spécifique et la mettre dans un autre objet/document de transport de données.
et/o
XSLT peut transformer votre XML en HTML, ce qui est un autre moyen d'afficher/de transporter les données contenues dans un document XML.
si vous souhaitez modifier le XML ou créer un document XML, vous pouvez utiliser n'importe quel nombre de langues: C #, VB, Ruby, etc.
habituellement, 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.