Bonjour cher journal,
Oui nous sommes vendredi et oui certains verront cette affirmation comme un appel au troll.
Mais il n'en est rien (enfin peut-être un peu quand même)!!!
Cette affirmation ne viens pas de moi, mais plutôt d'un des gourous de l'open-source reconnu pour sa tempérance, son objectivité et ses bonnes manières en toutes circonstances: Mr Linus Torvalds.
En effet, dans un post Google+ (https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV), il explique que le projet Subsurface (un logiciel qui permet de tenir un journal de ses expéditions sous-marines, projet dont Linus a été le mainteneur principal) s'appuie sur XML. Il évoque que ce choix devient de plus en plus difficile à maintenir avec le temps.
Dans les commentaires il va même plus loin:
XML is crap. Really. There are no excuses. XML is nasty to parse for humans, and it's a disaster to parse even for computers. There's just no reason for that horrible crap to exist.
Ce que j'aurais personnellement traduit par (un peu d'indulgence, je ne suis pas angliciste pratiquant):
XML c'est de la daube. Il n'y a aucun doute. XML n'est pas adapté à la compréhension humaine, et c'est un désastre pour une lecture par un ordinateur. Il n'y a aucune raison à l’existence de cette daube.
Il explique tout de même son choix initial par le fait que "I originally used XML as the save file format, because while it is probably the worst format ever designed, it's what other projects used" ("Je me suis appuyé sur XML comme format de fichier, car même si c'est le plus mauvais, c'est celui que tout le monde utilise")
Je ne discuterai pas du choix de Linux de passer son format de fichier sous un format Git, je ne connais pas assez la chose pour avoir un avis. Ce sabotage en règle de XML n'est peut-être, après tout, qu'une manière de justifier ce switch. Comme dit le poète, le meilleur format est certainement celui qu'on maîtrise le mieux et dans la mesure où Linus est à l'initiative de Git, ça se comprend.
Mais j'avoue que personnellement, je suis toujours resté septique par rapport à ce format qu'on m'a toujours vendu comme universel, car facile à comprendre par l'homme et le machine. Alors que, d'après moi, c'est loin d'être le cas. C'est surtout rigolo de voir à quel point il peut être utilisé à outrance dans des cas où d'autres formats plus simple (un fichier ini par exemple, qui je rappelle n'est pas un gros mot) aurai rendu la chose plus facile.
Aussi, j'en appel à toi journal, pour m'aider à me faire une vrai opinion sur ce format.
Bisous.
# YAML
Posté par Anonyme . Évalué à 10.
Un fichier ini, c'est un peu limité quand meme, meme si parfois ca suffit. En general je préfère un fichier YAML, ca reste simple et lisible par un humain. Et c'est suffisement évolué pour permettre de serializer à peu près toutes les structures de données possibles dans la plupars des languages.
[^] # Re: YAML
Posté par freem . Évalué à 2.
s/parfois/souvent
Du moins, souvent sur ma machine avec les logiciels que j'utilise. Pour la configuration.
Oui, parce qu'a mon avis, INI, c'est bien, c'est efficace… pour des config. C'est à dire des fichiers qu'il est agréable et utile de pouvoir modifier à la main, mais qui ont une volumétrie raisonnable.
Pour des fichiers de sauvegarde, je suis d'accord, ce n'est pas adapté. D'ailleurs, un format lisible par l'homme pour ce type d'utilisation ne me semble pas adapté non plus de façon générale. Les soucis étant que, les binaires, c'est pas versionnable, et en plus ça risque de péter en fonction de l'endianness.
Conclusion, j'utilise boost::serialization pour les sauvegardes de données, et boost::program_options pour la configuration ( ce qui me permets en plus de très aisément "configurer" mes outils en tapant la ligne de commande, et d'avoir un "--help" en 3 lignes de code. ).
Mais YAML n'est pas mal non plus :)
[^] # Re: YAML
Posté par Firwen (site web personnel) . Évalué à 3.
Boost::serialization est pas mal du tout, mais la sérialization des objets, c'est aussi loin d’être parfait en terme d'évolution.
Dés que le layout de tes objets changent un peu ( ajout de champs ou suppression ), tu es obliger de versionner tes classes pour pouvoir continuer à charger les vieux objets sérializés… Ce qui devient vite un gros bordel, disons le franchement.
[^] # Re: YAML
Posté par freem . Évalué à 2.
En même temps, dès que tu ajoutes ou supprimes des données importantes, peu importe la façon d'écrire/lire tes données, soit tu te cantonnes à l'ancien format qui sera donc limité ( pas de possibilités d'exploitation des nouveaux champs, et valeurs des champs supprimés perdues ), soit tu casses la compatibilité, soit tu implémentes un mécanisme de version, chose que boost::serialization fait, de mémoire, pas trop mal.
Et toi, tu fais comment dans ce type de cas ( question réelle, ce sujet m'intéresse ) ?
[^] # Re: YAML
Posté par Firwen (site web personnel) . Évalué à 4.
Je suis loin d'être un fan d'XML à toute les sauces qui est à mon gout souvent un overkill pour une simple sauvegarde.
Mais les gros avantages de formats textes XML, JSON ou des formats binaires fait correctement comme protobuf ( https://developers.google.com/protocol-buffers/docs/overview ), c'est que tu peux étendre facilement ton format au fil des versions sans casser la compat ascendante et descendante à tout va.
[^] # Re: YAML
Posté par freem . Évalué à 1.
Et c'est aussi ce que propose le format texte fournit avec boost::serialization.
Il n'empêche que tu dois fatalement gérer la différence de version quelque part, dans ton code. Aucune lib ne peut le faire d'elle même.
Le point étant que, de toute façon, boost::serialization n'est pas un format, mais une lib générique permettant de (dé)sérialiser. Il peut utiliser divers formats, dont XML, plus ou moins indiféremment ( sauf que dans le cas d'xml ou json, il faut dans la méthode serialize() indiquer le noms des clés, forcément, chose qui n'est pas nécessaire dans le format texte brut offert par défaut ).
[^] # Re: YAML
Posté par tyoup . Évalué à 1.
D'où l'intérêt d'utiliser des structures génériques (qui ne bougent pour ainsi dire jamais) dès que l'on doit serialiser des données. Il "suffit" de migrer la structure.
# XML
Posté par richardd . Évalué à 10.
Pour ma part, le principale soucis d'XML est surtout sa verbosité … et mal utilisé par certains développeurs (y compris pour des logiciels de "grands noms", par exemple Sage CRM) fait qu'on arrive à avoir pour 100ko de données utiles, plusieurs Mo de données "structurelles" et redondantes.
Et puis, hormis pour des fichiers XML très simplistes, sans l'aide d'un logiciel avancé, ils sont difficilement compréhensibles par un humain…
[^] # Re: XML
Posté par yeahman . Évalué à 2.
Je rejoins ce que tu dis, XML c'est la lose puissance 10 000 à lire si ton fichier contient un peu de données.
Après, quand t'as pas le choix… bah t'utilises un parser en ligne et tu copies-colles le rendu dans ton IDE en utilisant les fonctions d'arborescence pour fermer les sections qui t'intéressent pas…
Le XML, c'est moche pour les volumes.
En revanche, je le trouve pas si difficile que ça à parser (je n'ai touché du XML qu'en Python, donc peut-être que les autres langages s'en sortent moins bien, je ne sais guère).
[^] # Re: XML
Posté par Mathieu CLAUDEL (site web personnel) . Évalué à 8.
Ce que je que j'adore personnellement avec le XML : c'est XSLT.
C'est vraiment super puissant pour faire de la transformation de donné et le XML prend du sens comme format pivot.
Mais il y peut-être des technos équivalente pour le JSON ?
[^] # Re: XML
Posté par freem . Évalué à 2.
Et ton parseur python, il vérifie la validité du document par rapport au DTD qui y est lié?
Ma question, elle revient à dire, est-ce que tu parses du XML standard, ou du XML allégé, comme la plupart des gens le font?
[^] # Re: XML
Posté par yeahman . Évalué à 2.
On parlait de parser, pas de vérifier la validité par rapport à un modèle.
Ça me paraît logique (mais peut-être que ça l'est pas) qu'un parser ne fasse que… parser un fichier.
Effectivement, dès que t'as un DTD, ça devient plus galère.
[^] # Re: XML
Posté par freem . Évalué à 2.
C'est sûr. Sauf que le modèle est quand même l'un des vrais points forts d'XML, donc, utiliser le fait que le parser ne soit pas trop compliqué en oblitérant une fonctionnalité phare pour dire que ce n'est pas si dur/long/whatever me paraît… douteux.
Sinon, si on parles du simple parsing ( en espérant ne pas me planter et ne pas en oublier trop ):
Il faut être capable de lier à , mais savoir que si on rencontre alors pas de balise fermante.
%XX génère un octet de valeur hexa XX.
%% génère un %.
&foobar; génère le caractère foobar.
" est un délimiteur. ' aussi. Ils peuvent être imbriqués de mémoire.
En terme de coût CPU, je trouve que c'est assez coûteux. Après, je ne nie pas que tous les langages ont des libs plus ou moins bien foutues pour le faire à notre place, mais ça ne veut pas dire que leur implémentation est triviale, surtout quand il y a un besoin de performances.
Un collègue à tenté d'utiliser je ne sais plus quel parseur php, le résultat était misérable en terme de perf, il à donc dû en implémenter un lui-même. Je gage que j'arriverais à faire bugguer le code en question sans trop de souci, en jouant sur les assertions non vérifiées.
Si cet outil php est lent, il doit bien y avoir une raison… ou juste peut-être que mon collègue s'en est mal servi, je n'en sais rien ( je n'étais pas dans la boîte à ce moment, donc je ne connaît pas tous les tenants et aboutissants ).
[^] # Re: XML
Posté par Mathieu CLAUDEL (site web personnel) . Évalué à 1.
De mémoire (ça fait très longtemps que j'ai pas fait de PHP), utiliser la DOM pour parser du XML en php est pas très performant ( http://www.php.net/manual/fr/domdocument.loadxml.php ). Par contre utilise le parser ( http://www.php.net/manual/fr/function.xml-parse.php ) c'etait beaucoup, beaucoup plus rapide, mais bien plus ardu à écrire. Personnellement, je passais pas XLST (voir parfois même générer du code PHP à évaluer à partir du xml via XSLT)
[^] # Re: XML
Posté par windu.2b . Évalué à 2.
Le choix de passer par le DOM ou par un parser "en flux" dépend aussi de l'usage qu'on fait ensuite du XML : si tu dois juste parcourir et ne rien garder, le DOM est overkill (surtout pour la mémoire). À l'inverse, c'est la solution la plus simple à manipuler des 2.
[^] # Re: XML
Posté par Fabien PRORIOL . Évalué à 1.
Peut être qu'il a utiliser un parseur écrit en PHP (ou javascript…), j'en ai vu souvent des truc horrible comme sa…
Avec le module de binding PHP qui va bien, tu utilise libxml2 depuis le PHP, c'est performant, debugger, et contrairement au parseur maison qu'il a dut écrire (en PHP surement, donc comment peut-t-il être aussi performant que libxml2 ?), tu profite de la validation, des Xquery…
[^] # Re: XML
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 9.
Gnii ? Le XML, en rapport avec ses possibilités (hiérarchie des données, attributs etc), est certainement le format le plus simple à parser qui existe ! En terme de tokens primaires, c'est pinuts : ",',inférieur,supérieur,!,--,&..;,: et.. c'est tout.
En comparaison, YAML (puisqu'on parle de lui plus haut) est une horreur. Il y a plein de caractères différents selon ce que tu veux représenter (quand je vois un YAML bien fourni, j'ai l'impression de lire des hiéroglyphes), il y a l'indentation à tenir compte, et j'en passe. Bref, plein de cas différents à traiter etc.. YAML c'est super lent à parser en comparaison à du XML (sans faire de validation).
J'avais comparé les spécifications de XML et YAML à une époque : 77 pages A4 pour YAML, 30 pages A4 pour XML. Faire un parser XML est bien plus facile qu'un parser YAML.
[^] # Re: XML
Posté par rakoo (site web personnel) . Évalué à 3.
C'est couteux parce que chaque caractère doit être lu et interprété. Contraste ça avec les formats qui utilisent des length-prefix, où ton parseur peut sauter tout un tas d'octets (ou plutôt les passer a un autre parseur) si ça ne l’intéresse pas.
[^] # Re: XML
Posté par claudex . Évalué à 8.
Ça, c'est un format qui n'est pas du tout modifiable à la main (surtout avec l'utf-8).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: XML
Posté par ckyl . Évalué à 5.
JSON et XML c'est kif kif en terme de perf et de poids. Le XML lourd et lent est un mythe que les incompétents aiment se raconter le vendredi au coin du feu.
http://balisage.net/Proceedings/vol10/html/Lee01/BalisageVol10-Lee01.html
C'est orienté web mais tu retrouves la même chose sur des implementations backend. Tu peux aller un peu plus vite si tu te fais un parser custom qui ne respecte pas les API standards qui limite en général la perf possible.
Après c'est a quelques ordres de grandeur de ce qui est faisable avec un bon protocole binaire, mais c'est vraiment pas le même usage…
[^] # Re: XML
Posté par Fabien PRORIOL . Évalué à 1.
Oui oui, si tu utilise libxml2 en python, tu as la validation, Xquery tout ce qui peut servir… et de façon performante
[^] # Re: XML
Posté par freem . Évalué à -9.
Pour moi, demander à quelqu'un de monter une chaise, ce n'est pas monter une chaire.
De même, pour moi, utiliser un parseur n'est pas parser.
C'est sûr, utiliser une lib, c'est facile. Ou du moins devrait l'être, mais ce n'est pas faire le boulot de la lib. Surtout le vendredi :p
[^] # Re: XML
Posté par Sufflope (site web personnel) . Évalué à 10.
Et quand t'écris un programme la première étape c'est ré-écrire la glibc ?
Évidemment que personne de sain d'esprit ne se lance sans une sacrée bonne raison dans l'écriture d'un parser XML, et utilise une bibliothèque qui le fait mieux.
[^] # Re: XML
Posté par Fabien PRORIOL . Évalué à 1.
la libC ?? je suppose même qu'il doit ré-écrire le scheduler du noyaux, la gestion de la pagination mémoire… comme les vrais ??? non ???
Être un bon développeur, c'est pas uniquement savoir faire de bon programme, c'est aussi savoir regarder autour de soi si personne n'a pas déjà réfléchi sur le problème que l'on cherche a résoudre !!!
Ré-inventer la roue n'a jamais été une chose qui apporte; et si libxml (par exemple) n'apporte pas la réponse à ton problème, si les licences te le permettent, il est souvent plus judicieux de participer a une évolution de cette lib, plutôt de refaire son propre bousin dans son coins.
D'ailleurs, c'est la qu'on reconnait un "bon" développeur, il est AUSSI capable de s'adapter pour faire avancer un projet qui n'est pas le sien, mais qui peut lui servir.
[^] # Re: XML
Posté par barmic . Évalué à 6.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: XML
Posté par Claude SIMON (site web personnel) . Évalué à 2.
Mince, va falloir que je reprenne rendez-vous avec mon psy :
- http://hg.savannah.gnu.org/hgweb/epeios/file/tip/stable/xml.h
- http://hg.savannah.gnu.org/hgweb/epeios/file/tip/stable/xml.cpp
Ah ben non, ça ne sera finalement peut-être pas nécessaire…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: XML
Posté par arnaudus . Évalué à 4.
Soit j'ai loupé un épisode, soit cet argument est complètement débile. C'est la même chose que de dire que C++ est compliqué parce qu'il est difficile de coder un compilateur C++. Et qu'utiliser g++, c'est de la triche.
J'imagine que tu as donc codé ton OS, tes drivers, tes compilateurs, ton bureau, et ton navigateur?
Non seulement réinventer la roue est coûteux en temps, mais c'est aussi complètement stupide pour des raisons d'efficacité (bugs et optimisation). Alors oui, la programmation, la plupart du temps, c'est de l'assemblage d'algorithmes déja faits. Je ne suis pas certain qu'apprendre à faire du tri à bulle soit une compétence valorisable, c'est un exercice intéressant, mais savoir faire ça n'est probablement pas, la plupart du temps, quelque chose d'important. Ceci dit, il existe des milieux où la masturbation intellectuelle est bien vue, mais en ce qui me concerne, si j'ai à choisir entre deux étudiants, que je leur demande de trier un vecteur, et qu'un me recode un algo de tri tandis que l'autre m'écrit une ligne où il appelle un sort(vector), sans hésiter, je prend le second.
[^] # Re: XML
Posté par freem . Évalué à 1.
La seule chose que je dit, ce n'est pas qu'il est mal ou stupide ou quoique ce soit d'utiliser un outil externe. Juste, qu'on ne peux pas prétendre faire le boulot soi-même quand c'est un outil qui fait tout à notre place.
Dans le cas du compilo, il ne produit pas du C++, mais du code machine. Son utilisateur fait du C++, le compilo génère un binaire, en code machine. Pas en C++, ou en tout cas pas sur ma machine vu que le processeur ne saurait pas quoi en faire.
[^] # Re: XML
Posté par jbbourgoin (site web personnel) . Évalué à 7.
Oui, la verbosité c'est son problème.
D'ailleurs, il y a une syntaxe excellente qui a toute la puissance de XML sans sa verbosité. Voyez vous-même :
La même chose dans une langue que vous connaissez bien :
[^] # Re: XML
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: XML
Posté par jbbourgoin (site web personnel) . Évalué à 3.
[^] # Re: XML
Posté par GaMa (site web personnel) . Évalué à 5.
Matthieu Gautier|irc:starmad
[^] # Re: XML
Posté par jbbourgoin (site web personnel) . Évalué à 2. Dernière modification le 07 mars 2014 à 15:22.
Bah après ça dépend de la grammaire (toujours modifiable cela dit) du langage LISP utilisé, mais bon, je dirais un truc dans le genre :
Soit :
Ça donne :
[^] # Re: XML
Posté par hocwp (site web personnel) . Évalué à 3.
On peut même trouver les spécifications du SXML et sa grammaire. Mais après il risque d'y avoir ce problème.
Sinon, on peut aussi écrire ça (j'aime bien jouer moi aussi) :
[^] # Re: XML
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Si vous voulez vous amuser avec des équivalents légers du XML, c'est à dire d'autres formats pour représenter un DOM, il y a les formats PYX et xml2. Bon, c'est moins marrant pour ça :
ça donne des truc comme ça :
et
http://tanguy.ortolo.eu/blog/article110/xml2-pyx
[^] # Re: XML
Posté par GaMa (site web personnel) . Évalué à 4.
Pour ma part, niveau lisibilité, je préfère encore le xml.
Par contre, comme tu l'explique sur ton blog, le fait que ce soit orienté ligne rend le format pas mal pour l'interop avec les outils classiques (sed, grep, …).
Mais je risque pas de l'utiliser pour mes fichiers de conf.
Matthieu Gautier|irc:starmad
[^] # Re: XML
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5. Dernière modification le 07 mars 2014 à 17:16.
Oui, on est d'accord, question lisibilité c'est pire que XML. :-)
À noter un truc marrant : le premier de ces formats est orienté événements, à la façon des parseurs SAX, et le second est orienté chemin, ce qui peut faire penser à une comparaison avec les parseurs DOM.
[^] # Re: XML
Posté par KiKouN . Évalué à 2.
Je me suis toujours étonné de ne pas trouver de fichier de configuration écrit en C.
[^] # Re: XML
Posté par Zylabon . Évalué à 2.
Ça existe :)
http://git.suckless.org/dwm/plain/config.def.h par exemple
Please do not feed the trolls
[^] # Re: XML
Posté par racingfoli . Évalué à -1.
Que ce soit pour du XML ou pour un autre format, je n'ai toujours pas compris pourquoi la compression n'est pas intégrée de base.
On pourrait appeler ce format (standard) ZML pour le XML qui s'y prête très bien avec les redondances de tag. L'éditeur et/ou la librairie lisant ce format peut alors le compresser / décompresser automatiquement.
Ces standards de compression peuvent aussi être adaptés pour tout type de fichier de données.
# Pour moi, XML, c'est comme le PHP...
Posté par Atem18 (site web personnel) . Évalué à 3.
Beaucoup les utilisent car ils sont populaires, mais ce n'est pas parce qu'une entité est connue, qu'elle est forcement la meilleure dans son domaine. L'industrie musicale en est le parfait exemple.
P.S. : Et puis, XML, c'est old school. Si tu veux être hype, faut utiliser JSON, parce que Javascript est le meilleur langage jamais écrit.
[^] # Re: Pour moi, XML, c'est comme le PHP...
Posté par Framasky (site web personnel) . Évalué à 5.
Je suis d'accord, ou alors du YAML
Faut pas abuser non plus. C'est Perl le meilleur langage jamais écrit, tout le monde sait ça ! (on est vendredi, j'ai le droit)
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Pour moi, XML, c'est comme le PHP...
Posté par Kaane . Évalué à 10.
Mais non Perl est le meilleur langage jamais lu.
C'est pas du tout la même chose.
[^] # Re: Pour moi, XML, c'est comme le PHP...
Posté par freem . Évalué à 3.
JSon est moins pire que XML, pour l'usage que la majorité des cas ou XML est utilisé ( c'est à dire sans validation du document ). A choisir entre la peste et le choléra…
Sinon, je préfère le whitespace au javascript, ça à l'avantage d'être reposant pour les yeux :)
# XML n'a jamais été fait pour être compréhensible par l'homme
Posté par totof2000 . Évalué à 10.
C'est l'erreur de base de tous les pros-xml.
XML a été fait pour l'interopérabilité entre machines et OS ayant des représentations internes différentes, et de ce fait a utilisé un encodage de base plutôt "universel".
Le format en lui même, bien que verbeux, n'est pas si mauvais que ça pour les cas ou il est bien employé : c'est le détournement qui en a été fait qui est pénible.
Personnellement je rale depuis des années sur les fichiers de conf XML à modifier à la main, là ou l'interopérabilité n'est pas nécessaire. Et en général, on se rend compte que la seule raison de la présence de XML, c'est la paresse des devs qui ne veulent pas écrire un parseur (celà dit il y a un tas de formats qui peuvent être utilisés à la place du XML sans avoir à réinventer la roue).
Celà dit je crois comprendre que la tendance s'inverse un peu : parenons l'exemple de JEE : a une époque, le XML était plus ou moins incontournable. Aujourd'hui il a évolué. On peut toujours utiliser le XML, mais ce n'est plus indispensable. Et j'espère que cette tendance continuera.
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par totof2000 . Évalué à 3.
Je viens de vérifier, et il semble que finalement c'était l'un des buts du XML . J'avais lu il y a quelques temps déjà que le fait que XML soit lisible humainement était plutôt une conséquence qu'un objectif (je vais tenter de retrouver ma source). Celà dit c'est bizarre, car un document xml peut contenir des blobs binaires, ce qui est étrange pour un document lisible par un humain.
Maintenant, si on se penche sur le résultat, il est clair que l'objectif est complêtement raté de ce point de vue, et qu'il y a des formats mieux adaptés pour la lecture humaine …
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par freem . Évalué à 1.
La raison, en gros:
endianness.
XML étant du texte ASCII allégé ( moins les caractères de contrôle, entres autres ), il est facile de déterminer l'endianness. Ajouter à ce point le fait qu'il soit possible de créer des fichiers pour vérifier l'intégrité des données ( DTD ) voire convertir à un sous-format différent, ainsi que le mécanisme de balises qui permets de vérifier un minimum d'intégrité sans le DTD, oui, ce format à des raisons d'être.
Mais, il s'agit d'un format ayant un rôle limité, et maintenant je suis à la limite d'avoir une réaction allergique quand on m'en parle, à force de le voir utilisé pour de la configuration ( apache, code::blocks, par exemple, mais je crois aussi que dbus s'en sert… sigh… ).
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par tyoup . Évalué à -3.
texte oui, ascii… peut-être, mais pas toujours :-)
allégé ? le vendredi peut-être :-D
la question de l'endianness n'est pas pertinente : c'est du texte
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par oinkoink_daotter . Évalué à 4.
N'imp
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par tyoup . Évalué à -2.
Merci je suis au courant… Mais quand on génère du xml on se préoccupe rarement de la représentation binanire du texte généré pas comme quand on a à affaire à un protocole binaire où la la question de l'ordre des octets est particulièrement importante (les données binaires sont souvent encodées en base64 en xml). Et ça concerne plutôt utf-16 et utf-32, est-ce beaucoup utilisé ?
Alors je persiste et signe : la question de l'endianness n'est pas pertinente.
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par Zenitram (site web personnel) . Évalué à 2.
Tu veux dire que tu dit merde à la première ligne de ton fichier XML (celle qui dit le codepage, et qui n'est pas toujours utf8)?
On revient à la bétise das anti-journald qui ne veulent pas comprendre que tout est binaire, "texte" veut juste dire "binaire avec un codepage qu'on te dira d'une certaine manière, ou pas, juste que ce codepage permettra à des logiciels sachant lire ce bianire de te l'afficher de manière un peu lisible").
Alors je persiste et signe : la question de l'endianness n'est pas pertinente dans le binaire non plus, avec une bonne explication car c'est la tienne (celle qui est : c'est écrit dans la spec de la même manière que pour ton texte dit que c'est UTF8).
Et pour avoir "du texte", il suffit d'avoir le logiciel adéquoit comme pour du "texte", celui qui va traduit un format x dans un amas de pixel que tu sais comprendre.
(essaye de lire du japonais avec un logiciel qui connait "du texte", mais que de l'ANSI, pour rire, ça va être rigolo ton "texte").
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par tyoup . Évalué à -4.
Tout est binaire certes. Mais tout n'est pas texte. Perso je ne me pose pas de question d'endianness quand je code un entier en texte par contre en binaire c'est une autre paire de manche…
Pfff la dernière fois que j'ai essayé de lire une disquette avec un lecteur de cd ça marchait très bien…
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par pasBill pasGates . Évalué à 1.
Et le japonais qui ecrit ses caracteres en UTF sur plusieurs bytes tu crois qu'il fait comment pour coder son texte ?
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 10 mars 2014 à 07:06.
Quand on ne veut pas comprendre…
Je ne sais pas comment tu fais :
- Tu es utilisateur, tu rentres ton nombre comme tu rentres ton texte, le logiciel s'occuper de coder.
- Tu es programmeur, tu fais un mapping entre l'entrée utilisateur et une specification, que ce soit un texte (tu dois coder "A" en 0x41 par exemple, et le logiciel qui lira devra utiliser la même correspondance sinon fail) et pour les nombres "en texte" il vaut mieux éviter de devoir trop vouloir décoder ("3,141", c'est environ trois ou trois mille? Ben en fait ça va dépendre de ta locale que tu as oublié de donner, aussi important que l'endianness).
Ensuite, tu évites soigneusement, en répondant à côté, de vouloir accepter que le texte est autant merdique en normes que le binaires, en parlant de formats physiques, mais en n'essayant pas du tout de comprendre les conséquences de mon exemple, ni du tiens, sur le sujet discuté.
Tu ne veux pas comprendre (j'ai déjà donné un exemple avec des dates) car tu veux absolment "Perso je ne me pose pas de question" alors qu'en fait, il n'y a pas plus de questions que justement avec du texte qui donne un mapping binaire tellement basique qu'il ne résout pas grand chose car pas grand chose n'est indiqué et l'humain toi déchiffrer (dans le sens "j'ai pas la clé, je bidouille").
Le format texte, c'est génial tant que tu n'y as pas touché. Mais sinon, non promis tu n'as pas de problèems d'endianess (tu as juste 50 autres problèmes)
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par tyoup . Évalué à -4.
Bah non, je ne veux pas comprendre. Que ce soit avec un logiciel ou une api, je manipule des caractères et non des octets à la différence de quand je manipule un binaire. Je suis vraiment, mais vraiment, trop con, alors j'insiste.
Ou utiliser un truc standard comme xsd:decimal ?
Je n'ai jamais prétendu que le texte était moins merdique, j'ai juste réagi à trois conneries dites dans un message.
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par Zenitram (site web personnel) . Évalué à -2.
Que tu veuilles ou pas comprendre ne change rien dans les faits :
- Dans les deux cas, à la base tu manipules du binaire
- Dans les deux cas, tu peux avoir une interface qui soit plus intuitive pour toi.
La seule différence est d'avoir une interface générique mais en échange tu peux rien automatiser (tu ne sais même pas ta date, il faut déviner) sans contraintes extérieures (comme… pour le "binaire" que tu n'aimes pas).
Les amateurs de "texte" me feront toujours rire, ils pensent que "A" se code tel quel dans les fichiers (ben non c'est 0x41!) ou qu'il y a un codepage universel (ben non, faut le dire) et que c'est la réposne à tout (ben non)
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par tyoup . Évalué à 0.
j'adore le binaire (et le ternaire aussi :-))
c'est pas faux, en même temps comme à la base c'est aussi du binaire c'est aussi 0x41 (je ne saurais dire si c'est une subtile différence ou une différence subtile) ou encore 0x41 0x00 ou encore 0x00 0x41 ou encore 0x41 0x00 0x00 0x00 ou encore 0x00 0x00 0x00 0x41, soyons clairs ! celui qui me fera remarqué que j'ai oublié le middle endian aura peut-être raison mais je ne saurais l'anticiper :-)
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par oinkoink_daotter . Évalué à 4.
Cette incertitude montre bien que le problème d'endianness existe alors que trois posts plus haut tu dis que ce n'est pas pertinent oO'. Ca montre pourtant qu'à partir du moment où tu écris une suite d'octets liés entre eux le problème se pose.
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par totof2000 . Évalué à -1.
Je vais te faire lire les Misérables en affichant les caractères en Hexa, peut-être que tu comprendras la différence
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par barmic . Évalué à 4.
Bon j'ai du temps à perdre…
Moi je vais te passer un papyrus à lire et tu me dira ce que tu en dis de l'universalité de la transposition d'informations. Les hiéroglyphes sont bien antérieur à ta façon d'exprimer textuellement tes idées et ont étaient utilisés pendant près de 3 000 aucune des autres formes dont tu parle ne peut se targuer d'avoir la moitié de cette longévité.
Donc oui le texte numérique c'est comme le texte manuel, il faut savoir lire la bonne langue pour le lire (c'est pire pour le manuel, j'ai jamais rien compris à ce qu'écris mon médecin…).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par totof2000 . Évalué à -1.
0100010101110011011101000010110101100011011001010010000001110001011101010110010100100000011011010110000101101001011011100111010001100101011011100110000101101110011101000010000001110100011101010010000001100011011011110110110101110000011100100110010101101110011001000111001100100000011011000110000100100000011001000110100101100110011001101100001110101001011100100110010101101110011000110110010100100000011001010110111001110100011100100110010100100000011101000110010101111000011101000110010100100000011001010111010000100000011000100110100101101110011000010110100101110010011001010010000000111111
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par Maclag . Évalué à 9.
C'est parce que t'es un p'tit joueur. Dans Matrix, ils comprennent le binaire, même quand ça défile vite sur plusieurs colonnes! Aucun souci!
------------> [ ]
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par barmic . Évalué à 2.
Pour la configuration interne de l'application ça ne fait aucun doute (interne = celle que le développeur écris et qui n'a pas à être touché par l'utilisateur/l'administrateur). On voit de plus en plus de configuration générée par programmation : soit via des annotations dans le standard Java EE, soit via du code impératif java classique. Ce dernier en plus d'être plus concis à l'avantage d'être au moins partiellement vérifié par le compilateur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par galactikboulay . Évalué à 1.
Un truc qui commence à sévèrement me péter les noix, c'est justement les 42000 sortes de fichiers de configuration différents qu'on peut trouver sur nos systèmes. Ca me parait contre-productif de devoir apprendre une nouvelle syntaxe pour configurer un produit donné, au lieu de se concentrer uniquement sur la partie "fonctionnelle". Bon quand c'est un produit comme Apache ça va encore, par contre rsyslog je trouve le format complètement abscons (en fait c'est "à chier" qui m'est venu à l'esprit en premier).
Au début j'étais assez réticent aussi avec le XML pour les fichiers de configuration, et finalement… ça me parait pas si mal (même si c'est pas parfait). C'est parsable directement dans pas mal de langages, ça se génère assez facilement aussi, donc pour l'automatisation c'est largement un plus. C'est JBoss/Wildfly (serveur Java EE), qui se configure en XML, qui m'a vraiment fait changer d'avis. En fait, avec un éditeur qui fait de la coloration syntaxique, capable de réindenter et de faire un minimum de complétion (fermeture des balises), le problème de la verbosité disparaît (à mon sens).
Pour la remarque par rapport à Java EE: oui la tendance est à utiliser des annotations (ex: JPA, EJB), mais les fichiers XML peuvent s'avérer encore nécessaires dans certains cas bien spécifiques. Cela dit, ils ne sont pas très complexes non plus.
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par Firwen (site web personnel) . Évalué à 2. Dernière modification le 07 mars 2014 à 14:26.
Exactement, comme avec Maven et son pom.xml si lisible et agréable à configurer.
C'est vendredi aprés tout.
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par galactikboulay . Évalué à 3.
Oui et bien je trouve que les POM Maven sont très abordables justement. Si on prend les concurrents, au hasard sbt ou gradle, il faut apprendre une nouvelle syntaxe (Scala ou Groovy respectivement).
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
C'est bien mieux que make en tout cas.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par groumly . Évalué à 2.
Le probleme de maven, c'est pas le xml, c'est maven.
Le xml de maven est en soit plutot simple et assez naturel, quelques top level element, avec des noms comprehensibles, des sous elements simple a comprendre.
La ou ca devient couillu,c 'est les 40 millions de features de maven. Bon, apres, ces features elles sont la pour une raison, mais ca c'est un autre debat.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par tyoup . Évalué à 4.
et il manque celle dont j'ai besoin ! fichtre !
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par galactikboulay . Évalué à 5.
En fait Maven ne contient pas de base "40 millions" de features, il s'appuie sur un système de plugins qui viennent s'insérer dans le cycle de vie du build. Certains sont très couramment utilisés (maven-compiler-plugin, maven-jar-plugin, …), d'autres un peu moins souvent, mais c'est rare d'en utiliser un nombre démentiel pour un projet donné.
De toute façon, on ne regarde généralement la configuration d'un plugin que si on cherche à faire qqch qui n'est pas prévu par défaut.
Au pire, s'il n'y a pas ce qu'on cherche, c'est assez simple d'en écrire un soi-même, il y a une API pour ça, et on peut s'inspirer du code des plugins existants. Et le gros avantage, c'est que ça marche comme pour les artefacts: Maven les télécharge tout seul, donc si on a publié le plugin sur Central les autres développeurs peuvent en profiter.
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par totof2000 . Évalué à 4.
XML ou pas, tu es obligé d'apprendre la syntaxe de chaque balise XML, etc … avec parfois des différences assez amusantes d'un produit à l'autre : ce qu'un développeur considèrera comme étant un argument pourra être considéré comme un élément XML par un autre. Donc même si tu as la même syntaxe, tu trouves beaucoup de différences également.
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par groumly . Évalué à 2.
Ben faut comprendre la config de l'outil, efffectivement, mais la ya pas grand chose qu'on peut y faire, c'est de la semantique.
La difference, c'est que le format est 100% specifie. Pas d'embrouille sur l'encodage, pas de question a la con "les trailing spaces sont ils inclus dans la valeur ou pas", si ma valeur contient "=", est ce que ca va pasrser, et c'est quoi les caracteres pour les commentaires deja, multiligne ou pas, imbriques ou pas, l'ordre des elements est il conserve, est ce que mon document est valide.
C'est ca l'interet de xml, en plus d'offrir une lib dans tous les languages qui existent pour que le developeur puisse se concentrer sur autre chose que de creer des bugs et des buffers overflow sur le code qui lit la config.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par claudex . Évalué à 4.
Et comment gérer le fait qu'un élément puisse en contenir plusieurs. C'est le pire avec les .ini, une fois, il faut les mettre tous après le = séparé par des espaces, une autre fois, il faut séparer par des virgules, tout ça quand il ne faut pas spécifier une fois la variable par élément ou quand il faut mettre les éléments entre crochets.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# "chacun ses goûts"
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Bof, je ne crois pas à ce genre d'affirmation, on peut mesurer objectivement les avantages et inconvénients d'un format, comme d'un langage ou bien comme de n'importe quel produit technique, car on est pas en train de parler du goût des pommes ou des poires. Bien sûr, les compétences de l'équipe compte, mais c'est juste un des critères de choix.
# Linus...
Posté par Gof (site web personnel) . Évalué à 10.
Linus est peut-être un bon programmeur, mais il reste aussi ine personne avec des opinions personelles qui aime trollé.
Dans son post, il ne donne aucun argument contre XML, juste un avis personnel du fait qu'il ne l'aime pas.
Ah si: il donne un seul argument quand il dit que « nasty to parse for humans, and it's a disaster to parse even for computers ». Mais là encore l'argument est faible et pas vraiment expliqué. Son format git est pire pour la lecture par des humains. XML est juste un compromis entre une lecture par humain et une lecture par ordinateurs.
Je ne veux pas évangéliser sur les bienfaits du XML. Je veux juste prévenir qu'il ne faut pas prendre les paroles de Linus comme saint évangile.
Je parie que dans le futur, quand il y aura une discussion à propos de XML, certains vont venir lier ce poste en disant: « XML c'est mal, Linus le dit. » Et ce même dans des cas ou XML pourrait être une bonne solution.
Linus a fait pareil avec C++. Ce n'est pas parce que Linux n'aime pas quelque chose que c'est forcément le mal absolu. Et ce n'est pas parce que XML n'est pas la meilleure solution pour subsurface, que ce ne doit jamais être utilisé.
[^] # Re: Linus...
Posté par Le Gab . Évalué à 2.
Et c'est d'ailleurs sa fatiguante marque de fabrique. Pas de problème pour le côté grande gueule mais je trouve que Linus n'apporte généralement que peu de choses - techniques - lors de ses envolées.
D'ailleurs, ses postes G+ n'apportent rien si ce n'est une demonstration narcissique.
J'aimerais lire un jour un post G+ avec une discussion de fond mais non.
# Sans être fan du tout
Posté par arnaudus . Évalué à 10.
On n'a pas besoin d'épiloguer sur les défauts d'XML, tout le monde les connait. Quelques points qui vont dans l'autre sens quand même:
* La taille du fichier, on s'en fout pas mal, ça passe très très bien à la compression (c'est du texte très redondant)
* "Les devs ont la flemme d'écrire un parseur" -> "les devs ont l'intelligence de réutiliser des parseurs déja déboggués"
* La structure hiérarchique imposée par le xml permet de rationnaliser le stockage des données, à définir des noms de champs signifiants, etc.
* Il ne faut pas oublier la possibilité hyper-intéressante de définir un doctype et donc d'avoir une autovalidation du format, voire une auto-documentation.
* XML est conçu pour faciliter dans une grande mesure la compatibilité entre versions du fichier (en tout cas, ça ne va pas faire planter le parseur, ce qui est déja pas mal)
* Les gens qui ont un cerveau cablé d'une manière particulière qui permet de comprendre comment on se sert des moulinettes XSLT semblent trouver ça utile.
Je me demande au final si les problèmes attribués au XML ne sont pas en fait des problèmes à attribuer aux développeurs, qui utilisent XML à la place de fichiers textes, à la place de formats binaires (typiquement, pour stocker l'état interne d'un programme OO), ou à la place de bases de données. J'ai l'impression qu'XML excelle dans les formats qui mélangent contenant et contenu, avec une organisation peu prévisible—typiquement, des fichiers comme des pages HTML ou des documents de traitement de texte, où on va trouver des trucs comme
<document> <title> Bla bla</title> Texte text <italics> texte texte </italics> <img url=http://www.image.com /> </document>. Une niche pas si large, mais dans laquelle les propriétés d'XML sont probablement beaucoup plus utiles qu'ailleurs.[^] # Re: Sans être fan du tout
Posté par Fabien PRORIOL . Évalué à 2.
lol, bonne définition du XSL ;-)
En effet, c'est quelque chose de hyper surpuissant, mais pour comprendre sont écriture faut se levé tôt !!!
[^] # Re: Sans être fan du tout
Posté par par . Évalué à 3.
Quand j'ai commencé à bosser, j'ai fait pas mal de XSL-T et XML-FO. C'est vrai qu'au début, ça demande un peu de gymnastique intellectuelle, mais une fois qu'on a compris la logique, on trouve ça super-bien foutu. Je me demande si ça ne se rapproche pas de la programmation fonctionnelle : Variables constantes (enfin à moitié, selon de sens de parcourt de l'arbre), récursivité à la place des boucles, application de "fonction" par motif…
[^] # Re: Sans être fan du tout
Posté par jbbourgoin (site web personnel) . Évalué à 2.
Oui, fondamentalement, XML c'est une sorte de LISP verbeux ;)
[^] # Re: Sans être fan du tout
Posté par Michaël (site web personnel) . Évalué à 3.
Non car XML permet aussi la validation d'un document contre une DTD, ce qui est totalement absent de LISP.
[^] # Re: Sans être fan du tout
Posté par freem . Évalué à -8.
Un fichier compressé, c'est un binaire. L'intérêt d'origine d'XML, c'est d'être utilisable sur un réseau sans trop en chier, chose que le texte ASCII ( sur 7 bits, donc ) fait très bien, contrairement au binaire.
Compresser un fichier XML, c'est un non-sens, parce qu'on perd l'un de ses intérêts principaux… mais tout le monde le fait, parce qu'XML c'est verbeux…
Dit autrement, compresser XML, c'est prouver qu'on à pas réfléchit avant d'utiliser d'XML.
Ou alors, les devs se sont tapé l'écriture d'un parseur XML à la main et on la flemme d'en écrire un autre. Le fait que celui déjà écrit soit débogué est une assertion trompeuse, car les dev ne font pas tous ni toujours des tests unitaires couvrant à 100% leur code.
Certes, mais XML est loin d'être le seul à définir des noms signifiants. En fait, INI le fait aussi. ( vendredi…)
Pour le reste, je te rejoins, oui, le problème c'est bien le dev qui choisit XML… ou plutôt le type qui écrit le cahier des charges du dev ( ça peut être le dev, mais pas toujours ).
[^] # Re: Sans être fan du tout
Posté par arnaudus . Évalué à 10.
Je ne pense pas que ça soit juste. Un fichier texte se lit avec un logiciel, la distinction texte/binaire est symathique au quotidien, mais elle n'a pas vraiment de sens en informatique. Ce que tu appelles un fichier texte, c'est juste un ficher binaire que tu peux lire avec un décodeur binaire -> ascii (vim, emacs, less, ou libre office, pas très important). Ça prend à peu près 5 secondes de créer un alias "zipless" qui va te lire les fichiers compressés sans quetu t'en rendes compte, c'est juste un réencodage de fichier ascii sous un format compressé. D'ailleurs, il existe des systèmes de fichiers qui gèrent la compression et décompression à la volée… bref, c'est un non-argument. Un fichier zip ou un fichier txt, c'est juste deux moyens de stocker un fichier xml, l'un étant plus efficace que l'autre en terme de stockage, l'autre étant plus efficace en temps d'accès.
Ou alors les devs ne sont pas des gros blaireaux et ils utilisent libxml ou autres bibliothèques codées par des gens qui savent écrire et tester un parseur. Un logiciel qui contient son propre parseur de fichier non-trivial, à mon avis, c'est déja un signe que quelque chose ne tourne pas rond : soit tu a redéfini ton propre format (évidemment, sans norme ou doc sérieuse, ce qui fait que tes utilisateurs se trouvent à la merci de bogues aléatoires à l'utilisation de caractères spéciaux, d'encodage de fin de ligne différent, etc), soit tu as réimplémenté un parseur pour un format existant, ce qui est un bon exercice pendant ses études, mais qui relève de l'enc* de mouches dans le monde réel, puisqu'il est très très très très probable que quelqu'un d'autre l'a déja fait en mieux et libéré son code sous une licence assez permissive pour que tu puisses le réutiliser.
[^] # Re: Sans être fan du tout
Posté par Larry Cow . Évalué à 1.
Au contraire, elle n'est pas sympathique du tout, et elle a longtemps eu un sens très précis en informatique : on trouve des tas de protocoles (heureusement un peu dépassés ou corrigés) pour qui l'ASCII 7-bits est une limite forte. SMTP pendant longtemps, FTP, etc.
Fort heureusement, tout cela est globalement de l'histoire ancienne, et plus aucune technologie sérieuse ne fait cette distinction. À bien chercher, je ne vois guère qu'une seule exception : XML lui-même. Sauf si j'ai raté un truc récent, c'est toujours aussi chiant et contre-productif d'intégrer du binaire dans du XML (base64, quoi).
[^] # Re: Sans être fan du tout
Posté par totof2000 . Évalué à -1.
Et ? Est-ce une obligation d'utiliser XML ? N'y a-t-il pas d'autres parseurs pour d'autres formats ?
[^] # Re: Sans être fan du tout
Posté par arnaudus . Évalué à 4.
OK, on le refait avec le contexte :
Remarque: Mieux vaut un format simple parce qu'on peut coder facilement son propre parseur
Réponse: Personne de sensé ne code son propre parseur, mieux vaut un parseur XML validé par la communauté qu'un parseur maison non testé
Donc non, ce n'est pas une obligation d'utiliser XML, personne n'a jamais prétendu ça. C'est juste que l'argument du parseur compliqué est bidon.
[^] # Re: Sans être fan du tout
Posté par tyoup . Évalué à 3.
Et les gens qui savent écrire et tester un parser ils seraient pas développeurs par hasard ?
[^] # Re: Sans être fan du tout
Posté par cosmocat . Évalué à 4.
Oh mince, tu vieux de découvrir que des développeurs peuvent être spécialisés dans un domaine!
Un jour tu comprendras que une société fonctionne également sur ce principe (je demanderais jamais à un vétérinaire de me coder un programme).
Il faut donc, en tant que dev, s'appuyer sur des frameworks qui sont développés par des gens plus spécialisés que toi dans ce domaine là.
[^] # Re: Sans être fan du tout
Posté par xcomcmdr . Évalué à 9.
Spécialisé en XML ?
Ça doit pas être drôle tous les jours…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Sans être fan du tout
Posté par tyoup . Évalué à 1.
Il faut ? Non on est libre bien au contraire, enfin je l'espère. Quand je vois ce que les gens peuvent pondre sur un coin de table en terme de framework dans une entreprise, je me pose des questions. Une application bien faite est quelque part un framework (ensemble de briques bien designées, tout ça, tout ça).
[^] # Re: Sans être fan du tout
Posté par Fabien PRORIOL . Évalué à 1.
Pas vraiment, c'est un XML compressé, pas la même chose !!!
Ne pas utiliser un format binaire, c'est pour éviter les problèmes de portage (endianess, encoding…) pas juste pour faire jolie quand on l'ouvre avec un editeur.
Après, encapsulé l'XML dans un autre format, n'est ni forcement mauvais, ni interdit… a condition bien-sur que ce conteneur soit autant universelle et multi platforme, multi language… et de ce coté, gzip, lzma… le sont.
De même, rien n’empêche de crypter un XML, et on ne perd pas non plus l’intérêt de l'XML, c'est a dire que n'importe quel personne (/outils/programme/…) disposant de la clé de cryptage peut ouvrir et parser ce fichier quelque soit sa platforme.
C'est d'autant plus interessant qu'aujourd'hui, les processeur ARM se généralise, que X86 est toujours la, que PowerPC n'est pas mort…
Le HTML dans HTTP c'est aussi utilisable "sans trop en chier", et pourtant, une bonne partie des serveurs compresse en GZip les paquets HTTP et personne s'en plaint…
Il n'y a pas 1 seul implémentation de parser XML (MSXML, libxml2, Xerces…), ni d'ailleur un seul modèle de parser (SAX et DOM) et le faite qu'un parseur soit utiliser par des milliers de programme est quand même une meilleur preuve de sa qualité qu'un "parseur" maison, a peine tester et utiliser dans un cas particulier !!!
[^] # Re: Sans être fan du tout
Posté par Antoine . Évalué à 4.
Un format binaire bien défini n'a pas de problème de portage. Tu utilises des formats binaires portables tous les jours (archives compressées, images, musique, vidéos, etc.).
L'intérêt d'un format texte, c'est bien d'être lisible et modifiable assez facilement, pas d'éviter de soi-disant problèmes de portage. D'autant qu'un format texte mal fichu peut être non-portable (par exemple parce que le jeu de caractères ou la convention de fin de ligne ne sont pas définis).
[^] # Re: Sans être fan du tout
Posté par Zenitram (site web personnel) . Évalué à 5.
Désolé, mais j'ai du mal à voir le problème de portage dans les différent formats binaire que je connais.
forcément, si la spec dit "int" à la place de "integer 4 bytes big endian", tu vas te retrouver dans le même cas qu'un texte qui dit "EBCDIC ou ANSI et démerde-toi pour les accents", tu évites aucun problème de portage.
clair, on ne se demande jamais quel codepage est utilisé dans ce *** de format de texte à la *** qui plante le parsing… Ni le format de la date, 02/03/2010 c'est 2 mars ou 3 février? Encore des préjugés (pour troller : les mêmes que ceux qu'ont les anti-systemd qui croient que les logs textes c'est génial contre les logs binaires de systemd).
Bah si.
tu veux dire comme n'importe quel lecteur de format binaire qui t'affiche du non binaire à l'écran?
Wow… quel argument!
si, du monde s'en plaint, mais on vit avec (poids de l'existant contre le gain). Mais quelle perte…
Au fait, SPDY, c'est du texte comme HTTP car personne ne s'en plaint du texte?
[^] # Re: Sans être fan du tout
Posté par Vroum . Évalué à 3.
Rien de nouveau dans ce que je rajoute ici mais c'est juste pour souligner les arguments déjà mentionnés.
Le langage XML n'est qu'un format de fichier qui règlent déjà deux points extrêmement pénibles: la sérialisation et l'encodage (non, l'UTF8 n'est pas la panacée).
Au délà du langage, c'est bien la validation du document (DTD ou XML Schema) qui me semble super profitable. Car non seulement le code du parseur existe (avec les librairies externes) mais aussi tout le code nécessaire à la validation! Vous pouvez alors très facilement (et sans risque) changer les spécifications de données tout en restant rétro-compatible.
La transformation des documents étant assurée par XSLT, plus besoin des infâmes "moulinettes" toutes pourries qu'on peut trouver dans la plupart des projets de reprise. Ok, pas si simple à écrire le XSLT, mais ça vaut souvent le coup d'apprendre (d'autant plus que c'est un vrai langage Turing complet).
La plasticité du XML permet d'inclure plusieurs types de documents ensemble avec des espaces de noms séparés et accessibles depuis XPATH ou XQUERY bien supérieurs à la recherche "full-text".
Ce qui me semble important à retenir, c'est qu'XML n'est que le format. La vraie utilité ce sont les autres dialectes XML qui se fondent dessus.
Et chaque dialecte devient un outil extrêmement puissant et rarement comparable en terme de fonctionnalités par rapport à des formats à plat.
Forcément, si le seul but est juste d'avoir un format de configuration, alors évidemment on ne parle pas du tout de la même chose…
Pour l'efficacité de stockage, ce n'est pas vraiment un argument. La plupart du temps, l'ensemble fourni est recompressé (ex: formats OpenOffice).
Après, je comprends le ras-le-bol de certains après avoir subi la mode XML dans les fichiers de conf (à la Apache ou Zope…) et aussi le péché originel avec cette machine à gaz qui est SOAP.
Le fait que tous ces fichiers soient lisibles en partie par l'humain me semble anecdotique. Je ne suis pas sûr non plus que ce soit un des buts d'origine.
[^] # Re: Sans être fan du tout
Posté par El Titi . Évalué à 4.
Je trouve certaines qualités a XML que tu considères comme des défauts et à l'inverse les usages que tu cites ne me paraissent pas pertinents.
XSLT est simplement une hérésie en terme de langage de transformation pour n'importe qui a déjà fait un peu de model driven. Il est inutilement compliqué et limité même pour des transformations de modèle a modèle persisté en XML et ne parlons pas de la génération de code depuis un modele. Utiliser un langage à balises pour décrire des traitement, quelle idée saugrenue à part de vouloir faire rentrer le monde dans le même moule.
Autant utiliser du PHP pour faire un script tiens (vendredi tout est permis)
Et que reproche tu à SOAP exactement?
Hormis le fait que le REST apporte la simplification de l'architecture moyennant du stateless, SOAP est une grande avancée pour les échanges interopérables et correspond exactement à l'usage dévolu au XML. Des services plutôt que des objets avec Corba c'est plutôt positif, non ?
Moins de couplage, moins de contraintes d'architecture…
Bref, précise ta pensée.
[^] # Re: Sans être fan du tout
Posté par Vroum . Évalué à 3.
Le seul cas de «Model-driven» que je connaisse concerne le MDA et le format d'échange est du XML (XMI). Je serais bien curieux de connaître des alternatives ceci dit.
XSLT ne me semble pas une hérésie. Il ressemble à un langage fonctionnel tout en bénéficiant des mêmes avantages que les autres dialectes XML. Après il n'est pas super sexy mais à la différence d'autres langages, il est bien souvent généré par des interfaces utilisateurs qu'écrit directement à la main.
SOAP n'a pas été correctement pensé. Au tout début, il a réglé des problèmes simples (comme pouvait le faire XML-RPC) et à proposer ensuite un maquis d'extensions pour boucher les trous. Tout cela a été péniblement intégré dans la pile WS-I. Côté serveur: seul Java me semble aujourd'hui capable de traiter du SOAP correctement (j'imagine que .NET aussi après tout). De plus le support client SOAP est loin d'être complet dans la plupart des langages de programmation ce qui pose quand même un problème sur sa pérennité et son idéal agnostique.
Heureusement, on a trouvé largement mieux que SOAP pour faire du SOA aujourd'hui. Enfin, je ne connais pas assez CORBA pour avoir un avis tranché mais il me semble que la version 3 améliorait pas mal les choses.
Très honnêtement je pense que le succès de SOAP vient essentiellement du fait qu'il passait les pare-feux. C'est assez triste à dire et trollivore mais je te laisse le week-end pour en découdre :-)
[^] # Re: Sans être fan du tout
Posté par El Titi . Évalué à 6.
Pour du M2M (model tout model) tu as ATl oub xTend de open architectureware (sous eclipse maintenant). Pour du model to text: oaw xPand, Acceleo,…
Donc XSLT est tellement incompréhensible qu'il faut passer par des outils pour pouvoir l'utiliser. Ça démontre bien la simplicité de "truc".
Qu'est ce qui remplace SOAP pour du SOA aujourd'hui ?
Mis à part le fait de publier son API sous REsT je ne vois guère. Ce n'est plus du SOA.
Et tu n'as toujours pas répondu : mal gaulé ça n'avance pas à grand chose comme argument.
[^] # Re: Sans être fan du tout
Posté par ckyl . Évalué à 1.
Heu tu implémentes bien ton bus comme tu veux avec ce que tu veux. Même avec une techno proprio bien maison si ça correspond aux besoins de ton business.
[^] # Re: Sans être fan du tout
Posté par El Titi . Évalué à 4.
Et pour des échanges B2B?
[^] # Re: Sans être fan du tout
Posté par tyoup . Évalué à 2.
Ben oui, les standards ouverts c'est le mal absolu ;-)
[^] # Re: Sans être fan du tout
Posté par ckyl . Évalué à 2.
Ce n'était pas le sens du message. Le SOA est une approche architecturale. Tu utilises le moyen de communication adapté à ton service, après analyse.
Pour beaucoup de besoins tu vas trouver un truc sur étagère standardisé ou pseudo-standardisé qui convient. Mais de fois tu vas tomber sur des problèmes qui demandent des approches adhoc (bonjour les TX à gros volumes ou la finance de marché).
Un bon engineering c'est réutiliser les trucs standards autant que possible mais ne pas avoir peur de construire ce dont on à besoin quand c'est justifié.
[^] # Re: Sans être fan du tout
Posté par lolop (site web personnel) . Évalué à 2.
Faut dire que son ancêtre DSSSL n'est pas particulièrement lisible non plus.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Sans être fan du tout
Posté par Vroum . Évalué à 2.
(Ok merci, tombé sur http://wiki.eclipse.org/index.php/Modeling_Project grâce à toi)
Ces outils ne reposent-ils pas tous sur du XML et in-fine sur des transformations XSLT ?
On parle ici d'un langage de transformation et pas d'un langage de programmation. Et j'ai quand même l'impression qu'XSLT est très efficace pour ce genre de transformations même si pas forcément compréhensible de prime abord. Tu ne m'enlèveras pas de l'esprit que c'est bien grâce à la plasticité du XML que ce langage est systématiquement choisi comme langage pivot aux applications et qu'il n'existe pas vraiment d'alternative à cela aujourd'hui.
En même temps vu l'ambition (démesurée) du «Model-Driven», ce n'est pas ce que j'appelle la voie de la simplicité. XSLT me semble être un mal nécessaire pour ces masochistes du MDA!
Tu te rends bien compte que tu pourrais dire la même chose des développeurs qui se permettent d'utiliser des outils RAD pour développer leurs interfaces utilisateurs au lieu de prendre quelque chose de "plus simple".
[^] # Re: Sans être fan du tout
Posté par El Titi . Évalué à 2.
Justement non.
Ce sont des des langages déclaratifs à la base. Rien à voir avec le XSLT.
La puissance du MDD vient du du meta-metamodel MOF (Meta Object Facility) de l'OMG ( qui permet de décrire tout langage de modélisation standard ou DSLs (Domain Specific Lanaguage).
Son implémentation dans Eclipse est l'Ecore. EMF (Eclipse Modeling Framework) fournit toutes les facilités pour décrire les métamodèles des langages et les manipuler.
Pour une transformation, il faut donc décrire les metamodèles de départ (des cartridges existent pour les standards)et d'arrivée. Ca génère automatiquement tout le code de manipulation des modèles, puis écrire une transformation dans un des langage pré-cités (ATL et pas ATI d'ailleurs pas facile avec une tablette et son auto-correction).
Ces langages sont beaucoup plus compréhensibles et puissants que du XSLT.
Le XML n'est qu'un format de persistence. Tout se fait en mémoire avec une API adéquate. Et tout ca peut être beaucoup plus rapidement mis en place qu'avec du XSLT.
Pour du M2T Model 2 Text, tu utilse un langage de template.
Tu écrit ton texte final statique et à certains endroits tu "injectes" le code pour aller chercher les bonnes infos dans ton modèles source.
Le seuls truc qui reste merdique est la génération documentaire.
Avec le code on peut laisser la place à des balises protected pour que le code puisse être modidfié et par ecrasé lors des générations ultérieures. Avec un document Word ou odf ce n'est pas possible.
[^] # Re: Sans être fan du tout
Posté par El Titi . Évalué à 2. Dernière modification le 11 mars 2014 à 15:27.
Et pour l'ambition démesurée:
Ne confonds pas MDA (http://en.wikipedia.org/wiki/Model-driven_architecture) qui fonde l'architecture sur les modèles avec une approche purement top-down et le MDSD (http://en.wikipedia.org/wiki/Model_Driven_Software_Development) qui en fait un usage plus pragmatique.
Les techniques Model-Driven peuvent s'avérer très efficaces utilisées à bon escient y compris pour écrire son propre DSL textuel (Son langage personnalisé).
Jette un coup d'oeil à Xtext:
tutoriel
http://alain-bernard.developpez.com/tutoriels/eclipse/creation-grammaire-xtext/
Site officiel:
https://www.eclipse.org/Xtext/
[^] # Re: Sans être fan du tout
Posté par El Titi . Évalué à 2.
Et pour tout ce qui tourne autour du model driven avec Eclipse,
vas plutôt voir par ici:
http://www.eclipse.org/modeling/
Tout se base sur l'Ecore
http://download.eclipse.org/modeling/emf/emf/javadoc/2.9.0/org/eclipse/emf/ecore/package-summary.html#details
qui est lui-même une implémentation d'une sous-partie du MOF (http://www.omg.org/mof/)
[^] # Re: Sans être fan du tout
Posté par Vroum . Évalué à 1.
C'était pourtant le but du paragraphe qui suivait:
Pour être plus précis, SOAP est vendu comme solution de SOA mais très souvent tu n'as même pas de WSDL qui va bien ou un registre UDDI correct. On te vend une complexité superflue là où du XML-RPC ou du REST peuvent très souvent faire l'affaire.
SOAP est trop souvent utilisé comme un bus logiciel alors que c'est exactement là où il est le plus inefficace (en terme de charge réseau ou de puissance de calcul nécessaire pour le parsing).
Les normes des extensions sont exclusivement poussées par les grands éditeurs qui font en sorte de protéger leurs logiciels maisons. Au final, très peu de compatibilité et de coopération possible.
Pour les alternatives, j'en donne quelques-unes plus bas dans le fil.
[^] # Re: Sans être fan du tout
Posté par El Titi . Évalué à 3.
Pour l'UDDI tu as sans doute raison, en revanche le WSDL est très utilisés.
Et le REST ne résoud pas tout dans des transactions B2B complexes.
La volonté de baser un ESB sur du SOAP pour des web-services interne part d'un bon sentiment. Une réutilisation potentielle en externe à coup de BPEL s'il le faut.
Dans ma boîte, nous avions implémenté un bus de service des années avant la hype SOA et son standard. Il a fallu tout migrer vers un ESB proprio.
C'est un fiasco en terme de réutilisation de service car aucune gouvernance n'a été sérieusement entreprise.
Aujourd'hui, on aimerait se tourner ves un ESB open-source.
Je crois que le mirage du SOA vient surtout du fait que les daicideurs pressés ont imaginé decrire les processus métiers en BPMN, appuyer sur un boutons et virer les DSI.
Mais ca n'a rien à voir avec les caractéristiques du SOAP.
Mais merci d'avoir développé ton point de vue
[^] # Re: Sans être fan du tout
Posté par Marotte ⛧ . Évalué à 3.
Foutaises !
===> []
[^] # Re: Sans être fan du tout
Posté par El Titi . Évalué à 3.
Anéfé !
[^] # Re: Sans être fan du tout
Posté par tyoup . Évalué à 1.
SOAP c'est 4 tags xml, difficile de l'accuser de boucher le réseau et de manger tout le cpu :-)
[^] # Re: Sans être fan du tout
Posté par tyoup . Évalué à 2.
La spec peut-être, mais est-ce que les implémentations ont vraiment suivi, c'est une autre question. Ce n'était pas le cas il y a quelques années, j'ignore si la situation a changé depuis.
[^] # Re: Sans être fan du tout
Posté par Albert_ . Évalué à 3.
Heureusement, on a trouvé largement mieux que SOAP pour faire du SOA aujourd'hui.
Tu peux donner des exemples s'il te plait? Je serais interesse de connaitre des concurrents a SOAP.
[^] # Re: Sans être fan du tout
Posté par Vroum . Évalué à 2.
Pour les cas les plus simples, il y a évidemment REST mais évidemment on se retrouve avec pas mal de choses à gérer au niveau serveur HTTP (authentification, signature, …). Mais j'imagine que ça couvre un bon nombre des cas usuels en B2B.
Sinon, je pensais surtout aux middlewares à la AMPQ ou même quelques projets comme XMPP. Dans le monde Java, je regarderais du côté des services Jini et/ou OSGi. Après il y aurait tout un tas de projets à évaluer comme ZeroC, Apache Thrift, …
[^] # Re: Sans être fan du tout
Posté par El Titi . Évalué à 2.
AMQP à l'air d'être initiative intéressante elle n'a pas l'air d'avoir fédéré beaucoup de monde.
ZeroC introduit plus de couplage et retombe dans les travers de CORBA, il me semble. Ce protocole est trés ancine et n'a jamais vraiment percé. Elles se basent sur les données.
Les autres n'adressent que Java et ne sont donc pas agnostiques
XMPP j'ai du mal à voir comment ca pourrait s'appliquer mais pourquoi pas.
Enfin un autr initailtive que j'aime bien est OSLC ( http://open-services.net/ )
Ca adresse un bus de service ALM (Application Lifcycle Management) est c'est poussé par IBM avec leur plateforme Jazz/RTC.
Mais le core s'appuid sur des ressources en guise de données avec RDF et ca se construit au dessus d'une archi REST.
REST seule est très limité pour le transactionnel.
[^] # Re: Sans être fan du tout
Posté par tyoup . Évalué à 1.
Carton rouge ?
Apache Thrift Features
ØMQ Language Bindings
[^] # Re: Sans être fan du tout
Posté par Antoine . Évalué à 2.
Mouarf. Il y a beaucoup de vrais langages Turing complets qui valent plus le coup d'apprendre que XSLT.
XSLT aurait eu un sens à une époque où les langages haut niveau n'existaient pas. De nos jours, je ne vois pas l'intérêt de XSLT (bizarre, verbeux, super-limité) face à l'écriture d'une moulinette en Python par exemple.
[^] # Re: Sans être fan du tout
Posté par Vroum . Évalué à 1.
Le fait qu'il soit Turing-Complet veut surtout dire que tu peux exprimer tous les problèmes à résoudre. En ce sens, XSLT n'est pas limité à certaines tâches (comme par exemple faire seulement du templating) mais il peut couvrir tous les besoins programmables.
Pour des documents lourds et complexes, tu risques fort de semer une multitude de bugs avec une approche impérative sur des documents XML. Outre le fait que tu devras passer par du SAX car les parsers DOM seront trop lents, tu auras certainement la joie de baigner dans un code très difficilement maintenable.
Je ne doute pas que tu puisses écrire une «moulinette» bien foutue mais j'envisage plutôt le cas général avec des équipes de développement qui ne sont pas toutes core-dev de python.
[^] # Re: Sans être fan du tout
Posté par El Titi . Évalué à 2.
Relis mon paragraphe plus haut.
Un bon métamodèle et un langage de transfo sont bien plus efficaces.
J'avais testé le XSLT et c'était contreproductif pour notre besoin et pas adapté.
Si tu as cette problématique tourne toi vers des gens compétents.
Il y sûrement des personnes d'Obeo qui traînent par ici prêtes à t'apporter du conseil ou des solutions.
(Sinon envoie un MP)
[^] # Re: Sans être fan du tout
Posté par barmic . Évalué à 2.
La fonctionnalité n'a jamais était reprise dans la version RoR de linuxfr
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sans être fan du tout
Posté par El Titi . Évalué à 2.
Ca pouvait être pratique pourtant.
[^] # Re: Sans être fan du tout
Posté par barmic . Évalué à 2.
Ouai, celle de la version précédente était complètement bugguée par contre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sans être fan du tout
Posté par El Titi . Évalué à 2.
Là en fait on n'a pas moyen de contacter quelqu'un sans balancer son contact à la terre entière.
Y'a un ticket dans suivi (Y'a pas de recherche non plus)
2 features intéressantes pourtant
[^] # Re: Sans être fan du tout
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Ça par contre c'est faux. Cf http://linuxfr.org/recherche/tracker?q=message+priv%C3%A9&utf8=%E2%9C%93
(en l'occurrence c'est la plus vieille entrée du suivi, celle qui a entraîné des débats passionnés autour de verres sur « faut-il en période post-Snowden implémenter autre chose que des messages privés non chiffrés bout-en-bout ? Et si oui comment faire en web sans rencontrer des soucis de javascript, de navigateur, de non support de plugin GPG et d'incompatibilité dans les interfaces chaise-clavier)
[^] # Re: Sans être fan du tout
Posté par El Titi . Évalué à 2.
Oui mais de manière pragmatique:
Là dans une entrée de forum:
http://linuxfr.org/forums/general-general/posts/premiers-linux-magazine-a-donner-sur-toulouse
j'aimerais rencontrer qq1 pour lui remettre des bouquins.
Pas un besoin sophistiqué.
[^] # Re: Sans être fan du tout
Posté par claudex . Évalué à 3.
plus vieille entrée de suivi encore ouverte.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Sans être fan du tout
Posté par El Titi . Évalué à 2.
Faut dire tout de suite ca part dans du jabber.
Elles n'ont pas l'esprit "Lean Startup", les moules du bouchot.
Pas étonnnant que Non ne veuille pas s'y coller
L'intérêt est pourtant certain: passer d'un communauté virtuelle au réel.
Dommage
[^] # Re: Sans être fan du tout
Posté par claudex . Évalué à 3.
Le ticket pour les messages privés est populaire mais manque d'une bonne âme qui s'attelle à la tâche. Par contre, je ne comprends pas ce que tu veux dire avec la recherche.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Sans être fan du tout
Posté par El Titi . Évalué à 2.
Y'a pas de recherche dans le suivi, non ?
[^] # Re: Sans être fan du tout
Posté par claudex . Évalué à 4.
Si, quand tu fais une recherche, tu peux filtrer sur les entrées de suivi.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Sans être fan du tout
Posté par El Titi . Évalué à 2.
Ah oui
Intuitivement on s'attendrait à le trouver sur la page de suivi mais c'est ok
[^] # Re: Sans être fan du tout
Posté par barmic . Évalué à 2. Dernière modification le 11 mars 2014 à 18:06.
Le moteur de recherche permet de faire des recherches dans les tickets.
Edit: grillé
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# XML et son environment
Posté par Fabien PRORIOL . Évalué à 10.
J'ajouterais au débat, que XML utilisé tout seul, en effet, c'est pas terrible, c'est compliqué…
Le but d'XML n'est pas d'être lisible par l'humain, mais d'être universelle, par la j'entends qu'il peut être utiliser pour les échanges sur des plateformes différentes, entre different langage aussi (ex: échange entre Python - C++ - PHP), mais surtout et aussi, que des outils GENERIQUE peuvent être créé et utiliser de différente façon par tout les utilisateur de ce format.
En effet, celui qui aujourd'hui parse du XML a la main, n'a rien compris (je dis sa, mais je le voit couramment autour de moi quand la structure du fichier est "petite", pour ça, y'a la libxml2, y'a le SAX, le DOM….
Après la puissance d'XML viens de tout l’environnement qui gravite autour:
- Les schemas et la validation pour les gros projets
- XPath et XQuery pour les recherches avec des requêtes simple a écrire, mais surpuissante !!!
- XSLT pour transformer en n'importe ou mettre en forme les données (j'avoue XSL n'est pas des plus simple a comprendre et utiliser…, sa me fait penser au expression régulière, tu code une fois, puis tu ne sais plus ce que tu a voulu faire ni comment sa marche…, mais c'est tellement puissant)
Alors mal utilisé, c'est le top pour rendre un projet compliqué, mais si on utilise l’environnent et les outils correctement, sa devient vraiment quelque chose d'évolutif et de puissant !!!
[^] # Re: XML et son environment
Posté par fravashyo . Évalué à -1.
j'imagine qu'il y a encore beaucoup de dev web qui écrivent leur HTML à la main. Les pauvres.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: XML et son environment
Posté par Fabien PRORIOL . Évalué à 4.
Le HTML est un langage de description, c'est pas du tout absurde d'en écrire a la main, pas vraiment comparable a recoder un parser XML.
D'ailleurs, utiliser un editeur WYSIWYG, c'est assez moyen…
Il y a mille façon de produire du HTML (par exemple XSLT :-) ), mais écrire le HTML a la main n'est pas compliqué ni une mauvaise chose…
[^] # Re: XML et son environment
Posté par jbbourgoin (site web personnel) . Évalué à 1.
Certes, mais un document HTML est très facile à corriger à la main. Et dans certains cas c'est bien utile.
En fait, c'est même utilisé quotidiennement. Pour tester un truc dans une page je ne vais pas m'amuser à réécrire la section de de code et/ou l'article 15x, j'ouvre un Inspecteur web quelconque et j'entre le code CSS ou HTML qu'il faut pour tester la modification, ce qui suppose :
1) que le code soir facile à lire
2) et à écrire
Donc la simplicité du HTML est une force, même aujourd'hui dans le développement quotidien de sites web.
Ça vaut aussi pour le CSS et les générateurs comme LESS.
[^] # Re: XML et son environment
Posté par Anonyme . Évalué à 6.
parser != ecrire.
Ecrire du XML sans utiliser une lib faite pour ca, ca se fait sans problème. Le parser non.
# Quand on parle du XML
Posté par fearan . Évalué à 7.
2 citations me viennent à l'esprit
* when you have a hammer everything looks like a nail
* XML is like violence, if it doesn't work, use more!
Pour avoir beaucoup bossé avec, je constate que ces deux citations sont malheureusement très vraies. Si des fois ce format se justifie, ce n'est pas une raison de le mettre à toutes les sauces. En plus avec son lot de caractères interdits tu te retrouves avec des solutions de contournement (genre base64) et une taille de fichier pas piquée des vers.
puis ensuite tu met plusieurs process qui communique entre eux, donc xml, encore, tu finis avec des java heap space et te décides à toujours balader ton xml en gzip, tu recodes tes parseurs DOM en SAX, et tu mets le maximum de truc en attribut, puis un beau jour tu as un gars qui veut pouvoir mettre des retours à la ligne dans certains éléments, ce qui n'est pas faisable dans les attributs, alors tu fout quelques truc en éléments… Bref un bon gros bordel.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Quand on parle du XML
Posté par jon . Évalué à 1.
Je pense que pendant pas mal de temps, c'était malgré tout la solution la plus "standard", ou pratique, pour sérialiser de la donnée destinée à être échanger avec d'autres langages/logiciels.
Encore aujourd'hui en fait: mise à part JSON qui est livré de base avec pas mal de langages/bibliothèques de base, YAML qui est souvent cité comme alternative à XML n'est pas aussi disponible par défaut. C'est souvent juste à une nouvelle dépendance sur une bibliothèque, mais ça m'étonne pas que ça soit déjà trop pour certains développeurs…
[^] # Re: Quand on parle du XML
Posté par claudex . Évalué à 7.
Comme expliqué plus haut, YAML, c'est beaucoup plus compliqué à parser que tu XML (même si je trouve que c'est beaucoup plus adapter pour un fichier de config). Le problème de JSON pour moi, c'est l'absence de commentaire, ça empêche plein d'applications utiles.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Quand on parle du XML
Posté par Olivier Serve (site web personnel) . Évalué à 8.
+1
Les fichiers de configuration en JSON sans possibilité de commentaire, quelle brillante idée !
# CSV
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à -4.
En fait, quand la structure de données à stocker est très simple, l’idéal est un fichier CSV (à condition de choisir un séparateur de champs non utilisé dans les données), ou un fichier INI si on n’a qu’un seul enregistrement.
En utilisant la première ligne comme en-tête, on a l’avantage de l’auto-documentation. Et avec AWK (ou Perl pour les plus vicieux), sort et uniq, on a l’outillage universel pour les manipuler.
Si la structure se complique un peu, disons 2 entités et une relation en langage MCD, on s’en sort encore très bien avec 2 fichiers CSV, et en ajoutant join, comm et paste aux outils, ça roule.
Au delà, eh bien soit on dénormalise la structure pour faire tenir nos données dans 2 fichiers CSV en acceptant quelques limites, soit il faut oublier les fichiers plats et passer à une base de données.
Le XML, ça n’est rien d’autre qu’une tentative de faire rentrer une base de données dans un seul fichier, ce qui peut éventuellement se justifier en tant que format pivot dans le cadre d’échanges hétérogènes, mais pas plus – surtout un vendredi !
[^] # Re: CSV
Posté par barmic . Évalué à 4.
Il y a 50 commentaires au dessus pour expliquer que le problème c'est pas vraiment XML mais ce qu'on en fait et qu'il faut d'abord regarder les usages et toi tu viens expliquer qu'en fait il faut toujours utiliser CSV et que dans celui-ci ne suffit pas il faut une BDD.
C'est rigolo surtout que vu ta description tu parle de fichiers CSV très fragiles et qui peuvent facilement ne plus être utilisables… Croire que CSV est simple est une grossière erreur, croire qu'il fait tout aussi.
C'est quoi un fichier plat pour toi ?
Donc tu pense que sqlite et XMl c'est la même chose par exemple ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: CSV
Posté par Infernal Quack (site web personnel) . Évalué à 4.
Le CSV c'est de la merde en boîte ! Rien que le fait de ne pas pouvoir stocker l'encodage du fichier en fait une bouse immonde !
Désolé mais je bosse dans une boîte à l'international et on a une application qui importe du CSV et c'est pas joli. Surtout que le CSV par défaut des outils (comme Excel) n'est pas le même selon les pays. En Angleterre le séparateurs par défaut est la virgule et en France le point-virgule. Et l'encodage par défaut est celui de la version de Windows donc Windows-1252 en France,…
Bref, le CSV me donne des boutons. Par contre le XML, j'adore. Bien sûr, il faut qu'il soit bien utilisé et qu'il se justifie. Par exemple, les interfaces d'Android en XML, j'aime moins bien car trop verbeux au niveau des namespaces à répéter 40 fois, mais ça reste tout à fait lisible.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: CSV
Posté par Moonz . Évalué à 4. Dernière modification le 08 mars 2014 à 12:36.
On s’en tape.
Quelqu’un qui encode de nouveaux documents en 2014 avec autre chose que de l’UTF-8 mérite d’être pendu haut et court, et la facture de la corde envoyée à sa famille.
Moi ceux qui m’envoient des trucs en pas UTF-8 je leur répond en EBCDIC. Radical.
[^] # Re: CSV
Posté par Infernal Quack (site web personnel) . Évalué à 6.
La majorité des utilisateurs finaux font juste un "export CSV" dans Excel et ça ne génère pas du CSV en UTF-8 mais dans l'encodage du poste. Et tu peux toujours leur expliquer ce qu'est UTF-8, ils s'en cognent. Ils ne vont pas installer des convertisseurs pour tes beaux yeux. Alors oui, le problème est majoritairement la faute du monopole de Microsoft Office mais on ne peut ignorer que la majorité des utilisateurs l'utilisent.
Et puis malheureusement Windows ne pousse pas à l'utilisation d'UTF-8 mais plutôt d'UTF-16LE. C'est ainsi que dans Notepad par exemple, "Unicode" correspond à UTF-16LE.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: CSV
Posté par Zenitram (site web personnel) . Évalué à 2.
Rajoute dans la "locale régionale" et voila le C de CSV transformé en point virgule par chez nous :).
Sous WinXP, oui.
Souw Win7+, tu as le choix (UTF-16LE, UTF-16BE, UTF-8)
[^] # Re: CSV
Posté par Antoine . Évalué à 3.
La condition donne déjà une idée des restrictions (mais tu omets aussi les caractères de fin de ligne)…
Ajoute à ça le jeu de caractères non défini (en France, les données sont rarement pur ASCII), l'incapacité à représenter de façon naturelle des structures imbriquées, et CSV est en réalité un très mauvais choix.
C'est avec ce genre de bouses qu'on finit avec une dette technique incontrôlée. Bravo à toi.
Non, le XML permet avant tout d'interopérer entre des programmes (ou systèmes).
# Mon avis
Posté par Snarky . Évalué à 9.
Pour ma part, j'utilise principalement 4 formats pour le stockage de données:
CSV
Avantages
Inconvénients
XML
Avantages
Inconvénients
JSON
Avantages
Inconvénients
YAML
Avantages
Inconvénients
Pour ma part, depuis 1 ou 2 ans, ma préférence va à JSON+YAML. YAML pour les fichiers de configurations, et JSON pour le transport entre applications, ou stockage simple (le stockage de masse, c'est soit CSV soit un format binaire)
[^] # Re: Mon avis
Posté par Infernal Quack (site web personnel) . Évalué à 1.
XML pas évident à parser ? Tu es au courant pour DOM et SAX ? Pour XPath et XQuery ?
Vouloir parser le XML avec son propre algorithme ou avec un outil inadapté c'est s'assurer d'avoir des bugs.
Sinon un des avantages de XML est de pouvoir spécifier l'encodage dans l'entête.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Mon avis
Posté par Marotte ⛧ . Évalué à 3.
Je plussoie Shift et j'ajoute à propos de CSV que ce n'est pas un format à proprement parler, plus une sorte de méta-format. Il n'y a à ma connaissance aucun document « officiel » de définition d'un format nommé CSV.
Car non seulement :
Mais aussi :
Les chaînes sont quotées, ou pas…
Il y a une première ligne avec le nom des valeurs, ou pas…
Après, si on spécifie ces trois points ainsi que l'encodage utilisé on définit bien un format de manière formel. Ce format est probablement ce qu'on peut faire de plus efficace (ça se compresse très bien) pour échanger des données non hiérarchiques (ce qu'on nommerait une table dans le domaine de la BDD) avec des valeurs de type et taille arbitraires, donc là où un fichier à taille de champ fixe ne peut être utilisé.
[^] # Re: Mon avis
Posté par claudex . Évalué à 5.
Une RFC ça suffit ou il faut une résolution de l'ONU ? ;)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mon avis
Posté par Antoine . Évalué à 5.
En fait, il faudrait lire et comprendre la RFC avant de l'invoquer.
D'abord, ce n'est pas une RFC destinée à normaliser le format CSV :
(les standards se retrouvent normalement en catégorie "standards track")
("documents" et non "standardizes" : il s'agit juste de rendre compte des usages existants)
C'est d'ailleurs précisé plus loin :
(de nouveau : aucune prétention à normaliser le format et à dire ce qui est juste ou non, simplement documenter ce qui semble être l'existant)
Ensuite, la RFC ne spécifie pas le jeu de caractères, ce qui aggrave le problème. Elle laisse le soin au type MIME de passer le paramètre "charset", ce qui ne fonctionne que 1) lorsqu'il y a un type MIME quelque part 2) lorsque sa génération suit cette recommandation, ce qui est AMHA ultra-minoritaire (la plupart des outils vont se contenter de générer le type MIME en fonction de l'extension du fichier).
Donc, non, cette RFC ne rend pas le CSV portable en pratique.
[^] # Re: Mon avis
Posté par Zenitram (site web personnel) . Évalué à -3.
Ben si justement gràce à "This section documents the format that seems to be followed by most implementations".
Rien de 100% officiel avec l'ONU qui valide, tu as raison sur ce point, mais vraiment si tu fais pas ce qu'il y a dans cette RFC dans un programme depuis 2005, tu mérites juste d'être viré.
[^] # Re: Mon avis
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 10 mars 2014 à 21:51.
Le fait est que si les données que tu traites en utilisant CSV sont principalement, voir exclusivement des chaînes des caractères, les quoter est contre-productif.
CSV n'est pas un format, on tente de donner une définition pour le MIME type csv, c'est bien, il me paraît évident qu'un programme traitant, de manière généraliste, ce type de fichier passera par un dialogue pour l'importation, à l'instar des suites bureautiques.
D'ailleurs si on s'intéresse à l'OpenData donc aux CSV fournis, on se rend compte qu'ils sont pas bien homogènes ces .csv…
[^] # Re: Mon avis
Posté par claudex . Évalué à 4.
Ça tombe bien, il ne parlait pas de standard ni moi non plus.
Ça c'est sûr, mais je n'ai jamais dit que c'était le cas. Le CSV est à bannir rien que parce qu'il n'y a pas deux personnes qui vont le recevoir et le traiter de la même manière.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mon avis
Posté par Zenitram (site web personnel) . Évalué à 1.
RFC 4180
OK CSV a plein de défauts, mais certainement pas celui-la, sur ça c'est clair (voir la RFC) et classique (je peux mettre des codes HTML pour tous les caractères, ou pas, pareil)
"Fields containing line breaks (CRLF), double quotes, and commas should be enclosed in double-quotes"
Comme le charset, il faut effectivement le dire avant avec par exemple l'aide des en-têtes HTTP :
The "header" parameter indicates the presence or absence of the header line. Valid values are "present" or "absent".
Et c'est perdu lors du stockage sur disque.
4 points? Je vois que deux points qui sont les en-tête HTTP :
- "charset" : Encodage
- "header" : Header CSV ou pas
comme la RFC en fait ;-).
Et perso j'utilise UTF-8 avec en-tête.
[^] # Re: Mon avis
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 08 mars 2014 à 14:33.
Bon OK ça date quand même de 2005, je lag un peu. Mais avant 2005 il n'y avait rien je suppose.
Ce ne devrait pas être must à la place de should ? Il me semblait que les RFC étaient très pointilleuse sur le vocabulaire ?
[^] # Re: Mon avis
Posté par Zenitram (site web personnel) . Évalué à 2.
une autre RFC ;-).
SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
Bref, si tu ne le fais pas (SHOULD et pas MUST), ça ne plante pas mais ça peut faire des trucs pas propres tu dois savoir.
Et comme il n'y as pas vraiment de raisons valides, ça devrait être OK.
# XML n'est pas facile à lire par la machine
Posté par Michaël (site web personnel) . Évalué à 3.
XML n'est pas du tout facile à lire par une machine! En tout cas c'est loin d'être le format le plus facile à lire.
Tout d'abord, un point très important que je n'ai pas vu évoqué ailleurs: XML sert à deux choses:
D'une part c'est un format d'échange et persistance bien standardisé. C'est la fonction sérialisation.
D'autre part il permet de valider la donnée en la comparant à une DTD, une définition de document. C'est la fonction validation.
La vaste majorité des parsers XML ne valident pas la donnée et proposent donc la fonction sérialisation de XML sans la validation. Pour la sérialisation, les formats plus efficaces que XML — du point de vue de la machine, car plus faciles à lire — existent par pelletées, certains sont d'ailleurs très anciens.
Un parser même non validant pour XML doit prendre en charge une syntaxe plutôt riche (encodings, namespaces, extensions de la DTD, CDATA, etc.) et ils se contentent en général d'un sous-ensemble. Ce qui en pratique signifie que l'interopérabilité est loin d'être garantie.
Un parser validant est lui, confronté à un problème supplémentaire — mais en fait c'est le seul intérêt de l'XML, en plus de la disponibilité de beaucoup de biliothèques — qui est bien-entendu la validation.
En plus il faut noter que bien définir une DTD pour XML est difficile: il faut bien savoir qu'elle information on veut encoder dans la structure du document. (La problématique est semblable à «quelle informations sur mon programme puis-je encoder dans le système de types?»)
Dans la pratique XML est donc surtout utilisé comme protocole de sérialisation et de façon largement incomplète donc pas nécessairement interopérable. Autrement dit, XML est utilisé pour de mauvaises raisons.
Des formats de persistance nettement plus faciles à lire (pour l'ordinateur) que le XML sont par exemple les property lists et les S-expressions. N'importe quel programmeur peut écrire un parser de S-expressions en une après-midi, même s'il utilise un langage de bas niveau (voire l'assembleur!). De plus, d'après le Bureau des Statistiques Pifométriques, 90% des applications utilisant XML comme format de sérialisation pourraient le remplacer par des S-expressions sans perdre en fonctionnalité.
Voici un exemple de parser validant, en OCaml:
http://www.camlcity.org/archive/programming/pxp.html
# Un vieux débat
Posté par tyoup . Évalué à -3.
C'est un débat qui a quoi ? 10 ans ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.