[W3C] M*st*rbation intellectuelle

Signaler
Messages postés
32840
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
-
Messages postés
908
Date d'inscription
lundi 18 avril 2005
Statut
Membre
Dernière intervention
3 août 2008
-
Le W3C fait des choses bien, mais parfois aussi ils font un peu n'importe quoi.

Nouvelle lubie: le Binary XML.

L'XML a été inventé parceque (pensent-ils) le format binaire est difficile à manipuler.

Maintenant, ils veulent refaire du binaire, parceque l'XML c'est pas efficace.

http://tinyurl.com/3kr9a

Le Binary XML est donc un fichier MIME multipart (comme les mails), avec une des parties étant le fichier XML, et le reste les fichiers attachés.
La partie XML contient des références vers les parties binaires.

ça aurait pas été plus simple de faire directement un fichier ZIP ?

Comme.... comme... tiens comme ce que fait OpenOffice par exemple ?

5 réponses

Messages postés
33478
Date d'inscription
jeudi 14 octobre 2004
Statut
Modérateur
Dernière intervention
24 février 2011
1 767
Salut,
Ca ne serait pas une demande de Microsoft qui veut pouvoir dire que sa prochaine suite office répond aux standard du XML ?
Ca ressemble bigrement à leur format non?
Remarque je dis ça mais chez nous on fait pareil :o(
0
Utile
Messages postés
44
Date d'inscription
mercredi 12 décembre 2001
Statut
Membre
Dernière intervention
10 mars 2007
2
Maintenant, ils veulent refaire du binaire, parceque l'XML c'est pas efficace.

Une petite question au passage... En quoi l'XML n'est-il pas efficace ? (bah oui, je me demande ça parce que jusqu'ici, j'en avais plutôt entendu du bien de ce langage...)
0
Utile
Messages postés
18625
Date d'inscription
lundi 15 février 1999
Statut
Webmaster
Dernière intervention
8 avril 2021
62 995
Justement... faudrait leur demander.

A priori ce que SebSauvage a voulu dire c'est que le XML est fait à la base pour stocker les informations dans un format structuré et transparent (en texte clair). Or si on s'en sert pour mettre des paquets d'informations en binaire (opaque), on se mord la queue et on tourne en rond !
Utilisateur anonyme >
Messages postés
18625
Date d'inscription
lundi 15 février 1999
Statut
Webmaster
Dernière intervention
8 avril 2021

performance respectable au demeurant

moi j'y arrive pas. J'arrête pas de tomber.
Messages postés
33478
Date d'inscription
jeudi 14 octobre 2004
Statut
Modérateur
Dernière intervention
24 février 2011
1 767 > Utilisateur anonyme
:-DDDDD

Le zip aurait été plus simple, mais le problème n'est peut être pas là...
S'il y a un besoin de standard, ils font un standard, c'est tout. Après, voir si c'est bien, pas bien, compliqué, .... c'est pas leur problème. Enfin c'est ce que j'en pense. Il faut voir le W3C comme la référence en terme de compatibilité, pas de simplicité.
0
Utile
Messages postés
32840
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 491
S'il y a un besoin de standard, ils font un standard

Quel besoin couvre Binary XML ?
ça me laisse franchement perplexe.


En quoi l'XML n'est-il pas efficace ?

(attention, je risque de parler un langage un peu incompréhensible:)

XML est à la mode, mais ça n'est pas pour autant que c'est la solution miracle:
- XML est terriblement verbeux (lourdeur des fichiers)
- XML n'a pas de notion de typage
- la conversion texte --> format binaire est obligatoire pour que l'ordinateur puisse traiter les données: c'est couteux en terme de développement (vérifications de type, etc.)
- pour un ordinateur, interpréter un fichier XML est beaucoup plus lourd (en CPU et mémoire) qu'interpréter un format binaire (même si une conversion d'endianess est nécessaire).
- XML est bien adapté à la représentation de données hiérarchiques, mais cette représentation est loin d'être suffisante dans la vraie vie (exemple: les notions de relations manquent (comme en bases de données relationnelles, par exemple)).
- XML oblige émetteur et récepteur à définir un format commun très précis. Ce qui n'est pas plus intéressant que le binaire, finalement.
- XML, pas plus que le binaire, n'a de notion de sémantique. La sémantique doit être définie en dehors d'XML, comme pour le binaire. L'apport est donc nul.
- XML est censé être humainement lisible, mais dans la vraie vie, les fichiers XML sont très difficiles à comprendre du fait de leur structure hiérarchique fortement imbriquée (faites un peu de B2B, par exemple avec Rosetta.Net, vous m'en direz des nouvelles).
- etc.


Je ne suis pas en train de dire que "XML, c'est mal.".
Je dis simplement qu'on essai de le fourguer absolument partout, sans réfléchir à la pertinence, ce qui est une mauvaise idée.



"The right tool for the right job."
0
Utile
- XML n'a pas de notion de typage 
- la conversion texte --> format binaire est obligatoire pour que l'ordinateur puisse traiter les données: c'est couteux en terme de développement (vérifications de type, etc.)
Bah, et c'est quoi les schémas ?!?

- XML, pas plus que le binaire, n'a de notion de sémantique. La sémantique doit être définie en dehors d'XML, comme pour le binaire. L'apport est donc nul. 
- XML est censé être humainement lisible, mais dans la vraie vie, les fichiers XML sont très difficiles à comprendre du fait de leur structure hiérarchique fortement imbriquée (faites un peu de B2B, par exemple avec Rosetta.Net, vous m'en direz des nouvelles).
Disons que c'est moins catastrophique que le binaire :p
Messages postés
32840
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 491 > popo
Bah, et c'est quoi les schémas ?!?

Même quand tu as un schéma pour valider la structure de ton document, ça t'oblige la plupart du temps, derrière, à devoir caster quand même les données.

Les schémas n'affranchissent donc pas de la gestion des types de données derrière dans tes programmes.



Disons que c'est moins catastrophique que le binaire :p

Pas forcément.
Il y a des formats binaires très bien stucturés et pratiques (et moins consommateurs de place).
Par exemple les formats IFF ou RIFF, qui permettent de définir plusieurs sections.

Le base64 est une idée sympa, mais consommer 136 ko pour en stocker 100, ça reste du gaspillage.

Je reformule: ce n'est pas optimal.
>
Messages postés
32840
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019

Même quand tu as un schéma pour valider la structure de ton document, ça t'oblige la plupart du temps, derrière, à devoir caster quand même les données. 

Les schémas n'affranchissent donc pas de la gestion des types de données derrière dans tes programmes.
Désolé d'insister mais je ne comprend pas
pourquoi je serais obligé de revérifier dernière si le XML a été validé par un schémas sachant que ces derniers sont très riches? (+ de type que la moyenne des langages de prog si on ajoute les types dérivés, possibilité de patern, list, min, max,.... le tout sans rien programmer)

Pas forcément. 
Il y a des formats binaires très bien stucturés et pratiques (et moins consommateurs de place). 
Par exemple les formats IFF ou RIFF, qui permettent de définir plusieurs sections. 

Le base64 est une idée sympa, mais consommer 136 ko pour en stocker 100, ça reste du gaspillage.
D'accord, mais n'est-ce pas la un discours un peu dépassé - à l'époque où les PC avaient 4Mo de RAM?
Je suis absolument d'accord que ce n'est surement pas une raison valable pour programmer comme un porc mais pourquoi pas en profiter pour choisir une autre technologie moins optimisée et plus standardisée, simple, etc... ? (un peu comme CORBA vs les WS)
Messages postés
32840
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 491 > popo
pourquoi je serais obligé de revérifier dernière si le XML a été validé par un schémas

C'est vrai, une fois validé, on pourrait considérer que c'est ok.

Mais je n'importe et traite jamais de données extérieur sans un try/catch. Si je fais déjà un try/catch, pourquoi faire 2 fois le boulot ?

(Et encore, c'est quand on travaille sur des XSD bien écrite, ce qui est rarement le cas.)


XML en lui-même est pauvre: on doit ajouter XSD, XSL, etc. On ajoute des couches sur des couches.
Qui maîtrise vraiment ça ?
http://www.wdvl.com/Authoring/Languages/XML/XMLFamily/BigPicture/bigpix20a.html

XML et ses technos sont trop complexes, et donc mal maitrisées et mal utilisées.

Et même bien maîtrisées, les temps de traitement sont énormes (traiter du XML reste très très lourd comparé à des fichiers à plat ou des fichiers binaires).


D'accord, mais n'est-ce pas la un discours un peu dépassé - à l'époque où les PC avaient 4Mo de RAM?

Je ne crois pas non.
Quand on traite des documents de B2B, les volumes de données sont monstrueux.
L'XML multiplie par 2 à 5 le volume des données.
Quand on doit traiter plusieurs giga-octets de données métier par jour, ça peut rapidement devenir problématique.
Et pas seulement en terme de volume: aussi en terme de temps de traitement.




Je m'étale, je m'étale... c'est de l'amertume: j'ai vu dans mon métier des gens faire de l'XML pour faire de l'XML.
à vous dégouter des usines à gaz qu'ils ont mis en place: trop compliqué, impossible à maintenir, plus personne n'arrive même à comprendre comment ça marche.

Des fichiers à plat, un modèle relationnel ou un modèle objet auraient fait merveille, mais non ils ont fait de l'XML.



Dans les cas d'école, l'XML c'est beau, c'est clean.

Mais pour l'avoir pratiqué (Rosetta.Net par exemple, ou des documents échangés avec des clients externes (B2B, EAI)), c'est la galère.
L'XML ne fait qu'ajouter de la complexité à des traitements qui pourraient être simples avec des fichiers à plat.
Et personne ne les maîtrise correctement.
Messages postés
5927
Date d'inscription
mercredi 26 mai 2004
Statut
Contributeur
Dernière intervention
18 septembre 2009
212 >
Messages postés
32840
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019


Je m'étale, je m'étale... c'est de l'amertume: j'ai vu dans mon métier des gens faire de l'XML pour faire de l'XML.


toutafé d'accord avec toi.
mis à part pour des fichier config (koike) ou le svg je laisserai mon fondement exprimer ce que je pense du reste
Messages postés
908
Date d'inscription
lundi 18 avril 2005
Statut
Membre
Dernière intervention
3 août 2008
501 >
Messages postés
32840
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019

Salut,
Je me permets de rentrer dans la discussion car j'ai le cas d'une application
métier qui met en oeuvre ce mécanisme.
Des capteurs fournissent des valeurs à des fréquences élevées (200Hz ou plus)
a destination d'une application temps réel. Les visualisation sont donc gérées
en temps réel, mais ces valeurs doivent être historisées pendant plusieurs
heures afin d'être traités en temps différé (post traitement).
La majorité des outils mis en oeuvre : configuration de la chaine de mesure,
configuration des affichages, configuration du fichier historique,
configuration des outils de dépouillement (post traitement) tle XML se révèle
bien pratique, car la plus part des configuration sont de type "arbre" et le
volume manipulé faible de l'ordre du Mo pour des chaines de mesures
dépassant les 3000 capteurs.
Mais pour les valeurs, XML est inadapté. Donc une balise non standard permet
de faire le lien avec le/les fichiers de valeurs et ce/ces fichiers sont rangés dans
des blob en BD.
Si un standard sort, la plus part des applis serait plus simple à écrire car il
y aurai une prise en compte de la part de SGBD et des grapheurs. On ne
perdrait pas un temps fou dans la conception et la réalisation des modules
de transmission/transformation entre les diverses plateforme matérielle et
application (un peu comme le couple RPC/XDR).

C'était une idée en passant, A+, crabs.
Messages postés
7472
Date d'inscription
vendredi 14 octobre 2005
Statut
Contributeur
Dernière intervention
5 juin 2020
897
M*st*rbation
heu... un "y" comme yère.
Je propose mysterebation.

0
Utile
Messages postés
3310
Date d'inscription
dimanche 11 août 2002
Statut
Contributeur
Dernière intervention
22 juin 2015
50
:-D