Discussion :

[Hibou57]

Bonsoir,

Nous conaissons tous/toutes le fameux XSLT. Je le trouve pratique, je l'utilise aussi. Mais il faut reconnaître que pour des manipulations complexes, on est vite confronté(e)s à de véritables problèmes digne de la programmation pure et simple, ... et il se trouve que dans le genre langage de programmation, XSLT n'est pas ce qu'il y a de mieux

Je me dis que dans le fond, XSLT ne devrait peut-être pas être utilisé comme application de transformation dans une chaîne XML, mais qu'il devrait plutôt être utilisé presque seulement comme les feuilles CSS, c'est à dire attaché comme feuille de style à un fichier XML. Il existe encore d'anciens navigateurs qui ne traitent pas XML, et encore moins XSLT, et ceux qui le traitent, affiche de telles pages moins rapidement que les classiques pages HTML. Mais l'idée reste bonne pour les files RSS par exemple (si on veut donner une présentation à un fil RSS ouvert dans un navigateur, on a pas d'autres choix que de l'associer à une feuille XSLT).

Mais pour la production de fichiers HTML à partir de fichier XML, je trouve qu'il est encore préférable de faire la transformation directement, et de publier des pages HTML toutes faites. Et donc, même dans ce cas, on se retrouve alors dans la situation d'une chaîne XML.

Et si on tiens compte des avis exprimé plus haut sur les piètres qualités de XSLT en temps que langage de programmation, alors on se dit que les cas où XSLT est vraiment incontournables sont en nombres plutôt limités.

Je pense qu'on me ferait remarquer que XSLT est pratique pour diffuser/distribuer des transformation, car il est plus facile de distribuer une feuille XSLT, que de distribuer une application... sur plusieurs plates forme et OS.

Mais cela n'est-il pas une mauvaise solution ? En effet, elle reviens finalement à reporter le problème d'un domaine (la portabilité des applications à travers les platformes), vers une autre domaine qui ne lui a rien demandé : les feuilles de styles XML ? Et si XSLT doit effectivement son succès aux problèmes de portabilité des applications, alors on peut sourire d'une telle aberration (l'art de rejeter un problème ailleur).

N'y at-il pas de quoi être convaincu que le plus important est le concept de transformation XML, et non pas XSLT ?

De votre coté, qu'en est-il ? Quels sont vos habitudes ? Comment justifiez-vous la solution XSLT plutôt qu'une autre solution ? Ou comment à l'inverse défendez-vous la solution logiciel plutôt que la solution (trop évidente) XSLT ?

J'espère qu'il y aura beaucoup de réponse passionantes et passionées

EDIT: vu que j'ai voté XSLT + autres, et que je dis qu'il faut précisez... alors je précise « Autres » pour moi c'est parser maison.

[Erwy]

Bonsoir,

Nous conaissons tous/toutes le fameux XSLT. Je le trouve pratique, je l'utilise aussi. Mais il faut reconnaître que pour des manipulations complexes, on est vite confronté(e)s à de véritables problèmes digne de la programmation pure et simple, ... et il se trouve que dans le genre langage de programmation, XSLT n'est pas ce qu'il y a de mieux

Tu as des exemples, parce que j'ai quand même programmé un paquet avec XSLT/ js coté client et ASP/XSLT coté serveur et c'était tout à fait l'inverse.

Ca me simplifiait nettement la vie au niveau programmation surtout pour ce qui est complexe ...
Quand aux options du sondage

XSLT est un langage spécailisé(comme prolog...) pour la transformation/traitement de donnée XML
DOM sert généralement à créer ou extraire de la donnée XML
Le langage de programmation de support est la pour recuperer et transferer la donnée (souvent encore non xml).

Si tu répartis mal les tâches il est certain qu'il va y avoir bloquage

[Hibou57]

Tu as des exemples, parce que j'ai quand même programmé un paquet avec XSLT/ js coté client et ASP/XSLT coté serveur et c'était tout à fait l'inverse.

Sans donner de code d'exemple, je trouve que la manière de faire les passages de paramètres aux template est un peu lourde.

Code XSLT :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
<xsl:template name="template1">
	<xsl:param name="param1"/>
	<xsl:variable name="var2">
	   <xsl:call-template name="template2">
	      <xsl:with-param name="param2">
	         <xsl:value-of select="..."/>
	      </xsl:with-param>
	   </xsl:call-template>
	</xsl:variable>
... etc, etc

un langage de programmation standard fait ça de manière beaucoup plus lisible.

La façon dont se comportent les « variables », la manière dont se passe les importations, la syntaxe qui rend peu lisibles et longs des codes déjà pourtant longs, etc, etc.

La manière de créer des noeuds de document en JavaScript, est beaucoup plus simple par exemple, alors que JavaScript n'est déjà pourtant pas une merveille de langage.

Dans XSLT, ce qui est bon, c'est le mode d'accès aux noeuds (XPath), mais pas le mode de traitement de ces noeuds.

Un langage est adapté à un type de traitement, et ainsi Prolog est-il par exemple bien adapté à tout ce qui s'exprime en terme de pattern-matching (il serait d'ailleur tout à fait le bienvenue pour faire de la transformation XML aussi lui...). Lisp est adapté partout où dans la représentation algoritmique les fonctions peuvent être des données, et les données êtres des fonctions. Ces deux exemples de langages spécialisés montrent qu'aucun des deux ne se justifie par le format des données sur lesquels ils travaillent, mais seulement par la manière dont-ils les traitent, c'est-à-dire l'algorithme qui est appliqué. Il en va de même de la programmation procédurale classique, ou de la programmatiobn par objets.

Alors peut-être que XSLT correspond bien à certains traitement typiques sur les fichiers XML, mais ils ne convient surement pas à tous, parce que ce n'est pas pour la raison qu'on traite du XML que XSLT est adapté, mais pour la raison qu'on applique tel ou tel algorithme de traitement. Et voilà.... XSLT n'est peut-être pas adapté à tous.

D'ailleurs, si c'était vraiment le format des données que l'ont traite qui était le plus important, dans se cas certains personnes diraient qu'un fichier XML c'est un fichier texte, et donc que le langage de traitement le mieux adapté doit être Perl... bof.

Ce qui est peut-être le plus important, c'est d'avoir un DOM pour l'accés à la source, un DOM pour écrire le résultat... quoique même là, ça dépend encore de l'organisation des donnée en entrée ou en sortie. Parce que même si le DOM facilite la tâche dans tous les cas, il y en a dans lesquels ils ne montrent pas d'avantages particuliers.

Il faut comprendre que la question n'est pas de savoir si XSLT peut le faire, parce qu'il a été démontré que XSLT a toutes les caractéristique d'une machine de Turing, et qu'il permet donc de coder tous les algorithmes imaginables. Mais cela, cela on peut le dire de Prolog, de Lisp, de Pascal, ... la question n'est pas de savoir s'il peut le faire ou pas, mais de savoir s'il le fait de la meilleure manière, de la manière la plus sible et de la plus facile à maintenir. C'est sûrement parfois le cas, mais pas toujours, et tout dépend du traitement effectué pour passer d'un neoud d'entrer à un noeud de sortie.

Et quand tu dis

Le langage de programmation de support est la pour recuperer et transferer la donnée (souvent encore non xml).

Ca revient à la même chose. Mais avec le bémol que les données peuvent être déjà XML, et les langage de programmation de support n'en être pas moins justifié. Parce qu'en quoi est-ce le format des données qui justifiie XSLT ? Le format des données justifie XPath (ou quelque chose qui y ressemble), mais ne justifie pas XSLT.

[Erwy]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
   <xsl:call-template name="template2">
	      <xsl:with-param name="param2">
	         <xsl:value-of select="..."/>
	      </xsl:with-param>
	   </xsl:call-template>

C'est quoi ton truc

la syntaxe normale

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
   <xsl:call-template name="template2">
	      <xsl:with-param name="param2" select="..">
	  </xsl:call-template>

etc...
Tu permettras qu'avec de tels exemples j'ai de sacré doute sur tout le reste parce que c'est vraiment la base là

Pour le reste j'ai une grande expérience de DOM et de XSLT, et quand je te lis, j'ai surtout l'impression que tu manipules mal XSLT

[Hibou57]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
   <xsl:call-template name="template2">
	      <xsl:with-param name="param2">
	         <xsl:value-of select="..."/>
	      </xsl:with-param>
	   </xsl:call-template>

C'est quoi ton truc

Oui, bon ... elle est correcte cette syntaxe, et elle exprime exactement la même chose que l'autre manière dont tu l'écris. Et ce n'est pas ça qui fera la différence et qui changera quoi que ce soit aux arguments précédents.

[Erwy]

Oui, bon ... elle est correcte cette syntaxe

Non, elle fonctionne dans la plupart des cas ce qui est totalement différent mais au prix d'un coup certain (et générateur d'erreur) puisque tu viens de passer ta variable en type fragment node.

XSLT fonctionne sur le mécanisme de la template, qui n'est d'ailleurs pas utilisé que pour XML mais qui lui est particulièrement adapté .

D'ailleurs, si c'était vraiment le format des données que l'ont traite qui était le plus important, dans se cas certains personnes diraient qu'un fichier XML c'est un fichier texte, et donc que le langage de traitement le mieux adapté doit être Perl... bof.

dans ce cas la pourquoi utilisé des balises et un arbre DOM

Comparer DOM et XSLT , aucun intérêt, comme déjà dit il n'ont pas du tout les même finalités si on les utilise l'un à la place de l'autre ...
Puis j'ai déjà vu de l'utilsation de DOM pour la transformation , et coté performance,simplicité, généricité, reutilisabilité et maintenance ça ne peut tenir que face à des personnes qui manque d'expérience dans le sujet

A la limite c'est avec XQuery qu'on peut rapprocher DOM puisque l'on est sur sur un langage d'extraction/creation (priorité quand même un peu inversé par rapport à DOM) de donnée (qui lui n'est donc pas basé sur template mais sur une logique plus séquentielle à rapprocher du PL/SQL d'oracle pour ceux qui connaissent) mais cette norme est encore insuffisament développé même si de + en + (Oracle,DB2,MS SQL.... entre autre pour les bases;Saxon,Cocoon et d'autre outils indépendant )

[Hibou57]

Non, elle fonctionne dans la plupart des cas ce qui est totalement différent mais au prix d'un coup certain (et générateur d'erreur) puisque tu viens de passer ta variable en type fragment node.

Mais c'est un noeud texte, ce n'est pas comme si c'était un élément. Je serais surpris que la conception du processeur n'en tienne pas compte. En fait je l'écris comme ça parce que c'est plus générique. Et même sur mon ordi trés lent (c'est un nouveau concept ) ça ne se fait pas ressentir en terme d'efficacité.

dans ce cas la pourquoi utilisé des balises et un arbre DOM

Mais c'est bien ce que je disais : j'avais dit « dans ce cas certains personnes diraient ». Et je n'ai jamais dit que le DOM ne sert à rien, puisqu'au contraire j'insistait même sur son rôle centrale (c.f. les options du sondage). Ce que je disais, c'est que le choix de tel ou tel langage pour exprimer un traitement, dépend du traitement, et non pas du format des données sur lesquels on travail, puisque de toute façon le format de donnée peut être interfacé. Mieux encore même : le DOM étant une représentation « objet », alors un langage à objets et tout bien venue pour ce type de travail. Et donc XSLT n'est pas une solution unique, et ne devrait pas utiliser XSLT parce que c'est XML,mais plutôt aborder la question comme on le ferait avec n'importe quelle autre type d'application : choisir le langage en fonction du traitement ou des raisons technique -- maintenant, je disais justement que je pense que ce sont surtout des raisons techniques qui font systématiquement choisir seulement XSLT... et que ces raisons technique ne sont peut-être pas nécéssairement les meilleurs (bon, j'arrête là, parce que je parle de plusieurs choses, et on ne va plus arriver à suivre)

Puis j'ai déjà vu de l'utilsation de DOM pour la transformation , et coté performance,simplicité, généricité, reutilisabilité et maintenance ça ne peut tenir que face à des personnes qui manque d'expérience dans le sujet

A ce que je vois, il est toujours aussi aimable « monsieur je sais tout, je ne doute de rien, les autres sont tous des nuls »... Est-ce que toi-même tu es certain de bien connaître ces technologies alternatives ? Est-ce que tu es certain que les personne qui les ont mise en oeuvre sont les meilleurs exemples en la matière ? Il te suffit d'un cas pour te faire une idée ?

Qu'un langage à objet ne soit pas adapté pour travailler quelque chose qui a naturellement une bonne interface à objets, serait quand-même étrange.

A la limite c'est avec XQuery qu'on peut rapprocher DOM puisque l'on est sur sur un langage d'extraction/creation (priorité quand même un peu inversé par rapport à DOM) de donnée (qui lui n'est donc pas basé sur template mais sur une logique plus séquentielle à rapprocher du PL/SQL d'oracle pour ceux qui connaissent) mais cette norme est encore insuffisament développé même si de + en + (Oracle,DB2,MS SQL.... entre autre pour les bases;Saxon,Cocoon et d'autre outils indépendant )

Mmmhhhh.... mais on est dans un tout autre sujet ici.

Sinon, personne ici pour témoigner de son expérience de la transformation XML avec autre chose qu'XSLT ? Pourtant je sais qu'il y en a ..... (et que je ne suis donc pas le seul). A moins que ce ne soit que des secrets industriels ?

Et puis le sondage ne mord pas non-plus... n'ayez pas peur (j'y ai touché moi-même, et j'ai toujours tous mes doigts)

[Erwy]

Mais c'est un noeud texte, ce n'est pas comme si c'était un élément. Je serais surpris que la conception du processeur n'en tienne pas compte.

Totalement faux
Il y a 5 types en xpath/xslt
- nodeset
- string
- number
- Booleen
- fragment node

Dans une variable ou un paramètre , quand on crée en dehors de l'attribut select on crée un fragment node, type qui à disparu de la version 2.0 à cause des pb qu'il peut généré et de son manque d'intér^t hors cas particulier(en 2.0 c'est trnsformé en node-set).

Quand on utilise une fonction xpath ou xslt, ou qu'on cherche à appliquer un template, XSLT tente de "retyper" la donnée, en utilisant par exemle la valeur textuel pour les node-set
Hors le fragment-node est assez particulier et le typage "automatique" peut engendrer des erreurs, raison pour laquel dans la norme , quand est obligé de l'utilisé, il est conseiller de forcer le type à l'aide des fonction number ou string.

En fait je l'écris comme ça parce que c'est plus générique.

Mais c'est une ânerie monumentale là , et ça n'a rien de + générique c'est au contraire très vivement déconseillé, on doit utiliser les attributs select et même si ça te fait plaisir de le croire je n'exagère en rien, j'ai eu ma part de galère avec ce genre de chose


Ecoute tu peux disserter pendant 3 heures sur le sujet du XSLT, mais la tu commets une erreur grave de débutant, tu n'arrives pas à le reconnaitre, et ton argumentaire pour l'expliquer renvoi à d'autres ereurs de même niveau.L'ensemble montre bien que tu ne maitrise pas du tout les bases de ce langage.
Ne comprenant visiblement pas ceci comment veux-tu qu'on prenne ton raisonnement au sérieux car même si ta démarche est logique et "sérieuse" elle repose sur des bases fausses.
Avant de te lancer dans de grands raisonnements sur le sujet, je te conseille de sérieusement rebosser le langage XSLT.
Si tu as besoin d'aide sur certains points il te suffit de poster ici, on essaiera de t'expliquer en fonctions de nos disponibilté.

[Hibou57]

Je ne sais même pas d'ou tu va me chercher que cette construction est déconseillée .... cette construction est dans tous les manuels XSLT. Est-elle marqué obsolete ou depracated ?

Avant de te lancer dans de grands raisonnements sur le sujet, je te conseille de sérieusement rebosser le langage XSLT.

Beh non, bien sûr je n'y ai rien compris.... et quand je les fais tourner, ce qui en sort est produit par la volonté du saint esprit (je joue au dés à chaque fois).

Et si je parle d'application dédié à la transformation, c'est seulement parce que je suis maso, et le débat est clos.

En attendant, les témoignage de ceux/celles qui ont expérimenter les techniques alternative est toujours le bien venu.

[Erwy]

Je ne sais même pas d'ou tu va me chercher que cette construction est déconseillée .... cette construction est dans tous les manuels XSLT. Est-elle marqué obsolete ou depracated ?

Non, on est obligé de l'utiliser dans certains cas, maintenant le risque d'erreur est noté dans la norme , cherche et tu trouveras .

Beh non, bien sûr je n'y ai rien compris.... et quand je les fais tourner, ce qui en sort est produit par la volonté du saint esprit (je joue au dés à chaque fois).

Ce n'est pas parce que quelqu'un est capable de réaliser des choses simples, sans que cela tienne au hasard, qu'il maitrise le langage pour autant.
Hors , contrairement à la légende, il est assez facile d'utiliser XSLT sans en comprendre la moitié, tant qu'on se cantonne aux choses simples.
C'est toi qui te surestime grandement et qui à une mauvaise connaissance des normes. Cf par exemple le lien erroné que tu faisais entre cdata et sgtml dans une autre discussion et ta croyance ici dans le standart de ton écriture des paramètres

Quant au manuel pourri ou obsolète ce n'est pas ce qui manque sur le sujet (je te conseille d'ailleurs de vérifier le namesapce des exemples utilisés, ce ne serait pas la première fois que la version draft serait utilisé comme support, j'ai déjà trouvé des tutoriels écris après son abandon qui l'utilisait ), papier ou sur le net(même si ça la c'est bien pire) Ce n'est pas pour rien que j'ai été obligé de me rabattre sur la norme pour apprendre , et je ne suis pas le seul dans ce cas malheureusement.

Pour le reste, je pense que j'ai discuté avec suffisamment de gens de ce "milieu" , de langue française ou anglaise (forum,conférence...), dont certains reconnus et avoir une bonne connaissance/expérience technique acquis par des années d'utilisations intensives pour avoir une idée fiables des "bonnes pratiques". Peut tu en dire autant , toi qui m'accuse de ne connaître qu' "un seul cas" ?

[GrandFather]

"Ce que peut faire XSLT tout autre langage peut le faire". Certes... Maintenant, je soutiens que ce que peut faire XSLT aucun autre langage ne peut le faire de manière aussi efficace en terme d'ingénierie (coût de développement, de déploiement et de maintenance du code). XSLT n'est pas non plus la panacée universelle, et n'est pas obligatoirement accolé à XML dans tous les contextes ; par contre, dans une architecture multitiers, on le rencontre fréquemment dans la couche présentation, et ce n'est pas un hasard ou un pis-aller...

XSLT a quelques caractéristiques qui le distingue d'autres langages conventionnels type Pascal, tout de même. A l'instar des langages fonctionnels, les variables sont immutables ; l'absence d'effets de bord supprime toute une catégorie de bugs potentiels. La récursivité est au coeur du langage, ce qui favorise l'élaboration d'algorithmes plus élégants que leurs équivalents itératifs, et est bien adapté au concept des templates.

Le mécanisme d'importation des templates offre des possibilités de POO (l'appel aux templates "importés" se faisant avec xsl:apply-imports) et une bonne réutilisation du code.

En ce qui concerne ton sondage, comparer XSLT (un langage) à DOM (une API) ne me semble pas très pertinent... Au passage, DOM n'est qu'une possibilité de représentation interne d'un document XML - certes la plus répandue - parmi d'autres, souvent plus conformes aux standards de la POO ; il existe ElementTree pour Python, RubyXML pour Ruby, etc.

[Erwy]

l'absence d'effets de bord supprime toute une catégorie de bugs potentiels.

Sur ce point il serait intéressant de voir si c'est toujours vérifié en XSLT 2.0.
L'ajout de certains points ,comme le typage plus fort par exemple, fait que certains le considère comme un langage différent de xslt 1.0 , et il est possible que certaines caractéristiques de ce dernier aient de fait disparu.
Mais la je manque de pratique sur le 2.0 pour juger

[alain.couthures]

Comparer XSLT à un langage 3G, c'est comme comparer un L4G (SQL par exemple) à un L3G.

XSLT est bien adapté à la problématique de la manipulation des données et à leur présentation selon un format donné. On y retrouve tout un contexte d'applications de gestion où il n'y a pas de calcul mathématique particulier. Toute la logique exprimée avec XSLT en fait un outil très puissant mais pas forcément hyper efficace.

Alors, oui, pas de temps réel ou de traitements scientifiques pointus en XSLT mais cela laisse bien d'autres sujets où, là, XSLT est superbe !

Je pense que le problème est surtout que l'on n'a pas de normalisation XML pour faire autre chose que lire un document sur fichier ou sur serveur Web. Cela impose d'utiliser un L3G pour faire tout ce qu'il faut autour... C'est pour ça que j'ai fait mon petit projet OpenSource pour rajouter les quelques commandes élémentaires et écrire ainsi des scripts XML s'appuyant sur des transformations XSLT successives.

[Erwy]

Alors, oui, pas de temps réel ou de traitements scientifiques pointus en XSLT mais cela laisse bien d'autres sujets où, là, XSLT est superbe !

Il y a eu de grosses améliorations de ce point de vue en 2.0, grâce aux nombreux ajouts de xpath 2.0.
XSLT rajoute aussi dans ce style un système de parsage de string
Et je crois qu'on peut créer des fonctions aussi , le méchanisme utilisé par exslt,(comme l'avait prévu le draft xslt 1.1 que certains proc comme msxml implémente) mais là je suis moins sûr

[Hibou57]

Non, on est obligé de l'utiliser dans certains cas, maintenant le risque d'erreur est noté dans la norme , cherche et tu trouveras .

C'est dommage que tu n'ai pas donné d'exemples de telles erreurs, ça aurait rendue ta réponse encore plus interessante.

Ce n'est pas parce que quelqu'un est capable de réaliser des choses simples, sans que cela tienne au hasard, qu'il maitrise le langage pour autant.

Parenthèse: j'ai dit que j'utilisais beaucoup XSLT, mais je n'ai jamais que j'étais un spécialiste des moindres recoins de ce langage (et je ne suis spécialiste des moindres recoins de rien du tout.... c'est impossible)

Hors , contrairement à la légende, il est assez facile d'utiliser XSLT sans en comprendre la moitié, tant qu'on se cantonne aux choses simples.

Oui, bon, enfin, il n'y a pas de vrai légende qui tienne, mais des gens qui sauront toujours mysthifier pour mieux impressionner. Et au sujet d'XML, le besoin de mysthifier pour donner l'impression d'être le rois des sorcier, ce besoin n'a pas manqué chez certaines personnes.... et par contamination, XSLT a été touché. Mais personne ne crois vraiment que ces technologie soient complexes, et elles sont mêmes conçus pour être simple (tant qu'on n'entre pas dans certains détails).

C'est toi qui te surestime grandement

Re-parenthèse : arrête s'il te plaît, tu t'es assez vanté pour que cette réplique me fasse rire (je ne me vante pas, je parle passionément, ça n'est pas du tout la même chose)

et qui à une mauvaise connaissance des normes.

Si tu es en est encore à cette syntaxe, ne fait pas dire et croire à ceux qui lisent ce fil, que cette norme dit ce qu'elle norme dit ce qu'elle ne dit pas. Cette syntax est dans la documentation XML... les tutoriaux (que tu n'aime pas), et la référence officielle.

Cf par exemple le lien erroné que tu faisais entre cdata et sgtml

Il ne s'agissait absoluement pas d'une interpretation de la norme dans le cas de ce topic, mais d'une interprétation d'aprés l'usage qui en est fait concrêtement, et qui est ambigü. Et ca n'a pas été démentie.

dans une autre discussion et ta croyance ici dans le standart de ton écriture des paramètres

Mais encore une fois : c'est dans le standard!. Le processeur XSLTProc qui interpréte mes instruction n'est quand-même pas une fantaisie d'interprétation sortie d'on ne sait où....

Toi ensuite tu dis que c'est dangereux : soit, mais donne des exemples alors. Il ne s'agit pas de moi (je sais que tu n'aime pas ma vision des choses), mais aussi des autres personnes qui lisent ce fil...

Quant au manuel pourri ou obsolète ce n'est pas ce qui manque sur le sujet (je te conseille d'ailleurs de vérifier le namesapce des exemples utilisés, ce ne serait pas la première fois que la version draft serait utilisé comme support, j'ai déjà trouvé des tutoriels écris après son abandon qui l'utilisait )

Là c'est vrai, et il faut mettre ça sur le compte du fait que XSLT est courament utilisé depuis pas si longtemps dans le fond. En 1995/1996 il existait les même problème avec HTML. Il y a eu des working-draft, il y avait une attente, ou plutôt une impatience, des documents ont été écrits, et ils sont resté en ligne, mais il n'y avait peut-être pas toujours une mauvaise intention au départ. Si tu veux envois un mail aux webmaster concerné, pour soit leur demandé de mettre à jour, soit de retirer la mise en ligne pour ne pas induire les internautes en erreur.

En plus.... pour les name-spaces, c'est un sujet récurrent, et surtout avec les fonctions, comme le traitement des dates, etc... il y a toujours des problèmes de name-space. Parce que tous le monde veut y aller de son ajout... et voilà.

Peut tu en dire autant , toi qui m'accuse de ne connaître qu' "un seul cas" ?

Erwy, t'es « chiant » : je parlais de ton expérience des cas de transformations basés sur d'autres technique (comme celle reposant sur des langages procéduraux traditionel). Dis moi franchement : tu en connais beaucoup ? .... je n'ai pas eu l'impression, parce que j'y ai reconnu des impressions de deception comme ont peu en connaître avec n'importe quoi d'autres. Sincèrement, qu'à l'execution un langage interprété (ce qu'est XSLT), soit moins rapide et moins efficace qu'un langage compilé, je n'y crois pas... ou alors c'est que l'application a été mal conçus, ou que cette technique a été appliqué au mauvais cas. Le processeur (je parle de celui de la machine), est toujours plus rapide qu'un interpreteur qui repose sur ce même processeur... ça va de soit (je ne garde que cet argument, parce qu'il est impossible a contester, et je ne reviens pas sur ceux qui m'interessaient vraiment).

"Ce que peut faire XSLT tout autre langage peut le faire". Certes... Maintenant, je soutiens que ce que peut faire XSLT aucun autre langage ne peut le faire de manière aussi efficace en terme d'ingénierie

Quand-même une petite chose : XSLT repose sur une application qui interpréte ce langage, et on en puit formellement en déduire que toute autre application écrite pour la même machine peut donc fournir le même travail (je reviens dans le détail plus loin).

(coût de développement, de déploiement et de maintenance du code).

Beh oui, c'est ce que je disais dans le post d'ouverture, et je soutenais qu'il existe des cas ou le cout et la question du déploiement se présente d'un tel manière que XSLT n'est pas la solution unique, et même que d'autre peuvent éventuellement être meilleure.

on le rencontre fréquemment dans la couche présentation, et ce n'est pas un hasard ou un pis-aller...

Oui, quand on attache directement une feuille XSLT à un document XML, comme on attacherait une feuille CSS à un document HTML. Mais même là, ça peut poser problème (je pensais au cas des navigateurs pas tous compatible, ou compatible mais inefficace), et rien n'interdit que la présentation soit pré-produite, et non pas produite à la demande du document, ni même que quand elle est produite à la demande du document, qu'elle le soit avec XSLT.

XSLT a quelques caractéristiques qui le distingue d'autres langages conventionnels type Pascal, tout de même. A l'instar des langages fonctionnels, les variables sont immutables ; l'absence d'effets de bord supprime toute une catégorie de bugs potentiels.

Oui, ça supprime les risque de bug du genre « effet de bord innatendu », mais ça peut en ajouter en multipliant le nombre de variables requises. Et les variables immutables sont justement une des choses qui me gênent avec XSLT.

La récursivité est au coeur du langage, ce qui favorise l'élaboration d'algorithmes plus élégants que leurs équivalents itératifs, et est bien adapté au concept des templates.

Il y a beaucoup d'autres langage qui permettent la récursivité... c'est même la règle depuis longtemps et ceux qui ne la permettent pas sont plutôt des étrangeté... alors ce n'est pas un avantage révolutionnaire, c'est plutôt le minimum sans lequel on rierait de ce langage.

Le mécanisme d'importation des templates offre des possibilités de POO (l'appel aux templates "importés" se faisant avec xsl:apply-imports) et une bonne réutilisation du code.

Beh non, justement. Et si tu as une recette, je la veux bien, parce que justement je trouve que c'est pas pratique (je vais me replonger dans mes feuilles pour retrouver le détails de ce qui me posait problème, et j'essaierai de le simplifier pour le poster ici shématiqument). apply-imports, c'est bien une des choses dont j'attendais beaucoup, et pour lesquelles la deception a été à la hauteur de l'attente. Et c'est une des principales raisons pour lesquelle me penche maintenant vers le langage traditionnel : réutilisé avec la modularité.

En ce qui concerne ton sondage, comparer XSLT (un langage) à DOM (une API) ne me semble pas très pertinent... Au passage, DOM n'est qu'une possibilité de représentation interne d'un document XML - certes la plus répandue - parmi d'autres, souvent plus conformes aux standards de la POO

Qu'est-ce qui ne te parraît pas ortodox dans le DOM ? (quand tu ne dis que ça ne correspond pas à l'esprit orienté objet).

Sinon, pour le sondage, je pensais une transformation qui consiste en la transformation d'un DOM en un autre DOM (duqel on générerait un autre document)

Comparer XSLT à un langage 3G, c'est comme comparer un L4G (SQL par exemple) à un L3G.

Un langage L(n)G est le plus souvent implémenté dans un langage L(n-1)G, et donc le langage L(n-1)G peut fournir le même travail.

La différence est dans la facilité avec laquelle on va pouvoir encoder les instruction et spécifier ce travail. Tu va me dire alors : dans ce cas, on fait tout en assembleur. Non, parce que les langage comme Ada ou Pascal, sont des langage dignent de ce nom, et il peuvent faire tout ce que peut faire un langage L999999G, pour peu que l'on utilise les bonnes librairie. Et si tu te penche sur les « design patterns », tu découvrira un concept qui s'appel interpréteur, et qui te confortera dans l'idée qu'on peut tout faire à partir de ce niveau de langage. Le pattern interpréteur : c'est comme si on créait une machine avec des objets, et cette machine est spécialisé dans l'execution de jeux d'instructions complexes et spécialisé, et dispose d'une sytaxe ou de construction qui permet d'exprimer des suite d'instruction dédié à un domaine particulier, d'une manière qui est naturel à ce domaine particulier.

[Erwy]

Bon on va reprendr pour les fragment node


l'avertisssement de la norme

NOTE:When a variable is used to select nodes by position, be careful not to do:
<xsl:variable name="n">2</xsl:variable>
...
<xsl:value-of select="item[$n]"/>
This will output the value of the first item element, because the variable n will be bound to a result tree fragment, not a number. Instead, do either
<xsl:variable name="n" select="2"/>
...
<xsl:value-of select="item[$n]"/>
or
<xsl:variable name="n">2</xsl:variable>
...

Ce type se justifie parfois

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
	<xsl:with-param name="a">
	<xsl:choose>
		<xsl:when test="TT">1</xsl:when>
		<xsl:otherwise>2</xsl:otherwise>
	</xsl:choose>
	</xsl:with-param>

Plus rare parce que cela n'est réellement utilisable que via un xsl:copy

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
	<xsl:with-param name="a">
		<a>
			<xsl:value-of select="2"/>
		</a>
	</xsl:with-param>

Mais en dehors de ceci, les fragments nodes (ou result tree fragement) sont à éviter
Il suffit de lire leur description pour comprendre pourquoi

11.1 Result Tree Fragments
Variables introduce an additional data-type into the expression language. This additional data type is called result tree fragment. A variable may be bound to a result tree fragment instead of one of the four basic XPath data-types (string, number, boolean, node-set). A result tree fragment represents a fragment of the result tree. A result tree fragment is treated equivalently to a node-set that contains just a single root node. However, the operations permitted on a result tree fragment are a subset of those permitted on a node-set. An operation is permitted on a result tree fragment only if that operation would be permitted on a string (the operation on the string may involve first converting the string to a number or boolean). In particular, it is not permitted to use the /, //, and [] operators on result tree fragments. When a permitted operation is performed on a result tree fragment, it is performed exactly as it would be on the equivalent node-set.

When a result tree fragment is copied into the result tree (see [11.3 Using Values of Variables and Parameters with xsl:copy-of]), then all the nodes that are children of the root node in the equivalent node-set are added in sequence to the result tree.

Expressions can only return values of type result tree fragment by referencing variables of type result tree fragment or calling extension functions that return a result tree fragment or getting a system property whose value is a result tree fragment.

Tout ceci donne d'énorme problème de visibilité sur le contenu entre autres (en plus des risques d'erreurs ) qui font que la pratique en a extèmement limité l'usage et que XSLT 2.0 l'a carrément fait disparaître

je parlais de ton expérience des cas de transformations basés sur d'autres technique (comme celle reposant sur des langages procéduraux traditionel). Dis moi franchement : tu en connais beaucoup ?

D'autres methodes ques API et XSLT pour presenter/transformer, je t'en cite 3 sans même réflechir par ordre d'ancienneté
- application de css : peu puissant, peu supporté ,abandonné
- XML data island : peu efficace, jamais réellement fini de mettre en oeuvre,presque pas supporté, abandonné
- Le sytème de template de XUL, un peu l'equivalent de XSLT : réussit d'être encore plus verbeux en étant beaucoup moins puissant et limité au RDF

Et c'était sans chercher uniquement basé sur mon expérience propre, il y en a eu d'autres des tentatives à la noix...

[Hibou57]

l'avertisssement de la norme

Code XSLT :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
<!-- NOTE:When a variable is used to select nodes by position, be careful not to do: -->
<xsl:variable name="n">2</xsl:variable>
...
<xsl:value-of select="item[$n]"/>
<!-- This will output the value of the first item element, because the variable n will be bound to a result tree fragment, not a number. Instead, do either -->
<xsl:variable name="n" select="2"/>
...
<xsl:value-of select="item[$n]"/>

Mais en dehors de ceci, les fragments nodes (ou result tree fragement) sont à éviter

Alors en fait tu souligne l'importance de ne pas confondre fragment et expression ?

D'autres methodes ques API et XSLT pour presenter/transformer, je t'en cite 3 sans même réflechir par ordre d'ancienneté
- application de css : peu puissant, peu supporté ,abandonné
- XML data island : peu efficace, jamais réellement fini de mettre en oeuvre,presque pas supporté, abandonné
- Le sytème de template de XUL, un peu l'equivalent de XSLT : réussit d'être encore plus verbeux en étant beaucoup moins puissant et limité au RDF

Et c'était sans chercher uniquement basé sur mon expérience propre, il y en a eu d'autres des tentatives à la noix...

CSS : Le CSS est limité, c'est sûr (on ne peut faire aucune modification de la structure par exemple)... disont que c'est pratique pour présenter un fichier XML avec autre chose que le traditionel arbre à balise (du genre de ce qu'affiche Internet Explorer quand on lui fait ouvir un XML). Mais en même temps, le CSS n'a jamais eu d'autre prétention, et on ne peut pas lui en vouloir ne pas pouvoir faire de transformation.
XML Data Island : je ne connais que de nom...
XUL : c'est limité, plutôt pour les interface utilisateur, et en plus c'est une application de XML, et non pas du traitement de XML (pour ce que j'en sais)
Si tu pensais que je pensais à ça... beh non, je ne pensais pas du tout à ça. Et à part le CSS sur du XML, je n'utilise jamais rien de tout ça.

[alain.couthures]

Je trouve que XSLT apporte une autre approche à l'informatique : il ne s'agit pas d'exécuter un ensemble d'instructions selon certains paramètres, il s'agit de transformer des données en entrée en données en sortie.

Je ne suis pas d'acoord sur la confusion des générations : j'ai pu faire l'expérience de former des non informaticiens à un L4G puis à un L3G et j'ai constaté qu'un L4G est finalement bien plus facile à comprendre chez certains. La différence vient entre savoir ce que l'on veut et savoir comment faire ce que l'on veut.

Avec XSLT on s'appuie sur un outil parfaitement logique pour ne se préoccuper que de cette logique. Les L3G sont très répétitifs, il faut toujours plusieurs instructions pour faire des traitements basiques. Une feuille de style XSLT va en très peu de balises décrire un traitement pour lequel un langage 3G demandera beaucoup d'instructions d'où un risque d'erreurs plus important en 3G...

Tout cela ne peut se faire qu'au détriment des performances mais ce n'est pas toujours si grave d'attendre un peu quand c'est pour la perfection !

[Hibou57]

Avec XSLT on s'appuie sur un outil parfaitement logique pour ne se préoccuper que de cette logique. Les L3G sont très répétitifs, il faut toujours plusieurs instructions pour faire des traitements basiques.

(on bifurque, mais l'air de rien, on est toujours dans le sujet ) La différence est effectivement bien là, et alors tu devrait aussi bien pouvoir en conclure que selon le type de publique la préférence ne sera pas la même. D'ailleur il arrive aussi que pour comprendre un L4G on explique ce qu'il fait en terme de L3G (mais c'est vrai qu'avec XSLT, il ne serait pas approprié de le présenter comme ça).

Maintenant, XSLT, qui est un langage trés évolué (ce qui ne signifie pas supérieur, je précise pour qui nous lirait), porte la transformation en lui (puisqu'il est un langage dédié à ça). Mais quand on a une transformation à l'esprit et que la logique de cette transformation s'exprime assez naturellement en langage procédurale ou à objets, alors qu'elles raisons verrai tu de ne pas utiliser ce langage à la place ?

Parce que ce qui fait de XSLT un bon choix, c'est qu'il exprime bien ce qu'il exprime. Et alors logiquement, si tu imagine des cas ou les opérations sur le document source s'exprime clairement en langage procédurale (ce n'est pas difficile à imaginer, une application base de données en est un exemple... Erwy ne pourra pas nier), alors pourquoi se priver d'exprimer les choses en langage procédurale ?

Je me faisais une reflexion en marchant aussi : XML va se développer de plus en plus, et inévitablement donc, la multiplicité des solutions d'intégration viendra avec. Et donc XSLT ne restera sûrement pas une solution unique pour tout le monde. Faire croire que c'est la seule solution légitime, et que si vous ne l'utilisez pas, vous êtes « out », alors c'est risquer de faire reculer des personnes qui auraient put intégrer XML à leur manière, et se dire « finalement non », parce qu'en leur disant que XSLT est la solution unique, si leurs solution n'est pas XSLT, ce sera comme leur dire que XML n'est pas adapté à leur cas. Ce serait dommage.... (transformer du XML n'implique pas XSLT)

[Erwy]

Alors en fait tu souligne l'importance de ne pas confondre fragment et expression ?

Soit plus clair et développe ,s'il te plait.
Je ne comprends pas l'interprétation que tu en fait

XUL : c'est limité, plutôt pour les interface utilisateur, et en plus c'est une application de XML, et non pas du traitement de XML (pour ce que j'en sais)

Je ne parles pas de XUL lui même.
Je parles de son langage/module de template pour RDF , pas la même chose.

Si tu pensais que je pensais à ça...

Je ne cherches pas ce à quoi tu penses....
Tu me demandes d'autres cas , je t'en donnes , faudrait savoir....