* are simpler
Ok, j'avoue, comme je le disais, j'aime bien leur format de definition.
* 3 to 10 times smaller
Autant que mon format de serialization utilisé avec Python.
Au passage, 10 times smaller je n'y crois pas. XML implique une augmentation de poid importante je l'accorde, mais hormis dans le cas ou les noms de balise sont tres long et le contenu est tres cours, cela n'est pas de l'ordre de 10.
* Faster
Ok. Autant que mon format de serialization utilisé avec Python ?
* Less ambiguous
Je n'ai jamais trouvé le XML ambigus, juste les DTD illisibles.
* generate data access classes that are easier to use programmatically
Je n'aime pas la generation automatique de code et j'avoue ne jamais avoir traité de XML avec autre chose que Python, mais j'ai presque la meme chose avec Python. (en fait en 10 minutes de tests avec ElementTree (la lib de traitement de XML avec python) et un peu d'introspection, je fais la meme chose ;)
>>> Je n'y crois pas tellement. S’ils veulent des échanges rapides en XML, ils n'ont qu'à optimiser une librairie existante ; non!!!!!!
Tu ne feras jamais aller un parseur XML plus vite qu'un parseur binaire, puisque pour un parseur XML tu est forcé de traiter caracteres par caracteres, pour un parseur de fichier binaire n'as pas ce probleme la.
>>> Ce que je comprend c'est en gros qu'on a là un format binaire pour échanger des données entre c++, java et python.
Cela peut etre son aventage, mais le nombre de langage supporté sera toujours limitant, bien que je ne m'inquiete pas, chaque communautée va ecrire son adaptateur dans la semaine. D'autant que cela n'est pas trop en accord avec un fonctionnement sur un langage non objet.
Les criteres etant donc:
- Communication entre plusieurs langages, on a deja le XML pour ca.
- Bindage automatique sur des objects, moui, cela marche aussi avec le XML
- Vitesse. Le jour ou je commencerais a m'inquieter de la vitesse de traitement sur un truc qui est fortement dependant d'une IO, c'est que tous le reste de mon code sera parfait (j'ai hate)
- Poid. Argument presque valable, bien que je ne pense pas que cela soit de l'ordre de 10. Mais si le poid pose vraiment probleme, il existe deja des choses comme JSON qui permettent tout cela deja, non ?
- Syntaxe de l'equivalent a la DTD simple. Ca c'est bien ! Cela implique juste un format limité au final ?
[^] # Re: Re : Pas convaincu
Posté par Guillaum (site web personnel) . En réponse au journal Google offre un format de donnée sous licence Apache. Évalué à 0.
Ok, j'avoue, comme je le disais, j'aime bien leur format de definition.
* 3 to 10 times smaller
Autant que mon format de serialization utilisé avec Python.
Au passage, 10 times smaller je n'y crois pas. XML implique une augmentation de poid importante je l'accorde, mais hormis dans le cas ou les noms de balise sont tres long et le contenu est tres cours, cela n'est pas de l'ordre de 10.
* Faster
Ok. Autant que mon format de serialization utilisé avec Python ?
* Less ambiguous
Je n'ai jamais trouvé le XML ambigus, juste les DTD illisibles.
* generate data access classes that are easier to use programmatically
Je n'aime pas la generation automatique de code et j'avoue ne jamais avoir traité de XML avec autre chose que Python, mais j'ai presque la meme chose avec Python. (en fait en 10 minutes de tests avec ElementTree (la lib de traitement de XML avec python) et un peu d'introspection, je fais la meme chose ;)
>>> Je n'y crois pas tellement. S’ils veulent des échanges rapides en XML, ils n'ont qu'à optimiser une librairie existante ; non!!!!!!
Tu ne feras jamais aller un parseur XML plus vite qu'un parseur binaire, puisque pour un parseur XML tu est forcé de traiter caracteres par caracteres, pour un parseur de fichier binaire n'as pas ce probleme la.
>>> Ce que je comprend c'est en gros qu'on a là un format binaire pour échanger des données entre c++, java et python.
Cela peut etre son aventage, mais le nombre de langage supporté sera toujours limitant, bien que je ne m'inquiete pas, chaque communautée va ecrire son adaptateur dans la semaine. D'autant que cela n'est pas trop en accord avec un fonctionnement sur un langage non objet.
Les criteres etant donc:
- Communication entre plusieurs langages, on a deja le XML pour ca.
- Bindage automatique sur des objects, moui, cela marche aussi avec le XML
- Vitesse. Le jour ou je commencerais a m'inquieter de la vitesse de traitement sur un truc qui est fortement dependant d'une IO, c'est que tous le reste de mon code sera parfait (j'ai hate)
- Poid. Argument presque valable, bien que je ne pense pas que cela soit de l'ordre de 10. Mais si le poid pose vraiment probleme, il existe deja des choses comme JSON qui permettent tout cela deja, non ?
- Syntaxe de l'equivalent a la DTD simple. Ca c'est bien ! Cela implique juste un format limité au final ?