XML fête ses 15 ans

[alex_vino]

Envoyé par Reward

XDocument ou bien alors une recherche rapide sur un XML très volumineux.

Le XML n'est pas tres adapté aux fichiers tres volumineux tout de meme. Pour avoir été confronté a ce probleme dans l'un de mes projets j'ai du remettre en question l'utilisation de XML. Il n'y a qu'a ouvrir ces fichiers dans le navigateur pour se rendre compte que la vitesse décroit rapidemenet avec la taille (et au-dela d'une certaine limite seul Internet Explorer arrive encore a ouvrir le fichier tandis que tous les autres navigateurs "crasheront").
Dans ton cas tu utilises la sérialisation dans si tu confronte ce meme probleme tu devrais tres facilement le pallier grace au C# et sérialisation binaire. MSDN décrit bien les avantages des 3 techniques de sérialisation disponible (dont XML + binaire).

Envoyé par Reward

Je pourrais éventuellement lui reprocher d'être verbeux, mais bon, on ne peut pas tout avoir.

C'est vrai, rien n'est parfait ni meme JSon

[Traroth2]

XML et JSON n'ont pas le même point de vue sur l'information. JSON est un format d'échange d'objets entre applications, alors que XML est un format de meta-document permettant de représenter n'importe quel type d'information de manière structurée.

[alex_vino]

Envoyé par Traroth2

XML et JSON n'ont pas le même point de vue sur l'information.

Surtout l'article nous lance dans un débat sans queue ni tete

Il ne faut pas oublier que JSON signifie "JavaScript Object Notation" et XML "Extensible Markup Language".
Ca dit bien ce que ca dit, a quoi bon comparer un camion et une voiture, l'un peut faire des choses similaires a l'autre mais suivant la situation on sera amené a choisir l'un ou l'autre.

[thelvin]

En attendant l'état de l'art en industrie, les traite comme s'ils étaient interchangeables, et choisissent... Euh, je ne sais pas ? En fonction de ce que le décideur avait lu au moment de la décision ?

C'est une bonne chose de signaler que c'est pas interchangeable, et de dire pourquoi. Mais l'industrie faisant ce qu'elle fait, la question n'est pas absurde.

[Thorna]

Envoyé par thelvin

En attendant l'état de l'art en industrie, les traite comme s'ils étaient interchangeables, et choisissent... Euh, je ne sais pas ? En fonction de ce que le décideur avait lu au moment de la décision ?

C'est exactement ça ! Tout comme le développeur choisit le Framework qu'il connait ou qui est à la mode ( = dont il a lu pas mal d'articles dans les dernières semaines ), ou encore qui est "utilisé dans l'entreprise".
Et si c'est "performant" d'utiliser un gros Framework à la mode pour lire des gros fichiers XML qui stockent des données "plates", ça ne veut pas dire que c'est le truc à faire. L'informatique, c'est une science de faignants (je le sais, j'en suis...), mais il y a tout de même des limites.

[Freem]

Bof... XML, j'ai déjà dis ce que j'en pense, et ce n'est pas trop flatteur.

Vais éviter de troller et de me répéter, ça ne servirait pas à grand chose, mais, malgré tout un point a illuminé ma journée d'un sourire indélébile :

Envoyé par thelvin

De plus, pendant que tu concevais ton format binaire, moi je faisais quelque chose que la machine ne peut pas faire à ma place.

Ahhh, parce que, si XML nécessite des lib pour parser le code, les formats binaires doivent être réécrits à chaque fois?
Permets moi de protester: http://www.boost.org/doc/libs/1_53_0...doc/index.html

Cette lib, plutôt bien foutue et très pratique, permets au dev de supporter n'importe quel format sans se prendre la tête.
Enfin, je dis n'importe quel... j'exagère. A l'heure actuelle, il n'y a "que" 3 implémentations je crois: texte, binaire et XML.
Toujours est-il que passer de l'un à l'autre, c'est l'affaire de modifier 3 lignes. Sauf pour XML, bien sûr, puisque dans le cas d'XML, il faut renseigner pour chaque propriété à sérialiser le nom de la propriété XML (ben oui, C++ n'est pas réflexif, le binaire ne connaît pas les noms des variables).

Pour donner de véritables arguments contre le binaire, je crois que le meilleur est celui de l'inter-opérabilité: un format binaire est plus complexe a adapter d'une application à l'autre.
Mais la plupart des fois ou j'ai vu XML, les données n'étaient pas faites pour être exploitées par d'autres applications. Genre, les projets de Visual Studio ou de Code::Blocks, ou pas mal de jeux (sisi, je vous assure, dès lors qu'on passe un coup de 7zip, on est surpris du contenu des fichiers...).

Un autre gros défaut du binaire, c'est l'endianness. L'unicode sait de quoi je parle, et certains ont "résolu" le problème avec les BOM.

Après, moi, je vous avoue... quand j'utilise boost::serialization, j'utilise le format txt. C'est pas du CSV, c'est pas de l'XML.
C'est pas auto-documenté, c'est lisible par le développeur dans une faible proportion (histoire de tester. quoique, ça dépend de comment on à géré, à bien y réfléchir) et c'est concis.
En fait, comme le nom de la lib l'indique, c'est adapté à la sérialisation/désérialisation, et pas aux communications inter-applications.

Malheureusement, de ce que j'ai pu voir, le XML est utilisé aussi à des fins de sérialisation, alors qu'il n'a pas, je pense, été conçu pour ça.
Quant à l'argument "lisible par l'homme", une simple question: quand vous distribuez vos binaires, vous filez les versions de débogage, celles qui sont lisibles par l'homme et lentes, ou les binaires dont les symboles ont étés supprimés, et qui sont nettement plus rapides à l'exécution?

Je parie sur la 2nde option. Et si je me rate pas, alors, pourquoi donc distribuer des applications générant des choses "lisibles par l'homme", au risque qu'un utilisateur les bidouille "pour voir", que ça marche un temps, puis au bout d'un certain temps "allo Mr. le dev, votre dernière version à un bug !"?
Ce n'est pas de la fiction, ou, pour être exact, j'ai vu les dev de C::B regretter le choix de XML justement pour cette raison.

Pour ce qui est du fait qu'on ne puisse plus lire les documents 20 ans après... il suffit de distribuer les spec des formats utilisés. D'ailleurs, je pense que le problème est le même avec XML...
Pour finir sur ce problème de format... je me souviens avoir reversé en une semaine le format de fichier de sauvegarde de dungeon keeper, avec l'outil edit.com.
A cette époque, je ne connaissais que le QBasic, et même pas la version 4.5, pour dire.
Bien sûr, c'est vieux, il n'y avais pas de 3D, et mon cerveau n'avais pas encore été altéré par les soirées arrosées

[GrandFather]

Envoyé par Freem

Pour ce qui est du fait qu'on ne puisse plus lire les documents 20 ans après... il suffit de distribuer les spec des formats utilisés.

Bien sûr... C'est certainement pour cela que Microsoft n'a jamais rendu publiques les spécifications des formats de fichier d'Office pré 2003... Et puis il faudra aussi rendre publiques les spécifications du format du fichier qui contient les spécifications (infinite loop detected).

Pour lire le contenu d'un fichier XML, il suffit d'un bête éditeur de texte. La sémantique précise des éléments et attributs peut être perdue car imprécise et non normée, mais au moins les données sont immédiatement accessibles sous leur forme littérale. Pour lire le contenu du fichier binaire, il faut impérativement les spécifications - ou supporter le coût de l'ingénierie inversée - et écrire l'outil ad hoc en prenant en compte de la plateforme technique d'exploitation (big-endian/little-endian, 32/64 bits, chaînes à zéro terminal/préfixe). En matière de pérénnité, quand il s'agit de rendre des données numériques accessibles pour les siècles à venir, ce n'est vraiment pas la même chose.

[sekaijin]

Contrairement à ce que j'ai pu lire dans certains Posts je pense qu'il est bon de confronter XML et JSON.

et il ne s'agit pas (comme je l'ai lu) de mettre en oppositions les chose mais en vis à vis pour mieux comprendre l'étendue des outils à notre disposition.

ça me fait pensser à une discussion de 2011
Jusqu'où ira l'essor de JSON

en 2010 j'avais déjà abordé le sujet du typage de donnée dans JSON
qui est une question récurent. (peut-on en json avoir quelque chose comme xml schema ?) JSON types et classes

J'utilise de façon intensive les deux technos et je pense que les deux ont leurs avantage. il y a bien sur une zone de recouvrement.

Je pense toutjours qu'il est bon de se poser la question lorsqu'on doit définir un format d'échange.

et je dit toujours de rester pargmatique.

AJYT

[sekaijin]

Envoyé par alex_vino

Le XML n'est pas tres adapté aux fichiers tres volumineux tout de meme.....

je dirait que c'est tout le contraire. pour parser du XML il y a deux approche DOM et SAX. pour JSON les parseur s'apprent à DOM. ils produisent une image en mémoire de l'ensemble du document JSON.

les Paser SAX premettent de lire le XML en continu sans avoir à stoker le tout en mémoire. il est très facile avec SAX d'écrire un outils qui va réagir à certains TAG dans un flux XML continue de plus de 100 000 To

je fais express de donner une taille démesurée car en fait avec SAX il n'y a aucune limite de taille.

je ne pense pas que généré un tel flux soit la bonne solution.
mon propos est juste de dire que XML n'a pas de limite de ce coté là.

A+JYT

[Torotoro]

En tout cas pour moi qui développe des petits sites pour PME/PMI sur des hébergement mutualisés, le côté verbeux de XML est LE principal soucis quand on doit accéder à des BDD conséquentes.
On se trouve très rapidement en butée sur des tailles fichiers/buffer/temps d'exécution et devoir travailler par paquets de 100 enregistrements là où avec CSV ou JSON on en récupère 2000. Sur un projet en particulier qui laissait le choix entre CSV ou XML, je pouvais récupérer l'intégralité de la BDD distante en une seule opération en CSV alors qu'en XML j'aurais du développer une récupération segmentée.
Avantage au XML, un seul coup d'oeil au fichier permet de se faire une bonne idée de l'architecture des données. Mais une fois l'architecture connue, je préfère le JSON.

[niuxe]

Sujet à troll.... Tu préfères la viande ou poisson pour midi ?

Bon anniversaire XML ! Tu as de beaux jours devant toi.
Tu nous aides à structurer mieux les données d'une manière clair et concise afin d'échanger des données entres applications. Certes tu es moins performant que JSON. Mais tu as d'autres atouts en toi. Ton pote XSLT t'aide à ce que tes données ressemblent à quelque chose de concret.

[oxedet]

Je bouffe XML depuis sa naissance (avec le plugin sous IE4, je faisais de l'AJAX mais ça portait pas encore ce nom...) et en suis content. Personnellement, Json, amené avec la déferlante des frameworks javascript, j'ai pas encore réussi à digérer. Et puis comme le dit niuxe, faut pas oublier XSLT, XPATH et consors...

[arkhamon]

Bonjour à tous,

allez je vais me prendre un coup de 12 mais bon tant pis. En plus ça fait un moment donc je me lache...

D'abord bon anniversaire à XML, que j'ai découvert il y a quelques années (ouais je sais j'ai plus l'âge de faire la course à la technologie ) et que j'utilise depuis pour mon petit soft (les lecteurs du forum Delphi FMX me connaissent un peu avec mes questions tordues...).

Je vois ce post et déjà, j'ai pas été invité à la fête. C'était où ? Trève de blagues. C'est étonnant cette capacité toujours intacte des informateux de critiquer ce que font les autres, de dire la Sainte Parole sur les outils à utiliser, de décréter (par autre Sainte Parole) de ce qui doit être utilisé ou pas, de savoir ce qui est bon pour l'entreprise (dans laquelle ils ne travaillent pas) et autres vérités certaines (qui el resteront au bas mot 10 jours...).

Je n'utilise que 10% de XML (la partie balises en fait) car c'est pratique pour moi et je n'ai pas besoin de plus.

Au départ, XML était une description d'un format d'échange de données structurées et indépendant de la plateforme. C'est devenu quoi ? Une énorme chose capable de faire 36 000 choses, toutes plus abscon(e)s les unes que les autres. On en arrive une fois de plus à pondre un standard qui devient incompréhensible au commun des mortels qui n'a pas 10 heures par jours à passer à faire de la veille technologique.

Le résultat de cette idéologie ? Des fichiers PDF qui installent des DLL sur un poste et qui permettent de prendre le contrôle à distance, une VM Java qui permet je ne sais quelle faille, des doculetns Word qui permettent l'installation puis l'exécution de contrôles ActiveX (ça c'était en 1998) et j'en passe et des pires...

Avant, on avait des correctifs pour des bugs, et on râlait déjà. Mais maintenant, c'est des correctifs pour des failles de sécurité. A trop imbriquer les choses, on en contrôle plus rien. Et dans la mesure ou l'informatique rêgne désormais sans partage sur nos vies, j'ai peur...

Alors oui le vieux machin qui dit tout le temps "c'était mieux avant" souhaite un excellent anniversaire à XML qu'il continuera d'utiliser longtemps, car il a pas besoin de plus pour l'instant.

[singman]

Je savais pas qu'on pouvait faire du XSLT sur du JSON....
Et oui, XML est largement plus généraliste que JSON, très orienté "données sans transformations derrière".

[enneite2]

XML permet quand même de structurer mieux les choses que le JSON.

Rien que pour des appels AJAX, quand c'est un process très simple je prend du format TXT, quand c'est un peu plus complexe je passe au JSON et je finis par du XML quand l'architecture des données à récupérer est vraiment compliquée.


n ce qui concerne XML (bon anniv!) personnellement je n'aime pas trop utiliser d'attribut dans les balises, préférant multipliez les balises de l'arbre.
C'est peut être plus lourd mais plus logique, en fait je ne comprends pas à quoi servent les attributs* vu que les noeuds sont eXtensibles à l'infini.

* : dans le sens où "que peut faire un attribut que ne pourrait pas faire une nodeChild supplémentaire ?"

[GrandFather]

Envoyé par enneite2

* : dans le sens où "que peut faire un attribut que ne pourrait pas faire une nodeChild supplémentaire ?"

Justement le caractère unique de l'attribut (pas d'attributs de même nom dans un même élément) permet de s'assurer que la valeur qu'il contient n'est présente qu'en une seule occurrence, et attachée à l'élément associé. Si tu places cette valeur dans un élément, il te faut une étape supplémentaire de validation pour t'assurer de cette unicité.

C'est pour cette raison que les attributs sont généralement utilisés pour contenir des metadonnées, descriptives des données réelles qui elles sont contenues dans les éléments.

[Derek Corgan]

Et merci pour tous les services rendus.
Personnellement j'apprécie particulièrement la facilité d'interopérabilité, un format compréhensible facilement par les différents acteurs d'un projet et les techno associé : XPATH, XMLSchema, XSL, SOAP...

Après évidemment XML a ses défauts : les éternels problèmes d'encoding (grr), le coté verbeux...

Tout le monde ne peut être parfait.

JSON ? Pas le même usage pour ce que j'en ai vu. Les 2 sont à priori complémentaires.

Quel soulagement de m'être débarrassé de ces m... de fichiers binaires ()

[arkhamon]

Envoyé par enneite2

n ce qui concerne XML (bon anniv!) personnellement je n'aime pas trop utiliser d'attribut dans les balises, préférant multipliez les balises de l'arbre.
C'est peut être plus lourd mais plus logique, en fait je ne comprends pas à quoi servent les attributs* vu que les noeuds sont eXtensibles à l'infini.

* : dans le sens où "que peut faire un attribut que ne pourrait pas faire une nodeChild supplémentaire ?"

En ce qui me concerne j'y vois certains avantages :

D'abord, quand on regarde le fichier dans un éditeur style Notepad++ ou même Ie, les attributs sont colorés, ca rend la lecture un peu moins laborieuse? Bon c'est aps l'argument du siècle, mais quand on parle lisibilité ca peut jouer.

Ensuite, et ça va pas être l'argument du siècle non plus, la librairie que j'utilise pour parser le XML (OmniXML de Ondrej Pokorny) me renvoie '' sur ce code :

Code :

Valeur := RacineXML.NoeudXML.GetAttribute('Attribut');

même si l'attribut n'existe pas. Alors que si j'utilise :

Code :

Valeur := RacineXML.NoeudXML.NoeudValeur.Text;

ça va générer une exception si le noeud NoeudValeur n'existe pas.
Bon je sais c'est moyen comme argument mais bon...

J'ai quand même un argument un peu plus sérieux : dnas le principe les attributs sont des attributs () d'un noeud, alors que des sous-noeuds sont un niveau supplémentaire d'information. C'est pas clair non plus dans ma tête... Pour moi, un noeud a vocation à contenir derrière encore des niveaux de précision, alors qu'un attribut est une feuille finale, qui n' pas besoin d'être précisée plus.
Ca vous parle ?