[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-team] XML is (it) the futur (?)
Salut tout le monde et bonne année 2001,
Ce mail est une réponse (certainement partielle) à une discussion entammée
sur la liste ressource@ressource-toi.org . Si vous recevez ce mail alors que
vous n'êtes pas inscrit à cette liste, j'espère qu'il ne sera pas trop "off
topic", j'envois ce mail à certaines listes qui "pourraient" être
intéressées par cette discussion. La liste ressources@ est réservée aux
anciens stagiaires de la formation "Programmation Internet" du STE (Val
Benoît, ULg).
Qu'est-ce que XML et à quoi cela peut-il bien servir?
-----------------------------------------------------
XML est un "langage" qui sert à structurer de l'information et seulement de
l'information. Alors que HTML mélange les données et la mise en forme des
données, XML ne "s'occupe" QUE des données. De là à comparer XML et les
bases de données ou à mettre en concurrence XML et les logiciels bases de
données, il y a un (grand) pas que je n'oserais pas franchir. En ce qui
concerne de "petits" ensembles de données (qui peuvent aller jusqu'à 30 ou
40 méga ou plus, selon la capacité de l'ordinateur), et une structure plus
flexible, XML est préférable à la construction d'une base de données. Mais
il y a des problèmes de place et de rapidité quand à la recherche
d'informations et il n'y a pas de langage SQL pour interroger un fichier
XML, par exemple.
Donc, pour moi, XML, même s'il ne s'agit QUE de données (ou informations),
ne remplacera jamais la puissance d'une base de données.
XML et les (R)DBMS
-----------------------
Par contre, en ce qui concerne l'échange d'information (ce qui nous
intéresse tout de même au plus haut point dans le monde de l'internet), XML
EST (pour moi) le passage obligé. Comment échange-t-on des informations
entre deux bases de données? Il y a plusieurs méthodes:
- DUMP: l'instruction dump, présente dans beaucoup de (R-)DBMS, permet de
retranscrire dans un fichier texte toutes les instructions nécessaires à la
création de la base de données, données et structure(s). Ce fichier prend
énormément de place et n'est compatible qu'avec la base de données d'où
sortent ces informations (mais moins qu'un fichier XML, nous allons y
revenir);
- EXPORT: hors de toute base de données, il y a moyen de sortir un fichier
texte contenant toutes les informations séparée par des virgules ou points
virgules. Cette mise en forme prend aussi beaucoup plus de place que la base
de données, mais moins que le dump (et moins aussi que le fichier XML). Par
contre, la structure de l'information peut se révéler moins évidente puisque
les noms des champs, s'il sont présents, ne le sont qu'à la première ligne
du document. En ce qui concerne le traitement automatique de cette
information, il n'est pas très évident non plus et il y a des risques de
conflit au niveau des séparateurs;
- XML: lorsqu'on fait passer les informations dans un fichier XML, chaque
enregistrement est séparé par des balises qui délimitent de manière très
précise UN enregistrement. Chaque information contenue dans un champ de la
base de données est délimitée par des balises qui délimitent de manière
précise l'information de CE champ. Ce fichier prend moins de place que lors
d'un DUMP, mais certainement plus qu'un EXPORT.
L'avantage de XML dans l'échange de données
------------------------------------------------
Lorsque l'on analyse les trois fichiers ci-dessus, on observe que le premier
fichier contient TOUTES les informations nécessaires à la reconstitution
d'une base de données identique (structure(s) et données) mais que ce
format, souvent proche de SQL92, normalement, reste propriétaire. Si on veut
reconstituer la même base de données sur un autre (R)DBMS, certains
problèmes de compatibilités vont survenir. De plus, le fichier est en SQL,
langage qui appartient au (R)DBMS et ne pourra être traité qu'avec un
(R)DBMS. Le deuxième fichier est un simple fichier texte avec des
informations non ou peu structurées, séparée par des virgules. Pour en
extraire des informations de manière automatique, cela peut se révéler assez
problématique. Le troisième type de fichier, XML, permet d'avoir les
informations (données) et uniquement celles-ci, mais de manière structurée.
Ainsi, non seulement le traitement automatique est facilité, mais en plus,
il y a moyen de lire les données "à l'oeil nu"! De plus, XML est
"standardisé", personne n'en est propriétaire, tout le monde peut
l'utiliser... sans payer. Donc, connaissant ta base de données, tu peux
récupérer un fichier XML et stocker les données dans ta base de données
(dont tu connais la syntaxe). Ceci ne vaut que pour le passage
d'informations d'une base de données à une autre.
Les stagiaires pi2000b viennent de faire un exercice récapitulatif du cours
d'Access que j'ai mis en ligne. En ce qui concerne la structure de la db, je
n'ai pas pu me servir du fichier Access pour créer la db PostgreSQL, par
contre, en ce qui concerne les données, ils ont créé un fichier XML avec
toutes les balises et tous les attributs HTML, j'ai fait un petit programme
Java de cent ou deux cents lignes qui lit ce fichier XML et met à jour la
base de données précédemment créée. L'encodage a été relativement simple
pour les stagiaires et tout le monde pourra utiliser ce fichier pour créer
une db html4.0 (le résultat: http://www.ressource-toi.org/servlet/html/ ).
L'avantage de XML pour le web
---------------------------------
Pour cette partie, je vais d'abord faire une petite comparaison avec HTML
4.0, ensuite, je vous parlerai du serveur "Cocoon". Vous avez sans doute
suivi avec attention le cours d'Isabelle sur HTML4.0. Isabelle vous a
certainement fait savoir que le w3c recommandait de séparer la mise en forme
et les données dans la création des pages web en html. De là l'utilisation
des feuilles de styles que certains continuent d'ailleurs à intégrer DANS
les page et non dans un fichier séparé comme le voudrait la recommandation
du w3c. Pourquoi séparer le contenu et la mise en forme? Ce n'est pas
seulement pour faire plaisir à un consortium, c'est pour facilité
l'homogénéité, la structure et la présentation des sites. Vous décidez donc
de ne plus mettre le titre principal de votre page en Helvetica rouge taille
5, vous ne le ferez QUE dans la feuille de style et non dans vos 5662 pages
html! C'est certainement un gain de temps et une sécurité de ne pas oublié
une ou plusieurs pages. Malgré l'utilisation des feuilles de styles, HTML
mélange encore les données et leur mise en forme. Et si l'on regarde un peut
les balises html, on se rend compte qu'il y en a qui définissent une mise en
forme (div, b, p, br, etc...) et d'autres des "données" (address, cit, dfn,
code, em, etc...). En XML, les balises sont définies par l'utilisateur (ou
le programmeur) et n'ont aucun effet "visuel". Le seul effet est de séparer
et de hiérarchiser les données. Qu'est-ce que l'Internet si ce n'est pas une
masse d'informations? Bon d'accord, mais il faut mettre en forme. Dans ce
cas, on peut utiliser une feuille de style "classique" ou (encore mieux),
une feuille de style XSL. XSL(-T) est un ensemble d'instruction qui va
transformer les données XML en un autre type de données. Cela peut-être un
autre fichier XML (par exemple dans le cas d'un échage de données entre deux
bases de données n'ayant pas exactement la même structure), un simple
fichier texte (en séparant les données par des ";"), un fichier wml (pour le
wap), un fichier word (pour... ?), un fichier pdf, mais aussi, pourquoi pas,
un fichier postscript, ou même, un fichier HTML! On se retrouve dans ce
dernier cas (celui qu inous intéresse) avec UNE seule feuille de style pour
tout un site.
Pour réaliser cela (une feuille de style XSL qui va "parser" les document
XML), il faut un programme qui va exécuter tout cela. Il existe plusieurs
"parser" XML écrits sous forme de bibliothèques que l'on peut importer et
utiliser (pourquoi réinventer la roue?), et cela dans différents langages de
programmation (Java, C/C++, ASP, PHP -je crois-, etc.). Donc, vous créez une
feuille de style XSL, des documents XML et un petit programme (vraiment pas
compliqué, ça tient en une vingtaine de lignes en java) et vous avez un site
complet et homogène. C'est un procédé que j'ai utilisé pour le site
http://www.portoheredias.com/ . C'est un procédé que je vais aussi pousser
encore plus loin pour un site à venir dont je vous reparlerai.
Une deuxième méthode, beaucoup plus intelligente, mais il faut disposer d'un
serveur qui comprenne le java et pouvoir le configurer comme on le veut, est
d'utiliser l'ensemble de servlets Cocoon du projet Apache (
http://xml.apache.org/cocoon ). Cocoon est un serveur XML qui a été écrit
complètement en Java. Il est gratuit et on peut disposer du code source.
Avec Cocoon, vous écrivez une feuille de style XSL, des documents XML qui
pointent vers la XSL et la conversion est automatique. Si vous voulez
modifier des données, vous modifiez un des documents XML, si vous voulez
modifier la mise en page, vous modifiez la feuille de style XSL et TOUT le
site est mis à jour! C'est le procédé que j'ai utilisé pour
http://www.ressource-toi.org/ . Mais Cocoon ne se limite pas à cela. On peut
en effet intégrer du code Java ou JavaScript dans les feuilles de style (on
peut dire que cela "agit" côté serveur, sinon, on peut évidemment insérer du
JavaScript ou des applets dans les pages html comme on le fait
traditionnellement), on peut faire des requêtes SQL dans les pages XML qui
donneront comme résultat un fichier XML avec les données qui viennent de la
base de données qu'une feuille de style XSL mettra en forme (
http://www.ressource-toi.org/evolutionsdb.xml ). Le code de cette page est
en dessous du mail pour ceux que ça intéresse, ils remarqueront la
simplicité après en avoir fait une ou deux. Cocoon permet aussi de
transformer les pages XML en pdf, html, wml, xml, txt. Peut-être que
d'autres formats sont reconnus, je ne m'en sert pas et je n'en sais pas
plus. Par contre, la fameuse compatibilité entre browsers peut être
contournée grâce à Cocoon car on peut définir une feuille de style par type
de browser. Cocoon reconnait le type de browser qui fait la requête en
"parse" le document XML avec la feuille XSL que le programmeur a définie en
fonction du browser. Les browser reconnus par Cocoon sont:
- explorer=MSIE
- opera=Opera
- lynx=Lynx
- java=Java
- wap=Nokia-WAP-Toolkit
- netscape=Mozilla
La version de Cocoon qui est installée sur le serveur ressource-toi est la
1.8.1, mais des mises à jour se font régulièrement (toutes les semaines ou
au fil des bugs découverts), et le groupe travaille actuellement sur la
version 2. Cocoon 2 sera bientôt en version beta (un mois ou deux si tout se
passe bien).
Voilà, j'ai été long, peut-être parfois un peu confus (mais vous me
connaissez), mais j'espère avoir répondu à quelques questions. Je suis en
outre très heureux qu'un tel débat ait pris place sur
ressources@ressource-toi.org et je ne voudrais surtout pas le clore par ce
mail. Je vous encourage à faire des commentaires et à apporter vos
expériences personnelles à ce fil de discussion.
Bien à vous et encore une fois bonne année 2001,
--
Arnaud (icq:48119561)
<http://www.ressource-toi.org>
----------------------------------------------------------------------------
---------
evolutiondb.xml:
-----------------
<?xml version="1.0" encoding="iso-8859-1" ?>
<?cocoon-process type="sql"?>
<?xml-stylesheet href="evolutions.xsl" type="text/xsl"?>
<?cocoon-process type="xslt"?>
<?cocoon-format type="text/html"?>
<page section="main"
nompage="formations"
emailauteur="arnaud@ressource-toi.org"
datecreation="17 novembre 2000 (14:26:00)"
datemodification="17 novembre 2000 (16:49:00)">
<document>
<para>
Ceci est une page de <b>test</b>... Les dix dernières évolutions sont
accessibles de la plus récente à la plus ancienne.
</para>
<connectiondefs>
<connection name="foo_connection">
<driver>postgresql.Driver</driver>
<dburl>jdbc:postgresql://localhost:5432/ressourcedb</dburl>
<username>***</username>
<password>***</password>
</connection>
</connectiondefs>
<query connection="foo_connection">
select mem_prenom, mem_nom, mem_rstmail, evt_date, evt_sujet, evt_texte
from evolutions, membres where evolutions.mem_id=membres.mem_id order by
evt_date DESC limit 10
</query>
</document>
</page>
[ linux-team@rtfm.be and linux@lists.linuxbe.org in ONE :) ]
[ To subscribe or unsubscribe, go to http://linuxbe.org/ml.php ]
[ http://LinuxBe.org - http://OpenBe.net - listmaster@linuxbe.org ]