Je te remercie énormément pour m'avoir fait connaître ce framework :ccool:Citation:
Envoyé par Morbo
Version imprimable
Je te remercie énormément pour m'avoir fait connaître ce framework :ccool:Citation:
Envoyé par Morbo
Comme 400Mo d'autres choses risquent de faire voler en éclat les parsers d'autres choses... Mais, pour décrire ces mêmes données avec un autre format, peut-être que 200 Mo suffiraient ? Voilà deux considérations distinctes.Citation:
Envoyé par bretus
Parce que quand tu modifies un fichier YaML (par exemple) tu n'as pas besoin d'un balai pour le réécrire ? :aie:Citation:
Envoyé par bretus
Ah, et par quelle magie tu n'aurais pas besoin de lire un fichier séquentiellement pour y chercher qqchose ? Sinon, SAX, ça te dit qqchose ?Citation:
Envoyé par bretus
Est-ce un (simple) principe qui ne gène que ceux qui se posent des questions métaphysiques ? :DCitation:
Envoyé par bretus
Les accolades c'est bien : c'est concis, c'est joli, mais on se demande rapidement à quoi correspondant cette } ! Est-ce à celle-ci { ? Celle-là { ? Ou bien celle là { ? Argh !.. Certains sont rendus à devoir mettre des commentaires accolés aux accolades pour dire qu'on ferme la définition de telle ou telle chose. Cochons ! :mrgreen: XML est certes verbeux mais il y a très peu de confusions possibles en le lisant (étant donnée une grammaire qui tient de bout).
Sinon, après les considérations d'encodages, on peut aussi citer les délimiteurs spéciaux CDATA qui, le cas échéant, sont bien salutaires !
J'appuie le fait qu'XML est impeccable pour décrire des données. JSON est chouette également mais pas aussi puissant.
Je lis couramment des fichiers de plus de 500mo avec un parser Stax pour des importations à l'aide d'un process en java qui consomme environ 25mo de mémoire durant toute l'importation. Tout simplement parce que je charge une entité à la fois en mémoire, que je traite avant de passer à la suivante en forward-only.
C'est le même principe qu'un curseur, ou qu'un parcours de fichier plat ligne par ligne. Si on charge tout en mémoire avant de traiter, c'est plus confortable mais ça a des limitations.
Critiquer l'utilisation du format à toute les sauces et parfois dans un contexte où celui-ci n'est pas approprié c'est une chose, mais imputer au format les conséquences d'une mauvaise programmation c'est pas raisonnable.
J'ajouterai aussi que l'utilisation de la validation par schéma XSD permet au programmeur de s'affranchir de 95% du code de validation des données lorsqu'il écrit son parser, ce qui n'est pas négligeable.
Il faut savoir être pragmatique dans la vie XML n'a pas vocation à replacer tout et n'importe quoi. mais 400Mo n'est pas un pb pour XML pas plus que pour tout autre format.Citation:
Envoyé par bretus
J'imagine qu'il ne te viendrait pas à l'idée de charger tout un DVD en mémoire pour commencer à lancer le visionnage d'un film. alors que pour une page de PDF ça ne pose pas de pb ni même pour une vignette vidéo d'une minute. il en va de même avec XML
Lorsqu'on manipule de gros volume on ne charge jamais tout en mémoire chez moi les flux d'échange xml font parfois plusieurs Go
et ça ne pose aucun pb. Si la structure XML que tu as choisis t'impose de connaitre tout le doc pour en traiter une partie alors ton format est à revoir
c'est comme si tu avait en début de ton fichier vidéo l'image et à la fin le son
pour lire ta vidéo il faut avoir tout lu. alors que si tu définit un flux qui contient tout au long du fichier l'image et le son tu peux visionner ton film en ne chargeant que quelque secondes.
Là encore il ne faut pas confondre la structure et le stockage un flux XML n'est pas obligatoirement un fichier XML est si tu manipule de grosse structures le stockage sous forme de fichier n'est pas pour toi. je n'imagine même pas la chose si on avait continué à gérer les données des entreprise sous forme de fichier rechercher un client dans le fichier de AT&T prendrait des jours. modifier son nom des mois. écrie une section dans une structure XML à partir de son XPATH est aussi rapide qu'un update dans une table. (c'est d'ailleur ce qu'il fait souvent)Citation:
Envoyé par bretus
là encore tu ne vois que la lecture séquentielle qui est celle de base. mais XPATH permet d'accéder à tout ou partie sans lire la totalité ça dépends complètement de la façon dont tu stocke ton XMLCitation:
Envoyé par bretus
JSON est fait pour de petit flux (bien qu'il m'arrive d'en faire de plusieurs mega) et pour être concis et directement interprétable par JavaScript (donc un outil qui à la base n'a que peut de ressources mais ça évolue) et c'est étendu à l'extérieur. je l'utilise beaucoup.Citation:
Envoyé par bretus
mais justement xml avec les balises ouvrante et fermante xml représente un progrès. c'est certes verbeux mais sur un flux de 1Go ou les balise on des nom de 3 char max faire la relation entre la deuxième { du json et celle qui est en plein milieu est quasi impossible } alors que mettre en relation <cli></cli> est immédiat.
j'ai beaucoup pratiqué lisp et les ((((()))(()))(()()()()()()())) pas simple de s'y retrouver
qui n'a jamais vu dans du code C java php etc. des chose comme
tout ça pour ne pas se perdre dans les {}Code:
2
3function test() { ... } //end function test
pour la verbosité de XML il est vrai qu'on utilise souvent des noms longs
mais la norme n'interdit pas de faire plus court
format normalisé plutôt concis.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
mais on peut aller beaucoup plus loin
qui dit au correspondant dans le doc OMS_O05 remplacer l'élément /OMS_O05/MSH/MSH.1 par ¶ (premier fils->premier fils) et l'élémentCode:
2
3
4
/OMS_O05/MSH/MSH.5/HD.1 par ETL (premier fils->5eme fils->premier fils)
comme quoi XML permet si on le prends pour ce qu'il est de faire des choses concises rapide et qui reste bien plus lisible que
qui pourtant est exactement la même choseCode:4F4D535F4F30350D0A313126706172610D0A312E352E3145544C0D0A
A+JYT
Tu es beaucoup trop bon. À mon sens une remarque pareille était juste bonne à être ignorée.Citation:
Envoyé par sekaijin
Il est évident qu'à moins qu'absolument tous les champs d'un format soient de taille fixe, en nombre fixe, et à moins qu'un système de padding soit utilisé, ce qui arrive souvent mais pas tant que ça, et n'est jamais certain de toute façon, alors une modification entraîne la réécriture du fichier.
Même pour les formats binaires chéris du monsieur, hé oui !
Il n'a clairement pas réfléchi avant de sortir cette énormité, pas besoin de remarquer autre chose que ça.
Un peu d'accord avec ça ...Citation:
Envoyé par bretus
Comme je l'ai écrit plus haut, le problème vient quand on s'entête à faire un format à la fois lisible par l'humain et la machine ; la machine ne se perd jamais dans la structure et n'a pas besoin qu'on lui rappelle quelle balise on ferme ...
Donc on est en face d'un langage agréable pour l'humain, lisible par la machine mais loin d'être optimal pour cette dernière.
Quand on regarde l'histoire de l'informatique, seuls les concepts ayant un fort sens pratique ont perduré et non les concepts idéalistes.
A long terme XML n'aura peut être pas le succés escompté.
Depuis plus de 10 ans qu'il existe, je crois que le succès du format XML n'est plus à faire.Citation:
Envoyé par powel
Vous vous êtes jamais posé la question de pourquoi même Microsoft avait abandonné un format binaire pour le replacer par un format XML dans sa célèbre suite Office 2007 (les docx, xlsx, ... ne sont que du xml dans les faits) ?
Un format binaire est difficilement extensible, d'autant plus lorsque il faut maintenir la compatibilité avec plusieurs versions précédentes. Ça devient très vite un carcan qui ralenti l'évolution.
Le format XML est par définition extensible, quasiment à l'infini, et très rapidement. Il suffit d'inventer une nouvelle balise pour rajouter une nouvelle info. Au pire un parser correctement codé ne lira pas ou ignorera cette balise s'il ne sait pas l'interpréter.
Vous pouvez tirer à boulet rouge sur ce format, il a probablement des faiblesses (comme tous les formats), il peut ne pas plaire à certaines personnes, d'autres seront de toute façon toujours mécontentes et en voudront toujours plus, il n'en reste pas moins que ce format à encore quelques beau jours devant lui, ne serait-ce que parce qu'il est lisible par tous, humains, mais surtout machines de toutes sortes, quelque soit le système, la génération, .....
Il est peu probable que, par exemple, un fichier Word binaire (type 97-2003) soit encore lisible dans 10 ans (plus personne n'aura de Word 2003 sous la main). Un fichier XML sera, lui, toujours lisible, même si l'application qui aura créer le fichier n'existe plus, il sera toujours possible de recréer un parser ne serait-ce que pour extraire les données du fichier et les retraiter dans un nouveau format du moment.
Quant on pense que certaines entreprises exigent des pérennités à 30 ans alors que la plupart du temps au bout de 5 à 10 ans on est déjà plus capable d'ouvrir les fichiers ......
En même temps XML est une reommandation W3C depuis plus de 12 ans (et son implémentation à commencé avant), un jeunot quoi...,et loin de reculé, il est de plus en plus répandu et continue sa progression dans énormément de domaines.Citation:
Envoyé par powel
JSON a peut être remplacé XML au niveau AJAX, mais comme cette technologie à toujours très largement sous-employé XML , cela n'a pas été une grande perte, pareil pour d'autre domaine très spécialisé.
Et c'est quoi un "fort sens pratique" ?Citation:
Quand on regarde l'histoire de l'informatique, seuls les concepts ayant un fort sens pratique ont perduré et non les concepts idéalistes.
Un truc comme les bases orienté objets par rapport à l'idéalisme du relationnel ?
Marrant parce quand dans le la donnée, c'est plus les concepts fortement orienté logique et donc humain qui ont perduré plutot que ceux orienté applicatif.Peut être pas le même "fort sens pratique"
il ne faut pas oublier le côté fainéant du développeur.
ce n'est pas une critique.
franchement pourquoi se casser la tête lorsqu'on as quelque chose de dispos qui répond au besoin.
lorsqu'il s'agissait de définir un type de document dans les année 70 on se posait beaucoup de questions pour arriver tant bien que mal à faire quelque chose.
avec XML on a un méta langage qui nous permet facilement de définir quasiment n'importe quelle structure de donnée.
C'est n'est pas toujours la meilleur solution. c'est même parfois une très mauvaise. mais c'est facile à mettre en oeuvre.
il est évident par exemple que pour un flux vidéo c'est pas top. mais ça réponds tout de même à une grande majorité de cas sans effort intellectuels.
A+JYT
Ce dont personne n'a quoi que ce soit à cirer.Citation:
Envoyé par powel
Ce dont pas grand-monde n'a quoi que ce soit à cirer. Et quand on en a effectivement quelque chose à faire, c'est pas comme si on avait un couteau sous la gorge pour nous pousser à faire du XML.Citation:
Envoyé par powel
Sens pratique : maintenant on va faire travailler les gens au lieu des machines. Parce que c'est bien connu, les gens coûtent moins cher, se trompent moins, et adorent faire ce que des machines font mieux et plus vite qu'eux.Citation:
Envoyé par powel
Un fichier binaire peut tout à fait satisfaire tout ce dont vous parlez. Je pense par exemple au format .IFF (présent sur Amiga dés 1985) qui consistait à partitionner un fichier en blocs de données décrits par des "chunks" ayant une fonction similaire à certaines balises XML puisqu'ils décrivent le type de bloc de données placés après eux.Citation:
Envoyé par sevyc64
Les blocs sont indépendants les uns des autres au sein du fichier, leur maniement est donc facile et permet à des différents logiciels de se comprendre. Un logiciel lit les blocs qui l'intéresse et ignore les blocs dont il ne connait pas la fonction.
Comme ce format a été pensé pour la machine, il est lu d'une manière tellement naturelle qu'un algo. devant scanner le fichier ne dépasserai pas 3 lignes de codes ; un chunk indiquant également la taille d'un bloc, on est en face de quelquechose qui ressemble à une liste chainée. Donc rien de comparable avec la quantité de code, de mémoire et de temps d'éxecution que demande un parser.
XML était une initiative nécessaire, mais parce qu'il est lisible par l'humain il n'est pas idéal pour la machine qui n'a pas à se trimballer nos lacunes, elle est parfaitement rigoureuse là où on ne l'est pas et si nos mots nous semblent naturels, ils sont pénibles à lire pour elle.Citation:
Envoyé par sevyc64
XML concilie non-informaticiens, informaticiens et machines dans sa description de données ... dans beaucoup de cas c'est superflu ... même dans des fichiers de configs. à structure fixe qui pourraient être édités de manière hexa-décimal par des programmeurs.
Le titre de ce topic est "... XML, faut-il passer à autre chose ? ", je ne pense même pas qu'il faille passer à autre chose de plus sophistiqué ou de plus général, car un système trop global et trop large requiert un code compliqué truffé d'exceptions aux régles.
Il est possible qu'après ces années de sur-utilisation d'XML beaucoup de développeurs désireront revenir à quelquechose de plus archaïque mais directement adaptés à leurs besoins.
En fait tout est dit dans ma réponse à Sevyc64, "sens pratique" ou "bon sens" : au nom d'un idéal ou d'une utopie, il ne faut pas systématiquement vouloir rendre lisible une structure de données inter-machines par un humain. Ou par exemple rendre compréhensible un fichier de configuration par un non-informaticien et complexifier par un parser la lecture de celui-ci.Citation:
Envoyé par Erwy
Lorsqu'un programmeur doit contrôler un circuit intégré, il manipule des bits et il est parfaitement dans son élément. Un fichier de config. c'est souvent beaucoup de booléens mais par une inconsciente envie de lisiblité par "n'importe qui", on écrit des dizaines d'octets juste pour activer ou désactiver un bit ce qui bien sûr devra en plus être parsé. Je trouve que la soif de rendre l'informatique humaine nous conduit à des excès.
Je vois plus le fait qu'un développeur n'a souvent pas le choix et pas le temps, car dans son intérêt chaque entreprise (même Microsoft) suivra le mouvement d'un système en vogue ...Citation:
Envoyé par sekaijin
C'est pas vraiment normal d'avoir un nom de balise fermante pouvant être ignoré par le parser alors que son absence rend invalide le code XML. Résultat d'avoir voulu faire un compromis.Citation:
Envoyé par thelvin
Un autre aspect est tout simplement le gaspillage de place, de temps et de complexité en code. Même si nos machines sont de plus en plus puissantes, beaucoup de gens ont (heureusement) encore le goût de l'efficacité.
Tant que nos machines ne prendront pas d'initiatives, il vaut mieux utiliser des formats rigoureux et ciblés et non des formats suggérant une cohabitation "forcée" homme-machine comme si cette dernière allait se mettre à penser.Citation:
Envoyé par thelvin
Je veux bien que ça soit suboptimal au niveau de la rigueur explicitement exigée des parseurs. Toutefois, cette redondance a ses avantages au niveau lisibilité, bien que ça ne soit pas systématique. Cette considération est plus importante.Citation:
Envoyé par powel
Par ailleurs, même en admettant qu'il s'agisse d'un défaut de XML, ce seul argument n'invalide pas l'intérêt de XML. Il dirait juste que "XML peut être mieux" et si on veut mon avis, oui, XML pourrait être amélioré, et surtout pourrait avoir été mieux fait au départ. Comme tout, quoi.
Par contre, en conclure que XML ne devrait pas exister, ou pas être utilisé ce qui est la même chose, c'est débile.
Dans le cas général le goût de l'efficacité est non seulement inutile, mais contre-productif. La machine devrait travailler, pas nous.Citation:
Envoyé par powel
Non. Personne n'a jamais dit que la machine devait essayer de penser pour lire du XML.Citation:
Envoyé par powel
Tout est dit là.Citation:
Envoyé par powel
Une logique strictement axé applicative, genre robotique ou autre...
Désolé mais quand on travaille essentiellement sur de la donnée que l'on étudie, manipule,transforme... On n'a besoin d'avoir quelque chose de comprehensible pour l'humain et si c'est en plus lisible c'est un plus énorme.
Je ne compte plus les galère sur des bases de données ou à cause d'un caractères particulier ou d'un nouveau format de donnée on n'était obligé de changer de version de l'editeur SQL, voir d'éditeur pour pouvoir travailler.
Comme déjà dit, va peut être falloir que certains se sortent de leur logique strictement applicative, il y a autre chose que cela en informatique et pour ne pas comprendre pourquoi un format de donnée/document doit être comprehensible pour un être humain via un éditeur de texte, c'est qu'on n'a jamais bossé dans des domaines les utilisant...
sans être aussi catégorique. je pense que forma lisible par l'homme et la machine est souvent un plus
il n'y a pas très longtemps je consultais un mail via un webmail loin de chez moi loin de mon boulot avec une machine sur laquelle je n'avais pas mes outils.
un collègue m'alertait sur un problème d'échange entre deux applications d'un SI qui en compte des milliers
était joint le fichier contenant le message fautif. le format du document est un format d'échange mis au point à la grande époque de l'OSI et ces nombreuse couche. format de niveau 7 soit donc la couche applicative. (et non présentation) donc dédié à la lecture par une machine.
j'ai ouvert le truc est j'ai commencé à scruter le message qui heureusement pour moi était court.
bref lire dans notepad un truc destiné à une machine n'est pas simple.
à côté de moi une personne travaillant elle aussi dans le même genre de SI me demanda si je lisais le format en question dans le texte et ma réponse fut que j'essayais. elle me proposa son aide et me lu la chose comme vous ou moi un roman. et en rein de temps je trouvais et résolvait le pb.
après une petite discussion elle m'avoua être souvent confrontée à ce genre de pb et qu'elle avait fini par lire ce format directement dans les flux. l'utilisation d'outils étant couteuse en temps (extraction du doc de son domaine, I.e. transfert depuis un domaine sécurisé qui normalement l'interdit du fichier chargement d'un outil lourd pas toujours dispos)
pour ma part je n'y arrive pas aussi facilement et j'ai au magique un tout petit outil qui transforme se format en xml et là les bloc apparaissent et tout s'éclaire.
lorsqu'on travaille ainsi sur des échanges les exploitants finissent par lire des format qui ne sont pas du tout adapté à l'homme simplement parce qu'il ont étés pensé pour la machine en imaginant que jamais on aurait besoin d'aller y voir.
j'ai vu à l'époque un exploitant prendre un rack de cartes perforé les passer en vitesses ralentir au milieu du tas (gros le tas) et en regarder quelques unes. puis il a sortit un poinçon et a fait un trou. à l'étonnement de tous il a répondu "c'est toujours la même erreur!"
tout ça pour dire que oui c'est bien d'optimiser pour la machine mais qu'il faut aussi penser que souvent le format en question va se retrouver devant des yeux humain même si ce n'est pas sa vocation.
A+JYT
Bonjour
En réalité, il est bien dommage qu'on s'éloigne du post initial (je pense que le changement de titre du post par la modération n'y est pas pour rien).
La motivation de ce thread part à la base d'un constat de la prolifération des fichiers de configuration au format XML dans une application J2EE.
D'ailleurs les premières réponses du thread vont dans ce sens. Et, c'est aussi pour ça que j'ai ironisé sur le fait que je n'ouvre pas mes fichiers odt à coup de winzip + notepad ;)
La configuration d'une application doit être comprise par l'homme, doit être facile à compléter ET ne doit pas demander plus de réflexion, de temps ou d'argent que le développement de l'application elle même.
Bref, ça a dévié sur l'utilité du format XML alors qu'au départ, j'ai le pressentiment que personne ne le mettait en doute.
Voici les propres mots de l'auteur du thread :
Est à ce sujet, on veut quelque chose de plus simple que le XML, pas du binaire :lol:Citation:
Il y en eu partout et pour tout. Si pour l'échange de données entre systèmes il avait des atouts certains, je défends la thèse qu'il a été utilisé abusivement. Le paramétrage des composants, par exemple, est trop souvent passé par lui.
Yann
Au départ peut-être pas, mais à la longue... :roll:Citation:
Envoyé par yann2
De toute façon, je ne pense pas qu'il reste grand-chose à débattre sur la question de départ, si ?
Salut
Et bien, je pense que ça aurait été intéressant de débattre sur le sujet initial.Citation:
Envoyé par thelvin
Nous pouvons bien entendu débattre de l'utilité du format XML mais, pour ma part, à moins de voir des arguments de fou, je pense que dire que le langage XML est une ineptie est une ineptie :mouarf:
Donc je vais me retirer.
Yann
C'est allucinant de voir que bien des informaticiens considèrent l'accès direct comme de la magie. Tu penses que quand tu ouvres "C:/toto/monfichier.xml", windows se farci la lecture de l'intégralité de ton disque dur?Citation:
Envoyé par Oscar Hiboux
Tu as une idée de ce qui se passe dans un Oracle, Postgres, SQLite etc... quand tu recherches "valeur"=12 dans une table où "valeur" est indexée?
De là à savoir écrire ces moteurs de stockage, il y a des limites.
Quand tu modifies tout fichier à lecture séquentielle, tu dois le ré-écrire dans son intégralité. Quand tu modifies un fichier où les enregistrements on une taille définie, tu peux rentabiliser "seek".Citation:
Parce que quand tu modifies un fichier YaML (par exemple) tu n'as pas besoin d'un balai pour le réécrire ? :aie:
Ya rien de très "human friendly" dans les binaires de stockage des SGBD digne de ce nom. Et je m'en fiche que ma base postgres ne puisse s'ouvrir dans mon bloc note du moment que j'ai les moyens d'en lire/éditer le contenu dans un quelqu'onque outils et la manipulée par des bibliothèques de programmation.Citation:
YAML is a human friendly data serialization standard for all programming languages.
Mon seul regret est qu'SQL soit nettement moins user friendly que XPATH ou XQUERY
C'est là que l'on comprend tout à la philosophie du human friendly... Seul le parseur est censé passé son temps à lire ces salopries de flux. Pas le geek dans son bloc note.Citation:
JSON est fait pour de petit flux (bien qu'il m'arrive d'en faire de plusieurs mega) et pour être concis et directement interprétable par JavaScript (donc un outil qui à la base n'a que peut de ressources mais ça évolue) et c'est étendu à l'extérieur. je l'utilise beaucoup.
mais justement xml avec les balises ouvrante et fermante xml représente un progrès. c'est certes verbeux mais sur un flux de 1Go ou les balise on des nom de 3 char max faire la relation entre la deuxième { du json et celle qui est en plein milieu est quasi impossible } alors que mettre en relation <cli></cli> est immédiat.
j'ai beaucoup pratiqué lisp et les ((((()))(()))(()()()()()()())) pas simple de s'y retrouver
qui n'a jamais vu dans du code C java php etc. des chose comme
Quand à la syntaxe que les développeurs utilises :
Ca ne les a pas traumatisé à partir deCitation:
function test() {
...
} //end function test
De toute manière, avec des ouvrants fermants, qu'ils s'agissent de parenthèses, de balise ou d'accolade; sans indexation, le tout est illisible.Citation:
PROCEDURE test()
...
IF ( ) THEN
END IF;
END PROCEDURE
Le problème de la verbosité n'est pas la taille des noms; mais la répétition permanente des métadonnées...Citation:
pour la verbosité de XML il est vrai qu'on utilise souvent des noms longs
mais la norme n'interdit pas de faire plus court
Pour l'homme, qui ne lit ça que par flème de lire des spécifications OUI. Pour la machine NON.Citation:
comme quoi XML permet si on le prends pour ce qu'il est de faire des choses concises rapide et qui reste bien plus lisible que
Code:
2
[quote]
Hélas, non, sinon je me tairais et me dirais : Ce n'est pas bien grave d'utiliser XML à tout va. Dès lors que tu dois échanger des flux de données "important" par un réseau, tu te retrouves vite à saturer ta bande passante grace à XML face à JSON ou du CSV-like.Citation:
Envoyé par bretus Voir le message
Du point de vue "métaphysique", on peut se demander l'intérêt de la répétition pour chaque entrée, en double, des métadonnées :
<mon-nom-de-variable>...</mon-nom-de-variable>
JSON est plus pragmatique à ce niveau là (et distingue les tableaux des objets au passage).
Citation:
Est-ce un (simple) principe qui ne gène que ceux qui se posent des questions métaphysiques ?
Divise par deux la taille de tes flux, tu divises par deux ta consommation de bande passante.
etCitation:
Envoyé par Oscar Hiboux
Justement non. XML arrive comme seul support pour les spécifications des formats d'échanges de données. Du coup, les utilisateurs commence par exemple à exporter leurs cartes dans le format d'échange. Bilan : Des fichiers de 400 Mo sans problème.Citation:
Il faut savoir être pragmatique dans la vie XML n'a pas vocation à replacer tout et n'importe quoi. mais 400Mo n'est pas un pb pour XML pas plus que pour tout autre format.
Ensuite, il est le support des services réseaux; et pas seulement pour les requêtes où REST suffisait dans la plus part des cas; mais aussi pour les réponses à ces requêtes.
Au final, les outils se basant sur XML pullule et conduise à une utilisation déplacée car il devient quasi-incontournable pour rester dans du standard.
Mais vous avez raison : Il faut faire tourner dans le vent les machines et saturer les réseaux pour courir après le Human Readable sur le fichier/flux lui même.
Pour ma part, je trouve bien moins "idiot" d'avoir un format imbuvable, "machine readable" et les éditeurs qui vont avec...
C'est le cas avec les images et ça ne traumatise personne. L'image est stockée dans un format illisible par l'homme. L'utilisateur dispose de son lecteur/éditeur d'image. Le programmeur des specs et surtout des bibliothèques pour la manipuler.
Au rythme actuel, nous finirons par remplacer TIF et JPEG par des formats à base d'XML, plutôt que de s'inspirer de TIF et JPEG pour construire un format d'échange représentant des "objets" manipulé en P.O.O.
Alors pour en revenir à :
Il y juste ceux peut être juste ceux qui savent lire des spécifications; et ceux qui magouille dans leurs éditeurs de texte afin de décrypter les données plutôt que de lire des spécifications...Citation:
Est-ce un (simple) principe qui ne gène que ceux qui se posent des questions métaphysiques ?
Parmi les deuxièmes, on trouve ceux qui n'ont pas compris que ce n'était pas XML qui était pratique en temps que tel, mais les bibliothèques et outils qui tournent autour... S'ils devaient se farcir l'écriture d'un parser XML, je pense qu'ils regretteraient de ne pas avoir plutôt à écrire une bibliothèque de manipulation des TIF...
bye
Et un tel fichier en pratique, soit est bien trop limitant, soit nécessite de réécrire le fichier quand on dépasse la "taille fixe". Ton histoire de "grand coup de balais" ne vaut pas grand-chose.Citation:
Envoyé par bretus
Il n'y a pas de quoi être fier à ne pas voir l'intérêt qu'il soit possible de lire les flux à l'œil.Citation:
C'est là que l'on comprend tout à la philosophie du human friendly... Seul le parseur est censé passé son temps à lire ces salopries de flux. Pas le geek dans son bloc note.
Par exemple, le flux peut être reconstruit à la volée par des outils tiers pour le rendre lisible. En pratique c'est une question de trois touches et deux clics, et il n'y a pas eu à programmer quoi que ce soit, sans possibilité de bug.Citation:
De toute manière, avec des ouvrants fermants, qu'ils s'agissent de parenthèses, de balise ou d'accolade; sans indexation, le tout est illisible.
Le problème de la verbosité n'est pas la taille des noms; mais la répétition permanente des métadonnées...
Nope. Il n'y a aucun problème avec ça.
La "flemme" est une question d'économie de temps et d'argent. Les machines sont nos esclaves, et elles peuvent nous épargner du travail sans intérêt. Donc, elles doivent le faire.Citation:
Pour l'homme, qui ne lit ça que par flème de lire des spécifications OUI. Pour la machine NON.
Tu oublies un peu vite qu'un flux ça se compresse et que XML a d'autres avantages que la seule lisibilité transparente... Mais je suis quand même assez d'accord, pour un échange réseau, il est plus pragmatique de se tourner d'abord vers JSON ou CSV.Citation:
Divise par deux la taille de tes flux, tu divises par deux ta consommation de bande passante.
Je maintiens que si les informaticiens ne sont pas foutus d'être des informaticiens, ce n'est pas la faute du standard de fait. Des outils pour utiliser autre chose que XML quand c'est plus adapté, on manque un petit peu, mais pas tant que ça. Et ce n'est pas la faute de XML de toute façon.Citation:
Justement non. XML arrive comme seul support pour les spécifications des formats d'échanges de données. Du coup, les utilisateurs commence par exemple à exporter leurs cartes dans le format d'échange. Bilan : Des fichiers de 400 Mo sans problème.
C'est vrai, quel intérêt de confier les problèmes récurrents aux machines et de passer à autre chose ?Citation:
Pour ma part, je trouve bien moins "idiot" d'avoir un format imbuvable, "machine readable" et les éditeurs qui vont avec...
Et nous savons tous qu'il y a tout autant de formats d'images que de formats de données. D'ailleurs, un brouillon de nouveau format d'image se crée en 7 minutes environ et peut être manipulé avec des outils de base standard dans les 10 minutes qui suivent. Juste un peu moins bon que XML, JSON, YAML...Citation:
C'est le cas avec les images et ça ne traumatise personne. L'image est stockée dans un format illisible par l'homme. L'utilisateur dispose de son lecteur/éditeur d'image. Le programmeur des specs et surtout des bibliothèques pour la manipuler.
Car les spécifications, c'est un outil qui te permet de jouer immédiatement avec les données qu'elles décrivent, sur n'importe quel environnement de travail. Et elles vérifient même que tu les as bien comprises.Citation:
Il y juste ceux peut être juste ceux qui savent lire des spécifications; et ceux qui magouille dans leurs éditeurs de texte afin de décrypter les données plutôt que de lire des spécifications...
... Mais ils ne doivent pas. Magie !Citation:
S'ils devaient se farcir l'écriture d'un parser XML, je pense qu'ils regretteraient de ne pas avoir plutôt à écrire une bibliothèque de manipulation des TIF...
Bonjour,
Pour apporter ma pierre au troll :
Je pense que tout dépend du contexte d'utilisation du format de sérialisation des données.
Configuration de l'application :
Si on regarde du côté de symfony on se rend compte que le format yaml est dans bien des cas plus clair, moins verbeux et donc plus simple d'utilisation que le format xml. Il est aussi bien plus évolué que le fichier properties du fait de sa structure hiérarchique élaborée.
Le xml se débrouille aussi plutôt bien, c'est quand même pas la mort de lire un contrôleur Struts. Mais bon je pense que dans ce genre de cas d'utilisation la palme revient au yaml par son aspect moins verbeux dans ce genre de contexte et on gagne donc en efficacité et en aisance de développement : en clair le xml c'est pas fait pour ça, même s'il s'en sort pas trop mal.
J'ajouterai que la force de ces méthodes de travail basées sur des fichiers de configuration est quand même la propreté du code généré derrière. En clair si vous avez un développeur qui passe une semaine sur votre équipe et qu'on lui colle un contrôleur à coder, ben s'il doit se conformer à un standard pour produire du code, il a vraisemblablement moins de chance de faire un travail de cochon que si on lui donne l'occasion de coder directement.
Transfert de flux de données :
Là je vois deux concurrents, le json et le xml. Le json se retrouve souvent bien moins galère à parser qu'un xml. En python la différence est flagrante, on fait en 3 lignes avec SimpleJson ce qu'on fait en 20 avec Elementtree (+ une nouvelle classe parce que sinon c'est le bordel).
D'un autre côté à partir du moment où le flux en question peut-être lu par un humain alors on gagne beaucoup à utiliser le xml. On s'y retrouve beaucoup mieux dans les tags que dans les accolades, surtout quand on dépasse un certain nombre de ligne.
De ce point de vue j'aime bien l'approche de certaines api, par exemple celle de mediawiki qui propose les deux formats au choix. Clairement avoir un retour en xml est un plus pour l'humain, mais pour analyser le document avec un language de prog alors le retour en json est plus simple à exploiter.
Mise en forme de données :
Je comprend bien l'intérêt du xml couplé avec xsl, mais... euh... Pourquoi pas faire du html directement à ce moment là?
Bref je pense que le xml est un format tout terrain, et on peut toujours s'en sortir dans la plupart des cas avec. Il a donc l'avantage de l'universalité si on peut dire, car il est la fois compréhensible par l'humain et par la machine.
Toutefois si on regarde au cas par cas chaque utilisation on peut souvent trouver un format plus adapté. De ce point de vue j'aime beaucoup l'approche pragmatique du framework Symfony : à chaque cas précis son format. Pour un web service on utilise json, pour de la configuration on utilise yaml et pour le stockage des strings i18n on utilise du xml.
Et pour ce qui est de la présence de ce genre de formats à la place du code, comme avec Struts et Spring, moi je dis : oui oui oui! Plus on utilse ce genre de format en remplacement du code, plus le code est générique, plus il est carré, plus il est simple à maintenir. Cqfd.
Bah oui parce que dans le meilleur des mondes on peut dire qu'un bon développeur a pas besoin de ça, que son code doit être clair, lisible, bien documenté, qu'il recourt le moins possible à des verrues ou à de petites fantaisies "pour que ça passe".
En pratique dans la plupart des projets que j'ai connu les gens vont et viennent, on croise de bons développeurs comme des mauvais. L'appli, elle, reste et doit être maintenue. Il y a donc un facteur humain important qu'il ne faut jamais négliger.
Donc moins l'architecture de l'application est permissive et plus elle a de chances de rester claire et maintenable. Le fichier de configuration en lieu et place du code est fait pour ça, et moi je trouve ça plutôt bien ;)