Sondage XML est

Posté par .
Tags : aucun
0
20
oct.
2006
  • un langage informatique de balisage :
    1150
    (25.6 %)
  • gainial \o/ :
    176
    (3.9 %)
  • excellent pour échanger des données :
    739
    (16.5 %)
  • pratique :
    470
    (10.5 %)
  • une usine à gaz :
    462
    (10.3 %)
  • une pourriture infâme :
    484
    (10.8 %)
  • utilisé dans mon entreprise :
    115
    (2.6 %)
  • décideur compliant :
    491
    (10.9 %)
  • moins à la mode qu'AJAX :
    403
    (9.0 %)

Total : 4490 votes

La liste des options proposées est volontairement limitée : tout l'intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées, ou de l'impossibilité de choisir plusieurs réponses. 76,78% des sondés estiment que ces sondages sont ineptes.
  • # n00b xml

    Posté par . Évalué à 3.

    Autant des fichiers de conf XML, je peux comprendre à quoi ça sert...

    Autant des fichiers XML pour s'échanger des documents au même format je peux comprendre.....

    Mais finalement....je ne suis pas bien sûr d'avoir compris à quoi sert XML, ni même ce que l'on peut faire avec...

    Merci d'éclairer ma lanterne
    • [^] # Re: n00b xml

      Posté par . Évalué à 3.

      Je pense que tu réponds tout seul à ta question --> Proposer un standard pour l'échange de données !
      • [^] # Re: n00b xml

        Posté par (page perso) . Évalué à 5.

        l'échange de données non binaires. c'est un problème.
    • [^] # Re: n00b xml

      Posté par . Évalué à 2.

    • [^] # Re: n00b xml

      Posté par . Évalué à 9.

      L'intéret ? C'est que dans quasiment tous les languages, tu a des API ou bibliothèques pour lire du XML sans avoir a programmer de parseur.

      Voilà pour moi l'intéret : quand je manipule des fichiers XML, je sais qu'avec n'importe quel language je pourrais le relire facilement, dans avoir a manipuler des fopen, fgetc (et leurs équivalent dans tous les languages) et Co, sans avoir a me soucier si oui on non je respecte la structure[1] du fichier - l'API me garantit que je le fait.

      Un autre intéret, par exemple, si tu t'intéresse qu'a une seule partie du fichier, tu as juste a récupérer les bonnes balises, alors que sans le XML tu dois détecter la partie qui t'intéresse et bien valider que tu détecte toujours la bonne partie. Et c'est pas toujours si facile.

      Globalement, l'idée est qu'il est beaucoup plus simple de transformer un fichier XML en réprésentation mémoire interne - la structure de donnée de ton appli - qu'un autre fichier quelconque.

      Bref, ca permet de lire/écrire des fichiers sans se soucier de leur structure, alors qu'a la main c'est toujours la partie chiante et bouffeuse de temps. Tout en souplesse.

      [1] quand je parle de structure, c'est bien dans le sens "bien formé" de XML, et pas valide. C'est a dire que même s'il est bien formé (lisible par toutes les API XML) il faudra toujours mettre les bonnes balises ou il faut pour avoir une vraie interopétabilité, mais c'est toujours moins galère que de se taper un parseur ou générateur a la main :)
      • [^] # Re: n00b xml

        Posté par . Évalué à 2.

        Bravo et j'ajouterais qu'il est également très aisé de le transformer vers un autre format grâce aux feuilles de style XSL. Technique courament utilisée pour générer des pages HTML par exemple. Des moteurs s'apuient là-dessus, comme Cocoon du projet Apache notament...
      • [^] # Re: n00b xml

        Posté par . Évalué à 6.

        Et à part ça, XML est utile car il y a :

        - le typage de l'arbre XML
        - la validation des documents contre un schéma XML (et précédemment, contre la DTD)
        - la traduction de dialectes XML
        - la possibilité de streaming (SAX-like), ou le parcours d'arbres (DOM-like)
        - les nombreux protocoles et formats qui utilisent XML comme base (par exemple, XMPP et toutes ses extensions, les "webservices" en XML-RPC voire SOAP, OpenDoc ou tout simplement XHTML Strict).

        Pour résumer, XML est un langage au même titre que l'ensemble des mots UTF-8 en est un : cependant, XML est associé à des règles lexicales et syntaxiques (ainsi que quelques éléments sémantiques de base) qui facilitent son extensibilité, et surtout, qui permettent à tout le monde de travailler sur un seul et même format.

        Si l'UTF-8 c'est la voix, XML c'est la lingua franca de l'informatique actuelle, et les dialectes XML sont des patois strictement inclus dans XML (c'est-à-dire valides) et autodocumentés (on a d'habitude leur dico, leurs règles de grammaire et la sémantique désirée associée).

        Pour résumer, des avantages qui dépassent de loin les inconvénients (d'un point de vue complexité algorithmique, certains problèmes ont des solutions moins coûteuses avec un format plus simple), car on ne manque ni de bande passante ni de capacité de calcul.

        Si ce n'était pas XML, ça serait un autre langage similaire pour les mêmes besoins.
        • [^] # Re: n00b xml

          Posté par . Évalué à 3.

          On peut aussi ajouter qu'XML a le bon goût d'être lisible par un parseur et par un être humain (le périphérique situé entre la chaise et l'écran), surtout si la structure du fichier est bien conçue. Et ça, c'est quand même la classe.

          Moi j'aime aussi XML parce qu'il n'y a rien de plus facile que de lire une valeur dans un fichier de 10000 lignes, par exemple avec une expression régulière.

          Pour avoir testé, XML c'est quand même la merde par contre pour les gros fichiers.
          • [^] # Re: n00b xml

            Posté par . Évalué à 3.

            XInclude est ton ami...

            http://www.w3.org/TR/xinclude/
          • [^] # Re: n00b xml

            Posté par (page perso) . Évalué à 1.

            > Moi j'aime aussi XML parce qu'il n'y a rien de plus facile que de lire une valeur dans un fichier de 10000 lignes, par exemple avec une expression régulière.

            C'est ironique ?
            Car XML étant un arbre, il faut justement un parser pour le parcourir/l'analyser (un automate à pile) alors que ce n'est pas possible avec un automate fini (une regexp)

            Quand je veux lire une valeur dans un fichier XML de 10000 lignes, je prend lex/yacc (désolé, j'aime pas XML, alors j'utilise pas les librairies adaptées... je fais au plus rapide)
  • # Ne vous perdez pas en route!

    Posté par . Évalué à 5.

    Quelque soit un language ou un format. Si on se s'écarte ceu a quoi il était destiné au début, on arrive a tout les abus et les tracas qui vont avec.

    Comme par exemple des gens qui s'en servent comme une BDD.
    • [^] # Re: Ne vous perdez pas en route!

      Posté par . Évalué à 4.

      C'est pourtant bien son but,... une base de donée confinée à un rôle spécifique.
      On ne vas pas demander la même chose à une base de donnée :
      * XML (orienté document, le XML est plutôt un enregistrement, miam SVG, XHTML et OASIS entre autre), mais on ses limites ne sont pas encore définies.
      * DBM (gnuDB, berkley DB...) plutot table de hash
      * MySQL (SQL rapide, leger)
      * PostgreSQL (SQL puissant)
      etc...

      Mais pourquoi pas après tout.

      D'autant plus qu'il existe maintenant une version binaire appellée XOP
      qui permet d'avoir la puissance du XML, avec la legereté d'un arbre optimisé. Et c'est standardisé :

      http://www.w3.org/TR/xop10/

      Cela va également aider à résoudre les problèmes d'embarquement d'images et autres formats binaires dans ces documents.
      • [^] # Re: Ne vous perdez pas en route!

        Posté par . Évalué à 3.

        C'est clair, j'ai recement ecris un systeme de gestion d'equipement reseau visualisable en web.

        Et je devais sauvegarder la conf des equipements, mais il fallait que ça reste leger...!

        J'allais pas partir sur un gros truc SQL et tout le toutim. Un bon fichier XML, avec le perl XML::Simple, j'ai eu rapidement une bonne base rapide, fiable en moins de 200 lignes de perl.

        Franchement, si je serais partie sur du MySQL, même avec perl dbd::mysql, ça
        n'aurais pas été la même histoire.

        XML, pour stocker des données c'est bien, il faut juste bien hierachiser et, je pense, ne
        pas le faire des que ça depasse les 50Mo ou 100Mo de données.
        • [^] # Re: Ne vous perdez pas en route!

          Posté par . Évalué à 3.

          Pour ma part, j'ai développé un système qui doit être relativement similaire et qui concerne la collecte d'informations sur les serveurs linux dans l' entreprise : chaque machine tourne périodiquement un script qui génère un fichier contenant les informations relatives à la machine (infos rack, n° de séries, config réseau,soft installé, configuration sécurité, partitions, utilisateurs, ...).

          Ces fiches de config sont récupérées et stockées dans un point central et les contenus sont redistribués vers différents canaux grâce à différents scripts de transformation:

          - export vers fichiers plats pour que le management puisse intégrer les infos dans son outil de gestion d'assets.

          - export vers des fichiers plats à l'attention de consultants externes.

          - export vers une db mysql servant à la visualisation du parc (interface web) et à la (ré)installation automatique des serveurs.

          Une autre utilité du XML, c'est SOAP que j'utilise surtout pour les scripts de (re)configuration des serveurs.
        • [^] # Re: Ne vous perdez pas en route!

          Posté par (page perso) . Évalué à 3.

          Justement, pour les fichiers de configuration, il y a le YAML. C'est très simple et bien plus léger.

          C'est un des cas ou le XML est vraiment mauvais et employé à mauvais essient d'après moi. Le YAML est lisible et modifiable par l'homme et la machine.
          • [^] # Re: Ne vous perdez pas en route!

            Posté par . Évalué à 2.

            Justement, pour les fichiers de configuration, il y a le YAML. C'est très simple et bien plus léger.

            Effectivement, ça peut le faire mieux (sous réserve que le modèle ne soit pas trop complexe ou qu'on ne soit pas lié par des impératifs d'interopérabilité)... mais de là à prétendre qu'utiliser XML est "vraiment mauvais", il y a un pas qui doit s'appeler "religion"
            • [^] # Re: Ne vous perdez pas en route!

              Posté par (page perso) . Évalué à 3.

              Je n'aime pas tes sous-entendu. Je ne suis pas croyant !

              Je te parle ici de fichier de configuration, pas de base de données. Je n'irais pas faire une grosse base de données en YAML, c'est pas l'objectif.

              Comme je l'ai dis plus bas, les fichiers de configurations de TomCat sont une horreur. Heureusement qu'une grande majorité de logiciels libre ne suit pas cette tendance. Imagine la configuration de samba en XML ainsi que celle d'Apache !

              Ensuite, il faut aussi ramener le XML a sa juste valeur. S'il avait été génial, les wikis n'auraient pas été inventé. Le principe du wiki est le même que celui de TeX, privilégier le texte sur les commandes.

              Bref, le XML un peu, c'est bien, le XML partout, c'est trop.
              • [^] # Re: Ne vous perdez pas en route!

                Posté par . Évalué à 2.


                Imagine la configuration de samba en XML ainsi que celle d'Apache !


                Je signe tout de suite...!
              • [^] # Re: Ne vous perdez pas en route!

                Posté par . Évalué à 2.

                Je n'aime pas tes sous-entendu. Je ne suis pas croyant !

                Désolé pour ma réaction extrême, mais elle fait réponse à une déclaration extrême... Que le YAML soit plus adapté, soit, mais dire que le xml est carrément mauvais pour ce type de boulot, il y a tout de même un pas... Certes les fichiers de config de tomcat sont loin d'être des modèles de lisibilité (en fait une des raisons de cette illisibilité est l'abondance de commentaires qui perturbent la lecture de la structure indentée), mais ce n'est pas non-plus complètement impossible (au besoin, faire un petit coup de xmllint --format --noblanks avant de lire, ça aide un peu) ...

                Imagine la configuration de samba en XML ainsi que celle d'Apache !


                Personnellement, je serais plutôt demandeur, ça faciliterait la mise au point de scripts de configuration pour gérer de manière plus efficace les paramètres sur le parc de serveurs dont je fais l'automatisation.

                Ok, ce serait moins lisible pour les êtres humains, mais ça n'en deviendrait pas illisible pour autant, tout en offrant une structure plus facilement manipulable par scripts. Une version YAML me conviendrait sans doutes aussi.

                le XML partout, c'est trop.


                Je pense qu'effectivement, l'utiliser partout n'est pas forcément bon. Comme tu l'as dit, la syntaxe des wikis est plus simple et plus adaptée à la réalisation de documents relativement simples, le YAML est intéressant pour les petits fichiers de configuration.

                Maintenant, le XML n'est pas le pire non-plus et certainement pas le plus mauvais quand on sait l'utiliser.

                Pour reprendre l'exemple des fichiers de tomcat, il y aurait eu moyen de faire encore bien pire...
      • [^] # Re: Ne vous perdez pas en route!

        Posté par (page perso) . Évalué à 1.

        Après rapide lecture, XOP a l'air pire que XML. Ca va pas simplifier le code dans les applications embarquées communiquante (soap/upnp).

        La représentation est toujours en format texte et en plus, un decodage MIME doit être ajouté. Je ne vois pas l'optimisation à la lecture de l'exemple 3 et 4 du lien sité.

        Pourquoi toujours vouloir transformer les données binaires en texte. Il existe plein de format binaire interroperable (asn.1 par exemple).
        • [^] # Re: Ne vous perdez pas en route!

          Posté par (page perso) . Évalué à 1.

          Et quoi de l'EBML (1) développé au départ pour le wrapper media Matroska ? Le principe d'XML est gardé mais il parait assez simple de gérer des données binaires. Bon par contre on perd la lisibilité par un humain, mais est-ce qu'un humain est censé lire du binaire ?

          Est-ce que quelqu'un l'a déjà utilisé dans un projet personnel ? Quel avenir pourrait avoir l'EBML ?

          (1) http://ebml.sourceforge.net/
    • [^] # Re: Ne vous perdez pas en route!

      Posté par . Évalué à 3.

      Comme par exemple des gens qui s'en servent comme une BDD.

      Ce n'est peut-être pas adapté à servir directement de base de données (pas évident de faire une modif dans la base sans réécrire le fichier), mais au moins, d'un point de vue utilisation, c'est assez lisible.
      Il y a bien pire : l'utiliser pour une config avec des tests et des branches conditionnelles, genre fonts.conf.

      Franchement,
          <match target="pattern">
              <test qual="any" name="family">
                  <string>mono</string>
              </test>
              <edit name="family" mode="assign">
                   <string>monospace</string>
              </edit>
          </match>
      c'est plutôt calamiteux par rapport à un petit langage minimal avec if et =...

      Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

    • [^] # Re: Ne vous perdez pas en route!

      Posté par . Évalué à 2.

      L'utilisation de bases de données XML risque d'être de plus en plus importante dans le futur. Premièrement, il faut savoir que le temps de réponse d'une base de données XML est fonction de la taille de la donnée à renvoyer, et pas de celle à chercher. En clair, quelle que soit la complexité de la requête, c'est la taille de la réponse qui est le facteur limitant. On ne peut pas en dire autant des bases de données classiques. Il existe des bases de données réellement orientées XML, et qui sont capables de traiter plusieurs centaines de giga-octets (plusieurs teras, en fait) sans broncher.

      Pourquoi un SGBD/XML serait important ? C'est simple, on se retrouve de plus en plus avec des données non-figées. Avec un SGBD/R classique, j'ai une ligne dans une table, et même si je ne me sers pas des trois-quarts de la ligne, je suis obligé de l'allouer. Je perds donc de la place - mais bon, à la limite, ça c'est pas trop grave. Ce qui l'est plus, c'est quand je dois rajouter une colonne à ma table. C'est beaucoup, *beaucoup* plus chiant. En XML, c'est pas dur, je n'ai qu'à modifier la DTD ou le schéma XML, et c'est fini.

      Bref, les bases de données XML, ça ne fait que commencer, il reste à leur implémenter toutes les astuces connues dans le monde relationnel, ainsi que des astuces spécifiques au format lui-même (sachant qu'évidemment, l'arbre XML n'est pas représenté sous forme textuelle dans la base elle-même, mais sous forme d'index, le tout en binaire pour aller plus vite).
      • [^] # Re: Ne vous perdez pas en route!

        Posté par . Évalué à 7.

        est-ce que tu veux bien nous expliquer comment une requête ramenant 10ko dans une base de 1To avec un critère de recherche (disons: toutes les entités ayant un attribut toto=tata) peut avoir un temps de réponse et une consommation de ressource uniquement fonction du volume de données à ramener ? à part à avoir un index placé précisemment sur le bon attribut et fortement discriminant (c'est-à-dire strictement la même chose qu'avec un sgbdr).

        même question avec une expression xpath comme filtre (puisque tu dis "quelle que soit la complexité de la requête"), parce que là j'aimerais bien voir la structure d'index qui permet de résoudre le problème autrement qu'en temps proportionnel à la taille de la base (avec un sgbdr on parle de full scan).

        en sql il y a une commande qui s'appelle alter table. le problème est dans le code appelant, mais c'est le même avec une table ou avec un doc xml, si le code appelant ne lit pas le nouvel attribut couleurDesYeux dans l'entité ficheDuPersonnel, l'utilisateur ne sera pas plus content que si c'est une colonne qui n'est pas lue...

        pour ton info un sgbdr n'alloue pas la taille max d'un enregistrement à chaque fois qu'on fait un insert dont les 3/4 des colonnes sont à null.

        effectivement les bases de données XML ne font que commencer, mais heureusement demain le ciel sera plus bleu et l'herbe plus verte grâce aux bases XML.

        enfin en tout cas c'est comme tout ce qui salope le SI des clients et crée de l'entropie (eai, sgbdo...), après il faut faire les poubelles et ça me garantie du travail à vie sur plusieurs générations... mes futurs arrières-petits-enfants se joignent à moi pour dire merci à XML, dieu de la fertilité dans le panthéon de l'informaticien.

        (je réagis vivement à "base de données XML", je ne nie pas l'utilité de certains usages de XML)
  • # AJAX = ....

    Posté par (page perso) . Évalué à 10.

    ... Asynchronous Javascript And XML

    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: AJAX = ....

      Posté par . Évalué à 2.

      Plutôt gadget par rapport à un protocole comme SOAP.

      Ajax ne fait pas tourner le monde, mais SOAP est bel et bien occupé à se tailler une part gigantesque du monde des transactions intra et inter-entreprises...
      En fait, c'est surtout dans des standards comme soap que le xml montre le mieux ses capacités car l'interopérabilité est le maître mot.
      • [^] # Re: AJAX = ....

        Posté par . Évalué à 1.

        Le SOAP avec un grand S comme Sécurité ?
        • [^] # Re: AJAX = ....

          Posté par . Évalué à 3.

          S comme Simple...

          La sécurité, c'est le boulot du développeur qui utilise soap... (choix du protocole de transport, système d'authentication et d'autorisation, des librairies utilisées pour encoder et décoder, ...)
    • [^] # Re: AJAX = ....

      Posté par . Évalué à 1.

      Donc environ 8% des sondés pensent que XML est moins à la mode que XML (AJAX)
    • [^] # Re: AJAX = ....

      Posté par . Évalué à 1.

      Il est question de mode pas de technique... et AJAX a clairement gagné dans le monde des buzzwords.
      • [^] # Re: AJAX = ....

        Posté par . Évalué à 2.

        Ben non, il est question de technique...

        et puis question buzzword, au boulot j'entends plus souvent "webservices" et "soap" qu' "ajax".
  • # truc ou (machin truc) ?

    Posté par (page perso) . Évalué à 2.

    Pour ma part, je ne suis pas convaincu que la syntaxe XML soit plus puissante, ni plus simple, que celle du LISP.
    • [^] # Re: truc ou (machin truc) ?

      Posté par . Évalué à 3.

      Oui, mais tu compares deux choses qui ne sont pas comparables... le xml est un langage de balisage permettant de formuler des structures en vue d'un échange ou d'un traitement.

      Le lisp est un langage fonctionnel.

      Le xslt, en revanche, est un langage fonctionnel basé sur le xml, mais rien n'oblige l'usage du xslt pour effectuer le traitement du xml, d'ailleurs on peut utiliser du lisp pour traiter le xml.
      • [^] # Re: truc ou (machin truc) ?

        Posté par . Évalué à 3.

        Il compare la syntaxe XML à la syntaxe LISP, et pas XML à LISP :). Et elles ont presque la même expressivité, si on omet les namespaces en XML qui sont un must pour l'extensibilité d'XML, les URI, et tout plein de choses qui font que la syntaxe de XML est tout de même plus appropriée aux besoins actuels.

        Mais dans le fond, pour un document structuré simple

        <groupe>
            <nom>Led Zeppelin</nom>
                <membres>
                        <nom>Robert Plant</nom>
                        <nom>Jimmy Page</nom>
                        <nom>John Paul Jones</nom>
                        <nom>John Bonham</nom>
                </membres>
        </groupe>

        et

        (groupe (nom "Led Zeppelin"
            (membres
                (nom "Robert Plant")
                (nom "Jimmy Page")
                (nom "John Paul )
                (nom "John Bonham")
            )
        ))


        sont similaires. Mais pour des documents plus recherchés, XML est plus expressif. Après, c'est vrai que comparer LISP et XML (et non pas leurs syntaxes) n'a que peu de sens, et XSLT n'est pas comparable à LISP (même s'ils sont tous deux fonctionnels et T-complete, la comparaison s'arrête là ;)).
        • [^] # Re: truc ou (machin truc) ?

          Posté par . Évalué à 3.

          Les lecteurs avertis auront remarqué dans le snipet LISP qu'une parenthèse devrait être derrière le "Zeppelin" et non pas tout en bas si on veut une structure isomorphe à celle présentée en XML, d'où un autre avantage de XML contre "Lots of Irritating Single Parentheses" : la clarté (relative) ;).
          • [^] # Re: truc ou (machin truc) ?

            Posté par (page perso) . Évalué à 2.

            Sauf que les attributs en XML ne sont pas des arbres mais des chaines de caractères alors qu'en LISP, ce sont réellement des arbres !

            C'est marrant, les pro-XML ne voient jamais ce défaut. Or pour moi, c'est un défaut majeur du XML et je ne vois pas de solution correcte au problème.

            Ne me distes pas de mettre les attributs dans le corps de la balise, il y a une distinction entre les balises du corps et les attributs et les mélanger est rarement une bonne idée (mais un pis aller).
            • [^] # Re: truc ou (machin truc) ?

              Posté par . Évalué à 1.

              C'est marrant, les pro-XML ne voient jamais ce défaut. Or pour moi, c'est un défaut majeur du XML et je ne vois pas de solution correcte au problème.


              Ben, utiliser un parser... Le XML sert à exprimer une structure, la structure n'est structure que lorsqu'elle a été parsée avec un parser la reformulant en arbre.

              Ne me distes pas de mettre les attributs dans le corps de la balise, il y a une distinction entre les balises du corps et les attributs et les mélanger est rarement une bonne idée (mais un pis aller).

              On ne te le dira pas... on ne te parlera pas non-plus de formalisme et de méthodologie...
              • [^] # Re: truc ou (machin truc) ?

                Posté par (page perso) . Évalué à 0.

                > on ne te parlera pas non-plus de formalisme et de méthodologie...

                Des grand mots mais le problème reste présent ;-)

                Je sais bien qu'avec le XML, tu peux représenter n'importe quel arbre, il y a cependant la manière. Quoi que tu fasses et modélises, tes attributs restent et resteront des chaines de caractères.

                Il y a donc tout un tas de cas ou le XML est mal fichu...

                Pour ce qui est de la sérialisation, je lui préfère le YAML qui est plus léger et plus lisible. Quitte à avoir un programme qui lit et écrit mes données, autant faire simple.

                Par conte, il y a des cas ou il est vraiment pratique. Des cas seulement.
                • [^] # Re: truc ou (machin truc) ?

                  Posté par . Évalué à 2.

                  Quoi que tu fasses et modélises, tes attributs restent et resteront des chaines de caractères.
                  Les attributs sont des chaînes? Soit, mais tu n'es pas obligé d'utiliser des attributs... Tu peux tout aussi bien déclarer une structure complètement en arbre avec un typage fort. Le choix d'utiliser les attributs plutôt que de déclarer des éléments xml est une question de choix de modélisation, et peut être parfaitement justifiable dans certains cas.
                  Il y a donc tout un tas de cas ou le XML est mal fichu...
                  Disons qu'il offre une liberté peut-être superflue si on veut être puriste. Mais au final, un modèle mal fichu est surtout le fait de quelqu'un qui modélise mal. Il y a tout un tas de cas où le xml est la meilleure solution, à condition de savoir modéliser correctement les choses.
                  Pour ce qui est de la sérialisation, je lui préfère le YAML qui est plus léger et plus lisible.
                  Certes, mais avec le YAML, la modélisation d'objets complexes devient vite une catastrophe... quand à sa syntaxe, elle débarque d'un autre âge et n'offre pas la sécurité, ni la flexibilité, ni le typage du xml.
                  • [^] # Re: truc ou (machin truc) ?

                    Posté par (page perso) . Évalué à 4.

                    Le principe des attributs était plutôt bon en permettant de séparer la définition de l'objet de son contenu. Le fait que ceux-ci ne soient que des chaines fait que tu mets rapidement tout sous forme d'arbre et donc on perd un peu cette notion du contenu et du contenant qui était un plus.

                    Sinon, nous sommes d'accord, le XML est une bonne solution dans plein de cas mais pas dans tous. Par exemple, les fichiers de configuration de TomCat sont une horrreur... On a tendance à mettre du XML là ou il n'y en pas besoin.

                    Je suis plutôt dans le calcul numérique, là on oublie le XML et le HDF est bien plus performant ;-)

                    Quand au YAML, j'en ai parlé dans un cas spécifique, pas comme remplaçant du XML partout. Pour un fichier de configuration, il est par exemple parfait.

                    Je ne suis pas d'accord avec toi sur l'histoire de lâge. A chacun ses goùts et ses couleurs. Pour moi, c'est le XML qui est d'un autre âge car si c'est un langage pour la machine, un sosie du LISP pouvait faire cela mieux, un langage binaire portable du type HDF aussi ! Si c'est un langage pour l'homme, on ne peux pas dire que cela soit jouissif de se facir du XML dans un éditeur ou sur une page imprimée.

                    Bref, les concepts derrière le XML, tout l'environnement qui a été crée autour est effectivement passionnant mais le langage lui même est loin de me plaire.

                    Attention, lorsque je parle du XML, je parle toujours du langage ASCII, pas des API sur une structure d'arbre ou de graphe. Pour moi, ce sont deux choses bien distinctes. Ces API peuvent très bien être portés sur un autre langage.

                    A mon humble avis, les défenseurs du XML mélangent trop souvent ces API avec le langage XML lui même.

                    Je ne suis pas du tout un spécialiste du SQL et j'en fait très rarement. Mais lorsque tu vois une requête SQL, c'est quand même vachement esthétique comme langage. Le XML a coté, c'est quand même brut de fonderie.

                    Les langages de haut niveau sont quand même fait pour l'homme. Avec le XML, j'ai l'impression de refaire de l'assembleur. C'est amusant, un temps.
                    • [^] # Re: truc ou (machin truc) ?

                      Posté par . Évalué à 3.

                      Le fait que ceux-ci ne soient que des chaines fait que tu mets rapidement tout sous forme d'arbre et donc on perd un peu cette notion du contenu et du contenant qui était un plus.


                      Le véritable problème est de déterminer où commence l'objet et où se fini l'enveloppe de celui-ci. C'est un problème à traiter lors de la réalisation du modèle.

                      Sinon, en ce qui concerne l'élégance du XML, je suis totalement d'accord que ce langage soit loin d'être un premier prix de beauté, il y a vite moyen de s'y perdre. Mais si il n'est visuellement pas très agréable, il offre une excellente robustesse grâce à sa syntaxe. Il est possible de pousser très loin les contrôles de validation, ce qui est tout de même un plus extrèmement intéressant, et là on parle bien de la syntaxe du xml et non des librairies périphériques au comportement variable. La modularité offerte par les namespace est un atout formidable.

                      Je ne suis pas du tout un spécialiste du SQL et j'en fait très rarement. Mais lorsque tu vois une requête SQL, c'est quand même vachement esthétique comme langage. Le XML a coté, c'est quand même brut de fonderie.
                      si on veut rapprocher un système de base de données du xml, ce serait plutôt le ldap.

                      De même, il y a moyen de pondre facilement des usines à gaz en bases de données relationnelles.
                      • [^] # Re: truc ou (machin truc) ?

                        Posté par (page perso) . Évalué à 2.

                        Justement, les limitations du XML font que dans la question de l'objet et de l'enveloppe, les réponses sont partialles à ce niveau là. C'est dommage.

                        J'avais donné l'exemple du SQL mais celui du LDAP est aussi très bien. A la différence que LDAP est plus une API et qu'il n'y a pas vraiment de langage. Cependant, si je prends le LDIF, c'est aussi un arbre, très structuré avec des schémas de vérification... Bon, il n'y pas pas les namespace, c'est une erreur.

                        Enfin, il y en a qui n'aime pas les namespaces, j'ai essayé d'expliqué aux personnes qui développent Lisaac que c'était fondamental pour le succès du langage. /A priori/ sans succès...

                        Pour en revenir au LDIF, même si c'est bien lisible par l'homme, c'est clairement pas un langage fait pour tapper du texte.

                        Ton exemple sur le LDAP me parait effectivement très bien. Si les milliers de personnes qui ont bossé sur le XML avait bossé sur le LDAP, on aurait vraiment quelque chose de très bien. Pour avoir un modèle simple, on aurait un ldaplite à l'image de sqllite.
            • [^] # Re: truc ou (machin truc) ?

              Posté par . Évalué à 4.

              Les attributs d'une balise sont des chaînes si on utilise une définition par doctype (DTD).
              En revanche, avec l'utilisation des schémas XML (XSD), on peut utiliser un certain nombre de types de base, voire créer ses propres types.
              La recommandation du W3C concernant les types de données est disponible ici http://www.w3.org/TR/xmlschema-2/

              Alors oui, il s'agissait d'une limitation de XML conjointement à l'utilisation des DTDs. Mais maintenant, on a la possibilité de construire des modèles pour la validation qui sont beaucoup plus souples et permettant plus de contrôle. La recommandation sus-citée date de 2004, donc les analyseurs XML ne la respectant pas sont de plus en plus rares.

              Pour ceux qui ne voudraient pas lire la recommandation, voici le résumé
              XML Schema: Datatypes is part 2 of the specification of the XML Schema language. It defines facilities for defining datatypes to be used in XML Schemas as well as other XML specifications. The datatype language, which is itself represented in XML 1.0, provides a superset of the capabilities found in XML 1.0 document type definitions (DTDs) for specifying datatypes on elements and attributes.

              Traduction rapide : XML Schema: Datatypes [NdP : le titre de la recommandation] est la deuxième partie de la spécification du langage de schéma XML. Il définit des moyens pour déclarer des types utilisables dans les schémas XML ainsi que dans d'autres spécifications XML. Le langage des types, qui est lui-même déclaré en XML 1.0, propose une extension des possibilités trouvées dans les définitions de type XML 1.0 (DTDs) pour définir les types des éléments et des attributs.
          • [^] # Re: truc ou (machin truc) ?

            Posté par . Évalué à 1.

            Je recopie ci-dessous ton exemple corrigé (en dehors de la parenthèse, l'identation en lisp comme en xml enduisait avec de l'erreur).
            Et très honnêtement je ne vois pas du tout d'avantage à XML en terme de clarté.

            <groupe>
             <nom>Led Zeppelin</nom>
             <membres>
              <nom>Robert Plant</nom>
              <nom>Jimmy Page</nom>
              <nom>John Paul Jones</nom>
              <nom>John Bonham</nom>
             </membres>
            </groupe>

            et

            (groupe
             (nom "Led Zeppelin")
             (membres
              (nom "Robert Plant")
              (nom "Jimmy Page")
              (nom "John Paul )
              (nom "John Bonham")
             )
            )

            Le seul "avantage" que je lui vois est l'existence d'attributs, non représentables aisément en syntaxe lisp (mais comme je suis perplexe sur la façon de placer le curseur attribut/sous-entité de façon pertinente, je le sais pas si c'est un avantage).

            En revanche je vois plusieurs avantages aux parenthèses:
            - c'est moins hype ;-)
            - la forme ronde est moins agressive que le chevron pointu ;-)
            - c'est plus simple donc le parseur est plus simple (moins de bugs, moins de consommation de ressources)
            - l'absence de redite du nom de l'entité dans sa fermeture limite le risque d'erreur lors d'édition manuelle (le nombre de fois où on m'a filé un xml avec une coquille...)

            Cela dit, c'est un débat de tehchnicien ou d'esthète, car se battre contre un standard de fait ne fait pas souvent gagner de temps...
        • [^] # Re: truc ou (machin truc) ?

          Posté par . Évalué à 1.

          Vous remarquerez d'ailleurs que d'autres ont eu la même idée, pas avec Lisp mais avec Javascript, pour simplifier les échanges de données Ajax, en plus particulièrement leur exploitation côté client :

          "JSON (JavaScript Object Notation) est un format de structure de données générique. Il utilise la notation des objects JavaScript pour transmettre de l'information structurée.

          Exemple:

          {"menu": {
          "id": "file",
          "value": "File",
          "popup": {
          "menuitem": [
          {"value": "New", "onclick": "CreateNewDoc()"},
          {"value": "Open", "onclick": "OpenDoc()"},
          {"value": "Close", "onclick": "CloseDoc()"}
          ]
          }
          }}

          A titre de comparaison, même exemple en XML:

          <menu id="file" value="File">
          <popup>
          <menuitem value="New" onclick="CreateNewDoc()" />
          <menuitem value="Open" onclick="OpenDoc()" />
          <menuitem value="Close" onclick="CloseDoc()" />
          </popup>
          </menu>


          (tiré de http://fr.wikipedia.org/wiki/JSON )

          Voir aussi http://json.org pour les détails, et des bibliothèques pour parser les messages côté serveur, en Java, Python, C, C++, C#, E, Erlang, Haskell, Lisp (!), Perl, PHP, Rebol, Ruby, Squeak, Objectice C, Objective CAMEL, LUA, Lotusscript et Cold Fusion !!!
  • # une immondice infame

    Posté par (page perso) . Évalué à 1.

    XML est peut-être bien pour l'echange de données mais quand je vois des protocoles (upnp par exemple) et programmes l'utiliser en interne, alors là, je dis que c'est du délire.

    Rien ne vaut le binaire. Surtout dans l'embarqué.

    A+
    • [^] # Re: une immondice infame

      Posté par . Évalué à 0.

      J'ai voté immondice infâme aussi. Parmi les choses qu'on peut reprocher, voici une courte liste:
      * XML est trop verbeux, il prend trop de place (cf: JSON, YAML) - il y a aussi le binaire mais ce n'est pas forcément extensible, et puis on peut aussi zipper les données
      * XML est pas du tout évident à parser (namespaces, modes dom/sax, etc) ni à débogger - j'attends de voir un parser rapide et ayant toutes les fonctionnalités
      * Les dtds ne sont pas en XML

      Plus d'infos: http://xmlsucks.com
      • [^] # Re: une immondice infame

        Posté par . Évalué à 2.

        « XML est trop verbeux, il prend trop de place (cf: JSON, YAML) - il y a aussi le binaire mais ce n'est pas forcément extensible, et puis on peut aussi zipper les données »

        C'est le prix à payer pour quelque chose de totalement générique d'une part, et à peu près lisible pour un humain d'autre part. La représentation interne d'un fichier XML (en mémoire dans la machine) n'est que celle d'un arbre : beaucoup moins verbeux, donc.

        « Les dtds ne sont pas en XML »

        D'où la création des schémas XML, qui possèdent une sémantique plus forte que les DTD. Cependant, la DTD permet de définir très simplement les balises. Il est plus simple à mon avis d'écrire une DTD, de la transformer en schéma XML (via un outil qui automatise la tâche), et ensuite de compléter ledit schéma.

        Dans tous les cas, si tu veux spécifier du XML en XML, tu peux.
        • [^] # Re: une immondice infame

          Posté par . Évalué à 0.

          JSON est totalement générique aussi, et pourtant il est largement plus lisible pour un humain mais aussi pour des parseurs à écrire (pareil pour YAML).

          La représentation XML prend de la place, de la bande passante, et n'est certainement pas simple à débogger. Cela explique l'utilisation de JSON avec AJAX en particulier (appel de la fonction "eval" au lieu de responseXML pour obtenir un objet javascript).

          Si le format XML était si bien et si générique, alors pourquoi n'ont ils pas commencé par écrire les DTD dans ce format ?
          • [^] # Re: une immondice infame

            Posté par . Évalué à 3.

            « JSON est totalement générique aussi, et pourtant il est largement plus lisible pour un humain mais aussi pour des parseurs à écrire (pareil pour YAML). »

            Possible, je ne connais pas ces deux solutions.

            « La représentation XML prend de la place, de la bande passante, »
            Bof. Suffit de compresser le tout (et le XML, ça se compresse bien) avant d'envoyer.

            « Si le format XML était si bien et si générique, alors pourquoi n'ont ils pas commencé par écrire les DTD dans ce format ? »

            J'en sais rien. Le fait est qu'ils ont commencé par des DTD. La question en fait me semble totalement inutile : le langage C n'a pas su se compiler lui-même dès le départ, à ce que j'ai compris. Maintenant il sait. Est-ce vraiment pertinent de demander pourquoi XML n'a pas su se récrire en XML au début, alors que maintenant il sait ?
            • [^] # Re: une immondice infame

              Posté par (page perso) . Évalué à 1.

              Et le temps CPU pris pour générer une réponse en XML puis de la comprimer, c'est pas plus long que de simplement envoyer le binaire proprement?

              Essayez de faire du XML en environnement restreint. Vous m'en direz des nouvelles....


              PS: Pascal (et Delphi) ont toujours sus se compiler eux-même si je me souvient bien.
              • [^] # Re: une immondice infame

                Posté par . Évalué à 2.

                « Et le temps CPU pris pour générer une réponse en XML puis de la comprimer, c'est pas plus long que de simplement envoyer le binaire proprement? »

                Ton binaire, tu l'envoie en little ou big endian ? Il passe à l'échelle 32/64 bits ? (et je suis certain que tout un tas de questions supplémentaires pourraient me venir en tête).

                L'intérêt de XML c'est le côté plain-text des fichiers.

                « Essayez de faire du XML en environnement restreint. Vous m'en direz des nouvelles.... »

                Qu'est-ce que tu appelles environnement restreint ? (de façon générale, je ne suis pas pour le tout-XML, mais les attaques que j'ai vu contre le format n'étaient pas justifiées, de mon point de vue).

                « PS: Pascal (et Delphi) ont toujours sus se compiler eux-même si je me souvient bien. »

                Tant mieux pour eux. Ce n'était absolument pas le but de ma remarque. LISP aussi sait se compiler lui-même, je ne vois pas en quoi ça change le fait que XML sait se définir en XML, lui aussi. Même s'il est passé par une phase avec DTD qui n'était pas du XML (et à la limite on s'en fout un peu non ? L'important c'est que ton format de stockage soit défini).
                • [^] # Re: une immondice infame

                  Posté par . Évalué à 2.

                  Ton binaire, tu l'envoie en little ou big endian ?

                  Sachant que tu as prévu que ton binaire soit envoyé par le réseau, tu utilise bien entendu le network byte order...
                  A vrai dire y a peu prés qu'une archi qui fait des siennes ...

                  L'intérêt de XML c'est le côté plain-text des fichiers.

                  C'est intéressant dans certains cas, mais certainement pas dans une discussions soft à soft.
                  (je rapelle le post initial de la discussion : quand je vois des [...] programmes l'utiliser en interne )

                  Qu'est-ce que tu appelles environnement restreint ?

                  Sans doute embarqué toussa je présume.
            • [^] # Re: une immondice infame

              Posté par . Évalué à 0.

              Formulé autrement: XML c'est génial, tant que l'on ne connaît rien d'autre (surtout JSON et surtout YAML).

              La question sur les DTD montre à quel point le format (il ne s'agit pas d'un language de programmation) est lisible et pratique à utiliser rien que pour le cas d'utilisation le plus basique.
              • [^] # Re: une immondice infame

                Posté par . Évalué à 2.

                « Formulé autrement: XML c'est génial, tant que l'on ne connaît rien d'autre (surtout JSON et surtout YAML). »

                Non. D'après le site :

                « YAML is optimized for data serialization, configuration settings, log files, Internet messaging and filtering. »

                Exactement le genre de choses où je n'utiliserais pas XML (utiliser XML pour faire des fichiers ce configuration est quelque chose de totalement débile la plupart du temps, sauf pour certains logiciels-usines à gaz, et encore).

                Pour JSON, on faisait remarquer plus haut que des problèmes de performances pouvaient survenir. Quid de la machine virtuelle JavaScript qui doit tourner ?

                « La question sur les DTD montre à quel point le format (il ne s'agit pas d'un language de programmation) est lisible et pratique à utiliser rien que pour le cas d'utilisation le plus basique. »

                Je ne vois pas en quoi. Honnêtement, ça ne me dérange absolument pas d'utiliser une DTD tant que la description des données reste simple. Ce que les gens oublient, c'est que XML a été inventé pour être « human readable », mais pas dans une optique « je me farcis tout le texte avec les yeux, tout le temps ». On a tout de suite pensé le format pour qu'il puisse être traité automatiquement par des machines, mais modifiable quand même à la main par des humains, si besoin était.
                • [^] # Re: une immondice infame

                  Posté par . Évalué à 0.

                  >> « Formulé autrement: XML c'est génial, tant que l'on ne connaît rien d'autre (surtout JSON et surtout YAML). »
                  >
                  > Non. D'après le site :
                  >
                  >> « YAML is optimized for data serialization, configuration settings, log files, Internet messaging and filtering. »
                  >
                  > Exactement le genre de choses où je n'utiliserais pas XML (utiliser XML pour faire des fichiers ce configuration est quelque chose de totalement débile la plupart du temps, sauf pour certains logiciels-usines à gaz, et encore).

                  Donc tu n'utilises pas xml ni pour la sérialisation des données, ni pour les fichiers de configuration, ni pour les fichiers log, ni pour les transferts de données. Tu l'utilises pourquoi déjà ?

                  > Pour JSON, on faisait remarquer plus haut que des problèmes de performances pouvaient survenir. Quid de la machine virtuelle JavaScript qui doit tourner ?

                  C'est quoi cette "machine virtuelle JavaScript" ?

                  >> « La question sur les DTD montre à quel point le format (il ne s'agit pas d'un language de programmation) est lisible et pratique à utiliser rien que pour le cas d'utilisation le plus basique. »
                  >
                  > Je ne vois pas en quoi. Honnêtement, ça ne me dérange absolument pas d'utiliser une DTD tant que la description des données reste simple. Ce que les gens oublient, c'est que XML a été inventé pour être « human readable », mais pas dans une optique « je me farcis tout le texte avec les yeux, tout le temps ». On a tout de suite pensé le format pour qu'il puisse être traité automatiquement par des machines, mais modifiable quand même à la main par des humains, si besoin était.

                  On est donc bien d'accord, XML n'est pas lisible ni pratique d'utilisation.
                  • [^] # Re: une immondice infame

                    Posté par . Évalué à 3.

                    Reprenons.

                    « YAML is optimized for data serialization, configuration settings, log files, Internet messaging and filtering. »

                    Je me suis mal exprimé (j'ai tapé trop vite).

                    Tu me demandais : « Donc tu n'utilises pas xml ni pour la sérialisation des données, ni pour les fichiers de configuration, ni pour les fichiers log, ni pour les transferts de données. Tu l'utilises pourquoi déjà ? »

                    Je ne l'utilise pas pour faire des fichiers de configuration. La sérialisation, oui ; les fichiers de logs je n'ai jamais eu à en faire en XML, et les transferts de données, évidemment.

                    « C'est quoi cette "machine virtuelle JavaScript" ? »
                    Je ne savais pas que JavaScript était compilé est s'exécutait sans aide.

                    J'expliquais ensuite que « human readable » != « humans will like to read it » (en gros). Tu répondais :

                    « On est donc bien d'accord, XML n'est pas lisible ni pratique d'utilisation. »

                    Je passe outre le ton ironique. Le XML est effectivement fait pour être techniquement lisible par l'oeil humain.

                    J'aimerais que tu m'expliques comment tu fais pour avoir des données lisibles par un humain (autrement que du côté technique que j'ai évoqué précédemment) dans un format texte, lorsque tes données sont décrites de façon extrêmement complexe. Au final, si tu as 1To de données, XML ou YAML ou ... je ne vois pas trop ce que ça change dès que le volume généré est important.

                    Quel que soit le type de données semi-structurées que tu emploies (latex, XML, YAML, etc), tu te retrouves avec une hiérarchie (donc au minimum des arbres - bien que dans le cas du XML tu puisses faire des graphes si tu as besoin de cas tordus),

                    XML = arbre typé ordonné. C'est tout. Il se trouve que la syntaxe choisie pour XML (balises ouvrantes/fermantes, etc), l'a été pour permettre une bonne automatisation des traitements. Certains trouvent que justement ça l'empêche. Personnellement je ne vois pas en quoi, mais je peux concevoir que ça gêne. Mais on oublie souvent qu'avant XML, des dizaines de formats semi-structurés existaient, mais qu'aucun n'était utilisé partout. XML, c'est le résultat d'une standardisation, avec de gros acteurs industriels qui ont enfin daigné s'asseoir à la même table. Donc non, c'est pas parfait, mais au moins, c'est un format sur lequel des gens bossent (autant les chercheurs que les industriels pur sucre).
                    • [^] # Re: une immondice infame

                      Posté par . Évalué à 0.

                      > Reprenons.
                      >
                      > « YAML is optimized for data serialization, configuration settings, log files, Internet messaging and filtering. »
                      >
                      > Je me suis mal exprimé (j'ai tapé trop vite).
                      >
                      > Tu me demandais : « Donc tu n'utilises pas xml ni pour la sérialisation des > données, ni pour les fichiers de configuration, ni pour les fichiers log, ni pour les transferts de données. Tu l'utilises pourquoi déjà ? »
                      >
                      > Je ne l'utilise pas pour faire des fichiers de configuration. La sérialisation, oui ; les fichiers de logs je n'ai jamais eu à en faire en XML, et les transferts de données, évidemment.

                      Et qu'est-ce que tu as utilisé d'autre que xml pour pouvoir comparer ?

                      > « C'est quoi cette "machine virtuelle JavaScript" ? »
                      > Je ne savais pas que JavaScript était compilé est s'exécutait sans aide.

                      Je ne savais pas que JavaScript avait besoin d'une machine virtuelle ?

                      > J'expliquais ensuite que « human readable » != « humans will like to read it » (en gros). Tu répondais :
                      >
                      > « On est donc bien d'accord, XML n'est pas lisible ni pratique d'utilisation. »
                      >
                      > Je passe outre le ton ironique. Le XML est effectivement fait pour être techniquement lisible par l'oeil humain.

                      L'usage montre que non: sinon on écrirait les DTD dedans sans problème.

                      > J'aimerais que tu m'expliques comment tu fais pour avoir des données lisibles par un humain (autrement que du côté technique que j'ai évoqué précédemment) dans un format texte, lorsque tes données sont décrites de façon extrêmement complexe. Au final, si tu as 1To de données, XML ou YAML ou ... je ne vois pas trop ce que ça change dès que le volume généré est important.

                      Si justement, ça change énormémént. Les balises énormément de bruit et alourdissent les transferts de données. La meilleure façon de compresser des données, c'est avant tout de ne pas y ajouter du bruit. Ensuite cela alourdit le déboggage des données elles-même.

                      > Quel que soit le type de données semi-structurées que tu emploies (latex, XML, YAML, etc), tu te retrouves avec une hiérarchie (donc au minimum des arbres - bien que dans le cas du XML tu puisses faire des graphes si tu as besoin de cas tordus),
                      >
                      > XML = arbre typé ordonné. C'est tout. Il se trouve que la syntaxe choisie pour XML (balises ouvrantes/fermantes, etc), l'a été pour permettre une bonne automatisation des traitements. Certains trouvent que justement ça l'empêche. Personnellement je ne vois pas en quoi, mais je peux concevoir que ça gêne. Mais on oublie souvent qu'avant XML, des dizaines de formats semi-structurés existaient, mais qu'aucun n'était utilisé partout. XML, c'est le résultat d'une standardisation, avec de gros acteurs industriels qui ont enfin daigné s'asseoir à la même table. Donc non, c'est pas parfait, mais au moins, c'est un format sur lequel des gens bossent (autant les chercheurs que les industriels pur sucre).

                      C'est pas parce que c'est utilisé par tout le monde ou standardisé de fait/historiquement que c'est ce qu'il y a de meilleur. Les produits microsoft dominent le marché, je te laisse conclure.
                      • [^] # Re: une immondice infame

                        Posté par . Évalué à 2.

                        [utilisations de XML]
                        « Et qu'est-ce que tu as utilisé d'autre que xml pour pouvoir comparer ? »

                        Java. :-) Plus sérieusement, j'ai utilisé ce que proposaient des langages compilés pour faire tout ce dont il est question, et XML, point. Je l'ai dit dès le départ, je ne connaissais pas YAML et JSON avant qu'on n'en parle ici. Je ne dis pas que XML est la panacée (en fait, je dis exactement le contraire dans le message auquel tu réponds), juste qu'effectivement pour l'échange de données, ainsi que la sérialisation, XML se prêtait bien à la chose (ah oui, et le stockage BDD aussi).

                        « Je ne savais pas que JavaScript avait besoin d'une machine virtuelle ? »
                        Mauvais terme de ma part. Un interpréteur.

                        « Si justement, ça change énormémént. Les balises énormément de bruit et alourdissent les transferts de données. »
                        Les balises sont redondantes, donc si compression il y a, et donc je ne vois pas en quoi ça alourdirait le transfert de données.

                        « La meilleure façon de compresser des données, c'est avant tout de ne pas y ajouter du bruit. Ensuite cela alourdit le déboggage des données elles-même. »

                        De toute manière, dès que tu as un format de données flexible et générique, tu es obligé de gagner en verbosité, XML ou pas XML. Les softs que je vois traiter de gros volumes XML utilisent leur propre représentation interne des arbres XML, et donc tout se fait en binaire. Le côté « chiant » d'XML c'est le parsing, je suis d'accord - ce qui se traduit aussi par les problèmes de transfert que tu évoques. Mais honnêtement, aussi fastidieux cela soit-il, le fait d'avoir le côté ouvrant/fermant permet justement d'être systématique dans le traitement de l'information (et de faire la validation, etc).

                        « C'est pas parce que c'est utilisé par tout le monde ou standardisé de fait/historiquement que c'est ce qu'il y a de meilleur. Les produits microsoft dominent le marché, je te laisse conclure. »

                        Je ne peux pas accepter cet exemple, car MS est tout seul à imposer sa vision, alors que pour XML, tu as un collège d'industriels et de chercheurs. Alors oui, ça veut aussi dire qu'on n'obtient pas une forme optimale (chaque participant veut insérer à tout prix SA fonctionnalité de la mort, et pour des raisons « politiques » on laisse faire - ou pas). Mais ça veut aussi dire que pas mal de paramètres sont pris en compte et que l'évolution ne se fait pas à la va-vite.

                        Pour le côté « standardisé de fait » : c'est justement parce qu'aucun standard n'avait su s'imposer qu'il était temps de faire quelque chose. Le C est un standard de fait dans l'industrie. Java aussi. Pourtant, le C se prête de moins en moins à la programmation généraliste je trouve (l'utilisation de langages de plus haut niveau permet de faire moins d'erreurs de programmation, avec un temps de développement plus réduit), et le Java à toutes les sauces est une aberration informatique.

                        De façon générale, je ne sais pas depuis quand YAML et JSON existent, mais au pifomètre je dirais « ils sont plus jeunes que XML ». Et quand une structure adopte un changement déjà assez radical en lui-même, tu ne peux pas t'attendre à ce qu'elle change du jour au lendemain (un peu comme la boite qui est pleine de développeurs C et qui ne va pas se mettre au CAML du jour au lendemain). Il faut aussi gérer l'inertie, et crier « XML SAPU » tout en oubliant que, comme tout format, d'autres lui succèdent en tirant partie de ses erreurs (alors que, comme quelqu'un l'a fait judicieusement remarquer, XML a aussi un lourd passif avec SGML), c'est un peu facile.
                        • [^] # Re: une immondice infame

                          Posté par . Évalué à 1.

                          > « Si justement, ça change énormémént. Les balises énormément de bruit et alourdissent les transferts de données. »
                          > Les balises sont redondantes, donc si compression il y a, et donc je ne vois pas en quoi ça alourdirait le transfert de données.

                          Il faut vraiment faire un dessin ?

                          Entre un gros camion et une voiture pour transporter le même chargement, tu prends le gros camion ou la petite voiture ?

                          Si on te donne un autre format de stockage, et qui te fait pareil que ce que tu utilises habituellement (Castor probablement?) mais en plus rapide, plus petit et plus facile à lire, tu l'utiliserais pas ? Ou bien tu veux faire acheter plus de matos à ta boîte ?

                          > « La meilleure façon de compresser des données, c'est avant tout de ne pas y ajouter du bruit. Ensuite cela alourdit le déboggage des données elles-même. »
                          >
                          > De toute manière, dès que tu as un format de données flexible et générique, tu es obligé de gagner en verbosité, XML ou pas XML.

                          Tautologie ? Si tu as des données compliquées elles sont forcément compliquées ?

                          > Les softs que je vois traiter de gros volumes XML utilisent leur propre représentation interne des arbres XML, et donc tout se fait en binaire. Le côté « chiant » d'XML c'est le parsing, je suis d'accord - ce qui se traduit aussi par les problèmes de transfert que tu évoques. Mais honnêtement, aussi fastidieux cela soit-il, le fait d'avoir le côté ouvrant/fermant permet justement d'être systématique dans le traitement de l'information (et de faire la validation, etc).

                          Il n'y a pas confusion entre le format de stockage et l'utilisation que l'on fait des données ?

                          > « C'est pas parce que c'est utilisé par tout le monde ou standardisé de fait/historiquement que c'est ce qu'il y a de meilleur. Les produits microsoft dominent le marché, je te laisse conclure. »
                          >
                          > Je ne peux pas accepter cet exemple, car MS est tout seul à imposer sa vision, alors que pour XML, tu as un collège d'industriels et de chercheurs. Alors oui, ça veut aussi dire qu'on n'obtient pas une forme optimale (chaque participant veut insérer à tout prix SA fonctionnalité de la mort, et pour des raisons « politiques » on laisse faire - ou pas). Mais ça veut aussi dire que pas mal de paramètres sont pris en compte et que l'évolution ne se fait pas à la va-vite.
                          >
                          > Pour le côté « standardisé de fait » : c'est justement parce qu'aucun standard n'avait su s'imposer qu'il était temps de faire quelque chose. Le C est un standard de fait dans l'industrie. Java aussi. Pourtant, le C se prête de moins en moins à la programmation généraliste je trouve (l'utilisation de langages de plus haut niveau permet de faire moins d'erreurs de programmation, avec un temps de développement plus réduit), et le Java à toutes les sauces est une aberration informatique.
                          >
                          > De façon générale, je ne sais pas depuis quand YAML et JSON existent, mais au pifomètre je dirais « ils sont plus jeunes que XML ». Et quand une structure adopte un changement déjà assez radical en lui-même, tu ne peux pas t'attendre à ce qu'elle change du jour au lendemain (un peu comme la boite qui est pleine de développeurs C et qui ne va pas se mettre au CAML du jour au lendemain). Il faut aussi gérer l'inertie, et crier « XML SAPU » tout en oubliant que, comme tout format, d'autres lui succèdent en tirant partie de ses erreurs (alors que, comme quelqu'un l'a fait judicieusement remarquer, XML a aussi un lourd passif avec SGML), c'est un peu facile.

                          Le pifomètre ne s'est pas trompé cette fois-ci, mais malheureusement les tables de hachage, les listes et Lisp ont existé bien avant XML.

                          La maitrise d'un outil, c'est aussi d'en connaître les limites. Aujourd'hui, grâce aux comités qui sortent des standards tous les jours (des chercheurs en informatique amusante), on a besoin d'au moins 5 languages pour faire des simples pages web (sql, java/python/php/langage métier, html/xml, css, javascript), avec une incapacité à faire rapide, peu gourmand en mémoire machine et facile à débogger/analyser.

                          Les intégristes d'aujourd'hui sont les pionniers d'hier.
                          • [^] # Re: une immondice infame

                            Posté par . Évalué à 2.

                            Bon, je ne réponds qu'à la fin de ton post, ce qui précède n'étant pas argumenté correctement (analogie pas pertinentes, entre autres).

                            « Le pifomètre ne s'est pas trompé cette fois-ci, mais malheureusement les tables de hachage, les listes et Lisp ont existé bien avant XML. »

                            Le rapport avec XML ? Ce sont des structures de données dont tu parles, moi je parle d'un format de stockage, semi-structuré - et donc par définition hiérarchique, auquel la structuration en arbre pour symboliser ladite hiérarchie [des types entre autres] convient bien.


                            « [...] on a besoin d'au moins 5 languages pour faire des simples pages web (sql, java/python/php/langage métier, html/xml, css, javascript), »

                            Voyons un peu. HTML/XML sont là pour le contenu, CSS/XSL pour le rendu (et n'oublions pas que XSLT et XQuery vont quand même plus loin que ça, et permettent de générer tout un tas d'autres sorties), JavaScript pour le côté dynamique côté client, et SQL pour les bases de données.

                            Je ne dis pas que c'est génial, mais j'aimerais que tu m'expliques comment tu comptes simplifier le tout. Le langage généraliste qui fait tout est à exclure, car alors ce serait une usine à gaz monstrueuse (il n'y a qu'à voir les JSP au début - et même maintenant c'est pas joli à voir, malgré les simplifications et le rajout des tags). Il se trouve qu'une base de donnée n'est pas uniquement utilisée par des applications orientées Web, il leur faut donc un langage standardisé pour pouvoir être utilisées (tiens, ce serait assez drôle d'ailleurs de faire remarquer que chaque SGBD/R n'implémente pas tout des normes SQL...).

                            D'ailleurs, des solutions comme Hibernate pour Java sont plutôt intéressantes, car justement on peut éviter un maximum le côté SQL des SGBD et passer par la correspondance Relationnel/Modèle Objet.

                            Donc pour faire bref :
                            1/ À moins de faire une base de données spécialisée Web, les langages de type SQL/XQuery vont rester un bout de temps (et même en ayant une on duplique inutilement les efforts, du coup)
                            2/ Le langage spécialisé est obligatoire pour faire l'interfaçage front-end/back-end (ou alors tu réussis je ne sais comment à tout faire passer en XML/HTML/XSLT, beurk)
                            3/ Il te faut bien un moyen de décrire le contenu et le mettre en forme (HTML,XML/CSS,XSL)
                            4/ Le seul truc éventuellement serait de réussir à fusionner HTML et JS, car effectivement, au final, tout se fait côté client (d'un autre côté, on peut utiliser Javascript à part, et mélanger la description des données avec leur traitement dynamique, bof...)

                            L'incapacité à faire rapide/peu gourmand/etc vient du fait que le développement spécifique à une plate-forme coûte cher en temps et en expertise, d'autant plus qu'on parle d'outils de haut niveau, extrêmement complexes. Le problème c'est qu'une bonne conception nécessite de bien séparer les modules, et du coup on perd au moins le temps de communiquer entre ceux-ci.

                            Je te rejoins sur le côté debogage : on est encore à la préhistoire de ce qui pourrait s'envisager, quelle que soit la plate-forme envisagée (et pas seulement pour du Web, même si c'est là que ça pêche le plus).
                            • [^] # Re: une immondice infame

                              Posté par . Évalué à 1.

                              > Le rapport avec XML ? Ce sont des structures de données dont tu parles, moi je parle d'un format de stockage, semi-structuré - et donc par définition hiérarchique, auquel la structuration en arbre pour symboliser ladite hiérarchie [des types entre autres] convient bien.

                              Représenter des données sous forme d'un arbre Lisp, sous forme de tables de hachages (python cpickle) ou sous forme d'une structure javascript revient exactement à la même chose, et les données sont extensibles de la même manière (changement de structure). Pourquoi tant tenir à ajouter des balises ?

                              > Donc pour faire bref :

                              J'aimerais en revenir aux cas d'utilisation les plus courants du web:
                              * transférer des données de façon sécurisée
                              * transférer des données de façon efficace (éviter d'ajouter du bruit)
                              * permettre de débogger rapidement et facilement
                              * échanger des données entre un client et un ou des serveurs
                              * apporter de la cohérence dans les outils utilisés
                              La complexité du développement web est aujourd'hui telle que l'on ne peut même pas disposer d'outils d'analyse automatique des erreurs. Quand on voit le résultat, eh bien oui, on est en droit de se poser des questions.

                              Imaginons un web entièrement en Lisp : sql s'apparente fortement à Lisp, JavaScript aussi, le stockage des données et des feuilles de style peut se faire aussi très facilement sous forme d'une structure Lisp (voir commentaires du dessus) - on peut tout à fait garder la même modularité sous une forme plus facilement utilisables à la fois pour les machines et les programmeurs.

                              Ce web aurait été effectivement bien plus léger et efficace (Lisp ayant été inventé il y a très longtemps). D'autres langages tels que Python, Ruby ou même une variante fortement typée sont envisageables aussi. C'est d'ailleurs la forme que prend JSON : des tables de hachage très faciles à parser et à analyser. Il était donc possible de faire largement plus simple, et en se basant sur des technologies extrêmement anciennes.

                              Mais je comprends, quand on ne connaît rien d'autre que XML et que l'on n'a aucune notion des languages passés tels que Lisp il est difficile d'avoir de l'imagination et surtout d'avoir le moindre regard critique pour les outils que l'on utilise.
                              • [^] # Re: une immondice infame

                                Posté par . Évalué à 2.

                                « Mais je comprends, quand on ne connaît rien d'autre que XML et que l'on n'a aucune notion des languages passés tels que Lisp il est difficile d'avoir de l'imagination et surtout d'avoir le moindre regard critique pour les outils que l'on utilise. »

                                Et sur ces bonnes paroles, où tu ne fais qu'être aggressif, et parler pour ne rien dire, je te laisse le dernier mot.
                              • [^] # Re: une immondice infame

                                Posté par . Évalué à 2.


                                La complexité du développement web est aujourd'hui telle que l'on ne peut même pas disposer d'outils d'analyse automatique des erreurs. Quand on voit le résultat, eh bien oui, on est en droit de se poser des questions.



                                T'as raison, ça doit être la faute des balises :)
          • [^] # Re: une immondice infame

            Posté par (page perso) . Évalué à 3.

            L'argument de la DTD est un peu foireux... Plus exactement, XML est issu de SGML, comme HTML et les DTDs datent aussi de cette époque là, soit avant le tout XML. Et puis ça fait un bout de temps qu'on peut décrire du XML en XML, inutile de faire les ignorants avec des « gnagna les DTDs »...

            Personnellement, le tout XML me gonfle et je trouve la syntaxe lourde à souhait (merci toutes les balises fermantes qui reprennent le nom de l'ouvrante, c'est profondément inutile puisque l'overlapping est interdit).

            Après XML, ça marche et pas mal de gens et de machines le comprennent ou peuvent l'apprendre vite.
        • [^] # Re: une immondice infame

          Posté par (page perso) . Évalué à 1.

          On peut aussi faire quelque chose de totalement générique en binaire. Une fois que les types de base sont bien définis, tout est possible.

          De plus, la lisibilité par un humain ne me parais pas primordiale. Des outils de traductions binaire<->humain permettent une mise en forme humaine bcp plus lisible que du XML et le programme continue de travailler avec des données binaires optimisées pour son architecture.

          Je trouve les schemas XML complètement illisible. Pire que la notation ASN.1.
          • [^] # Re: une immondice infame

            Posté par (page perso) . Évalué à 0.

            Je suis d'accord pour la lisibilité. Dès qu'un document devient un petit peu compliqué, avec une forte granularité (en utilisant une DTD comme TEI par exemple, ou encore du RDF, ou les document généré par OpenOffice, ou un XSL un peu compliqué), le document devient illisible par l'humain qui a besoin d'un outil sérieux pour se retrouver dedans.

            On se retrouve donc avec un document long à traiter de toute façon.
  • # le stade ultime de l'évolution des langages informatiques :)

    Posté par (page perso) . Évalué à 4.

    • [^] # Re: le stade ultime de l'évolution des langages informatiques :)

      Posté par (page perso) . Évalué à 5.

      Pour entrer plus précisément dans le troll, le seul réel avantage de XML c'est que ça évite d'avoir à se souvenir des cours de théorie des langage que tout ingé devrait recevoir pendant sa formation...

      - ça définit une syntaxe, mais elle est verbeuse (pratique ni pour les humains, on fait plus lisible, ni pour les machines, on fait plus compact)
      - ça définit pas de sémantique (un arbre DOM n'est qu'un arbre abstrait, pas un modèle des objets métier)
      - on peut valider contre une DTD, mais bon un parser maison ça valide tout aussi bien voire mieux puisqu'on connait la sémantique
      - la structure est arborescente et pour pouvoir représenter des graphes, ce qui est quand même souvent utile, il y a 12000 possibilités différentes
      - pourquoi différencier attributs et le contenu des éléments ?
      - on peut transformer avec xslt... vous avez déjà essayé de maintenir du code xslt ? sérieusement ?

      ...
      • [^] # Re: le stade ultime de l'évolution des langages informatiques :)

        Posté par . Évalué à 1.

        - pourquoi différencier attributs et le contenu des éléments ?

        Je suis d'accord a 100% avec ca et je rajouterais comment une balise non leaf peut elle contenir d'autres balises plus du contenu. Ca a compliqué puissance 1000 le parseur dom generique.

        Exemple

        <a>le <b l="ffkldf">lfkdjflk</b>fklsjdlkfjd </a>

        Voici les même données en enlevant les contenus des balises non leaf et en créant une balise destinée a cet effet. En interdisant les attributs.

        <a>
        <t>le </t>
        <b>
        <l>ffkldf</l>
        <t>lfkdjflk</t>
        </b>
        <t>fklsjdlkfjd </t>
        </a>

        Le parseur necessaire pour cela est bcp plus simple a utiliser et seul trois methodes (getchildren isleaf getvalue)sont necessaires au lieu de la quinzaine ou plus existantes pour la version full.

        voila comment des milliers de programmeurs se refont un sous ensemble d'XML pour pouvoir l'utiliser de facon conviviale.
      • [^] # Re: le stade ultime de l'évolution des langages informatiques :)

        Posté par . Évalué à 2.

        [[- on peut transformer avec xslt... vous avez déjà essayé de maintenir du code xslt ? sérieusement ?]]

        J'ai a le faire de temps à autre et je ne dirais qu'une chose: XSLT SUCKS!!!!
        A coté, le Perl est un langage super lisible..
        Je n'aime pas le Perl, mais je déteste XSLT.

        Je pense que tout ceux qui pensent qu'XML est une bonne techno devraient débugger un script XSLT qui ne fait pas ce qu'il faut: après on leur redemande leur avis sur XML..
  • # L'important, c'est le choix

    Posté par . Évalué à 1.

    Dire que XML est infame ou est super n'a pas vraiment de sens à mon avis.
    L'important c'est l'utilisation que l'on veux en faire.

    J'avoue que j'ai beaucoup de mal à savoir quand utiliser XML.

    Par exemple, je me vois mal utiliser XML pour des fichiers de configuration. Je ne vois pas apache utiliser un format XML par exemple.
    Je préfererai utiler YAML qui est 'User friendly'. Plus facile à lire avec mes yeux je trouve.

    Utiliser XML avec AJAX ? j'ai du mal aussi. Je trouve JSON interessant dans le simple fait que je n'ai pas besoin de faire des boucles et de parcourir un arbre.

    L'interet d'XML est à mon avis sa capacité a pouvoir être utilisé avec "n'impote quoi" :
    - mon application web peut utiliser le même XML que mon application écrite en C, et mon autre écrite en Perl.
    - l'apparation des micro-formats ;
    - et peut etre d'autres, je n'utilise pas assez XML.

    Bref, il faut faire le bon choix en fonction de ses besoins

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.