Discussion :

[Erwy]

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 ?

Va falloir être un peu plus clair là parce que je ne comprends rien et je serais étonné d'être le seul.

L'interfaçage BDD c'est ce que je fais tout les jours, et je préfère de loin utiliser le XSLT à toutes les étapes, même avec des données non XML à la base. Je suis sur oracle qui comme toutes les autres grosses BDD fournisent des outils simples pour récuperer le resultat d'une requête SQL en XML(PL/SQL,XSQL....) , après je traite en XSLT, plus simple, plus modulaire, plus puissant . Je gère même parfois des jointure de resultat de requêtes sql en XSLT parce que le coup est moindre que de trafiquer la requête SQL( quand c'est possible, ce qui n'est pas toujours le cas >>jointure externe sur jointure externe).

[Hibou57]

Va falloir être un peu plus clair là parce que je ne comprends rien et je serais étonné d'être le seul.

Je t'accorde que ce n'est pas le meilleur exemple, mais j'ai voulu autant que possible prendre un exemple que quelqu'un ici pourrait comprendre : toi.

Le détail : je ne parlais pas de l'interfacage, mais du traitement de la requête lui-même, c'est à dire la production du résultat : je ne pense pas que le traitement de la requête soit fait par une programme XSLT. C'est vrai que quand je dis base de donnée, on pourra me répondre qu'il n'y aucun rapport avec les transformation, parce qu'on se dit « une base de donnée c'est une base de donnée ». Et pourtant évaluer une requête dans un document XML, c'est faire un traitement sur ce document, et ce traitement est fait par une application binaire, pour des raisons d'efficacité et de spécialisation, et parce que ces traitements s'expriment bien en langage procédurale.

Et il se trouve qu'une transformation effectue des sortes de requêtes aussi (c'est comme ça je construit les transformation dans ma tête en tous cas), et produit un résultat en sortie à partir de ce qu'elle extrait du document source. Ce n'est sûrement pas ma meilleur idée que d'avoir pris cette exemple, mais il est encore un cas qui suggère qu'une transformation, c'est une transformation, c'est-à-dire qu'il y a un document en entré, et un résultat en sortie (qui peut être n'importe quoi d'ailleur). Entre les deux, il y a un traitement (et une transformation est un traitement), et rien n'impose à ce traitement d'être codé en XSLT (je répète toujours la même chose, je sais, mais chaque fois différement.... l'intérêt est là... enfin, j'espère que c'est interessant ).

J'ai eu tord je crois de ne l'avoir pas encore dit explicitement : si j'ai ouvert ce fil, c'est surtout parce que je m'étonne d'un certain automatisme en la matière (comme s'il n'existait rien d'autre). Et je ne pense pas que cet automatisme soit justifié... je veut seulement ouvrir des portes, et sûrement pas jeté l'opprobre sur XSLT (jaime bien XSLT, mais je n'aime pas l'idée qu'il serait un monopol indiscutable du traitement XML).

[Erwy]

Ce qui correspond à ta description c'est par exmple SQL, un langage de requêtage, hors XSLT n'est pas un langage de requêtage, ni XPath (on considère qu'il lui manque des elements à cet usage) , c'est XQuery qui l'est pour le xml et comme déjà dit ils n'ont pas le même mode de fonctionnement.
Pour le non XML à formatter dans ce sens il y a des outils comme XSQL(oracle), XGQL....
De fait ton exemple est hors sujet de mon point de vue

[GrandFather]

J'ai eu tord je crois de ne l'avoir pas encore dit explicitement : si j'ai ouvert ce fil, c'est surtout parce que je m'étonne d'un certain automatisme en la matière (comme s'il n'existait rien d'autre). Et je ne pense pas que cet automatisme soit justifié... je veut seulement ouvrir des portes, et sûrement pas jeté l'opprobre sur XSLT (jaime bien XSLT, mais je n'aime pas l'idée qu'il serait un monopol indiscutable du traitement XML).

On ne doit pas fréquenter les mêmes équipes de développement... Le recours automatique à XSLT ne me paraît pas si répandu que ça, son style déclaratif perturbe encore beaucoup de développeurs. Pour preuve ce forum, où beaucoup de demandes d'aide ont pour origine une tentative maladroite de plaquer en XSLT des algorithmes paraîssant pourtant "naturels" dans des langages plus "classiques". La courbe d'apprentissage de XSLT est quand même assez pentue ; s'il n'apportait pas une plus-value par rapport à des solutions développées avec des langages classiques, ça ferait longtemps qu'il serait tombé en désuétude.

Le succès de XSLT a d'ailleurs dépassé ses concepteurs. Il est dit en préambule de la spécification de 1999 que XSLT a été conçu pour "préparer" les données d'un format XML quelconque au traitement par un processeur FO, et n'était pas destiné à servir de langage "boite à outils" pour XML. Le fait est que 8 ans après il est encore là et son usage dépasse largement le seul cadre de XSL-FO, et pour longtemps encore. 8 ans, c'est une éternité en informatique...

[Hibou57]

On ne doit pas fréquenter les mêmes équipes de développement... Le recours automatique à XSLT ne me paraît pas si répandu que ça, son style déclaratif perturbe encore beaucoup de développeurs.[...]

Je ne suis pas en équipe moi, alors je ne pouvais pas savoir Je pensais ce que tu dis, ou j'avais des soupscons (je voulais m'en assurer), mais je vois que personne ne semble venir le confirmer dans ce fil (à part ce post que tu viens de faire), et alors cette abscence de réaction dans ce sens me semblait le confirmer.

Réponse à tes suppositions : le style déclaratif n'est pas toujours repoussoir, et c'est même souvent le but recherché, dès que l'on souhaite avoir quelque de clair dans un domaine particulier (il est sûrement dans l'esprit de tous le monde dans ce cas là). Mais comme je disais à Alain, ça ne passe pas nécéssairement par un nouveau langage, mais ça se ressent dans l'organisation du programme, et les commentaires qui l'accompagnent.

Le tours de la question a été fait je pense.... en tous j'y vois beaucoup plus clair dans les visions de chacuns (il n'y a pas eu de chacune ici ...). Je vais marquer le fil comme résolu (résolu pour moi)... ce qui n'empêche pas de continuer à en discuter.

Je crois qu'on pense finalement aux mêmes choses, qu'on a les mêmes penser finalement, mais qu'on ne les exprime pas dans la même langue

[GrandFather]

Réponse à tes suppositions : le style déclaratif n'est pas toujours repoussoir, et c'est même souvent le but recherché, dès que l'on souhaite avoir quelque de clair dans un domaine particulier

Je n'ai jamais dit que c'était un repoussoir. D'autre part, ce ne sont pas des suppositions, mais une constatation personnelle issue de la fréquentation assidue de ce forum et de beaucoup d'autres, des formations que j'ai reçues et celles que j'ai données au sein de mon équipe. XSLT n'a rien d'inaccessible pour un développeur même moyen, c'est juste un mode de réflexion particulier à adopter, qui change un peu de la pratique quotidienne du développement pour la grande majorité d'entre nous.

Beaucoup de gens peu à l'aise avec XSLT vont donc lui préférer systématiquement une solution "traditionnelle" (avec DOM ou autre), pas parce que c'est la solution optimale, juste parce qu'ils sont en terrain connu. A l'inverse, les gens qui ont fait l'effort d'apprendre XSLT et l'ont mis en oeuvre à une échelle importante, connaissent donc bien ses limitations et l'utiliseront généralement à bon escient.

[Hibou57]

Beaucoup de gens peu à l'aise avec XSLT vont donc lui préférer systématiquement une solution "traditionnelle"

J'avais bien compris... seulement XML n'impose pas suffisament de logique propre pour que l'on puisse être si catégorique. Le traitement est avant tout dicté par la logique du document. Puisque l'on parle langage, imagine par exemple un doctype qui représente un langage quelconque, comme Pascal, adapté à XML (pour écrire des programes Pascal en XML). Imagine maintenant que tu veuille faire une transformation sur les source, pour en faire des formes canoniques (à fin d'analyse ou d'audit, par exemple). Donne moi ton avis : est-ce que tu pense que XSLT doit être impérativement utilisé, ou est-ce que tu répondrais qu'un autre choix est une erreur de comprehension de ce que peux apporter XSLT ?

XSLT pourra certainement faire cette transformation.... mais au prix de nombreux détours, et surtout au prix d'une représentation du traitement qui sera totalement étrangère au domaine dans lequel s'applique ce traitement... en tous cas qui ne sera pas naturel, et tu ne peux pas en vouloir à des domaines propres, d'avoir leurs représentations propres. Evidement que XSLT est une bonne vision et une bonne réprentation de certaines opérations. Mais l'important n'est pas d'utiliser XSLT, mais d'utiliser ce qui colle le mieux au domaine cible. N'est-ce pas d'ailleur l'esprit des langages déclaratifs ? (puisque tu met en avant l'aspect déclaratif). Si certains langages (objet ou procéduraux) sont si prégnants dans certains domaines, ce n'est pas uniquement parce que ce sont des langages « système et de bas niveau », mais c'est aussi parce qu'ils ont un caractère déclaratif vis-à-vis de certain domaine.

D'ailleur au passage, quand je parle d'utiliser ces langages pour les domaines auquel je pense pour moi, je ne pense même pas à les utiliser à leur propre niveau, mais à passer par ce que j'exposais à Alain, c'est à dire par des objets et librairies faites pour permettre d'exprimer les chose de manière déclarative. A la base du l'esprit déclaratif, il y a l'assertion (l'énnoncé d'un fait), et un processeur qui évalue des règles avec une base de fait comme argument (cas typique de Prolog par exemple). Et l'assertion est une fonction, .... tu vois ou je veux en venir. Par exemple au tout début ou je m'interessais abstraction informatique, j'avais écris un interpréteur prologue.... qui n'était rien d'autre qu'un programme en langage procédurale, et le « source » qu'il interpretait était un programme lui même procédural, dont le rôle était d'initialiser la base d'assertion. Ce qui est un exemple de l'usage de la programmation procédurale en vue d'obtenir une organisation déclarative.

Avec l'objet, on peut faire du déclaratif, et dans le fond, l'objet c'est le déclaratif universel. Un langage déclaratif ce n'est pas une syntax d'un fichier texte. Mais c'est l'organisation et l'expression d'un problème à résoudre. Et ceci est parfaitement représentable pas une structure d'objets relier entre eux de manière adéquate, et disposant des méthodes adéquates.

XML, et les concepts qui l'entourent, ne dominent pas toujours la logique propre de ce que représente ces documents XML. Les documents ont leur propre logique aussi en plus de tirer partie des avantage d'XML (qui est d'abord d'être un format ouvert et humainement lisible... on peut d'ailleur trés bien faire des XML à la volé, comme ça au feeling, sans aucun doctype)

Et quand tu parle d'allergie ou d'ignorance de la programmation déclarative... il ne faut pas oublier que c'est comme avec la lecture : on ne doit pas se plaindre que les gens n'aiment pas les livres, mais on doit se demander « quels sont les livres qui pourraient amener les gens au livre ». Tu crois pendant longtemps qu'une personne n'aime pas les livres, jusqu'au jours où cette personne découvre un livre qui lui plait énormément. Et là tu comprends que ce n'est pas cette personne qui était en cause, parce que le livre, c'est la communication, et tout le monde aime communiquer..... mais on aime communiquer sur certaines choses et moins sur d'autres. Donc c'est au livre d'aller vers le lecteur, et non pas au lecteur d'aller vers le livre. Parce qu'on ne lis pas n'importe quoi juste pour le plaisir de dire « c'est bien, je lis un livre ». Non, on lis parce qu'on a trouver un livre qui nous passione.

De même : ce n'est pas au gens d'aller au langage déclaratif, mais c'est au langage déclaratif d'aller aux gens.

XSLT est déclaratif et parle à bien à certaines personnes, mais il ne peut pas être le bon langage déclaratif pour tous les domaines (à moins de n'avoir qu'un vision abstraite des documents, et de ne pas avoir à traiter véritablement avec leur signification)

A moins d'avoir l'esprit complétement destructuré, tous le monde fait de la programmation déclarative, et tous le monde exprime les choses de manière déclarative, même à travers un langage procédurale ou à objet.

Comme je l'ai dit : faire croire que XSLT est le seule langage digne et ligitime pour le traitement XML, c'est prendre le risque de faire reculer beaucoup de monde.... et même de faire reculer le plus gros de la foule dont la préoccupation première n'est pas XML ou XSLT, mais plutôt ce que véhicule leurs documents.

Tu parle de ces gens qui ne « comprennent rien au déclaratif et préfèrent les solutions traditionel comme DOM ». Tu pense vraiment qu'il voit le DOM comme une solution ? Beh alors c'est que tu n'as vraiment aucune idée du traitement effectué entre le DOM d'entrée et le DOM de sortie. Non, ce n'est pas le DOM qui est vu comme une solution, mais le traitement qu'il y a entre les deux. Et le DOM lui est une interface convenable qui s'adaptent facilement pour être une entrée et une sortie de ce traitement.

Je recite donc, et je re-répond

Beaucoup de gens peu à l'aise avec XSLT vont donc lui préférer systématiquement une solution "traditionnelle"

J'aurais plutôt dit,

Beaucoup de gens sentent que XSLT est peu à l'aise avec leur domaine, et vont donc lui préférer systématiquement une solution plus "traditionelle" et typique de leur domaine

Ces personnes que tu dis ne pas être à l'aise avec XSLT : quel est le sens des documents sur lesquels elles travaillent ? C'est la question à se poser, et qui expliquerait peut-être bien des choix ...

N.B. Tout ceci n'exclus pas bien sûr que les choix puissent être mauvais, mais il faut débusquer les mauvais choix sur d'autres critère que XSLT/pas-XSLT.... en terme d'efficacité et de clarté aussi. Sans compter l'efficacité technique aussi (vitesse d'execution par exemple), qui peut devoir entrer en compte.

[GrandFather]

Comme je l'ai dit : faire croire que XSLT est le seule langage digne et ligitime pour le traitement XML, c'est prendre le risque de faire reculer beaucoup de monde.... et même de faire reculer le plus gros de la foule dont la préoccupation première n'est pas XML ou XSLT, mais plutôt ce que véhicule leurs documents.

Recadrons un peu. "Traitement XML", ça ne veut rien dire. Il est question de XSLT, donc de transformation, soit la conversion d'un dialecte XML en un autre. Et pour la grande majorité des besoins de transformation, XSLT fournira une solution plus concise, plus facile à déboguer, à maintenir et à déployer qu'une solution développée en Java, C++ ou ce que tu veux. Pourquoi ? Parce que ça a été spécifiquement conçu dans ce but, et pas par des imbéciles.

Tu parle de ces gens qui ne « comprennent rien au déclaratif et préfèrent les solutions traditionel comme DOM ». Tu pense vraiment qu'il voit le DOM comme une solution ? Beh alors c'est que tu n'as vraiment aucune idée du traitement effectué entre le DOM d'entrée et le DOM de sortie.

J'en ai une très vague idée, en effet... J'ai juste codé en Java et en utilisant DOM des extensions XSLT à Xalan pour des conversions OOo 1.x->Docbook, pour prendre en charge certaines transformations complexes (de tableaux notamment) pour lesquelles XSLT posait problème (de performances et même sur certains processeurs des problèmes avec la profondeur de récursion). Je connais donc bien les limites des deux possibilités, et je peux t'affirmer qu'hormis ces cas très particuliers et pointus XSLT est de loin la solution optimale en matière de transformation.

DOM est une API pas très bien foutue, dont le plus gros handicap à l'heure actuelle est de ne pas respecter totalement le paradigme objet, dont le polymorphisme (il faut souvent faire un test de typage avant de pouvoir accéder à certaines propriétés ou méthodes d'un objet sous peine d'une belle erreur d'exécution). D'autre part, les possibilités d'extraction de noeuds selon des critères particuliers de DOM sont largement en deça de ce que propose XPath, même si cela s'est amélioré avec DOM 2.