-
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
# n00b xml
Posté par Dabowl_92 . Évalué à 3.
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 blackhawk . Évalué à 3.
[^] # Re: n00b xml
Posté par gc (site web personnel) . Évalué à 5.
[^] # Re: n00b xml
Posté par account . Évalué à 2.
[^] # Re: n00b xml
Posté par Anonyme . Évalué à 9.
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 ome . Évalué à 2.
[^] # Re: n00b xml
Posté par smc . Évalué à 6.
- 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 arnaudus . Évalué à 3.
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 rewind (Mastodon) . Évalué à 3.
http://www.w3.org/TR/xinclude/
[^] # Re: n00b xml
Posté par Mildred (site web personnel) . Évalué à 2.
[^] # Re: n00b xml
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
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 pasPierre pasTramo . Évalué à 5.
Comme par exemple des gens qui s'en servent comme une BDD.
[^] # Re: Ne vous perdez pas en route!
Posté par tao popus . Évalué à 4.
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 kowalsky . Évalué à 3.
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 ragoutoutou . Évalué à 3.
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 Sytoka Modon (site web personnel) . Évalué à 3.
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 ragoutoutou . Évalué à 2.
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 Sytoka Modon (site web personnel) . Évalué à 3.
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 kowalsky . Évalué à 2.
Je signe tout de suite...!
[^] # Re: Ne vous perdez pas en route!
Posté par ragoutoutou . Évalué à 2.
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) ...
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.
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 David (site web personnel) . Évalué à 1.
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 Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1.
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 David (site web personnel) . Évalué à 1.
[^] # Re: Ne vous perdez pas en route!
Posté par Arthur Accroc . Évalué à 3.
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 =...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Ne vous perdez pas en route!
Posté par lasher . Évalué à 2.
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 DerekSagan . Évalué à 7.
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 Infernal Quack (site web personnel) . Évalué à 10.
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 ragoutoutou . Évalué à 2.
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.
[^] # Re: AJAX = ....
Posté par ragoutoutou . Évalué à 3.
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.
[^] # Re: AJAX = ....
Posté par nwrk2 . Évalué à 1.
[^] # Re: AJAX = ....
Posté par ragoutoutou . Évalué à 2.
et puis question buzzword, au boulot j'entends plus souvent "webservices" et "soap" qu' "ajax".
# truc ou (machin truc) ?
Posté par Jiba (site web personnel) . Évalué à 2.
[^] # Re: truc ou (machin truc) ?
Posté par ragoutoutou . Évalué à 3.
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 smc . Évalué à 3.
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 smc . Évalué à 3.
[^] # Re: truc ou (machin truc) ?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
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 ragoutoutou . Évalué à 1.
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.
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 Sytoka Modon (site web personnel) . Évalué à 0.
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 ragoutoutou . Évalué à 2.
[^] # Re: truc ou (machin truc) ?
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
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 ragoutoutou . Évalué à 3.
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.
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 Sytoka Modon (site web personnel) . Évalué à 2.
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 François B. . Évalué à 4.
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é
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 DerekSagan . Évalué à 1.
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 Franck Routier (Mastodon) . Évalué à 1.
"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:
(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 !!!
[^] # Re: truc ou (machin truc) ?
Posté par Hank Lords . Évalué à 1.
# une immondice infame
Posté par David (site web personnel) . Évalué à 1.
Rien ne vaut le binaire. Surtout dans l'embarqué.
A+
[^] # Re: une immondice infame
Posté par . . . Évalué à 0.
* 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 lasher . Évalué à 2.
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.
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 lasher . Évalué à 3.
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 David (site web personnel) . Évalué à 1.
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 lasher . Évalué à 2.
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 briaeros007 . Évalué à 2.
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 ...
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 )
Sans doute embarqué toussa je présume.
[^] # Re: une immondice infame
Posté par . . . Évalué à 0.
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 lasher . Évalué à 2.
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.
>
> 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 lasher . Évalué à 3.
« 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.
>
> « 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 lasher . Évalué à 2.
« 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.
> 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 lasher . Évalué à 2.
« 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.
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 lasher . Évalué à 2.
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 Thomas Douillard . Évalué à 2.
T'as raison, ça doit être la faute des balises :)
[^] # Re: une immondice infame
Posté par Nicolas Legrand (site web personnel) . Évalué à 3.
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 David (site web personnel) . Évalué à 1.
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 Nicolas Legrand (site web personnel) . Évalué à 0.
On se retrouve donc avec un document long à traiter de toute façon.
# le stade ultime de l'évolution des langages informatiques :)
Posté par Damien (site web personnel) . Évalué à 4.
[^] # Re: le stade ultime de l'évolution des langages informatiques :)
Posté par Damien (site web personnel) . Évalué à 5.
- ç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 Bungee Tux . Évalué à 1.
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 reno . Évalué à 2.
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 Joffrey . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.