 |
|
|
|
| Le XML A quoi ca sert? par  Lust |
mardi 16 mai 2006 à 05:08:47 |
|
|
|
Merci,
SebSauvage, je connais bien ton site et j'ai déjà pas mal survoler ton article la dessus, quand à celui de développer .com, lui aussi je connais, celui d'ici aussi avant qu'on me le propose... En faite, je suis plus à la recherche d'un petit exemple concret de mise en application des fonctionnalités du xml |
Enfin bon, désolé, mais je vois pas l'intérêt profond du xml
Moi non plus ! Le principal intérêt que je verrais, c'est pour l'échange de données automatisés entre système hétérogènes. (Et encore ! Souvent des fichiers à plat ou un fichier SQLite3 ferait mieux l'affaire.) |
Ok, merci, alors je vais bien attendre pour m'y mettre.... |
va jetter un oeil sur cet article afin de comprendre les enjeux liés à l'XML.
http://www.guideinformatique.com/fiche-xml-355.html cordialement, geb's |
Je sais à quoi ca sert... je fais du dot net... et avec le framework 3, xaml, c'est du xml et puis les fichiers ressources, config....... et puis les rss, les plans sitemap, etc etc etc.....
Mais reste que xml, je comprends pas qu'on dise que c'est compliqué, c'est juste une espece de type de classement ou organisation de données texte. Je ne comprends en faite pas vraiment qu'on en fasse tout un foin... En faite, quand j'essai d'utiliser le xml dans des applications je m'arrete vite parce que j'ai besoin de relationnel.... le xml reste pour des stockages de données simples, paramètres d'appli, plans, des données plattes... Quand aux pages avec du xml comme sources et xls format ou autres, je ne suis pas pret de m'y mettre... sauf sous la torture. Enfin, pour moi xml, ca reste un fichier texte structuré... pas un langage... désolé.
|
Je vais jouer l'avocat du diable (rien de personnel contre toi, slooptoo):
plus besoin de parsers exotiques ... mais des tas d'API différentes pour accéder à un même contenu. Qu'est-ce que vous utiliserez pour lire votre fichier XML ? SAX ? DOM ? ElementTree ? Expat ? 4Suite ? Xerces ? libxml ? MSXML ?... Chaque parseur a une API différente. ( Et il faut voir la tronche des API... :-/ Rien que pour lire une simple valeur, c'est celuiQuiEcritLeNomDeFonctionLePlusLongAGagné() ) Vous changez de plateforme (langage, OS) ? Ah flûte, la librairie que vous utilisiez n'existe pas sur la nouvelle plateforme. Il faut recoder complètement le code qui lit le fichier XML pour utiliser la nouvelle API. Pouark ! un meme parser simple pour tout ... sauf qu'un parseur XML c'est tout sauf simple (en interne) :-) (détection fin et début des balises, support des encodages (UTF-8, ISO-8859-1...), détection et conversion des entités (& ...;), prise en compte des espaces inutiles, éventuelle validation contre un schéma...) Par rapport au parsing d'un fichier tabulaire ou un simple fichier .ini, les parseurs XML consomment nettement plus de mémoire et plus de CPU... pour le même résultat. enfin xml n est pas un fichier texte, le fichier texte n est qu une 'vue' de la structure xml Ah... ça fait plaisir de lire ça ! Vraiment. Il y a si peu de personnes qui comprennent la différence entre une donnée et sa représentation. (Combien de fois j'ai pu entendre: "Mais moi je veux que ma date elle soit au format français dans ma base de données !") “Life is short - You need Python” -- Bruce Eckel, membre du comité ANSI C++
|
Merci d'être le diable... lol
Désolé d'avoir traité XML de fichier texte... mais je crois j'en démords complètement. En faite, ce que j’ai voulu dire par la, c’est que la données en elle même est du texte, sans les transformations du parseur, la donnée est du texte… tu peux très bien enregistrer une données texte dans un champ qui se dis entier… tu ne types pas réellement les données. Quand aux parseurs, oualala, c’est bien vrai que la j’ai beaucoup de mal… enfin, j’utilise surtout celui de dot net, et la, je pense qu’à chaque fois, faut que je regarde comment ca fonctionne (p-e aussi de la mauvaise volonté). Quand aux langage dérivés du xml (si je m’exprime bien), langage déclaratif à la xaml, je ne suis pas adepte… mais je vais m’y mettre quand même, j’ai pas le choix. Mais, j’admets quand même qu’en matière d’échange de données, ou gestion de données assez simples et à volumes réduits, c’est vrai que c’est génial. Mais si j’ai choix de placer mes données d’applications dans un bdd ou dans un xml… la bdd l’emporte… si j’ai des échanges, il me sera plus simple de générer du xml avec ma bdd, que de travailler en continu avec du xml. NB : Le SQL, ca c'est de la standardisation... lol ( pour comparer aux parseurs) |
volumes réduits, c’est vrai que c’est génial.
Volumes réduits, oui. Justement, c'est là que XML me pose un problème: A gros volume, c'est ingérable (je ne sais pas si vous avez déjà travaillé avec les Purchase Order de Rosetta.Net, les schémas sont à se tirer une balle). Ok. Donc XML est mieux adapté aux petits volumes. On est d'accord. Mais dans ce cas, est-ce que XML n'est pas un peu overkill ? Si c'est un petit volume, un simple fichier texte ne serait-il pas largement suffisant ? (Je ne parle pas de CSV, qui est - c'est vrai - pas simple à parser). Exemple 1: Entre les fichiers de configuration XML du serveur Samba et ceux en texte (paramètre=valeur) d'Apache, je préfère largement ceux d'Apache: c'est beaucoup plus simple à lire humainement et il est facile d'écrire un parseur. (Et c'est plus facile à comparer aussi ! Et aussi à tracer dans un gestionnaire de sources) Exemple 2: Dans un de mes soft, j'avais la configuration du programme à conserver. J'avais fait en XML et je suis revenu à une structure .INI. Au final, je me suis aperçu que j'avais une structure nettement plus simple lire et écrire que l'XML, tout aussi humainement compréhensible et qui pourtant permet de hiérarchiser les paramètres. (En fait, je suis arrivé à un truc très similaire au about:config de Firefox). Donc que ce soient gros ou petits volumes, dans grande majorité des cas les solutions autres que XML me semblent mieux adaptées. J'ai de plus en plus de mal à trouver de pertinence à l'XML. Comme disait je ne sais plus qui sur un blog, XML est une solution à la recherche d'un problème. (C'est méchant comme remarque, c'est vrai.) Tiens justement, deux articles pertinents et critiques (et argumenté) concernant XML (Ne vous fiez pas au titre qui est racolleur): http://xmlsucks.org/but_you_have_to_use_it_anyway/does-xml-suck.html http://webservices.xml.com/pub/a/ws/2001/10/03/webservices.html (Le premier article est vraiment très bien.) “Life is short - You need Python” -- Bruce Eckel, membre du comité ANSI C++ |
si j’ai des échanges
Justement j'ai découvert un truc très intéressant pour stocker des données, les rechercher et les échanger: SQLite C'est une base de données sous forme de librairie (le runtime ne fait que 250 ko). - Les bases SQLite sont portables (Windows, Linux, MacOSX, PDA...). (XML l'est aussi, ok). - SQLite est accessible de pratiquement tous les langages (C, C++, Java, Python...). (XML aussi, ok) - Une base SQLite est un simple fichier contenant tout (schéma, tables, indexes,...). (En XML le schéma est un fichier séparé) - SQLite est efficace (stockage des données en binaire) ; XML est verbeux (tout est stocké en texte, même le binaire !) - SQLite supporte entiers, flottants, texte et binaire (blob). XML ne supporte que le texte. Pour stocker du binaire, vous devez passer par du base64 (gaspillage de place !) - SQLite gère les transactions (donc en prime ça assure l'intégrité des données). Aucune notion de transaction en XML. - Et enfin ça permet de gérer jusqu'à 2 Téra-octets de données (totalement impensable en XML). - SQLite est indexé: la recherche est ultra-rapide. (XML ne l'est pas, et la recherche est très lente) Ce qui veut dire que SQLite peut servir à échanger des données relationnelles ou à plat, texte, nombre ou binaire, entre programmes et systèmes hétérogènes. ça me semble nettement plus efficace, simple et intéressant que l'XML pour échanger un ensemble de données complexes (quel que soit le volume). Plus besoin de perdre son temps à créer des parseurs XML, parcourir les arbres XML pour extraire les données, tout ça pour au final aller les remettre dans une base de données (ce qui est bien souvent le cas). Là vous échangez directement la base de données. (Et en prime si un jour SQLite ne suffit plus, vous pouvez switcher votre base de données sur de l'Oracle ou autre pour gérer de très gros volumes.) Je suis de plus en plus fan de cette base de données. “Life is short - You need Python” -- Bruce Eckel, membre du comité ANSI C++ |
pour le meme resultat ?
pardon mais c est exagere J'argumente: Un fichier de config: Version XML:
<?xml version="1.0" encoding="ISO-8859-1"?>
<config>
<network>
<proxy>
<enabled>True</enabled>
<address>myproxy.myisp.com</address>
<port>3128</port></proxy>
</network>
<assembler>
<invert>True</invert>
<emboss>False</emboss>
</assembler>
<debug>False</debug>
<pool>
<directory>imageppol</directory>
<nbimages>50</nbimages>
</pool>
</config>
La même chose en version "à plat": network.proxy.enabled=True network.proxy.address=myproxy.myisp.com network.proxy.port=3128 assembler.invert=True assembler.emboss=False debug=False pool.directory=imageppol pool.nbimages=50 Les deux me permettent de coder la même information, et de manière hiérarchique. Mais la seconde est: - nettement plus lisible (humainement) - tout aussi facile à parser (voir plus) - plus courte Voilà ce qui me tracasse: Puisque la seconde solution répond parfaitement au besoin, pourquoi s'embêter avec de l'XML ? Et comme on a dit, si les volumes sont plus importants, l'XML devient lourd à gérer. “Life is short - You need Python” -- Bruce Eckel, membre du comité ANSI C++ |
Lust : malheureusement j ai l impression que ta volonte de rester sur ton impression qu xml n est pas adapte voile ta comprehension de la technologie
tu dis 'la donnee est du texte' et tu oublies donc que la grammaire xsd est justement la pour 'typer' le document... le fait qu elle soit optionnelle est une bonne idee qui simplifie l utilisation d xml mais si tu veux justement utiliser des fonctionalites plus avancer tu dois prendre en compte les 'technologies' liees et ne compare pas xml a une base de donnees... en gros tu es en train de critiquer une mauvaise pratique que tu as probablement vu etre mise en oeuvre (et tu as le droit de le critiquer) cela ne veut pas dire pour autant qu xml n a aucun but sebsauvage : desole mais si on me dit que pour traiter un fichier de parametres je dois ecrire un parseur alors je reponds 'j ai autre chose a faire' pour les gros volumes de donnees (et notamment documentaires) c est tout a fait gerable (documentations de maintenance en avionique... 160M la piece sans images) ; un schema complexe denote soit une incompetence du redacteur (douteux) soit un fonctionnel lui meme complexe mais en aucun cas ce n est un probleme d xml pour la solution qui ressemble au about:config... une question au hasard : ou est le typage de la donnee ? quel est l outil de validation permettant a quelqu un le modifiant a la main de savoir ou est une erreur ? on gratte un peu et on se retrouve avec toutes les questions deja posees et resolues avec xml (sic) je ne trouve pas que le premier article soit si argumente que ca et il est meme tres critiquable (2002 peut expliquer certains points) par exemple : le point 6 ne sont que des affirmations non argumentees le point 7 est une reponse a cote de la plaque car ses exemples de remplacement ne fournissent pas de systeme de parcours/recherche... a partir du moment ou l on type/identifie de maniere verbeuse le resultat est forcement verbeux le point 8 n est pas une complexite mais une liberte donnee dans l utilisation d xml (venant du sgml d ailleurs) il est idiot de critiquer xml parce que 'des gens' (lesquels d ailleurs) utilisent des attributs plutot que du contenu le point 9 est du meme tonneau quoiqu il soit vrai que dans les 10 buts premiers il etait indique qu ecrire un parser xml devait etre simple (et a vrai dire cela ne me semble pas si complique a coup de Lex/Yacc... pas simple mais pas si complique)... la derniere ligne est desormais fausse etc (je passe sur des points ou il semble avoir raison et d autres ou il a manifestement tort) on trouve une discussion plus interessante ici http://c2.com/cgi/wiki?XmlSucks il y aurait beaucoup a dire sur la solution SQLite qui ne m en semble pas une notamment parce qu elle ne resout qu un probleme (stockage de donnees) parmi d autres (interoperabilite, acces simplifie) : autrement dit xml / SQLite = pas le meme combat (ils n adressent pas les memes problemes) SQLite gere les transactions(donc l integrite des donnees... pardon ?)... on se trompe manifestement de combat... qui a dit qu xml devait remplacer les bases de donnees ??? pourquoi xml qui decrit un format devrait s occuper de definir les transactions qui permettent de le mettre a jour ?!? d autant plus que c est tres facile a mettre en place dans le langage de programmation utilise autour d xml le meilleur pour la fin : > ça permet de gérer jusqu'à 2 Téra-octets de données > (totalement impensable en XML). c est tout a fait exact mais... est-ce bien le traitement du meme type de probleme ? > SQLite est indexé: la recherche est ultra-rapide. > (XML ne l'est pas, et la recherche est très lente) pardon ? compilation des patterns ca dit quelque chose ? xml est indexe aussi (en fait cela depend du parser) mais ce n est pas si explicite... a propos de tout ca j ai aussi un lien autrement plus interessant http://www.awprofessional.com/articles/article.asp?p=367637&rl=1 comment SQLite permet d echanger des donnees ? en envoyant le fichier representant la base de donnees c est cela ? je signale que la meme chose etait faisable avec access (sic) il est donne deux utilisations totalement incompatibles comme argument... si SQLite n est plus suffisant alors on change vers Oracle et du coup on ne peut plus utiliser l idee (pas si astucieuse de mon point de vue) de la transmission de donnees... plus efficace ? plus simple ? plus interessant ? pardon ??? et cette bibliotheque en C est tres standardisee probablement... et elle est d une simplicite telle que si le modele de donnees evolue... dommage... j imagine qu il n y a rien de tel que quelques requetes SQL dans le code pour recuperer des parametres... et elle est probablement parfaitement adaptee aux problemes documentaires (conversion pour presentation, donnees structurees faiblement (multiplication de para), donnees hierarchisees dynamiques (elements optionnels))... et, pour reprendre l argument, c est un bonheur de l avoir en controle de version et je ne vois pas le rapport avec l utilisation qui est faite d xml quant au dernier exemple il frise la mauvaise foi (si cela venait de quelqu un d autre que vous j en serais absolument sur... la je pense plutot a un leger manque de profondeur) : quel objet utilisez vous donc pour parser ce document a plat ? quelle est la representation retrouvee en memoire ? peut on la parcourir facilement ? ajoutez donc un tableau (type liste de choix de textes) dans ce fichier a plat et on verra s il est plus court... la seconde solution peut repondre au besoin mais elle n offre pas la flexibilite d xml (c est a dire l ajout reflechi de fonctionnalites avec l evolution du besoin vis a vis de ce fichier) comme il vaut mieux prevenir que guerir autant utiliser la meme solution pour tous ces 'petits' problemes (et ne revenez pas me dire qu xml empiete sur les bdd... cela n est pas son role et je serai toujours d accord pour dire qu une telle utilisation est incorrecte) |
Ce que je veux dire, c'est que tant qu'a faire xml un format d'échange de données avec de toute façon la nécessité d'utiliser un parseur pour la lecture des données, pourquoi enregistrer ces données encodé en texte, pourquoi ne pas directement enregistrer un entier pour ce qu'il est, parce même si le xsd type tes données, elle reste quand même enregistrée sous forme de texte... et même si le xml évite d'avoir à typer les données ce qui le rends plus extensible, un format binaire et bien plus extensible encore.
En plus, enregistrer les données dans leurs plus simple appareil permettrait de réduire leurs tailles. Xml est une bonne idée d'agencements de données et possède des parseurs qui s’en trouvent simplifiés. J'aurai plus trouvé ca comme une révolution si les données étaient enregistrées dans leurs formats d'utilisation... sans besoin de conversion.
|
