« 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).
|
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.
<!-- Fin du texte de la news -->
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.
Lisez donc ce chapitre en PDF pour savoir si le livre vous intéresse... ou
lisez la suite de cette critique (ou la conclusion) !
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
- La fiche du livre sur le site O'Reilly France --- avec le lien vers le site des auteurs
- La page sur le XSLT du W3C
- Le chapitre 2 en PDF (42 pages A4, 634 ko)
Aller plus loin
- La fiche du livre (49 clics)
- La page sur le XSLT du W3C (14 clics)
- Le chapitre 2 en PDF (34 clics)
# Re: Comprendre XSLT, critique du livre
Posté par GP Le (site web personnel) . Évalué à 1.
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 . Évalué à 1.
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
Posté par Harry Cover . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 1.
Pire, il paraitrait même que certains aprécient de lire ces articles !
[^] # Re: Comprendre XSLT, critique du livre
Posté par Pascal Terjan (site web personnel) . Évalué à 1.
Le lien le plus visible c'est L et X
[^] # Re: Comprendre XSLT, critique du livre
Posté par David Pradier . Évalué à 1.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
> 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/(...) -+-
Envoyé depuis mon PDP 11/70
[^] # Re: Comprendre XSLT, critique du livre
Posté par oliv . Évalué à 1.
http://www.adobe.com/misc/copyright.html(...)
[^] # Re: Comprendre XSLT, critique du livre
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: Comprendre XSLT, critique du livre
Posté par ndv . Évalué à 1.
[^] # Re: Comprendre XSLT, critique du livre
Posté par Frédéric Lopez . Évalué à 1.
> 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 . É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 ?
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
Posté par Anonyme . Évalué à 1.
Fais une news...
# Re: Comprendre XSLT, critique du livre
Posté par Ptitpattes Pitbull . Évalué à 1.
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 . Évalué à 1.
[^] # Re: Comprendre XSLT, critique du livre
Posté par Guillaume Smet (site web personnel) . É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 . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
[^] # Re: Comprendre XSLT, critique du livre
Posté par Moby-Dik . Évalué à 1.
Justement... XSL est lisible, peut-être ? ;)
[^] # Re: Comprendre XSLT, critique du livre
Posté par thoran . Évalué à 1.
http://www.cduce.org/(...)
[^] # Re: Comprendre XSLT, critique du livre
Posté par afrisch . Évalué à 1.
Je détaille un peu; les traits marquants de CDuce sont:
avec fonctions surchargées (style POO)
Un prototype utilisable devrait être disponible autour de fin décembre - début janvier...
[^] # Re: Comprendre XSLT, critique du livre
Posté par thoran . Évalué à 1.
http://www.cduce.org/(...)
[^] # Re: Comprendre XSLT, critique du livre
Posté par Dolmen (site web personnel) . Évalué à 1.
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é
Mainteneur de LiquidPrompt - https://github.com/nojhan/liquidprompt
[^] # Re: Comprendre XSLT, critique du livre
Posté par Dolmen (site web personnel) . Évalué à 1.
- http://lists.xml.org/archives/xml-dev/200102/msg00483.html(...)
- http://lists.xml.org/archives/xml-dev/200102/msg00511.html(...)
Olivier Mengué
Mainteneur de LiquidPrompt - https://github.com/nojhan/liquidprompt
[^] # Re: Comprendre XSLT, critique du livre
Posté par boubou (site web personnel) . Évalué à 1.
A suivre...
[^] # Re: Comprendre XSLT, critique du livre
Posté par boubou (site web personnel) . Évalué à 1.
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 . Évalué à 1.
[^] # Re: Comprendre XSLT, critique du livre
Posté par reno . Évalué à 1.
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 (site web personnel) . Évalué à 1.
[^] # Re: Comprendre XSLT, critique du livre
Posté par reno . Évalué à 1.
Donc tu te retrouves avec le namespace repete partout --> beurk.
[^] # Re: Comprendre XSLT, critique du livre
Posté par boubou (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 1.
[^] # Re: Comprendre XSLT, critique du livre
Posté par JSL . Évalué à 1.
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 . Évalué à 1.
à charger ;) et à ne nessecite plus de parsages gourmand dans tout les sens.
[^] # Re: Comprendre XSLT, critique du livre
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: Comprendre XSLT, critique du livre
Posté par Ptitpattes Pitbull . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 1.
données que css ne gère pas.
[^] # Re: Comprendre XSLT, critique du livre
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: Comprendre XSLT, critique du livre
Posté par Anonyme . Évalué à 1.
[^] # Re: Comprendre XSLT, critique du livre
Posté par frecillia8 . Évalué à 1.
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
Posté par oliv . Évalué à 1.
Mozilla sait faire cela depuis Juin 2001 (version 0.9.1).
Je ne sais pas pour opéra, mais si je ne sais pas, je ne vais pas sous-entendre le contraire.
[^] # Re: Comprendre XSLT, critique du livre
Posté par Ptitpattes Pitbull . Évalué à 1.
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 :
Extraction du fond :
Ecriture des programmes :
Traduction :
Execution :
[^] # Re: Comprendre XSLT, critique du livre
Posté par JSL . Évalué à 1.
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 (site web personnel) . Évalué à 1.
[^] # Re: Comprendre XSLT, critique du livre
Posté par JSL . Évalué à 1.
[^] # Re: Comprendre XSLT, critique du livre
Posté par Ptitpattes Pitbull . Évalué à 1.
Sinon http://www.zvon.org/(...) m'avait bien aidé aussi
[^] # Re: Comprendre XSLT, critique du livre
Posté par Ptitpattes Pitbull . Évalué à 1.
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 (site web personnel) . Évalué à 1.
[^] # Re: Comprendre XSLT, critique du livre
Posté par Moby-Dik . Évalué à 1.
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 ?
Posté par Franck Guillaud . Évalué à 1.
Ou alors il faut qu'ils changent d'éditeur.
[^] # Re: Des langages verbeux ?
Posté par boubou (site web personnel) . Évalué à 1.
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 ?
Posté par chakal . Évalué à 1.
PS : elle est ou la case -1?
[^] # Re: Des langages verbeux ?
Posté par Ptitpattes Pitbull . Évalué à 1.
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 ?
Posté par Moby-Dik . Évalué à 1.
[^] # Re: Des langages verbeux ?
Posté par reno . Évalué à 1.
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...
Posté par oliv . Évalué à 1.
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 (site web personnel) . Évalué à 1.
[^] # Re: XSL considéré comme nuisible...
Posté par Moby-Dik . Évalué à 1.
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 (site web personnel) . Évalué à 1.
[^] # Re: XSL considéré comme nuisible...
Posté par frecillia8 . Évalué à 1.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
[^] # Re: XSL considéré comme nuisible...
Posté par oliv . É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...
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 _ _ . É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 (site web personnel) . É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. 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 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 1.
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 . É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.
>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 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 _ _ . É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."
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 (site web personnel) . Évalué à 1.
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 . Évalué à 1.
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'essentiel, à savoir la sémantique
Relis mon premier post, en particulier cette phrase :
"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."
C'est exactement ce que je dis, je dis que si l'auteur a si peur que l'on brise la sémantique en ne donnant pas le source XML, il n'ont qu'a brider le navigateur pour obliger les gens à transformer XSL-T en local, sinon le navigateur refuse le rendu du XSL-FO.
Ca serait moins con que de refuser d'implémenter XSL sous pretexte que c'est dangereux.
<FOND>
D'ailleurs, il y a autre article sur XML qui explique bien que XML ne crée pas magiquement de la sémantique, il ne fait que la rendre possible
Il faut que les gens passent du temps à élaborer des DTD, et discutent entre eux pour établir le sens de chaque mot.
Exemple : <PRIX>200</PRIX>
Le prix, il en euros ou en francs, hors taxe ou toutes taxe comprise, avec ou sans remise sur volume, on compte les frais de transports ?, et ça comprends le rabais (dédommagement lorsqu'un produit est livré endommagé) ?
Pour un particulier la dénomination brut c'est un prix HT, dans certaines profession un prix brut ça veut dire sans remise commerciale ce qui n'est pas la même chose.
Bref, il faut que les gens se mettent d'accord sur le sens de chaque mot.
Donc il ne sert à rien de forcer les gens à livrer du XML pour avoir de la sémantique, car si les gens ne font aucun effort pour créer des DTD, la sémantique contenue dans le XML sera de toute façon très pauvre.
</DIALOGUE DE FOND>
[^] # Re: XSL considéré comme nuisible...
Posté par oliv . Évalué à 1.
ça doit être à cause des XPs que ce gars a au moins 3 comptes ;) ça permet de voter plus, de moins se faire descendre, et de donner l'impression que l'on est plusieurs :)
[^] # Re: XSL considéré comme nuisible...
Posté par frecillia8 . Évalué à 1.
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: Comprendre XSLT, critique du livre
Posté par Dolmen (site web personnel) . Évalué à 1.
Mainteneur de LiquidPrompt - https://github.com/nojhan/liquidprompt
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.