[Précédent (date)] [Suivant (date)] [Précédent (sujet)] [Suivant (sujet)] [Index par date] [Index par sujet]
Re: Part 1 Projet Linux, la philo de l anarchie ... - Part 2 Xml
- To: Liste Générale LQ <>
- Subject: Re: Part 1 Projet Linux, la philo de l anarchie ... - Part 2 Xml
- From: (Fabien Ninoles)
- Date: Mon, 23 Jul 2001 01:48:25 -0400 (EDT)
-
In-reply-to: <[email protected]>
Je suis généralement d'accord avec Nicolas Marchildon mais j'aimerais
ajouter quelques commentaires tardifs:
On Mon, Jul 16, 2001 at 03:23:52AM -0400, Nicolas Marchildon wrote:
> On Sunday 15 July 2001 12:54, [email protected] wrote:
> > Cette technologie issue du sgml tend à remplacer le html. Le xml va sans
> > aucun doute s implanter, cependant voila les observations personnelles que
> > j ai pu faire à propos de ce nouveau langage:
>
> Le XML ne remplacera pas le HTML de si tôt. En fait, les internautes
> vont continuer à recevoir du HTML pendant encore un bon moment, mais
> c'est derrière la scène que tout se passe. Par exemple, les données
> peuvent être stockées dans des fichiers XML, et transformés en HTML
> dès qu'il faut les présenter à l'internaute. De cette façon, les
> administrateurs peuvent changer la façon de générer le HTML à partir
> du XML très souvent. De plus, le fait de stocker leur données en XML
> leur permet de gérer l'information de façon beaucoup plus intelligente
> que s'ils avaient à gérer des fichiers HTML.
De croire que le XML a été créer pour remplacer le HTML est réduire
considérablement sont rôles. Le XML est une simplification du SGML
permettant, grâce à des API prédéfini, de définir un format de
description et d'échanges de données standard afin de faciliter la
communication entre les applications. D'un certain coté, les XML est
aux données, ce que l'IDL/Corba est aux applications.
Une grave erreur est aussi de croire que les données en XML doivent être
stockés en format texte. Rien n'empêche ses données d'être stockées
dans une base de données. L'avantage du XML provient du fait que le
format des données peut être décrit dans un langage strict connu et bien
décrit par tous, et qu'il suffit ensuite de créer les interfaces
nécessaires (API) afin d'accéder à cette base de données de façon à
obtenir à nouveau l'information en XML. Le langage de requête peut
aussi bien être du SQL retournant les données en XML (un peu comme
postgresql peut retourner ses tableaux en HTML), ou des standards comme
XQuery ou même XPath.
> > * la mise en page de l informations est inutile. (car ce n est qu un flux)
>
> La mise en page est normalement nécessaire pour présenter quelque chose à un
> utilisateur, même si les données sont stockées en XML. À cette fin, il est
> possible d'utiliser du XML pour définir la mise en page de données XML. Par
> exemple, il existe le XSLT (http://www.w3.org/Style/XSL/), qui est
> relativement puissant.
La mise en page n'a surtout rien à voir avec le XML. Le w3c a même
séparé le XSL du XSLT, ce dernier étant un excellent langage de
transformation des données et pouvant servir à autre chose que de la
mise en page. Le XSL même, qui inclus le XSLT, permet de transformer
des données XML quelconques, vers une application XML (c'est à dire un
document XML ayant une signification particulière pour chacune de ses
balise... un peu comme le HTML) permettant la description typographique
d'un texte (par exemple, les marges autour d'une page, la présence d'un
graphique, la police et la taille des titres, etc.). La mise en page
est donc entièrement excluse non seulement du XML, mais aussi du XSLT
pour n'apparaître que dans le XSL lui-même (dans sa version la plus
récente encore à l'état de proposition). Votre application n'est donc
aucunement alourdie par des concept de mise en page si elle n'en a pas
besoin.
> > * la syntaxe du langage se rapproche plus des balises html, word,
> > que d un type de langage puissant (je pense au C par exemple)
>
> Son nom le dit bien: "Extensible Markup Language". La puissance d'un
> langage, selon moi, est bien subjective. La simplicité su XML est un
> de ses principaux avantages.
C'est un langage descriptif, et non pas procédural. Je me refuserais à
toute comparaison sur ces langages puisqu'ils sont loin d'avoir le même
but. Je reviendrai plus tard dans ce mail sur l'utilisation du XML dans
les communications interprocessus comme SOAP ou XML-RPC.
> > * la definition de types des données est optionnelle, ce qui rend la
> > gestion des variables, et meme du support absolument inutile.
>
> Actuellement, ce qui est le plus utilisé pour définir une utilisation
> du XML est la DTD (Document Type Definition), qui comporte plusieurs
> lacunes. Toutefois, le w3c travaille sur le XML Schema
> (http://www.w3.org/XML/Schema), qui vient combler les lacunes des DTD.
La définition optionnelle est une "feature" du XML afin de permettre de
créer plus facilement du contenu XML et de faciliter l'adaptation pour
des protocoles de transmissions. Comme le répond Nicolas 2, il est
possible de fixer la définition et le type des données ainsi que toute
la structure du document. Cette définition peut-être définie par une
DTD ou un schema, mais aussi simplement indiqué dans la définition du
protocole utilisé.
> > * les données sont stockées dans des fichiers au détriment des bases de
> > donnée, ce qui signifie une charge importante des serveurs lors du de la
> > récupération et du traitement de l informations.
>
> Le XML ne vise pas à remplacer à tout prix les bases de données telles qu'on
> les connaît. Cependant, dans certains cas, il est plus naturel est approprié
> de stocker l'information dans des fichiers XML. En fait, les deux techniques
> sont amenées à travailler ensemble. Par exemple, une base de données peut
> stocker un fragement de XML dans un champ, voire un document complet.
L'avantage d'utiliser les fichiers est simplement que le XML a déjà une
représentation graphique et que peut de bases de données (y'en a-t-il?)
sont optimisés pour gérer les données XML. Mais rien n'empêche de créer
une interface entre les deux. Jabber, qui utilise le XML à la fois
comme protocole de communication et comme structure de données a été
développé avec une première interface sauvegardant les données du
serveur dans un fichier texte. Depuis, de nouveaux modules sont apparus
permettant la sauvegarde dans une DB (gdb/ndb/etc.), dans une
arborescence de répertoires, ou en LDAP. D'autres sont probablement en
préparation pour une DB avec MySQL, PostgresQL ou encore bien d'autres
formats.
> > Je pense que l utilisation d une telle technologie engrende: une
> > importante baisse de performances des systèmes,
>
> Comme dans la majorité des applications les données XML ne changent pas
> souvent, il est facile d'intégrer un système de mémoire tampon qui rend les
> performances très satisfaisantes.
>
> De plus, le XML est un langage qui a beaucoup d'avenir dans les échanges
> d'informations, qui ne connaissent pas réellement de problèmes de
> performances, surtout si les données sont compressées.
Je rajouterais ici que le coût, souvent très faible lorsque
l'application est bien construite, du XML en terme de performance est
compensé par la facilité à comprendre, adopter et adapter les
technologies utilisant le XML pour d'autres fins. Le XML, c'est aussi
une série d'outils standards permettant de comprendre, manipuler et
adapter les différentes informations disponibles un peu partout sur le
net. Avec n'importe quel document XML, un nombre impressionnant
d'outils (XSLT, SAX, DOM, XPath, etc.) vous permet de manipuler les
données de la façon que vous préférez, peu importe l'application qui les
a créé, du moment que ce soit du XML. La seule chose nécessaire est
alors de connaître la signification de ces données, signification
souvent fourni avec le DTD/Schema utilisé.
> > une sécurité des flux informatifs précaires,
>
> Ce n'est pas le rôle du XML que de sécuriser des données. À cette fin, il
> existe l'excellent système d'encryption par clef publiques et privées (SSL,
> PGP).
>
> > une mauvaise politique de management qui serait tenu par l émetteur
> > de l informations, qu il serait libre de modifier au détriment de
> > la politique interne de l entreprise réprésenté par le dataware
> > house.
>
> Si un intervenant ne devrait pas avoir droit de modifier une information,
> c'est au logiciel d'en faire la vérification. Au besoin, un document maître
> peut être nettoyé de certains renseignements avant d'être transféré ou
> affiché.
>
> Le XML ne répond certainement pas à tous les besoins, mais son champ
> d'applications reste très large, et son avenir est loin d'être sombre. Il
> s'agit d'un effort de standardisation qui rentabilise les efforts de milliers
> de développeurs qui peuvent maintenant partager leur outils.
>
> Nicolas Marchildon
> Développeur Java
>
> Liens intéressants:
> http://www.w3.org/XML/
> http://xml.apache.org/
Je rajouterai:
http://www.jabber.org et particulièrement
http://docs.jabber.org/general/html/protocol.html pour un exemple
d'utilisation du XML en dehors des documents, incluant une partie
encryptée.
--
-------------------------------* *-------------------------
Fabien Niñoles / / [email protected]
Chevalier Servant de Sa Dame / / C15D FE9E BB35 F596 127F
Veneur Gris par la Clef / / BF7D 8F1F DFC9 BCE0 9436
Développeur pour Debian / / http://www.tzone.org/~fabien
--------------------------* *------------------------------