Articles précédents : Livre
- [51] Le livre "Programming Linux Games" disponible en pdf
- [11] Old Games
- [35] LFS v4 pour bientôt
- [9] Bibliothèque Linux
- [23] L'ésotérisme du bazar
- [8] L'âge du Capitaine
- [15] L'histoire illustrée des ordinateurs
- [4] Routage IP
- [3] Introduction à Romain Gary
- [12] Livre O'Reilly en ligne : « Free as in Freedom »
Liens connexes
- La fiche du livre (1487 hits)
- La page sur le XSLT du W3C (589 hits)
- Le chapitre 2 en PDF (1534 hits)
Dépêche modérée par
Livre : Comprendre XSLT, critique du livre
Posté par Fabien Penso (Jabber id, page perso, ). Modéré le 04 novembre 2002.
« La critique de ce livre part de 3 points avec 3 questions : Le XML est de plus en plus utilisé, toujours cité comme très avantageux. Mais en quoi le XML est-il si intéressant concrètement, et le XSLT en particulier pour y consacrer tout ce livre ? (...) » (voir la suite dans l'article).
Note : Si vous souhaitez proposer une critique d'un livre, ou si vous souhaitez rédiger un article pour LinuxFr, contactez les modérateurs préalablement. Vous pourrez ainsi remporter des livres O'Reilly ou des abonnements LinuxMag, et voir votre article lu par beaucoup. Les sujets peuvent être variés (Cinéma, etc).
![[fr]](../../../images/fr.png)
La fiche du livre (1487 hits)![[en]](../../../images/en.png)
La page sur le XSLT du W3C (589 hits)-
Le chapitre 2 en PDF (1534 hits)
> Lire la dépêche (84 commentaires, moyenne: 1).
| Comprendre XSLT | |
| Auteurs | Bernd Amann et Philippe Rigaux |
| Éditeur | O'Reilly |
| ISBN | 2-84177-148-2 |
| Pages | 528 |
| Prix | Prix indicatif 35 euros (229,59 F) |
| Rédacteur | Thierry Stoehr |
La critique de ce livre part de 3 points avec 3 questions :
- Le XML est de plus en plus utilisé, toujours cité comme très avantageux. Mais en quoi le XML est-il si intéressant concrètement, et le XSLT en particulier pour y consacrer tout ce livre ?
- Le commentaire en ligne d'O'Reilly au sujet de son livre est : "Si vous n'achetez qu'un seul livre d'informatique en 2002, achetez celui-là !". Et lors de la Linux Expo 2002, le livre qui allait sortir était logiquement présenté comme tel. Simples déclarations promotionnelles ou valeur réelle ?
- Enfin, tout le chapitre 2 du livre, "Introduction à XML et XSLT", est disponible en téléchargement : il porte vraiment bien son nom en proposant une mise en perspective et des explications très claires. Cette introduction est-elle suivie d'un développement de même valeur ?
Réponses dans la suite.
Pour lecteurs pressés
Pour savoir si ce livre est fait pour vous, voici deux éléments rapides :- sachez qu'il se situe à juste titre selon moi dans la catégorie des livres "pour se former en tant qu'utilisateur débutant ou expérimenté" comme indiqué au dos du livre (les spécialistes de XML/XSLT n'en apprendont donc pas beaucoup). Pour débuter, le livre est excellent, notamment à partir du chapitre introductif de présentation (voir ci-après) ;
- sachez que pour vous faire une idée juste du livre, vous pouvez télécharger le fichier PDF du chapitre de présentation générale du livre, "Comprendre XML et XSLT". Ces pages sont excellentes : elles expliquent pas à pas, avec des exemples concrets, réalistes et détaillés ce qu'est le XML et son intérêt couplé avec XSLT. Tout cela avec des schémas clairs et une approche pédagogique réelle.
En détail
Le livre "Comprendre XSLT" a plusieurs particularités qui méritent tout d'abord d'être indiquées :- le livre est une édition originale en français : pas de traduction donc, il est écrit par deux enseignants en informatique (Conservatoire National des Arts et Métiers, Université de Paris Sud Orsay), spécialistes entre autres du XML, Bernd Amann et Philippe Rigaux ;
- une partie des informations du livre est disponible en ligne et téléchargeable : le chapitre 2 (excellent et cité plus haut), mais aussi le descriptif détaillé du contenu du livre, les fichiers d'exemple du livre (utiles pour ne pas tout saisir) et les deux annexes. Cele se trouve sur le site des auteurs, accessible depuis la page du livre chez O'Reilly (nous en reparlerons plus loin). Le site fournit aussi de la documentation complémenatire et des liens à propos de XML/XSLT ;
- la volonté pédagogique déjà citée est bien présente au fil des pages : le livre s'appuie sur des exemples réalistes (un cinéma qui publie son programme en version imprimée, en version HTML, en version WAP, en version multimedia, avec une base de données, en PDF) en les détaillant et en développant les points de façon progressive. Les auteurs sont enseignants, cela ressort, dans le bon sens du terme ;
- les exemples basés sur un cinéma sont bien sûr facilement transposables à d'autres structures avec les mêmes besoins (une société, une administration, un service, voire un particulier). De plus, ces exemples passent en revue de nombreux champs d'application du XSLT : l'échange et l'intégration de données, le Web, l'impression, le multimedia, les bases de données. En utilisant de nombreux formats ouverts (HTML, XHTML, WML (pour WAP), RSS (pour des News), SMIL (pour le multimedia), PDF).
Prenons maintenant le livre par chapitre successif (la lecture peut se faire de façon linéaire en suivant l'ordre proposé, mais aussi sans problème en allant directement au domaine qui intéresse).
Le chapitre 1 est l'avant-propos classique de ce type de livre : il
donne l'objectif du livre, une définition du XSLT, la nature des
exemples, les pré-requis nécessaire, l'organisation du livre, les conventions et
les remerciements.
Précision : le Java, SQL et les CGI sont indiqués dans des pré-requis
conseillés. Si vous ne les connaissez pas (ce qui est mon cas), cela
n'empêche pas du tout de lire, de comprendre et d'utiliser le livre !
Le chapitre 2 a déjà été cité. Il est remarquable pour comprendre et toucher du doigt la puissance de XML et XSLT. Lisez-le, faites-le lire, utilisez-le pour expliquer voire convaincre des responsables de travailler efficacement avec le XML, sans que cela reste de la théorie !
Le chapitre 3 développe la syntaxe XML, avec la DTD de l'un des exemples du chapitre précédent traité et commenté, avec la notion d'arbre XML, avec le langage XPath. Ces trois sous-parties sont illustrées par des schémas et des exemples du code utilisé. Ce chapitre se termine par 16 exemples concrets et commentés d'expressions XPath.
Le chapitre 4 constitue la suite logique du 3. Il répond à la question : comment écrire un programme XSLT pour créer un document XML résultat à partir d'un document XML de départ. Les règles XSLT, les instructions de contrôle et des aspects de programmation avancée sont traités, avec 31 exemples pour ce chapitre.
Le chapitre 5, toujours de manière logique et progressive, permet de produire un document en sortie (autre que XML, vu au chapitre précédent). Le document en sortie peut-être du HTML, qui est tout d'abord traité, ou un document imprimé. Dans ce second cas, les problèmes des espaces et des caractères réservés (qui n'existent pas en HTML) sont à considérer avec attention, ce que fait la seconde partie du chapitre. Là encore, de nombreux exemples sont donnés (plus de 50).
Le chapitre 6 explique comment partager et intégrer des informations XML avec XSLT. C'est une partie de la puissance du XML et l'intérêt du XSLT, qui est traitée avec tout d'abord un exemple de moteur de recherche de ressources cinématographiques. Puis ce sont trois autres cas d'utilisation de XSLT qui sont développés, en s'appuyant sur le format de nouvelles RSS : génération de document RSS, création de HTML à partir de RSS et enfin génération automatique d'une description de site.
Le chapitre 7 revient sur les documents XML avec un approfondissement de ce qu'est une DTD (plus développé qu'au chapitre 3) et avec la DTD SMIL (Synchronized Multimedia Integration Language) consacrée aux objets multimedia pour produire un document SMIL (toujours à partir du fil rouge que constitue l'exemple du cinéma).
Le chapitre 8 complète le 5 : cette fois, on s'attarde à la production d'un document sortie imprimé. C'est le langage XSL-FO qui permet cela et qui est donc développé : principes de base, éléments XSL-FO et production d'un document PDF sont proposés.
Le chapitre 9 conclut le tour d'horizon des possibilités en
traitant de la publication de documents avec des informations issues
de bases de données (tout ou partie de la base, avec ou sans autres
éléments autres que la base). Cette fois, c'est l'exemple d'une agence de
voyage qui est traité, toujours avec cette approche pratique et
concrète pour expliquer.
La chapitre traite aussi des perspectives d'évolution du XML utilisé avec les bases de données : ainsi XML Schéma et XQuery sont expliqués (rapidement).
L'annexe A a un objectif pratique : installer ce qu'il faut pour utiliser le XSLT. On a le choix entre l'environnement de la fondation Apache (avec Xerces, SAX, DOM, Xalan, FOP, Cocoon) basé sur du Java, ou l'environnement du projet GNOME, qui n'utilise pas Java. La description de l'installation de chacun est fournie.
L'annexe B donne par ordre alphabétique la liste de tous les éléments (avec syntaxe) du XSLT. Encore une fois, de nombreux exemples (48) illustrent cette partie.
L'index enfin se révèle pratique et pertinent (d'après une utilisation personnelle).
Tout au long du livre, une autre qualité se dégage : l'objectivité. Les auteurs ne clament jamais que XSLT sait tout faire, ni que ce qu'il fait est encore le plus performant.Ainsi reconnaissent-ils des limites actuelles à XSLT et les indiquent :
- pour un document imprimé, XSL-FO, "en raison de la jeunesse de ce langage, le résultat obtenu n'est pas --- pas encore ? --- au niveau de ce que l'on peut obtenir avec des outils de mise en forme de texte existant depuis des années et ayant faits leurs preuves." (page 358). Soit DocBook/TeX/LaTeX qui sont cités.
- pour l'extraction d'informations, "On ne peut cependant pas compaprer XSLT avec un langage de programmation classique (comme le C ou Java), et nous verrons dans le chapitre 4 les limites qui sont rapidement rencontrées dès que l'on se confronte à des algorithmes un tant soit peu complexes." (page 53).
- pour les bases de données, "il semble à l'heure actuelle souvent plus raisonnable d'utiliser une base de données classique dès qu'on a besoin de gérer un ensemble de données de taille conséquente, et de prendre plutôt XML comme format d'échange ou de "vue" sur les données pour certaines applications" (page 421).
Le livre a tout de même des imperfections. Voici les critiques que je formulerais :
- je n'ai pas trouvé de manière assez explicite de conseils sur comment organiser les éléments XML (notamment les attributs) ; mais ce n'est pas l'objet essentiel du livre, c'est plus de l'élaboration de DTD ;
- un glossaire aurait été parfait pour retrouver les définitions des termes de la galaxie XML/XST (les XPath, DOM, SAX, parseurs, DTD, éléments, attributs, XSL et autres Cocoon) ;
- contrairement à nombre de livres O'Reilly, il n'y a pas en fin d'ouvrage de partie "À propos et colophon" pour répondre à des questions comme "Avec quels outils le livre est-il fait ? Les beaux schémas sont générés avec quel logiciel ? Que sont ces poissons sur la couverture ?" ;
- le site des auteurs n'a pas toujours été accessible (cela m'était arrivé au moment de la sortie du libre), d'où l'absence de lien direct ci-dessous, mais plutôt le lien de la page du livre chez O'Reilly qui permet d'y aller ensuite en un clic de plus ;
- pour pinailler, j'ai relevé quelques coquilles (déformation de relecteur !) comme une belle série de "parours" (pour parcours) voire une phrase énigmatique qui surgit dans une page. Mais c'est très secondaire et ne nuit en rien à la lecture et à la compréhension !
Enfin, le livre m'a permis concrètement de commencer à gérer à titre personnel mon carnet d'adresse, et à titre professionnel une liste bibliographiques (180 titres), avec des sorties HTML, LaTeX et PDF. Et d'autres projets sont posssibles...
En conclusion
Je trouve que le livre est clair, pédagogique et progressif, concret et avec une approche pratique riche de nombreux exemples détaillés, tout en restant ojectif et enfin sans prix trop élevé.Pour répondre aux 3 questions en début de ma critique, le XSLT mérite bien un livre, et celui-ci est à la hauteur de son excellente introduction générale. C'est vraiment un livre à conseiller pour comprendre à quoi peut servir le XML et comment l'exploiter concrètement avec le XSLT. La puissance et les possibilités offertes sont vraiment importantes et on saisit pleinement pourquoi le XML est à la base d'un système d'information moderne et efficace.
Et si vous souhaitez vous pencher sur le XML de manière plus générale , les titres "Introduction à XML" ou "XML in a Nutshell" sont des exemples de piste de lecture.
Table des matières
Les indications entre crochets ne figurent pas dans la table des matières du livre.- 1 : Avant-propos [8 pages + 5 pages de table des matières + 5 pages de début de livre]
- 2 : Introduction à XML et XSLT [54 pages]
- 3 : Documents XML : structure et navigation [62 pages]
- 4 : Programmation XSLT [62 pages]
- 5 : Production de documents texte et hypertexte [52 pages]
- 6 : Échange et intégration [46 pages]
- 7 : Production de documents XML [38 pages]
- 8 : XSL-FO [50 pages]
- 9 : Publication de bases de données [56 pages]
- Annexe A : Environnement XML/XSLT [14 pages]
- Annexe B : Référence XPath/XSLT [64 pages]
- Index [12 pages]
Références
Re: Comprendre XSLT, critique du livre
Pour ma part, je cherchais un bouquin pour etayer un cours que je donnais a la FAC. Apres avoir parcouru as de livre, je suis tombe sur le chapitre telechargeable. Apres la lecture, j'ai couru a la FNAC.
C'est un excellent bouquin facile et simple d'acces. La progression des exemples parfaite mais certains domaines sont abordes trop superficiellement a mon gout.
Je suis assez d'accord avec les points fort et les points faibles. Un livre a avoir quand on debute le XSLT.
Par contre, pour les non debutant, je recommande plutot la serie WROX qui offrent de bon pave (700 pages) avec un bon prix ;)
-
[^]Re: Comprendre XSLT, critique du livre
Posté par grafit () le 05/11/2002 à 15:21. (lien). Évalué à 1.zut, je suis plus debutant, je l'aurais bien acheté autrement :)
pour les anglophones connectés, la FAQ xsl est bien fournie:
http://www.dpawson.co.uk/xsl/xslfaq.html(...)
http://www.dpawson.co.uk/xsl/sect2/sect21.html(...)
Re: Comprendre XSLT, critique du livre
J'aurais juste 2 remarques à faire sur cette annonces.
La première c'est que je ne vois pas le lien qu'il peut y avoir entre linux et XML. Pourquoi ne pas parler également de SGML, latex, html, voire AmigaGuide (pour les amigaïstes) ou PDF tant qu'on y est ?
La deuxième remarque, plus amère celle-ci, c'est de constater qu'on fait encore une fois la part belle au sponsor. Est-ce un hasard si l'un des sponsors de LinuxFR se voit élogieusement plébisciter dans ces pages, et pas dans la catégorie "autres", s'il vous plait ! Ce qui me navre, c'est qu'après on critique TMC pour ses liens avec Microsoft dans l'affaire du benchmark J2EE/.Net, et qu'ici on ne fait finalement pas mieux !
A bon entendeur. J'espère simplement ne pas me faire flamer pour avoir dit tout haut ce que beaucoup pensent tout bas...
-
[^]Re: Comprendre XSLT, critique du livre
Posté par lorill (page perso, ) le 04/11/2002 à 18:07. (lien). Évalué à 1.La première c'est que je ne vois pas le lien qu'il peut y avoir entre linux et XML.
y'en a pas, et alors ? ou plutot si, mais je te laisse chercher..
Pourquoi ne pas parler également de SGML, latex, html, voire AmigaGuide (pour les amigaïstes) ou PDF tant qu'on y est ?
Et ? On en parle, justement (fin sauf amigaguide, mais y'avait une news amiga y'a pas longtemps).
Est-ce un hasard si l'un des sponsors de LinuxFR se voit élogieusement plébisciter dans ces pages, et pas dans la catégorie "autres", s'il vous plait !
non, il se trouve qu'Oreilly fait de bons livres... Tu remarqueras que l'osdn fait pleins de pubs pour .net, et pourtant ca n'est pas "plébiscité" dans leurs pages...
-
[^]Re: Comprendre XSLT, critique du livre
Posté par Serge Rossi (page perso, ) le 04/11/2002 à 18:09. (lien). Évalué à 1.Tu sais, il parait que sur LinuxFr, on trouve même des articles sur les dernières sorties de films au ciné (et des films sans un seul pingouin en plus).
Pire, il paraitrait même que certains aprécient de lire ces articles !
-
[^]Re: Comprendre XSLT, critique du livre
Posté par Pascal Terjan (Jabber id, page perso, ) le 04/11/2002 à 18:14. (lien). Évalué à 1.La première c'est que je ne vois pas le lien qu'il peut y avoir entre linux et XML
Le lien le plus visible c'est L et X
-
[^]Re: Comprendre XSLT, critique du livre
Posté par David Pradier (page perso, ) le 04/11/2002 à 19:01. (lien). Évalué à 1.Concernant O'Reilly, j'attends de voir une collection qui simplement l'égale...
Personnellement, je pense que leur qualité fait que tout développeur devrait se tenir au courant des livres disponibles chez cet éditeur :-)
(Au fait, ceci n'est pas un troll.)
-
[^]Re: Comprendre XSLT, critique du livre
Posté par oliv () le 04/11/2002 à 19:20. (lien). Évalué à 1.>La première c'est que je ne vois pas le lien qu'il peut y avoir entre linux et XML
linuxfr n'est pas qu'à propos de Linux. Elle s'intéresse ausssi à GNU, aux logiciels libres dans leur ensemble, aux standards libres (png, tex, html, xml, etc.), à l'open-source, aux livres, au cinéma, et même à certains systèmes propriétaires (MS Windows, MacOS, BeOS, Unix).
De nombreux programmes libres utilisent d'ailleurs le xml, comme glade, rox, OpenOffice.org, Koffice, Gnome, etc.
>Pourquoi ne pas parler également de SGML,
DocBook, c'est du SGML, non?
http://linuxfr.org/2001/06/25/3999.html(...)
>latex,
http://linuxfr.org/2000/12/03/1270.html(...)
> html,
http://linuxfr.org/2001/11/19/5991.html(...)
> voire AmigaGuide (pour les amigaïstes)
y'en a plus! :)
> ou PDF tant qu'on y est ?
c'est pas un standard ouvert!
>La deuxième remarque, plus amère celle-ci, c'est de constater qu'on fait encore une fois la part belle au sponsor.
>Est-ce un hasard si l'un des sponsors de LinuxFR se voit élogieusement plébisciter dans ces pages
Non, ce n'est pas un hasard. ça vient du fait que O'Reilly est quasiment le seul éditeur à publier des livres techniques sur des sujets tournant autour de GNU, Linux ou les standards libres (W3C et autres)-
[^]Re: Comprendre XSLT, critique du livre
Posté par William Steve Applegate (page perso, ) le 04/11/2002 à 23:52. (lien). Évalué à 1.> > ou PDF tant qu'on y est ?
> c'est pas un standard ouvert!
Bah ça dépend ce que tu appelles « ouvert ». J'ai trouvé en deux minutes un document [
http://partners.adobe.com/asn/developer/acrosdk/DOCS/PDFRef.pdf(...) ] (attention, ça pèse près de 5 Mo !) qui semble bien être les specs complètes de PDF 1.3. Perso, je trouve ça valable question ouverture. Après, je sais pas s'il y a pas de sombres histoires de brevets ou autres derrière, mais le cas échéant, je suis certain qu'on ne manquera pas de m'éclairer sur la question ;-))
--
Les cacahuètes, c'est le mouvement perpétuel à la portée de l'homme
-+- Jean-Claude Van Damme in http://www4.tz-technologie.com/(...) -+---
Ce message vous a été présenté par les trollomètres de compétition Prumpleffer™-
[^]Re: Comprendre XSLT, critique du livre
Posté par oliv () le 05/11/2002 à 09:41. (lien). Évalué à 1.tu as lu le texte en tout petit par ici?
http://www.adobe.com/misc/copyright.html(...)-
[^]Re: Comprendre XSLT, critique du livre
Posté par boubou (page perso, ) le 05/11/2002 à 11:12. (lien). Évalué à 1.Ob ne va pas reprendre un milliard de fois cette discussion débile. PDF n'est pas ouvert au sens où tu n'as pas le droit d'ajouter des choses ou de contourner la spec. Par contre, si tu respectes la spec, tu as le droit d'implanter comme tu veux le standard. Donc, c'est disons "semi-ouvert".
-
[^]Re: Comprendre XSLT, critique du livre
-
-
-
-
-
[^]Re: Comprendre XSLT, critique du livre
Posté par Frédéric Lopez () le 04/11/2002 à 19:35. (lien). Évalué à 1.> La première c'est que je ne vois pas le lien qu'il peut y avoir entre
> linux et XML.
Euh, l'informatique ?
> Pourquoi ne pas parler également de SGML, latex, html,
> voire AmigaGuide (pour les amigaïstes) ou PDF tant qu'on y est ?
Il me semble qu'il y a régulièrement des nouvelles sur ces sujets. Quant aux critiques de livres, j'imagine que ça dépend un peu des sorties et de la bonne volonté des lecteurs pour écrire des critiques de qualité, comme celle-ci. Chacun est libre d'en publier une.
> La deuxième remarque, plus amère celle-ci, c'est de constater
> qu'on fait encore une fois la part belle au sponsor.
Amer, c'est le mot qui convient. Si Linuxfr s'auto-censure vis-à-vis des éditions O'Reilly, il ne va pas rester beaucoup de livres de qualité à critiquer. Rien ne t'empêche d'écrire une critique sur un livre d'informatique d'une autre édition.
> Est-ce un hasard si l'un des sponsors de LinuxFR se voit
> élogieusement plébisciter dans ces pages, et pas dans la catégorie
> "autres", s'il vous plait !
Tu reproches la même chose aux journaux papier ? Si tu as une contre-critique à formuler sur ce livre, vas-y, les commentaires sont faits pour ça.
> Ce qui me navre, c'est qu'après on critique TMC pour ses liens
> avec Microsoft dans l'affaire du benchmark J2EE/.Net, et qu'ici on
> ne fait finalement pas mieux !
Peut-être parce que les enjeux commerciaux sont différents et que ce genre de tests a déjà eu mauvaise presse, notamment lorsqu'ils étaient sponsorisés par Microsoft.
A part ça, si c'est un troll, c'est pas mal vu... :)-
[^]Re: Comprendre XSLT, critique du livre
Posté par PAtrice Manac'h () le 04/11/2002 à 21:37. (lien). Évalué à 1.Activation du torllomêtre :
>> La première c'est que je ne vois pas le lien qu'il peut y avoir entre
>> linux et XML.
>Euh, l'informatique ?
comme Windows ou Mac.. donc pas très pertinent
>> Est-ce un hasard si l'un des sponsors de LinuxFR se voit
>> élogieusement plébisciter dans ces pages, et pas dans la catégorie
>> "autres", s'il vous plait !
>Tu reproches la même chose aux journaux papier ? Si tu as une >contre-critique à formuler sur ce livre, vas-y, les commentaires >sont faits pour ça.
Non, certains sont sans pubs (comme le Canard) et ne supporte donc pas ce genre de reproche...
Les ouvrages cités sont peut être bons mais la critique ne vaut que vis à vis des concurrents : quid de Wrox, Eyrolles voir MS Press (troll trop facile, j'en conviens). Sérieusement, comment classer le livre, quelle population cible t'il ?
A titre personnel, j'utilise le chm de MS fournis avec le toolkit MSXML 3 et en dehors d'un livre aux éditions SAMs, je n'ai pas trouvé mieux. Il y a peut être quelque chose à construire là dessus ?
Patrice-
[^]Re: Comprendre XSLT, critique du livre
-
-
Re: Comprendre XSLT, critique du livre
Bah je viens de passer 6 mois sur le XSLT avec ce bouquin en main ....
Heureusement que le bouquin existe parceque le XSL c'est vraiment un langage cree par des tordus, sadiques malsains.
En faite, le langage est tellement mal foutu, verbeux, pas puissant, anti-intuitif et
anti-pratique, qu'on dirait qu'il a ete cree pour vendre des bouquins !
En bref, tout le contraire de XPath qui lui, est vraiment excellent.
Ma question est, mais pourquoi ne pas avoir continue avec la meme syntaxe et
le meme esprit que Xpath, dont xsl a forcement besoin ?
Pourquoi appeler des constantes des variables ???
Pourquoi imposer la recursivite avec un langage aussi verbeux ?
Pourquoi ne pas appliquer les css(la forme) directement sur le XML(le fond) ?
En bref, le XSL m'a vraiment donne envie d'apprendre XUL :)))
Conclusion : l'auteur du livre a vraiment beaucoup de merite ;)
-
[^]Re: Comprendre XSLT, critique du livre
Posté par Anonyme () le 04/11/2002 à 22:14. (lien). Évalué à 1.XSL est tout le contraire de ce que tu dis: bien fait, puissant et intuitif. C'est l'habitude de programmer en langage procédural, voire pseudo-objet comme le C++ qui foire tout quand tu commence XSL.
-
[^]Re: Comprendre XSLT, critique du livre
Posté par Guillaume Smet (page perso, ) le 05/11/2002 à 09:48. (lien). Évalué à 1.[+]
Le fait de se trouver face à un langage déclaratif est assez déroutant au début. Cependant, les fous peuvent toujours se rapprocher du procédural avec des boucles for et compagnie...
On ne peut pas tout faire avec XSL mais c'est _très_ puissant et je trouve cela très plaisant à utiliser (avis personnel).
J'ai un peu peur de ce que va donner la possibilité d'ajouter des fonctions dedans et j'espère que ca ne foutra pas en l'air le côté déclaratif que j'apprécie particulièrement.
Par contre, j'ai souvent un peu de mal à convaincre les gens car y a un petit saut logique à faire quand même au début.
-
[^]Re: Comprendre XSLT, critique du livre
Posté par Ptitpattes Pitbull (page perso, ) le 05/11/2002 à 12:50. (lien). Évalué à 1.C'est vrai que j'ai fait du C, du Java, du C++, du Delphi, du PHP, j'ai taté du python
mais j'ai aussi beaucoup bossé avec du Lisp et du Prolog et puis d'autre trucs comme le
latex et le SQL.. tous ces langages (surtout le lisp et le prolog) me plaisent beaucoup :)
Donc je ne pense pas avoir un esprit déformé par l'usage abusif de langages procéduraux.
Eux, ils sont fait pour programmer, le XML est fait pour présenter des données de fond ...
s'en servir pour programmer et à mon avis très tordu, surtout quand on s'applique à
faire quelque chose de facilement parsable ... je pense qu'il est plus intelligent de faire bosser les machines (les parsers) que les informaticiens ;-)
-
-
[^]Re: Comprendre XSLT, critique du livre
Posté par reno () le 04/11/2002 à 22:15. (lien). Évalué à 1.Note que franchement j'ai l'impression que c'est XML qui a des cotés mal fichus.
Tout au moins pour ce qui est de l'écriture "a la main" de XML.
Les namespace ont vraiment été "rajouté" de manière sale sur le XML normal, pourtant le besoin d'avoir une hiérarchie de noms me parait plutot évident..
Quand un element a un certain namespace, le fait que ses attributs ne soient pas dans le meme namespace --> beurk!
Certes cela ne pose pas de probleme a un parseur, mais bon au niveau lisibilité pour un humain, c'est franchement lourd!!
Quand a XSL, franchement je trouve cela verbeux et moche, ceci dit j'ai téléchargé le PDF, peut-etre qu'il va me faire changer d'avis, mais j'en doute fortement.
Ca aurait été bien un peu moins de hype et un peu plus de reflexion *a priori* AMHA (je sais la critique est facile, l'art est difficile).-
[^]Re: Comprendre XSLT, critique du livre
Posté par Bernard VALTON () le 05/11/2002 à 10:22. (lien). Évalué à 1.Utiliser un language déclaratif et récursif pour manipuler des arbres XML : c'est une super idée et ca existe dans pleins de languages fonctionnels depuis belle lurette (souvenez vous à l'école, au début de vos études, quand vous ne faisiez pas du C++ ou du java toute la journée ...)
Maintenant, un langage de programmation doit etre lisible : avec une syntaxe clair, alors les petits gars, ils ont remplacé les (((())))) par des <>
Je dois dire que le résultat est encore pire que dans les langages fonctionnels traditionnels :(
Donc si quelqu'un connait un langage déclaratif/fonctionnel qui a les mêmes capacités que XSLT avec une syntaxe puissante, claire et lisible (comme celle de python au hasard), je suis intéressé mais ne compter pas sur moi pour les (((()))) et les <> et autres XMLeries pour programmer !-
[^]Re: Comprendre XSLT, critique du livre
Posté par boubou (page perso, ) le 05/11/2002 à 11:02. (lien). Évalué à 1.DSSSL (http://www.jclark.com/dsssl/(...) ), mais bon :
1) c'est pour SGML
2) ça reste genre scheme (donc plein de () qui sont quand même plus lisible je trouve que XML, mais bon...)
Sinon, comme je le dis plus bas, XML n'a jamais été fait pour être écrit à la main, il faut donc utiliser un éditeur adapté...-
[^]Re: Comprendre XSLT, critique du livre
Posté par Moby-Dik () le 05/11/2002 à 19:23. (lien). Évalué à 1.Sinon, comme je le dis plus bas, XML n'a jamais été fait pour être écrit à la main,
Toi y en a rigoler ? XML est précisément fait pour que l'opérateur soit capable de travailler (lire et écrire) directement sur le fichier. Pourquoi un machin si verbeux, à ton avis, si ce n'est pas pour ça ?
D'ailleurs, faut pas déconner : c'est quoi XHTML ? C'est pas du XML ? :-))-
[^]Re: Comprendre XSLT, critique du livre
Posté par boubou (page perso, ) le 06/11/2002 à 10:29. (lien). Évalué à 1.Tu devrais lire la spec (http://www.w3.org/TR/REC-xml(...)), en particulier les "design goals". Le but est qu'un être humain soit capable de LIRE un document XML (point 4). Il est explicitement indiqué que la consision (terseness) n'a que très peu d'importance (point 10). A aucun endroit il est indiqué que le but est de faciliter l'ECRITURE d'XML à la main. Le fait que XHTML ainsi que des dizaines d'autres dialectes XML soient justement du XML n'a aucun rapport avec le fait que XML soit destiné à être écrit à la main...
-
[^]Re: Comprendre XSLT, critique du livre
-
-
-
-
[^]Re: Comprendre XSLT, critique du livre
-
[^]Re: Comprendre XSLT, critique du livre
Posté par afrisch () le 08/11/2002 à 14:50. (lien). Évalué à 1.Merci Fred, c'est la gloire :-)
Je détaille un peu; les traits marquants de CDuce sont:
- langage fonctionnel d'ordre supérieur (les fonctions sont des valeurs comme les autres, que l'on peut passer en argument, récuperer comme résultat, etc...),
avec fonctions surchargées (style POO) - langage fortement typé (un programme accepté ne peut pas planter à cause d'une erreur de type à l'execution), mais avec un système de type très souple (types unions, intersections; dispatch dynamique suivant le type à l'execution, etc ...); on est sûr que les documents XML produits sont du bon type !
- langage généraliste avec structures de données, mais adapté à la manipulation de documents XML: types expressions régulières (dans le genre DTD, XML-Schema ou Relax-NG), filtrage (pattern-matching) puissant pour capturer des éléments ou des sous-séquences d'un document XML (sous la forme d'expression régulières); gestion agréable des chaines de caractères (Unicode), avec également des expressions régulières
Un prototype utilisable devrait être disponible autour de fin décembre - début janvier... - langage fonctionnel d'ordre supérieur (les fonctions sont des valeurs comme les autres, que l'on peut passer en argument, récuperer comme résultat, etc...),
-
-
[^]Re: Comprendre XSLT, critique du livre
-
[^]Re: Comprendre XSLT, critique du livre
Posté par Dolmen () le 06/11/2002 à 22:31. (lien). Évalué à 1.Donc si quelqu'un connait un langage déclaratif/fonctionnel qui a les mêmes capacités que XSLT avec une syntaxe puissante, claire et lisible
Essaye XQuery : http://www.w3.org/XML/Query(...)
C'est développé par le W3C (donc futur standard) mais encore au stade de Working Draft.
Plusieurs implémentations sont disponibles :
- GNU Qexo : http://www.gnu.org/software/qexo/(...)
- Oracle : http://otn.oracle.com/sample_code/tech/xml/xmldb/xmldb_xquerydownlo(...)
- Microsoft : http://xqueryservices.com/(...)
(les deux citations d'implémentations propréitaires sont là pour montrer que du monde s'y intéresse)
J'ai découvert ça hier, et les sources XQuery me paraîssent plus lisible que du XSLT car on distingue mieux la structure du code des tags XML.
Olivier Mengué-
[^]Re: Comprendre XSLT, critique du livre
Posté par Dolmen () le 06/11/2002 à 23:02. (lien). Évalué à 1.Pour compléter, voici deux points de vue sur différents sur XSLT et XQuery :
- http://lists.xml.org/archives/xml-dev/200102/msg00483.html(...)
- http://lists.xml.org/archives/xml-dev/200102/msg00511.html(...)
Olivier Mengué
-
-
-
[^]Re: Comprendre XSLT, critique du livre
Posté par boubou (page perso, ) le 05/11/2002 à 11:18. (lien). Évalué à 1.J'ai bien l'impression que tu n'as pas bien compris les namespaces. Les namespaces ne sont pas une hiérachie de noms, mais des collections disjointes de noms qui s'ajoutent aux collections déjà présente en XML. Si tu avais compris ce principe, ça t'éviterait de critiquer quelque chose qui est logique. Parce que vois-tu, même sans l'ajout des namespaces, les attributs sont dans des collections de noms à part.Plus précisément, dans un document XML sans namespaces, tu as déjà une collection de noms correspondant aux éléments, puis une collection de noms pour chaque élément correspondant aux attributs (de l'élément). C'est pourquoi tu peux avoir deux attributs qui portent le même nom dans deux éléments différents, avec une interprétation différente pour chaque attribut. Les attributs ne sont donc jamais dans le même namespace que leur élément dans XML de base.
A suivre...
-
[^]Re: Comprendre XSLT, critique du livre
Posté par boubou (page perso, ) le 05/11/2002 à 11:19. (lien). Évalué à 1.Suite...
Grâce à l'extension des namespaces, non seulement on a plusieurs collections de nom d'éléments, mais en plus, on peut placer les attributs dans d'autres collections de noms que celle correspondant à chaque élément.
Moralité, avant de critique n'importe comment, il est utile de savoir de quoi on parle, par exemple de lire et de comprendre les normes...
Sinon, aucun rapport : suis-je le seul à ne pas pouvoir poster de "gros" textes ? Je me demande si le fait d'être sur renater ou d'avoir un routeur CISCO peut poser des problèmes ???-
[^]Re: Comprendre XSLT, critique du livre
Posté par Moby-Dik () le 05/11/2002 à 19:25. (lien). Évalué à 1.Je crois que la remarque était que les attributs d'un éléments namespacé devraient, en l'absence d'indication supplémentaire, être considérés comme appartenant par défaut au dit namespace. Ce serait plus conforme au principe de "least astonishement".
-
[^]Re: Comprendre XSLT, critique du livre
Posté par reno () le 05/11/2002 à 19:47. (lien). Évalué à 1.Tout a fait.
Boubou:
j'ai peut-etre utilisé hierarchie a la legere, mais en tout cas, je comprends tout a fait le besoin d'avoir des espace de nommage séparé: quand on autorise les utilisateurs a definir leur propre tag, il faut pouvoir eviter les conflits.
D'ou ma surprise devant l'ajout tardif et "crade" selon moi des namespace.
Crade car ce n'est pas le plus simple, cf remarque de Master-dik cela a été nécéssaire car ceux qui ont la version 1.0 n'ont pas vu plus loin que le bout de leur nez..-
[^]Re: Comprendre XSLT, critique du livre
Posté par boubou (page perso, ) le 06/11/2002 à 10:33. (lien). Évalué à 1.Donc, tu n'as toujours pas compris. La remarque de Master-dik n'est pas pertinente car le principe de "least astonishement" est justement que des attributs sans préfixe soient traités comme ils le sont quand on ne tient pas compte des namespaces. Le truc, c'est que comme personne ne lit les normes, personne n'avait compris avant les namespaces que les attributs étaient dans des espaces de non spécifiques, donc tout le monde est étonné par un truc logique. Si tu veux légitimement dire que les concepteurs de 1.0 n'ont pas vu plus loin que le bout de leur nez, commence par lire la norme et par la comprendre.
-
[^]Re: Comprendre XSLT, critique du livre
Posté par reno () le 06/11/2002 à 13:00. (lien). Évalué à 1.Je te parie que plus de 90% des attributs d'un elements sont dans le meme espace de nommage que l'element.
Donc tu te retrouves avec le namespace repete partout --> beurk.-
[^]Re: Comprendre XSLT, critique du livre
Posté par boubou (page perso, ) le 06/11/2002 à 16:35. (lien). Évalué à 1.Putain, mais lis donc la spec !!!!!!!!!!!!!!!
Tu n'a jamais remarqué qu'on utilise presque jamais d'espace de noms pour les attributs dans XSLT, RELAX NG, les Schémas W3C, etc ? C'est parce que les processeurs reconnaissent les éléments (en se basant sur l'URI associé au namespace) puis ils traitent les attributs qui sont dans l'espace noms DE L'ELEMENT. Par exemple, tu écrits <xsl:template match="bla">, tu n'écris jamais <xsl:template xsl:match="bla"> (même si c'est correct). Donc, la réalité est exactement le contraire de ce que tu dis, à savoir 90% des attributs sont dans l'espace de noms propre à l'élément et pas dans le même espace de noms que l'élément (STP, lis bien ma phrase avant de répondre).A part Xlink et Xpointer, je ne vois d'ailleurs pas beaucoup d'utilisation d'attributs dans un élément avec un espace de noms qui n'est pas celui propre à l'élément.-
[^]Re: Comprendre XSLT, critique du livre
Posté par boubou (page perso, ) le 06/11/2002 à 16:37. (lien). Évalué à 1.Petite précision, par espace de noms de l'élément, je veux dire espace de noms propre à l'élément, pas espace de noms auquel le nom de l'élément appartient (cette distinction est d'ailleurs à la base de toute la confusion qui tourne autour des namespaces).
-
-
-
-
-
-
-
-
[^]Re: Comprendre XSLT, critique du livre
Posté par JSL (page perso, ) le 05/11/2002 à 10:07. (lien). Évalué à 1.> «Pourquoi ne pas appliquer les css(la forme) directement sur le XML(le fond) ?»
Parce que le css ne peut pas faire tout ce que peut faire le xsl : la transformation de la structure du document d'origine en est le plus gros morceau (voir xslt).-
[^]Re: Comprendre XSLT, critique du livre
Posté par Ptitpattes Pitbull (page perso, ) le 05/11/2002 à 10:51. (lien). Évalué à 1.Pas si tu taille tes flux XML sur mesure :) ce qui a l'avantage d'être moins lourd
à charger ;) et à ne nessecite plus de parsages gourmand dans tout les sens.-
[^]Re: Comprendre XSLT, critique du livre
Posté par boubou (page perso, ) le 05/11/2002 à 11:04. (lien). Évalué à 1.Mais qu'est-ce que tu racontes ? css et XSL, ça n'a presque rien à voir, que ton "flux" XML soit "taillé sur mesure" ou pas.
-
[^]Re: Comprendre XSLT, critique du livre
Posté par Ptitpattes Pitbull (page perso, ) le 05/11/2002 à 13:05. (lien). Évalué à 1.le CSS te permet de mettre en forme directement le XML (avec gecko)
le XSL te permet de mettre en forme html du XML .... et de faire des transformations
de strucure.
Si ton flux XML est tailé sur mesure, tu n'as pas besoins de rebidouiller sa structure.
Pour la mise en forme je prefere le CSS sur XML qui est plus propre que du HTML + CSS.
2 solutions :
1- Base de Donnée
-/marshall brutale/-> XML brute
-> transformations XSL de structure
-> transformation XSL d'ajout de HTML(ou autre) avec CSS
2- Base de Donné
-/marshall élaboré/-> XML sur mesure avec CSS
Je pense que la solution n°2 en une étape est plus efficace :-)-
[^]Re: Comprendre XSLT, critique du livre
Posté par boubou (page perso, ) le 05/11/2002 à 13:22. (lien). Évalué à 1.CSS ne permet pas de mettre en forme, il permet de réaliser une présentation, ce qui n'est pas la même chose (tu ne changes pas la structure du document XML).
Quant à ta deuxième solution, elle est peut être plus rapide, mais elle ne couvre que certains cas, manque singulièrement de souplesse et n'est pas modulaire du tout.-
[^]Re: Comprendre XSLT, critique du livre
Posté par Ptitpattes Pitbull (page perso, ) le 05/11/2002 à 13:37. (lien). Évalué à 1.Je crois que tu devrais potasser CSS un peu plus ;o) il n'y a que la duplication de
données que css ne gère pas.-
[^]Re: Comprendre XSLT, critique du livre
Posté par boubou (page perso, ) le 05/11/2002 à 14:48. (lien). Évalué à 1.Tu devrais lire http://www.w3.org/Style/CSS-vs-XSL(...) au lieu de dire des conneries. Plus je te lis plus j'ai l'impression que tu n'as rien compris à XSLT.
-
[^]Re: Comprendre XSLT, critique du livre
-
-
-
-
[^]Re: Comprendre XSLT, critique du livre
Posté par frecillia8 () le 05/11/2002 à 13:56. (lien). Évalué à 1.le CSS te permet de mettre en forme directement le XML (avec gecko)
Pourquoi spécialement Gecko ? IE et Opéra le font aussi très bien.
En plus, je crois qu'IE 6.0 est capable de faire la transformation XSL côté client.
Si ton flux XML est tailé sur mesure, tu n'as pas besoins de
rebidouiller sa structure.
Bah, justement c'est une erreur de conception que le format XML soit taillé en fonction de la sortie (donc de la présentation) vu que le but de XML c'est justement de séparer la forme du fond.
La bonne solution c'est :
BD --> format XML décrivant les données (fond) --> format XML taillé pour la sortie (forme) + CSS
Ensuite il faut essayer de transformer côté client, non pas seulement pour des problèmes de ressource serveur, mais surtout pour que les gens récupérent le document contenant le fond, ce qui rends possible l'écriture d'automate parsant le document (le fameux Web Sémantique).-
[^]Re: Comprendre XSLT, critique du livre
-
[^]Re: Comprendre XSLT, critique du livre
Posté par Ptitpattes Pitbull (page perso, ) le 05/11/2002 à 16:58. (lien). Évalué à 1.Oueh, on peut effectivement faire du XML de forme avec de divers attributs de forme
pour le css, c'est pratique, mais je trouve ça pas très popre (on reserve le XML
au fond sémantique du document).
En faite quand je parle de flux XML sur mesure, je considère que je garde la valeure
sémantique des tags, mais je ne sort que ce qui est nécessaire et dans l'ordre qui
m'intéresse.
Bref je "mens" par omission à l'utilisateur finale, mais bon trop d'info tue l'info, je vais
pas non plus lui faire un dump de ma base de données XML :o)
____
format XML décrivant les données de ma base de donnée -->
BD -->
format XML sémantique taillé pour la sortie (fond allégé) + CSS (forme)
____
Pour ce qui est du Web Sémantique on devrait plutôt s'orienté vers des contenus
libres et des bases de données XML en libre service :o) mais c'est un problème
politique.
Mais j'avoue il reste le problème des formulaire et de la dynamique
des sites, et quelques trucs de mise en forme difficile à faire avec juste du css (genre
une ligne sur deux de couleures différentes pour un listing)... donc il faut bien passer
par du xsl à un moment ou un autre(en attendant que CSS se complète) ...
mais moins y'en a, mieux on se porte.
Enfin où place t'on le langage de programmation ? dans la catégorie fond ou dans la
catégorie forme ? (Parceque le tout XML, c'est un peu lourd à la fin :o)
IMHO le fond c'est l'algorithme et la forme c'est le langage :
1 - Algorithmes en XML
2 - Programmes en Langage de programmation "Human Readable" et "Human Writable" et aussi "Human debugable"
-------------------------------------------------------
Base de donnée XML --/extraction sur mesure/-->
---> Flux XML sémantique de donnée sur mesure(fond)
---> Flux XML sémantique d'algorithmes sur mesure(fond)
Traduction des algos(fond) en vrai programme (forme) --/éxecution/-->
Transformation dans un format de présentation (html, latex, pdf) --/affichage/--->
ex:
Requètes SQL aux petits-oigons :
select * from $info;
select * from $algo;
Extraction du fond :
<flux>
<personne>
<nom>Godzilla</nom>
<prenom>Wiki</prenom>
<adresse>... </adresse>
</personne>
</flux>
<flux type="algo
<afficher>
</flux>
Ecriture des programmes :
afficher($target){ echo " $target " };
Traduction :
afficher(//personne);
Execution :
Godzilla Wiki
-
-
-
-
[^]Re: Comprendre XSLT, critique du livre
Posté par JSL (page perso, ) le 05/11/2002 à 11:15. (lien). Évalué à 1.C'est vrai, mais ça nécessite de penser le DTD de son format xml en fonction du rendu final, ce qui est contraire à l'esprit. De plus, si il y a plusieurs sorties totalement différentes (xhtml, pdf...), ça devient quasi-impossible. Et je ne parle même pas du cas où le format de sortie change : il faudrait alors revoir son format xml de stockage de donnée brute parce que le format proposé au monde extérieur a changé ?
Quant au parsages gourmands, rien à dire sur l'état actuel des choses, mais je ferais remarquer que même si ça serait bien compliqué à implémenter, rien n'interdit d'envisager un système à la templeet, avec système de cache à tous les étages, sauf que le langage de templates serait xslt (après tout, dans le cas d'un site web, rien n'oblige que le traitement du fichier de style xls se fasse côté client. J'irais même plus loin : templeet a prouvé que ça pouvait être bien plus malin de faire la chose côté serveur de façon à ne faire les choses qu'une fois, et non pas une fois par client, même si ça soulagerait le serveur ;). Bref, ce n'est pas une limitation intrinséque au language à mon avis, mais bien un problème qui pourrait être grandement aplani via une implémentation performante.
En attendant, xml+xlst est déjà un couple formidable pour automatiser la gestion et les mises à jour d'un site statique, ou même dynamique en intégrant du php au fichier transformé qui sera utilisé pour le site.-
[^]Re: Comprendre XSLT, critique du livre
Posté par boubou (page perso, ) le 05/11/2002 à 11:21. (lien). Évalué à 1.Et d'ailleurs, ce système avec des caches, de la compilation de feuilles de style, etc., on appelerait ça cocoon ? http://xml.apache.org/cocoon/index.html(...)
-
[^]Re: Comprendre XSLT, critique du livre
Posté par JSL (page perso, ) le 05/11/2002 à 12:02. (lien). Évalué à 1.Je ne connaissais que de nom, et je ne m'étais jamais rendu compte qu'il s'agissait de ça. Donc : merci pour l'info :)
-
[^]Re: Comprendre XSLT, critique du livre
Posté par Ptitpattes Pitbull (page perso, ) le 05/11/2002 à 13:10. (lien). Évalué à 1.Jboss avec cocoon + Jetty gère les caches, les url, les flux de données et les transformations et les actions de manière très propre.
Sinon http://www.zvon.org/(...) m'avait bien aidé aussi
-
-
-
[^]Re: Comprendre XSLT, critique du livre
Posté par Ptitpattes Pitbull (page perso, ) le 05/11/2002 à 13:17. (lien). Évalué à 1.le CSS fonctionnent tres bien sans DTD, mais c'est pas très propre :)
pour le pdf .. c'est vrai que je suis orienté WEB :).
En même temps si je veux faire du Latex avec XSL .... je peux faire du html paginé
et appeler une moulinette html2latex, puis une autre moulinette vers pdf ..etc non?-
[^]Re: Comprendre XSLT, critique du livre
Posté par boubou (page perso, ) le 05/11/2002 à 13:23. (lien). Évalué à 1.Si, si et à la fin tu obtiens une bouse immonde...
-
-
-
-
-
[^]Re: Comprendre XSLT, critique du livre
Posté par Moby-Dik () le 05/11/2002 à 19:20. (lien). Évalué à 1.En faite, le langage est tellement mal foutu, verbeux, pas puissant, anti-intuitif et anti-pratique, qu'on dirait qu'il a ete cree pour vendre des bouquins !
En bref, tout le contraire de XPath qui lui, est vraiment excellent.
Ma question est, mais pourquoi ne pas avoir continue avec la meme syntaxe et
le meme esprit que Xpath, dont xsl a forcement besoin ?
Pourquoi appeler des constantes des variables ???
Pourquoi imposer la recursivite avec un langage aussi verbeux ?
Pourquoi ne pas appliquer les css(la forme) directement sur le XML(le fond) ?
Ah, enfin une remarque censée :-)))
Des langages verbeux ?
Les seuls personnes qui trouvent qu'un langage est "verbeux" sont des neuneus qui ne savent pas activer la complétion automatique dans leur éditeur favori.
Ou alors il faut qu'ils changent d'éditeur.
-
[^]Re: Des langages verbeux ?
Posté par boubou (page perso, ) le 05/11/2002 à 10:56. (lien). Évalué à 1.Trop puissant, tu es le 96 et je suis le 97 !!!!!!!!!
Bon sinon, je suis d'accord et je dirais même plus qu'XML n'a jamais été conçu pour être écrit à la main...
-
[^]Re: Des langages verbeux ?
-
[^]Re: Des langages verbeux ?
Posté par Ptitpattes Pitbull (page perso, ) le 05/11/2002 à 13:26. (lien). Évalué à 1.emacs complète et indente à meirveille, c'est plus coté lisibilité du code que ça pause
problème.
J'ai toujours trouvé que écrire le même programme en 12 lignes de lisp était plus
sexy que de l'écrire en 3 page de C.
De plus la complétion peut générer quelques erreures, et plus il y'a de signes plus
il y'a d'erreures possible :o), c'est combinatoire.
-
[^]Re: Des langages verbeux ?
-
[^]Re: Des langages verbeux ?
Posté par reno () le 05/11/2002 à 19:55. (lien). Évalué à 1.Bah il n'y a pas que l'écriture, il y a la lecture et franchement lire du XSL c'est du masochisme a mon avis.
Dans le style language fonctionnel je prefererais nettement lire du O'Camel !!
Bon il n'a pas été prévu pour cela au départ, mais avec une bonne librairie..
XSL considéré comme nuisible...
C'était le titre de deux articles parus il y a 3 ans, qui expliquaient pourquoi CSS+DOM sont plus propres que XSL, et surtout plus puissants.
http://www.xml.com/pub/a/1999/05/xsl/xslconsidered_1.html(...)
http://www.xml.com/pub/a/1999/05/xsl/XSLCompare.html(...)
C'était juste pour mettre de l'huile sur le feu :)
-
[^]Re: XSL considéré comme nuisible...
Posté par boubou (page perso, ) le 05/11/2002 à 13:36. (lien). Évalué à 1.C'est intéressant, mais avec quand même un certain biais. Je m'explique : une grande partie de l'argumentation se focalise sur le fait que XSL est imbitable par rapport à un langage de programmation standard. Je pense qu'on touche ici à un problème intéressant. Personnellement je trouve que les langages fonctionnels comme XSL ou scheme sont beaucoup moins clairs que les langages impératifs. Le sommet est atteint à mon avis par OCaml que je trouve totalement incompréhensible (ça ne veut pas dire que je ne sais pas programmer en OCaml, ça veut juste dire que ça me prend beaucoup plus de temps, de réflexion et d'efforts qu'en Java, par exemple). Pourtant, je suis sûr que certains lecteurs de Linuxfr sont convaincu du contraire. Et dans un tel débat, aucun argument technique ne permet de trancher. Donc, effectivement, DOM+CSS c'est super (et d'une certaine manière plus puissant que XSLT+XSL:FO), mais à la limite, on s'en fout...
-
[^]Re: XSL considéré comme nuisible...
Posté par Moby-Dik () le 05/11/2002 à 19:31. (lien). Évalué à 1.Et dans un tel débat, aucun argument technique ne permet de trancher.
De même que l'ergonomie s'intéresse à l'intuitivité et à la commodité des interfaces, on pourrait imaginer que des chercheurs abordent les différents langages informatiques selon une grille de critères (cognitif, psychovisuel, etc.).
Car, enfin, même s'il y a des gens qui adorent l'assembleur et intercal, il est sinon objectif, du moins raisonnable d'affirmer que ces langages ne sont pas taillés pour les projets de taille conséquente (pour prendre un exemple extrême).-
[^]Re: XSL considéré comme nuisible...
Posté par boubou (page perso, ) le 06/11/2002 à 10:36. (lien). Évalué à 1.Tu as parfaitement raison, mais justement, on quitte très vite le débat technique. Par exemple, il est classique d'affirmer qu'on développe plus vite en Java qu'en C++. J'ai pu le vérifier moi-même. Mais où est la vérification scientifique de ce fait ? Et quand bien même, pourquoi cet argument devrait-il être décisif ? En gros, on a plein d'arguments, plus ou moins fondés, mais on reste devant un problème de décision multi-critères, domaine de recherche à part entière...
-
-
-
[^]Re: XSL considéré comme nuisible...
Posté par frecillia8 () le 05/11/2002 à 14:11. (lien). Évalué à 1.si c'est le vieux argument qui consiste à dire que les gens pourrait distribuer le fichier XSL-FO directement, au lieu de faire une transformation XSL pour le produire, c'est clairement pas très convaincant.
D'abord, la plupart des boites qui disait celà (Opera, Netscape/Mozilla) le faisait parce que leur navigateur était à la bourre sur IE en terme de support du standard XSL.
Ensuite, si ces boites ont vraiment peur du webmaster un peu crétin qui n'a pas compris que le XSL-FO ça n'était pas fait pour être écrit directement, il existe une autre solution que d'abandonner tout support d'une norme importante du W3C, tout bêtement brider le navigateur pour lui interdire d'afficher du XSL-FO lorsqu'il n'est pas généré en local.-
[^]Re: XSL considéré comme nuisible...
Posté par oliv () le 05/11/2002 à 15:12. (lien). Évalué à 1.1- Non ce n'est pas cet argument là.
2- L'auteur n'est ni de Nestcape, ni d'Opera
3- Est-ce que tu peux faire un commentaire qui ne se ramène pas à cette affirmation dépassée depuis 2-3 ans "les autres navigateurs sont à la bourre sur IE".-
[^]Re: XSL considéré comme nuisible...
Posté par boubou (page perso, ) le 05/11/2002 à 15:20. (lien). Évalué à 1.Je te sens énervé là. Il faut dire que quand quelqu'un répond sans même avoir lu les liens que tu postes il y a de quoi. Sinon, pour surenchérir sur ton point 3 je trouve incroyable que frecillia8 nous sorte l'argument IE en avance sur les autres pour le traitement XSL, alors que l'avance en question était une implantation totalement foireuse de XSLT basé sur un parseur assez étrange...
-
[^]Re: XSL considéré comme nuisible...
Posté par oliv () le 05/11/2002 à 16:45. (lien). Évalué à 1.> Je te sens énervé là
Juste que je me souviens avoir déjà vu par le passé pas mal de FUD sur Mozilla, et il me semble (si je me trompe, dites le moi) que ça vient toujours de la même personne...
Et là, en 2 commentaires, il nous parle deux fois de IE alors que personne ne parlait de "navigateur", mais de XML XSLT SGML CSS ...
En ce qui me concerne, j'ai toujours dit que IE pour Mac était un navigateur fantastique :) support des CSS, des PNG, etc. Mozilla (et fils) l'a ensuite rejoint. Opera est arrivé à niveau avec la version 6 (support png décent) et Konqueror avec KDE 3 (idem png - le CSS était déjà correct depuis un certain temps).
J'attends toujours de voir IE pour Win32 avec un support CSS1:)
A la vitesse où ça va... je pense que IE 8.5 saura traiter le CSS1;)
PS: je trolle pas, je me base sur ce que dit Eric Meyer ici:
http://www.meyerweb.com/eric/css/edge/complexspiral/demo.html(...)
c'est le gars derrière le "CSS test suite" du W3C, donc je pense qu'il s'y connaît un peu en CSS ;)-
[^]Re: XSL considéré comme nuisible...
Posté par _ _ () le 05/11/2002 à 21:24. (lien). Évalué à 1.
Juste que je me souviens avoir déjà vu par le passé pas mal de FUD sur Mozilla, et il me semble (si je me trompe, dites le moi) que ça vient toujours de la même personne...
En effet, j'ai toujours pensé que Mozilla était mal designé :
* par exemple, avec XUL, Netscape crée son propre toolkit graphique portable, un concurrent de QT ou de Java 2/Swing.
C'est une mauvaise idée car ce n'est pas domaine de compétence de Netscape (des boites comme ILog sont plus crédibles la-dedans), et puis l'abstraction crée une pénalité ...
Les gens de NS disait qu'il n'y aurait pas de coût en terme de performance en disant "pourquoi notre code serait plus lent que celui de Microsoft".
Finalement, avec Galéon/Kméléon ... on s'est rendu compte que la pénalité d'abstraction existait bel et bien.
* Pour Gecko, NS avais voulu rendre le code plus modulaire, il avait imposé comme contrainte : chaque gros projet doit fournir son code sous la forme de binaire indépendant (une DLL et pas un .LIB). Le problème c'est qu'avec une librairie dynamique le linkage à lieu au lancement du programme et non à la compilation.
J'avais lu un benchmark qui montrait clairement que le temps passé à résoudres les symbole au démarrage était une des causes principales de son manque de réactivité (KDE à le même problème d'ailleurs).
Ici on a clairement une erreur de design, des .LIB/.a aurais suffit car avec la disponibilité du source et le manque de contribution externe à NS, pouvoir éviter de relinker lorsque qu'on contribue à une librairie ne justifie pas la lenteur du démarrage imposéé par les DLL/.so.
Et là, en 2 commentaires, il nous parle deux fois de IE alors que personne ne parlait de "navigateur", mais de XML XSLT SGML CSS ...
Bah quand GECKO supporte un truc que IE en supporte pas, on ne se prive pas pour le mentionner alors je vois pas pourquoi on ne le ferait pas avec IE.-
[^]Re: XSL considéré comme nuisible...
Posté par Éric (Jabber id, page perso, ) le 05/11/2002 à 21:58. (lien). Évalué à 1.C'est une mauvaise idée car ce n'est pas domaine de compétence de Netscape (des boites comme ILog sont plus crédibles la-dedans),
Peut etre mais au final c'est réussi, leur bébé tourne sur beaucoup de plateforme et personnellement je n'ai vu aucun bug d'interface. Moi je dis que le pari est réussi. Leur but était d'avoir quelque chose qui tourne avec le minimum de dépendances afin d'etre partout exactement pareil et de ne dépendre de personne. Moi je dis ca marche.
Au pire on peut penser que ca a été un peu gachi et du coup il n'y a pas d'intégration avec les themes gtk mais bon, c'est limité comme reproche.
Quand à QT ce n'est pas libre partout sauf erreur, J2/Swing est loin d'etre un exemple niveau ressources et beauté. De ce coté là franchement je n'ai rien à leur reprocher.
Mieux, leur XUL est peut etre lourd mais on voit effectivement des barres d'outils et autres petits trucs basés dessus qui tournent. Ca n'aurait pas été aussi simple pour les extensions avec du gtk par exemple.
Les gens de NS disait qu'il n'y aurait pas de coût en terme de performance en disant "pourquoi notre code serait plus lent que celui de Microsoft".
Finalement, avec Galéon/Kméléon ... on s'est rendu compte que la pénalité d'abstraction existait bel et bien.
Ah ? oui,Galeon, Kméléon, phoenix sont beaucoup plus légers. Ca vient de XUL.
Ah non, erreur ... phoenix est aussi tres léger mais toujours basé sur le toolkit de mozilla. Bon, ca ne doit pas etre la faute au toolkit alors :)
Bah quand GECKO supporte un truc que IE en supporte pas, on ne se prive pas pour le mentionner alors je vois pas pourquoi on ne le ferait pas avec IE.
Sauf que moz aussi gere ton XSLT donc bon ...-
[^]Re: XSL considéré comme nuisible...
Posté par frecillia8 () le 06/11/2002 à 09:34. (lien). Évalué à 1.Peut etre mais au final c'est réussi, leur bébé tourne sur beaucoup de plateforme et personnellement je n'ai vu aucun bug d'interface. Moi je dis que le pari est réussi.
La grande question c'est que Netscape veut concurrencer les fabricants de toolkit : ILog ou Trolltech/QT.
Je croyais que NS faisait des navigateurs, à vouloir réinventer la roue, on risque de la réinventer plus mal que les gens qui ne font que ça 24h/24.
Sauf que moz aussi gere ton XSLT donc bon ...
Maintenant, mais ils ont commencé avec du retard vis-a-vis de IE.-
[^]Re: XSL considéré comme nuisible...
Posté par boubou (page perso, ) le 06/11/2002 à 16:40. (lien). Évalué à 1.Maintenant, mais ils ont commencé avec du retard vis-a-vis de IE.
Non, vis à vis de la merde sans nom qui tenait lieu de support XSLT dans IE 5.x. Donc en fait, sans retard. Le vrai gros défaut de microsoft est de souvent mal implanter des standards (à cause d'une "interprétation" maison) et d'installer de facto un nouveau standard foireux...
-
-
-
-
-
-
[^]Re: XSL considéré comme nuisible...
Posté par frecillia8 () le 05/11/2002 à 16:33. (lien). Évalué à 1.XSL Considered Harmful
by Michael Leventhal | Pages: 1, 2, 3, 4, 5, 6
Sommaire :
I] XSL Has Nothing New for the Web
II] XSL Does Not Support Interactive Web Documents
III] Semantic Information Threatened by XSL
IV] XSL is an Ugly, Difficult Language
V] XSL vs. the DOM+CSS toe-to-toe
1) L'argument n°3 est celui dont je parlais dont tu vois sans avoir lu l'article, j'avais deviné le genre d'argument
2) Oui mais il fait partie du projet Mozilla (un navigateur qui comme par hasard était à la bourre sur IE au niveau du support XSL)
Donc j'étais pas loin quand je disais Opéra ou Netscape (et en plus j'avais pas cliqué sur le lien)
3) L'article date du 20 Mai 1999 une époque ou le projet Mozilla était encore dans la course pour concurrencer IE.
ça peut expliquer pourquoi le type essaye de discréditer XSL alors que dans le même temps Netscape avait annoncé qu'il n'avait pas les ressources humaines nécessaire pour faire bosser des gens sur le projet Transformiix (le module XSL) qui a été laissé à la seul communauté Open-Source.
En fait sur le fait de ne pas avoir lu l'article avant, je suis au boulot et je n'ai pas le temps de lire 6 pages. En plus, sans l'avoir lu j'avais deviné son contenu-
[^]Re: XSL considéré comme nuisible...
Posté par oliv () le 05/11/2002 à 17:14. (lien). Évalué à 1.>1) L'argument n°3 est celui dont je parlais dont tu vois sans avoir lu l'article, j'avais deviné le genre d'argument
Si tu parles de "Semantic Information Threatened by XSL", je pense que son argument est plus de forme, et orienté par son expérience en SGML.
>2) Oui mais il fait partie du projet Mozilla
sa bio est ici:
http://www.xml.com/pub/au/46(...)
Il ne fait pas partie du staff du projet Mozilla:
http://www.mozilla.org/about/stafflist.html(...)
Il travaille sur un projet qui utilise des morceaux de Mozilla, c'est très différent.
DocZilla n'est ni un projet officiel de Mozilla:
http://www.mozilla.org/projects/(...)
ni un projet référencé comme proche de Mozilla:
http://www.mozilla.org/projects/other-projects.html(...)-
[^]Re: XSL considéré comme nuisible...
Posté par frecillia8 () le 06/11/2002 à 09:47. (lien). Évalué à 1.Si tu parles de "Semantic Information Threatened by XSL", je pense que son argument est plus de forme, et orienté par son expérience en SGML.
De toute façon, la sémantique il n'y en a que si l'auteur fait des efforts pour écrire une bonne DTD et la standardiser (en discutant avec d'autres utilisateurs qui travaillent dans le même domaine).
C'est vrai qu'avec XSL-FO on peut ne pas distribuer le source alors qu'avec XML+CSS on est obligé, mais si l'auteur n'a pas fait l'effort de créer une DTD propre ça n'a pas d'interêt.
-
-
[^]Re: XSL considéré comme nuisible...
Posté par boubou (page perso, ) le 05/11/2002 à 17:30. (lien). Évalué à 1.En plus, sans l'avoir lu j'avais deviné son contenu
Trop puissant tu es. Surtout quand on voit la qualité de ton intuition.
La même chose, avec d'autres mots : tu te fous de notre gueulle ou t'as juste de grosses chevilles (c'est laid, les grosses chevilles) ?
Toujours la même chose, mais en plus clair : tu te rends compte que le point numéro 3 de la critique c'est exactement le contraire de ce que tu racontes dans ton super commentaire top intuitif ? Ce que critique l'auteur, c'est justement que XSLT permet de distribuer directement du XSL:FO, ce qui fait perdre la sémantique.
Dernière version : quel con je suis, tu n'as toujours par lu l'article.
Vivement le retour des XP...-
[^]Re: XSL considéré comme nuisible...
Posté par _ _ () le 05/11/2002 à 20:53. (lien). Évalué à 1.J'avais dis dans mon commentaire plus haut :
"si c'est le vieux argument qui consiste à dire que les gens pourrait distribuer le fichier XSL-FO directement, au lieu de faire une transformation XSL pour le produire, c'est clairement pas très convaincant."
Tu me réponds
"tu te rends compte que le point numéro 3 de la critique c'est exactement le contraire de ce que tu racontes dans ton super commentaire top intuitif ? Ce que critique l'auteur, c'est justement que XSLT permet de distribuer directement du XSL:FO, ce qui fait perdre la sémantique."
Dialogue à la Didier Deschamps :
- Je crois que l'auteur veut dire c'est que l'on peut distribuer le XSL-FO directement
- Ah pas du tout. C'est tout le contraire ! Il dit que l'on peut distribuer du XSL-FO directement.-
[^]Re: XSL considéré comme nuisible...
Posté par boubou (page perso, ) le 06/11/2002 à 10:46. (lien). Évalué à 1.Ok, donc non seulement tu ne lis pas les articles avant de les critiquer, mais en plus soit tu es idiot, soit tu ne sais pas parler français (les deux est une bonne réponse).
Histoire de préciser les choses, ton premier post dit clairement que l'article n'a surement aucun intérêt car il doit comporter l'argument contre XSLT qui est qu'on pourrait distribuer directement du XSL:FO et donc se passer d'XSLT. Or, l'auteur de l'article dit exactement le contraire, à savoir que le défaut de XSLT est justement de permettre et même d'inciter à distribuer directement du XSL:FO, c'est-à-dire un contenu qui n'a d'XML que la syntaxe et le nom, mais qui a perdu l'essentiel, à savoir la sémantique.
Ton dialogue à la Didier Deschamps résume effectivement notre dialogue. Ce qui est incroyable, c'est que tu ne te rendes pas compte que tu racontes n'importe quoi.
Je me demande pourquoi je continue à te répondre.-
[^][HS]
Posté par frecillia8 () le 06/11/2002 à 17:09. (lien). Évalué à 1.ton premier post dit clairement que l'article n'a surement aucun intérêt
J'ai jamais dis que l'article n'a aucun intérêt, j'ai dis que j'ai deja entendu cet argument et que je trouve peu convaincant pour justifier un abandon du support XSL.
En effet, si l'auteur de l'article à peur que les gens écrivent du XSL-Fo sous Notepad, et le sauvent directement sur leur serveur Web, au pire il bride son navigateur pour ne pas afficher le XSL-Fo qui vient du Web (et non pas d'une transformation XSL), mais utiliser cela comme excuse pour ne mettre personne à bosser sur le support de XSL dans le navigateur, c'est gros.
ton argument contre XSLT est qu'on pourrait distribuer directement du XSL:FO et donc se passer d'XSLT
Qu'est ce que tu veux dire par là ? Tu crois que j'avais compris que l'auteur conseillait au gens d'écrire directement du XSL-Fo pour ne pas s'embêter avec "ce truc compliqué d'XSLT".
Or, l'auteur de l'article dit exactement le contraire, à savoir que le défaut de XSLT est justement de permettre et même d'inciter à distribuer directement du XSL:FO, c'est-à-dire un contenu qui n'a d'XML que la syntaxe et le nom, mais qui a perdu l
-
-
-
-
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.