Le XML A quoi ca sert?
Résolu
Salut tous le monde,
Je sais, je vais en faire sauter plus d'un sur leur chaise avec le titre de ma question.... désolé d'être bete...lol
En faite, j'ai vu bcp de site qui parle de xml, disant que c'est génial, je veux bien le croire.... mais pourquoi?
Parce qu'a ce que j'ai vu, c'est une syntaxe assez simple dans le fond, on créer ses propre balises, ca stocke des données, ok... mais comment je modifie ca, mes sgbdd fond la meme chose. Ensuite, j'ai vu que les xsl, ou xslt, qui, si j'ai bien compris, sont la pour la mise en forme... mais moi, avec des syntaxes pareil, je prefere rester avec le html...
Enfin bon, désolé, mais je vois pas l'intérêt profond du xml, j'aimerais savoir ou je peux trouver un site qui saura m'eclairer plus sur le sujet parce qu'apparament se serait super et je n'aime rester dans cette ignorance.
Ne soyez pas trop dur et merci pour vos réponses.
Je sais, je vais en faire sauter plus d'un sur leur chaise avec le titre de ma question.... désolé d'être bete...lol
En faite, j'ai vu bcp de site qui parle de xml, disant que c'est génial, je veux bien le croire.... mais pourquoi?
Parce qu'a ce que j'ai vu, c'est une syntaxe assez simple dans le fond, on créer ses propre balises, ca stocke des données, ok... mais comment je modifie ca, mes sgbdd fond la meme chose. Ensuite, j'ai vu que les xsl, ou xslt, qui, si j'ai bien compris, sont la pour la mise en forme... mais moi, avec des syntaxes pareil, je prefere rester avec le html...
Enfin bon, désolé, mais je vois pas l'intérêt profond du xml, j'aimerais savoir ou je peux trouver un site qui saura m'eclairer plus sur le sujet parce qu'apparament se serait super et je n'aime rester dans cette ignorance.
Ne soyez pas trop dur et merci pour vos réponses.
19 réponses
Résumé de la discussion
XML est discuté comme une syntaxe flexible pour structurer des données, et la question centrale porte sur son intérêt réel, sa modification, et la comparaison avec HTML et les bases de données relationnelles. Pour comprendre les usages, l'échange entre systèmes hétérogènes et le stockage de paramètres apparaissent comme les principaux cas, tandis que XSLT transforme les données pour la présentation et le typage via XSD renforce la fiabilité. Certains exemples citent son intérêt pour l'échange de données entre environnements hétérogènes et la gestion de contenus structurés, tout en étant moins adapté à des besoins relationnels stricts.
-
arth Contributeur
-
sebsauvage ModérateurQuelques précisions:
http://sebsauvage.net/comprendre/xml/ -
Lust AuteurMerci,
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 -
sebsauvage ModérateurEnfin 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.) -
Lust AuteurOk, merci, alors je vais bien attendre pour m'y mettre....
-
geb'sva jetter un oeil sur cet article afin de comprendre les enjeux liés à l'XML.
https://www.guideinformatique.com/fiche-xml-355.html
cordialement,
geb's -
Lust AuteurJe 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é.-
slooptoola tu confonds un peu
xml n est pas un language c est un meta language (une serie de regles qui permettent de creer facilement des languages)
et justement le but est qu il ne soit pas complique
on en fait tout un foin parce que c est extremement utile : plus besoin de parsers exotiques, un meme parser simple pour tout (donnees de configuration, documents structures, language de representation...)
en gros il s agit de la premiere brique pour la standardisation
tres important : il ne faut jamais 'essayer' d utiliser xml, il faut DECIDER de l utiliser en fonction du besoin
quant a xsl tu te coupes d une fonctionnalite extremement puissante je t assure
enfin xml n est pas un fichier texte, le fichier texte n est qu une 'vue' de la structure xml
-
-
sebsauvage ModérateurJe 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 !")
-
slooptoofais donc je t en prie
heureusement qu on est encore ouvert a l argumentation
des APIs differentes ? il doit y avoir confusion vu que je ne vois que DOM, SAX et eventuellement StAX et E4X
getAttributes, getChildNodes... normalise tout ca
probleme de librairies entre plateformes ?
c est lie avec le DOM ca... si les parsers utilises ne s y conforment pas on peut pas y faire grand chose
> ... sauf qu'un parseur XML c'est tout sauf simple (en interne) :-)
je me suis mal exprime
je voulais dire que des parseurs bien plus complexes existaient deja pour le SGML et qu ils etaient presque totalement reuitilisables pour le XML (les parseurs xml sont simples en comparaison)
> 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.
pour le meme resultat ?
pardon mais c est exagere
cela me rappelle quelqu un qui disait qu il etait simple de creer un parseur de csv... pas si simple en prenant en compte les retours chariot et l encodage
qu ils consomment plus c est un fait mais ce n est pas a mon sens un killer argument compte tenu de la puissance apportee
pourquoi creer des parseurs differents aussi simples soient ils pour gerer fonctionnellement le meme besoin ? (et tous les besoins annexes de definition, de validation, d extensibilite)
oui on peut penser que c est utiliser un bulldozer pour ecraser une mouche... je prefere dire que c est un outil tres polyvalent et qu on aurait bien tort de s en priver (disons plutot que l analogie est mal choisie de mon point de vue)
maintenant on ne me fera jamais dire qu xml est utilisable partout
en revanche pour tout ce qui est internet il n y a pas photo, lorsqu on a un besoin de format documentaire pivot idem (et c est souvent), passer des donnees hierarchisees entre composants etc
-
-
Lust AuteurMerci 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) -
sebsauvage Modérateurvolumes 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.)
-
sebsauvage Modérateursi 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.
-
sebsauvage Modérateurpour 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.
-
slooptooLust : 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://wiki.c2.com/?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
https://www.informit.com/imprint/index.aspx?st=61085&p=367637&rll=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) -
Lust AuteurCe 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.-
slooptooparce que c etait un des buts premiers d xml... human readability...
et que tu fais comment pour distinguer un string d un numerique voire de binaire pur ? tu ajoutes le type devant ?
donc plutot que de se prendre la tete paf lors d un export fichier tout est en texte
un format xml binaire n est pas plus ni moins extensible... mais il n est pas lisible facilement
a noter un groupe de reflexion qui se penche d ailleurs sur la possibilite d avoir du 'xml binaire' http://www.w3.org/XML/Binary/
mais tant que les parsers ne sont pas prets...
pour enregistrer des donnees typees encore faudrait il qu xml oblige le typage des informations... ce qui n est pas les cas pour des raisons de simplification (j imagine qu a partir du moment ou xml est tire de SGML qui a des racines documentaires fortes on voit mal l interet de stocker binairement les informations numeriques)
xml n est pas une revolution c est une evolution... un outil tres puissant et versatile... libre a toi de ne pas l utiliser si tu penses que ce n est pas un bon outil pour tes problemes (et c est parfois le cas) mais ce detourner d une telle technologie parce qu on est pas d accord avec l ensemble des 10 buts initiaux d xml c est tres reducteur et peu constructif -
Lust Auteur@slooptooben un fichier texte n'est pas lisible non plus sans notepad...
Et pour ce qui est de s'écarter du xml... c'est assez dur. Je fais 98% de dot net... sans xml, je vais vite m'arrêter.... et bientot, je vais plus rien faire.
Xml, je pense pas qu'on puisse s'en écarter éternellement.
Juste que t'en qu'a faire un super format d'échange, autant le faire jusqu'au bout, et faire un lecteur de fichier xml binaire au meme titre que notepad qui lit lui aussi des données binaire pour les mettre en texte.
Et puis tant qu'a faire, on en profitera pour indexer les données. -
slooptoo@Lusteuh... la je vais prendre ta premiere ligne comme une plaisanterie ;-)
l indexation des donnees n est pas du ressort de la donnee elle meme... c est le cas meme dans les bdd... xml ne fait que presenter la donnee
elle est indexee ! (mais pas ou tu le crois)
il faut 2 secondes pour que msxml4 retrouve une node dans un fichier de 100M ! tu imagines si elle n etait pas indexee lors du parsing
xslt te proposes meme la creation de dictionnaires pour rendre les recherches encore plus rapides
c est un super format d echange (mais a t il seulement ete cree specifiquement pour ca) justement grace a son 'mono format' (tu penses vraiment vouloir entrer a nouveau dans les discussions int/bigint/float16/unsigned int voire varchar/nvarchar etc) et je te pointe a nouveau vers le groupe qui etudie la pertinence d un xml binaire
pour finir je ne saisis pas ton allusion a notepad et sa relation avec le binaire
le probleme que tu tentes d adresser est au dela de la simplicite d xml
-
-
Lust AuteurEn faite, ce que je reproche le plus au XML, c'est cette nécéssité d'avoir une représentation visuel directe et de vouloir confondre mécanique et carburant (dans la syntaxe) dans sa volonté de séparer les deux.
Pour un langage de prog, se baser sur les standards XML, ok, le programmeur à besoins de règles et d'une représentation texte de son langage.
Pour des données, la ou on trouve un atout au XML, moi je ne trouve pas. XML permet de stocker des dates sous des formes multiples et variées… mais ca reste une date, pour vouloir stocker une date n’importe comment pour au final retransformer, avoir des Pb de compatibilités de formats…..
L’exemple le plus flagrant à mon sens est la représentation d’un booléen : oui/non, vrai/faux, true/false, yes/no… pour récupérer ca et transformer ca en 0 ou 1…. Aye, je crois pas que stocker un « true » et un 0 soit la même chose…. Et en plus, faut analyser cette chaine de caractères pour dire c’est true quand : vrai, oui, true ou yes…. Voir même d’autres forme falquinotentesque (j’aime bien je viens d’inventer lol)… le forcing des formats n’est pas une mauvaise chose, surtout qu’on a vite fais le tout des formats (texte, numérique, booléens, date et binaire)-
slooptooqui t a dit qu on stockait une date n importe comment en xml ???
de meme que les booleens ?!?
le typage booleen en xml + xsd accepte true/false/0/1 et c est tout (il n est pas localise)
le parseur saura reconnaitre ces valeurs et les convertir en type de base le cas echeant
si tu utilises struts ou la reflexion, le mapping objet/relationnel etc tu verras a quel point l extensibilite d xml est utile
on ne peut pas critiquer d une part le fait qu xml est simple puis qu il est complique
je pense qu il est extremement simple a utiliser basiquement mais qu il possede une richesse assez incroyable (je parle d xml + xsd + xsl + xpath etc)
je dis aussi que du fait de la simplicite il est utilise a tort et a travers sans les competences requises (notamment en architecture de donnee) donc il est facile de se planter avec
-
-
sebsauvage Modérateuron se retrouve avec toutes les questions deja posees et resolues avec xml
XML résoud le problème de typage des données ? :-.
Là j'ai un doute, franchement.
(cf.l'exemple de Lust: True/False, 0/1, yes/no, etc.)
Dans tous les cas - que ce soit XML ou fichier à plat - on échappe pas à un contrôle des formats et un transtypage des données.
Certes XML avec ses outils (XSD) permet de faire certains contrôles, mais ça reste limité
(par exemple, XSD ne permettra pas de s'assurer que le numéro d'une annulation de commande correspond à celui d'une commande existantes. ça ne résoud donc que très partiellement les choses.)
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'
Quand on te demande d'extraire des données d'un fichier XML, tu n'as rien à développer ?
Pas même des appels à SAX, DOM ou XPath ?
Ou encore un XSLT ?
Quant à un parseur de fichier config paramètre=valeur, ça se fait en quelques ligne et c'est réutilisable sur beaucoup de fichiers de ce type.
autrement dit xml / SQLite = pas le meme combat (ils n adressent pas les memes problemes)
Generalement, oui, je suis d'accord.
Mais dans le cas d'échange de gros volumes de données, la question peut être pertinente.
Or l'un des buts premiers d'XML, c'est l'échange. (Et j'ajoute: voir la remarque ci-dessous sur l'XML binaire).
pardon ? compilation des patterns ca dit quelque chose ?
Ok, ok. +1.
Mais l'utilisation des patterns compilés ne nécessite-elle DOM (ou équivalent), c'est à dire le chargement intégral du fichier XML en mémoire ?
160 Mo de mémoire consommée d'un coup ?
C'est faisable, mais ça n'est pas forcément acceptable dans toutes les situations.
je signale que la meme chose etait faisable avec access (sic)
oui, mais Access était une base propriétaire, à source fermés, mono-plateforme et sous license non libre.
Ce n'est pas le cas de SQLite.
plus efficace ? plus simple ? plus interessant ? pardon ???
Je maintiens ce que j'ai dit sur SQLite.
Moins d'espace disque utilisé, structuré, totalement portable, typage, méthodes d'accès standardisées (SQL-92).
Elle réunit tous les critères nécessaires à l'échange automatisé de données.
et cette bibliotheque en C est tres standardisee probablement... et elle est d une simplicite telle que si le modele de donnees evolue... dommage...
C'est vrai.
Mais est-ce que la migration sera moins lourde dans le cas d'un changement de schéma XML ?
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
L'argument "contrôle de version" concernait les fichiers texte.
Dans un contrôle de version, on peut facilement suivre les modifs des fichiers de config à plat.
Suivre des modifs de fichiers de config XML n'est pas génial, parceque le retour à la ligne n'est pas une information pertinente en XML, et les gestionnaires de version ne savent pas comparer des fichiers XML.
Difficile, donc, de faire un suivi des modifications d'un fichier XML.
il frise la mauvaise foi (si cela venait de quelqu un d autre que vous j en serais absolument sur
Oh il m'arrive d'être de mauvaise foi des fois :-)
la je pense plutot a un leger manque de profondeur)
Non je suis sérieux.
Pourquoi prendre un marteau-pilon pour écraser une fraise ?
Oui XML peut faire mieux, peut faire plus, mais est-ce vraiment nécessaire ?
J'aime le principe du KISS.
quelle est la representation retrouvee en memoire ? peut on la parcourir facilement ?
Une hashtable fait l'affaire, généralement. L'accès est donc très rapide.
ajoutez donc un tableau (type liste de choix de textes) dans ce fichier a plat et on verra s il est plus court...
blacklisted_checksums=3c5454ab|5537ab3d|2174bdfe|5eca35bd
Le parseur n'en est pas beaucoup plus compliqué.
a noter un groupe de reflexion qui se penche d ailleurs sur la possibilite d avoir du 'xml binaire'
Justement, ça ne te met pas la puce à l'oreille que ce besoin se fasse ressentir ?
(On semble se rapprocher de fichiers du type RIFF ou IFF, mais en plus évolué (qui en soit étaient de bonnes idées)).
Je ne suis pas un adversaire absolu de l'XML.
C'est juste que je trouve qu'il ajoute une complexité qui est parfois utile, mais dans la très grande majorité des cas XML est mal maîtrisée, mal utilisé et abusé, et aboutit à une complication inutile des programmes et des interfaces.
XML a ses usages, mais dans la pratique, il complique souvent des solutions qui pourraient être simples.
je dis aussi que du fait de la simplicite il est utilise a tort et a travers sans les competences requises (notamment en architecture de donnee) donc il est facile de se planter avec
Voilà, tout à fait.
XML en soit n'est pas mal du tout.
Mais cet argument me fait penser aux critiques sur l'Agile Programming: Quand on montre aux défenseur de l'Agile Programming l'énorme quantité d'échecs dans la pratique, ils rétorquent que c'est parceque la méthode a été mal utilisée.
Mais si 95% des utilisateurs ne parviennent jamais à maîtriser correctement la méthode, est-ce qu'il ne vaut pas mieux choisir une autre méthode ? (Quitte à ce qu'elle soit moins "pure" ?)
C'est un peu le cas pour XML, je trouve.
(Merci pour les liens, c'est intéressant)
-
slooptoomais en fait on dirait que nous sommes d accord mais nous ne l exprimons pas de la meme facon
j aimerais rapprocher le probleme de l utilisation du html :
tres imple d utilisation si bien que tout le monde l utilise (et surtout pour faire n importe quoi) si bien qu une partie de la communaute informatique le denigre fortement
je pense que pour xml le proces est exagere... c est tout de meme une base extremement interessante (qui ne comble pas tous les besoins repetons le encore mais ce n est pas son but)
une semantique simple de creation de language : c est tout de meme un besoin tres recurrent
je en repasse pas sur le message qui, je le pense, est tres critiquable sur certains points (par exemple sur l idee d une table de hash hierarchisee... hem... ou alors l histoire de controles fonctionnels mis au meme niveau que les controles de type... on s emporte)
peut etre que la facon d aborder xml apporte son lot de confusion :
personnellement je pesne qu on ne peut pas dire qu on connaisse xml sans connaitre les technologies autour (DOM, SAX, xsd, xsl...)
(je precise que ce n est en aucun cas une critique a l encontre de qui que ce soit sur le forum)
et que seules les personnes ayant cette connaissance peuvent juger de la pertinence et du volume technique a engager pour repondre a tel ou tel probleme
par exemple, et tout a fait honnetement, pour les fichiers de configuration j estime que c est une solution plus que pertinente sinon incontournable et que l utilisation de fichiers plats avec des separateurs pipes est peut etre seduisante au premier abord mais comporte des limitations certaines (notamment de par la necessite de developer le parser... qui devra evoluer dans le temps... jusqu au point ou on se trouvera avec un mock-up d xml (sic... deja vu))
attention a ne pas comparer des elements materiels a de l immateriel (methodes et outils)
-
-
sebsauvage Modérateurpersonnellement je pesne qu on ne peut pas dire qu on connaisse xml sans connaitre les technologies autour (DOM, SAX, xsd, xsl...)
Tout à fait !
Et c'est pas simple, d'ailleurs: https://wdvl.com/
-
estelleEt si on revenait aux sources http://www.w3.org/XML/1999/XML-in-10-points.fr.html
-
etudiantebonjour
j'ai ce fichier xml
<?xml version="1.0" encoding="UTF-8"?>
<usecase>
<titre>Retirer de l'argent</titre>
<resume> permettre à tous client de la banque porteur de carte bancaire de retirer de l'argent
si son solde hebdomadaire le permet</resume>
<listedesacteurs>
<acteur>client</acteur>
<acteur>ATM</acteur>
<acteur>receveur de banque</acteur>
</listedesacteurs>
<version>1.0</version>
<datedecreation>14 juin 2006 11:44:26</datedecreation>
<datedemiseajour>14 juin 2006 11:44:26</datedemiseajour>
<precondition>Caisse du ATM alimentée</precondition>
<postcondition>Diminution de la somme d'argent</postcondition>
<listrelationship >
<Include>
<Source>retirer de l'argent</Source>
<Destination>authentification</Destination> </Include>
<Extend>
<Source>controler solde</Source>
<Destination>retirer de l'argent</Destination>
</Extend>
</listrelationship >
<NbreSA>4</NbreSA>
<NbreSE>3</NbreSE>
<ScenarioNominal>
<action>
<numN>1</numN>
<preconditionN>lecteur de carte libre</preconditionN>
<acteurN>client</acteurN>
<nomN>le client introduit sa carte dans le lecteur des cartes</nomN>
</action>
<action>
<numN>2</numN>
<preconditionN>lecteur de carte libre</preconditionN>
<acteurN>ATM</acteurN>
<nomN>l'ATM vérifie que la carte introduite</nomN>
</action>
<action>
<numN>3</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>ATM</acteurN>
<nomN>l'ATM demande au client de saisir son code d'identification</nomN>
</action>
<action>
<numN>4</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>client</acteurN>
<nomN>le client saisit son code d'identification</nomN>
</action>
<action>
<numN>5</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>ATM</acteurN>
<nomN>l’ATM compare le code d’identification avec celui qui est codé sur la puce de la carte </nomN>
</action>
<action>
<numN>6</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>ATM</acteurN>
<nomN>L’ATM donne son accord et indique le solde hebdomadaire </nomN>
</action>
<action>
<numN>7</numN>
<preconditionN> caisse alimentée </preconditionN>
<acteurN>ATM</acteurN>
<nomN>l’ATM demande au client de saisir le montant de retrait désiré</nomN>
</action>
<action>
<numN>8</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>client</acteurN>
<nomN>le client saisit le montant désiré du retrait</nomN>
</action>
<action>
<numN>9</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>ATM</acteurN>
<nomN>L’ATM contrôle le montant demandé par rapport au solde
hebdomadaire </nomN>
</action>
<action>
<numN>10</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>ATM</acteurN>
<nomN>L’ATM delivre l’argent </nomN>
</action>
<action>
<numN>11</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>L’ATM </acteurN>
<nomN> L’ATM registre la transaction </nomN>
</action>
<action>
<numN>12</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>L’ATM </acteurN>
<nomN> L’ATM modifie le compte de client</nomN>
</action>
<action>
<numN>13</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>L’ATM </acteurN>
<nomN> L’ATM délivre un ticket</nomN>
</action>
<action>
<numN>14</numN>
<preconditionN>caisse alimentée</preconditionN>
<acteurN>L’ATM</acteurN>
<nomN> L’ATM éjecte la carte</nomN>
</action>
</ScenarioNominal>
<SAlternatif1>
<num>1</num>
<NomScenarioA> montant desiré supérieur au solde hebdomadire</NomScenarioA>
<EvenementA> montant désiré </EvenementA>
<ActionDebutA>9</ActionDebutA>
<SequenceA1>
<NumA>13</NumA>,
<SystemeA>ATM</SystemeA>
<NomA>indique au client que le montant demandé est superieur au solde hebdomadaire</NomA>
<Reprendre> Le scénario nominal reprend au point 3</Reprendre>
</SequenceA1>
</SAlternatif1>
<SAlternatif2>
<num>2</num>
<NomScenarioA> ticket refusé</NomScenarioA>
<EvenementA> ticket refusé</EvenementA>
<ActionDebutA>9</ActionDebutA>
<SequenceA1>
<NumA>14</NumA>,
<SystemeA>ATM</SystemeA>
<NomA>indique au client que le montant demandé est superieur au solde hebdomadaire</NomA>
<Reprendre> Le scénario nominal reprend au point 3</Reprendre>
</SequenceA1>
</SAlternatif2>
<SErreur1>
<NomScenarioE>carte non valide </NomScenarioE>
<EvenementE> le client entre une carte non valide </EvenementE>
<ActionDebutE> SErreur1 commence au point 2 du scénario nominal </ActionDebutE>
<SequenceE>
<NumE>3</NumE>
<PreconditionE/>
<SystemeE>ATM</SystemeE>
<Nom>l’ATM indique au client que la carte n’est pas valide </Nom>
</SequenceE>
<SequenceE>
<NumE>4</NumE>
<PreconditionE/>
<SystemeE>ATM</SystemeE>
<Nom>l’ATM, confisque la carte et le cas utilisation se termine</Nom>
</SequenceE>
</SErreur1>
<SErreur2>
<NomScenarioE>retrait non autorisé </NomScenarioE>
<EvenementE> le client n’est pas autorisé de retirer argent</EvenementE>
<ActionDebutE> SErreur2 commence au point 9 du scénario nominal </ActionDebutE>
<SequenceE>
<NumE>10</NumE>
<PreconditionE/>
<ActeurE>receveur de banque</ActeurE >
<Nom> receveur de banque interdit tout retrait</Nom>
</SequenceE>
<SequenceE>
<NumE>11</NumE>
<PreconditionE/>
<ActeurE>ATM</ActeurE >
<Nom>L’ATM ejecte la carte</Nom>
</SequenceE>
</SErreur2>
<SErreur3>
<NomScenarioE>carte non reprise </NomScenarioE>
<EvenementE> le client ne prend pas sa carte</EvenementE>
<ActionDebutE> SErreur3 commence au point 14 du scénario nominal </ActionDebutE>
<SequenceE>
<NumE>15</NumE>
<PreconditionE>Après 15 secondes</PreconditionE>
<SystemeE>ATM</SystemeE>
<Nom>l’ATM confisque la </Nom>
</SequenceE>
<SequenceE>
<NumE>16</NumE>
<PreconditionE/>
<SystemeE>ATM</SystemeE>
<Nom>l’ATM informe la receveur de banque ;le cas d’utilisation se termine </Nom>
</SequenceE>
</SErreur3>
<SErreur4>
<NomScenarioE>ticket non pris</NomScenarioE>
<EvenementE> le client ne prend pas le ticket</EvenementE>
<ActionDebutE> SErreur3 commence au point 13 du scénario nominal </ActionDebutE>
<SequenceE>
<NumE>14</NumE>
<PreconditionE>Après 30 secondes</PreconditionE>
<SystemeE>ATM</SystemeE>
<Nom>l’ATM confisque le ticket </Nom>
</SequenceE>
<SequenceE>
<NumE>15</NumE>
<PreconditionE/>
<SystemeE>ATM</SystemeE>
<Nom>l’ATM informe le receveur de banque ;le cas d’utilisation se termine avec echec</Nom>
</SequenceE>
</SErreur4>
</usecase>
et je vais extraire les balises nomN
j'ai ce programme
import java.io.FileReader;
import org.xml.sax.InputSource;
import org.xml.sax.XMLReader;
import org.xml.sax.helpers.DefaultHandler;
import org.xml.sax.helpers.XMLReaderFactory;
import com.sun.org.apache.xalan.internal.xsltc.runtime.Attributes;
public class recherche extends DefaultHandler
{
public static void main (String args[])
throws Exception
{
XMLReader xr = XMLReaderFactory.createXMLReader();
recherche handler = new recherche();
xr.setContentHandler(handler);
xr.setErrorHandler(handler);
xr.parse("usecase.xml");
// Parse each file provided on the
// command line.
for (int i = 0; i < args.length; i++) {
FileReader r = new FileReader(args[i]);
xr.parse(new InputSource(r));
}
}
public recherche ()
{
super();
}
////////////////////////////////////////////////////////////////////
// Event handlers.
////////////////////////////////////////////////////////////////////
public void startDocument ()
{
System.out.println("debut de l'analyse");
}
public void endDocument ()
{
System.out.println("fin de l'analyse");
}
public void startElement (String uri, String name,
String qName, Attributes atts)
{
if (qName.equals ("nomN"))
{ System.out.println("ouverture de la balise " + qName);
System.out.println("valeur:" + uri + "}" + atts);
}}
public void endElement (String uri, String name, String qName)
{
if (qName.equals ("nomN"))
System.out.println("fermeture de la balise: " + qName);
else
System.out.println("fermeture de la balise:" + name);
}
public void characters (char ch[], int start, int length)
{
System.out.print("attribut:");
for (int i = start; i < start + length; i++) {
switch (ch[i]) {
case '\\':
System.out.print("\\\\");
break;
case '"':
System.out.print("\\\"");
break;
case '\n':
System.out.print("\\n");
break;
case '\r':
System.out.print("\\r");
break;
case '\t':
System.out.print("\\t");
break;
default:
System.out.print(ch[i]);
break;
}
}
System.out.print("\"\n");
}
}
il me donne pas les attributs comment je peux le corriger
pouvez vous me corriger s'il vous plait-
-
NyroAbusé...Franchement poster aussi betement c'est criminel...
Enfin j'aurais quand meme retenu de cette conversation que le XML c'etait bien mais pas top.
Si il avait ete plus concis (au niveau structure des donnees) et qu'on avait developpe des logiciels de lecture (pour le "human readability"), ca aurait ete beaucoup mieux. Un stockage de donnees le moins typee possible et que les parsers gereraient eux-meme le transtypage ou la conversion (avec des parsers ultra basiques et des parsers ultra complets par exemple).
Apres j'ai peut etre mal compris. Mais bon rien n'est jamais parfait et je vois mal un changement aussi fondamental intervenir pertinemment pour le xml (il faudrait que tout le monde refasse ses donnees, ses scripts de gestion, etc...)..
-
