Pourquoi XSLT n'a-t-il jamais vu la popularité de nombreuses autres langues apparues pendant le boom Internet? [fermé]

Question

L’utilisation de XSLT (XML Stylesheet Language Transform) n’a jamais connu la même popularité que beaucoup d’autres langues parues pendant le boom Internet. Bien qu’il soit utilisé, et dans certains cas par de grandes entreprises prospères (comme Blizzard Entertainment), il n’a jamais semblé s’étendre au grand public. Pourquoi pensez-vous que c'est?

Answer 1

Un problème est que XSLT a l'air compliqué. Tout développeur doit pouvoir choisir les constructions de langage, car il existe des analogues dans la plupart des autres langues. Le problème est que les constructions et les données ont exactement la même apparence, ce qui rend difficile la distinction entre les deux, ce qui rend XSLT plus difficile à lire que d’autres langues.

Un deuxième problème est que ses utilisations sont plus limitées que d’autres langues. XSLT est excellent dans ce qu'il fait; faire des transformations compliquées ou radicales sur XML. Mais cela ne s’applique pas à un aussi large éventail de problèmes que d’autres langues, il n’est donc pas utilisé autant.

Troisièmement, de nombreux langages de programmation ont leurs propres bibliothèques pour transformer XML. La plupart du temps, lorsque vous travaillez avec XML, vous n'avez besoin que de petites modifications ou de simples recherches. Le code XML est probablement également généré ou utilisé par un programme que le développeur écrit déjà dans un autre langage. Ces facteurs font que l’utilisation des utilitaires intégrés à une langue est tout simplement plus pratique.

Un autre problème auquel tous ces problèmes contribuent est l’inertie. C’est-à-dire que les gens ne le savent pas, ils ne voient pas qu’ils en ont vraiment besoin, alors ils l’évitent comme une solution s’il existe une autre option.

Vous vous retrouvez avec un langage qui est le dernier choix de nombreux développeurs lors de la création de solutions. Il est probable que XSLT soit même évité alors que ce serait le meilleur outil pour le travail.

Answer 2

Les XSLT utilisent une programmation fonctionnelle - une chose à laquelle la plupart des programmeurs ne sont pas habitués (ce qui explique pourquoi certaines personnes la considèrent non intuitive, je suppose).

Answer 3

À mon avis, l’un des problèmes les plus gênants dans le langage XSLT standard (je parle de XSLT 1.0 car c’est la seule version que j’ai utilisée) est le manque de prise en charge des transformations de chaîne et de certaines manipulations de base des fonctions date-heure.

Une chose que je ne comprendrais jamais, c’est pourquoi une fonction telle que translate () a été conçue et implémentée dans xpath alors que d’autres fonctions plus utiles, telles que replace , to_lower , < em> to_upper, ou - soyons fous - les expressions régulières ne l'étaient pas.

Certains de ces problèmes ont été résolus avec eXSLT (xslt étendu?) pour les analyseurs syntaxiques autres que MSXML de Microsoft. . Je dis, je suppose, car je ne l’ai jamais utilisé car il a été déclaré incompatible avec MSXML.

Je ne comprends pas pourquoi XSLT 1.0 a été conçu avec ce principe que la manipulation de "texte" n'était pas dans la portée du langage quand il est évident que lorsque vous convertissez des fichiers, vous ne pouvez pas éviter ces problèmes de conversion de chaîne (par exemple: : transforme une date mal cadrée donnée au format américain en format français, du 31/1/2008 au 31/01/2008) hein ...

Ces problèmes de manipulation de texte étaient généralement très simples et facilement résolus dans MSXML en permettant l’extension de XSL avec des fonctions JScript: vous pouvez appeler une fonction JScript pour effectuer certains traitements, comme vous le feriez pour tout modèle XSL, mais j’ai toujours trouvé que solution inélégante et a fini par créer mes propres bibliothèques de modèles XSL. D'abord parce que la méthode JScript a cassé votre portabilité XSL, puis parce que cela vous a obligé à mélanger votre logique de programmation: certains bits dans une expression XPath / XSLT pure et d'autres dans la notation DOM / object avec JScript.

Le fait de ne pas disposer de variables pouvant être mises à jour est une autre limite qui est très déroutant pour les nouveaux arrivants. Certaines personnes ne surmontent tout simplement pas cela et continuent à se débattre avec cela. Dans certains cas simples, vous pouvez avoir des solutions de contournement avec une combinaison de modèles paramétrés et d'appels récursifs (par exemple, pour implémenter un compteur croissant ou décroissant), mais avouons-le, la récursivité n'est pas si naturelle.

Je pense avoir entendu dire que toutes ces limitations étaient abordées dans la spécification XSLT 2.0. Malheureusement, MS a décidé de ne pas l'implémenter et de promouvoir XQuery à la place. C'est triste, pourquoi ne pas mettre en œuvre les deux? Je pense que XSLT aurait tout de même de bonnes chances de devenir aussi populaire que CSS est devenu HTML. Quand vous y réfléchissez, la partie la plus difficile de l'apprentissage de XSLT est XPath, le reste n'est pas aussi difficile que de comprendre le comportement en cascade en CSS, et le CSS est devenu si populaire ...

Donc, à mon avis, c’est le manque de toutes ces petites choses mentionnées ici et le temps qu’il a fallu pour les aborder dans XSLT 2.0 (avec même pas MS pour le soutenir de toute façon) qui a conduit à cette situation d’impopularité. Comme je souhaite que MS décide de l’appliquer après tout ...

Answer 4

Parce que la plupart des implémentations XSLT ont une empreinte mémoire importante (je suppose que cela est dû à la conception du langage), parce que les gens avaient tendance à abuser de XSLT pour toutes sortes de choses pour lesquelles il n'était pas particulièrement adapté et purement déclaratif. nature de XSL qui rend certains types de transformations assez difficiles.

Answer 5

C’est génial pour XML, mais pas pour un codage typique. Il manque de concepts de base typiques (variables mutables) et rend ce qui devrait être simple assez complexe (ou impossible). La plupart de ses problèmes proviennent du fait que XML est un excellent langage de représentation de données, mais pas un bon langage de programmation. Cela étant dit, je l'utilise quotidiennement et je le recommande lorsque cela fait sens. En conjonction avec les espaces de noms externes, cela peut être rendu plus utile (appels à java, etc.). En fin de compte, c’est une autre langue à apprendre et de nombreux développeurs préfèrent s’en tenir à quelque chose auquel ils sont habitués ou qui leur ressemble.

Answer 6

Parce qu'il est plus facile d'écrire et de gérer du code utilisant Java, C #, JavaScript, etc. pour désérialiser un flux XML, le transformer et exporter la sortie souhaitée, XSLT n'offre aucun avantage de performance substantiel.

XSLT facilite les choses, mais rend les choses très très difficiles.

Answer 7

Eh bien ... Peut-être parce que c’est pénible d’écrire des xslts ... j’ai dû écrire quelques xslts il ya quelques mois et je rêvais de crochets pointus ...

<Really> 
    <No>
        <fun/>
    </No>
</Really>         

(Je sais que ce n'est pas xslt)

Answer 8

En règle générale, le nombre de fois où il vous sera demandé de transformer des données XML en une forme différente de données XML sans aucun autre traitement ne sera très limité. Habituellement, XML est utilisé comme intermédiaire entre deux systèmes distincts, l'un d'entre eux étant généralement personnalisé pour traiter la sortie de l'autre. En tant que tel, il est plus simple d'écrire l'un des systèmes pour traiter la sortie XML de l'autre sans l'étape supplémentaire consistant à effectuer une transformation.

Answer 9

XSL est courant et largement adopté. De quelles autres langues parlez-vous? XSL n'est pas un langage de programmation, mais un simple langage de transformation . Son étendue est donc plutôt limitée.

Answer 10

Je pense que cela se résume à la syntaxe XML qui est sans doute bonne pour décrire les données, mais ce n'est pas une syntaxe parfaite pour ce qui est essentiellement un langage de programmation (XSLT).

Answer 11

Comme indiqué précédemment, XSLT (comme "les bonnes parties" de JavaScript) est un langage de programmation fonctionnel. La plupart des programmeurs traditionnels détestent cet apatridie. Aussi, trop de programmeurs traditionnels détestent les crochets.

Mais, plus important encore, une utilisation correcte de XSLT résout le problème de génération d'interface graphique déclarative et de liaison de données pour le serveur Web d'une manière indépendante de la plate-forme. Les fournisseurs tels que Microsoft ne sont pas motivés pour célébrer cet & # 8220; inconvénient & # 8221; pouvoir.

Toutefois, je dirai que Microsoft dispose du meilleur support XSLT pour l'IDE (Visual Studio) au monde.

Answer 12

Je pense qu’il a essayé de couvrir un trop grand nombre de cas d’utilisation, devenant ainsi une langue complète de Turing (ou du moins l’ai-je entendu). Si vous essayez de faire une transformation non triviale, vous finirez par écrire des boucles complexes, des conditions ... dans un langage laid et verbeux, ce qui est mieux fait avec une GPL.

À mon avis, cette complexité rend difficile l’écriture d’une implémentation correcte de XSLT et limite les choix disponibles. Par conséquent, une utilisation généralisée parmi les pirates vocaux qui aiment souvent bricoler avec du code petit et efficace, pas du code d’entreprise.

Answer 13

XSLT est très puissant, mais nécessite une autre façon de penser au problème. Cela s'est également compliqué la vie en ne fournissant pas de fonctionnalités de données utiles dans les premières versions. Prenons par exemple une méthode de style ToUpper (), vous l'implémentez généralement avec quelque chose comme:

<xsl:variable name="lcletters">abcdefghijklmnopqrstuvwxyz</xsl:variable>
<xsl:variable name="ucletters">ABCDEFGHIJKLMNOPQRSTUVWXYZ</xsl:variable>  

<xsl:value-of select="translate($toconvert,$lcletters,$ucletters)"/>

Pas le moyen le plus simple de coder!

Answer 14

xslt est idéal pour XML à XML, lorsque vous avez des données déjà échappées et une définition claire des entrées et des sorties. L’utiliser pour des choses comme xml2html m’apparaît comme un casse-tête, et avec presque tous les langages dynamiques et CSS, la sortie est beaucoup plus facile à mettre en œuvre avec style.

Answer 15

Je trouvais cela formidable pour "l'architecture de services Web composites". Parfois, plusieurs services Web fonctionnent ensemble pour obtenir la sortie finale. Lorsque ces services Web doivent communiquer entre eux via XML, XSLT peut transformer le message XML d'un formulaire à un autre.