IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

XML/XSL et SOAP Discussion :

Que pensez-vous du XML, faut-il passer à autre chose ?


Sujet :

XML/XSL et SOAP

  1. #81
    Membre éprouvé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2006
    Messages
    519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Septembre 2006
    Messages : 519
    Points : 1 104
    Points
    1 104
    Par défaut
    Citation Envoyé par Morbo Voir le message
    Sinon mon framework web préféré du moment, c'est Play! qui n'a aucune configuration xml .
    Je te remercie énormément pour m'avoir fait connaître ce framework

  2. #82
    Membre averti
    Profil pro
    Inscrit en
    Mars 2006
    Messages
    319
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : Belgique

    Informations forums :
    Inscription : Mars 2006
    Messages : 319
    Points : 351
    Points
    351
    Par défaut
    Citation Envoyé par bretus Voir le message
    Un XML de 400Mo fait voler un éclat bien des parseurs sur des machines moyennes.
    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 Voir le message
    Quand aux écritures, c'est une vrai catastrophe. Modifier une balise, et c'est parti pour le grand balais d'écriture.
    Parce que quand tu modifies un fichier YaML (par exemple) tu n'as pas besoin d'un balai pour le réécrire ?

    Citation Envoyé par bretus Voir le message
    Ce format n'a rien de structuré du point de vue de la machine. Il n'est lisible qu'en séquentiel, l'accès à un élément impose la lecture de l'intégralité du fichier...
    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 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).
    Est-ce un (simple) principe qui ne gène que ceux qui se posent des questions métaphysiques ?
    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 ! 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.

  3. #83
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Points : 7 752
    Points
    7 752
    Par défaut
    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.

  4. #84
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    Citation Envoyé par bretus Voir le message
    Justement pas tant que ça... Le lisibilité n'est pas là pour la pauvre machine qui se fade les lectures. Un XML de 400Mo fait voler un éclat bien des parseurs sur des machines moyennes.
    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.
    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.


    Citation Envoyé par bretus Voir le message
    Quand aux écritures, c'est une vrai catastrophe. Modifier une balise, et c'est parti pour le grand balais d'écriture.
    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 Voir le message
    Ce format n'a rien de structuré du point de vue de la machine. Il n'est lisible qu'en séquentiel, l'accès à un élément impose la lecture de l'intégralité du fichier...
    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 XML

    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).
    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
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    function test() {
    ...
    } //end function test
    tout ça pour ne pas se perdre dans les {}

    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
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    <?xml version="1.0" encoding="UTF-8"?>
    <OMS_O05>
      <MSH>
        <MSH.1>|</MSH.1>
        <MSH.2>^~\&amp;</MSH.2>
        <MSH.3>
          <HD.1>ORBIS</HD.1>
        </MSH.3>
        <MSH.4>
          <HD.1>047</HD.1>
        </MSH.4>
        <MSH.5>
          <HD.1>EAI</HD.1>
        </MSH.5>
        ..
      </MSH>
    ...
    </OMS_O05>
    format normalisé plutôt concis.
    mais on peut aller beaucoup plus loin
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    <OMS_O05>
    <1.1>&para;</1.1>
    <1.5.1>ETL</1.5.1>
    </OMS_O05>
    qui dit au correspondant dans le doc OMS_O05 remplacer l'élément /OMS_O05/MSH/MSH.1 par &para; (premier fils->premier fils) et l'élément
    /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
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    4F4D535F4F30350D0A313126706172610D0A312E352E3145544C0D0A
    qui pourtant est exactement la même chose

    A+JYT

  5. #85
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 547
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 547
    Points : 21 602
    Points
    21 602
    Par défaut
    Citation Envoyé par sekaijin Voir le message
    Citation Envoyé par bretus
    Quand aux écritures, c'est une vrai catastrophe. Modifier une balise, et c'est parti pour le grand balais d'écriture.
    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.
    Tu es beaucoup trop bon. À mon sens une remarque pareille était juste bonne à être ignorée.
    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.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  6. #86
    Membre à l'essai
    Profil pro
    Inscrit en
    Mars 2006
    Messages
    30
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2006
    Messages : 30
    Points : 19
    Points
    19
    Par défaut
    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>
    Un peu d'accord avec ça ...

    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é.

  7. #87
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2007
    Messages
    10 191
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 191
    Points : 28 070
    Points
    28 070
    Par défaut
    Citation Envoyé par powel
    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.

    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 ......
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  8. #88
    Rédacteur

    Avatar de Erwy
    Homme Profil pro
    Développeur Web
    Inscrit en
    Novembre 2003
    Messages
    4 967
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Novembre 2003
    Messages : 4 967
    Points : 10 927
    Points
    10 927
    Par défaut
    Citation Envoyé par powel Voir le message
    A long terme XML n'aura peut être pas le succés escompté.
    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.
    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é.
    Quand on regarde l'histoire de l'informatique, seuls les concepts ayant un fort sens pratique ont perduré et non les concepts idéalistes.
    Et c'est quoi un "fort sens pratique" ?
    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"

  9. #89
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    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

  10. #90
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 547
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 547
    Points : 21 602
    Points
    21 602
    Par défaut
    Citation Envoyé par powel Voir le message
    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 ...
    Ce dont personne n'a quoi que ce soit à cirer.

    Citation Envoyé par powel Voir le message
    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.
    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 Voir le message
    Quand on regarde l'histoire de l'informatique, seuls les concepts ayant un fort sens pratique ont perduré et non les concepts idéalistes.
    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.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  11. #91
    Membre à l'essai
    Profil pro
    Inscrit en
    Mars 2006
    Messages
    30
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2006
    Messages : 30
    Points : 19
    Points
    19
    Par défaut
    Citation Envoyé par sevyc64 Voir le message
    Depuis plus de 10 ans qu'il existe, je crois que le succès du format XML n'est plus à faire.

    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.
    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.
    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.

    Citation Envoyé par sevyc64 Voir le message
    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 ......
    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.

    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.


    Citation Envoyé par Erwy Voir le message
    Et c'est quoi un "fort sens pratique" ?
    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"
    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.

    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.

    Citation Envoyé par sekaijin Voir le message
    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
    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 thelvin Voir le message
    Ce dont personne n'a quoi que ce soit à cirer.

    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.
    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.

    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é.

    Citation Envoyé par thelvin Voir le message
    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.
    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.

  12. #92
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 547
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 547
    Points : 21 602
    Points
    21 602
    Par défaut
    Citation Envoyé par powel Voir le message
    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.
    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.

    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.

    Citation Envoyé par powel Voir le message
    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é.
    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 Voir le message
    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.
    Non. Personne n'a jamais dit que la machine devait essayer de penser pour lire du XML.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  13. #93
    Rédacteur

    Avatar de Erwy
    Homme Profil pro
    Développeur Web
    Inscrit en
    Novembre 2003
    Messages
    4 967
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Novembre 2003
    Messages : 4 967
    Points : 10 927
    Points
    10 927
    Par défaut
    Citation Envoyé par powel Voir le message
    [..]
    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.
    [..]
    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.
    [..]
    Tout est dit là.
    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...

  14. #94
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    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

  15. #95
    Membre expérimenté Avatar de yann2
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2004
    Messages
    897
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Mai 2004
    Messages : 897
    Points : 1 635
    Points
    1 635
    Par défaut
    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 :

    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.
    Est à ce sujet, on veut quelque chose de plus simple que le XML, pas du binaire

    Yann

  16. #96
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 547
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 547
    Points : 21 602
    Points
    21 602
    Par défaut
    Citation Envoyé par yann2 Voir le message
    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.
    Au départ peut-être pas, mais à la longue...

    De toute façon, je ne pense pas qu'il reste grand-chose à débattre sur la question de départ, si ?
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  17. #97
    Membre expérimenté Avatar de yann2
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2004
    Messages
    897
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Mai 2004
    Messages : 897
    Points : 1 635
    Points
    1 635
    Par défaut
    Salut

    Citation Envoyé par thelvin Voir le message
    Au départ peut-être pas, mais à la longue...

    De toute façon, je ne pense pas qu'il reste grand-chose à débattre sur la question de départ, si ?
    Et bien, je pense que ça aurait été intéressant de débattre sur le sujet initial.

    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

    Donc je vais me retirer.

    Yann

  18. #98
    Membre éprouvé
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2009
    Messages
    552
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Mars 2009
    Messages : 552
    Points : 1 060
    Points
    1 060
    Par défaut
    Citation Envoyé par Oscar Hiboux Voir le message
    Ah, et par quelle magie tu n'aurais pas besoin de lire un fichier séquentiellement pour y chercher qqchose ?
    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?
    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.

    Parce que quand tu modifies un fichier YaML (par exemple) tu n'as pas besoin d'un balai pour le réécrire ?
    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".

    YAML is a human friendly data serialization standard for all programming languages.
    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.
    Mon seul regret est qu'SQL soit nettement moins user friendly que XPATH ou XQUERY

    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
    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.

    Quand à la syntaxe que les développeurs utilises :

    function test() {
    ...
    } //end function test
    Ca ne les a pas traumatisé à partir de

    PROCEDURE test()
    ...
    IF ( ) THEN

    END IF;
    END PROCEDURE
    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.

    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
    Le problème de la verbosité n'est pas la taille des noms; mais la répétition permanente des métadonnées...

    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    4F4D535F4F30350D0A313126706172610D0A312E352E3145544C0D0A
    Pour l'homme, qui ne lit ça que par flème de lire des spécifications OUI. Pour la machine NON.

    [quote]
    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).

    Est-ce un (simple) principe qui ne gène que ceux qui se posent des questions métaphysiques ?
    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.
    Divise par deux la taille de tes flux, tu divises par deux ta consommation de bande passante.


    Citation Envoyé par Oscar Hiboux Voir le message
    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.
    et
    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.
    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.
    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 à :
    Est-ce un (simple) principe qui ne gène que ceux qui se posent des questions métaphysiques ?
    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...

    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

  19. #99
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 547
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 547
    Points : 21 602
    Points
    21 602
    Par défaut
    Citation Envoyé par bretus Voir le message
    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".
    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.

    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.
    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.

    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.
    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.

    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.

    Pour l'homme, qui ne lit ça que par flème de lire des spécifications OUI. Pour la machine NON.
    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.

    Divise par deux la taille de tes flux, tu divises par deux ta consommation de bande passante.
    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.

    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.
    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.

    Pour ma part, je trouve bien moins "idiot" d'avoir un format imbuvable, "machine readable" et les éditeurs qui vont avec...
    C'est vrai, quel intérêt de confier les problèmes récurrents aux machines et de passer à autre chose ?

    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.
    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...

    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...
    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.

    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...
    ... Mais ils ne doivent pas. Magie !
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  20. #100
    Membre du Club
    Inscrit en
    Avril 2010
    Messages
    18
    Détails du profil
    Informations forums :
    Inscription : Avril 2010
    Messages : 18
    Points : 43
    Points
    43
    Par défaut
    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

Discussions similaires

  1. [ADO.Net][XML]Que pensez-vous de cette manière de faire?
    Par RiiiDD dans le forum Accès aux données
    Réponses: 6
    Dernier message: 22/03/2006, 12h29
  2. Que pensez vous du mariage ASP Flash?
    Par tyma dans le forum Flash
    Réponses: 4
    Dernier message: 09/07/2003, 16h00
  3. Réponses: 13
    Dernier message: 11/05/2003, 14h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo