Tous les formats ou protocoles qui sont basés sur XML le compressent dans l'usage "normal" (hors débuggage où on désactivera la compression temporairement).
Ce n’est pas le cas de soap (par exemple). La compression HTTP ne s’est pendant très longtemps faite que pour la réponse (je crois que désormais il y a aussi des choses pour le faire sur la requête, mais je ne suis pas sûr que ça soit tout standardisé). J’avais développé des extensions pour de la compression de requête, vers la fin des années 2000, il n’y avait à l’époque rien de standard. Ça fonctionnait bien, mais ce n’était plus du tout interopérable, du coup (on s’en foutait car on maîtrisait le client et le serveur, mais de manière générale c’est un manque).
pas de différentiation entre attribut et valeur du nœud
Je ne comprends pas ce que tu veux dire.
La différence entre <toto attr="tutu" /> et <toto><attr>tutu</attr></toto> . Sémantiquement, c’est compliqué de savoir lequel est la « forme à utiliser ».
le fichier XML définit simplement son codage dans sa déclaration.
Oui, ça veut dire que ton parseur doit connaître tous les encodages de la terre (ou qu’on puisse lui apprendre).
En plus dans les faits, très souvent les sous-formats vont imposer un codage unique (souvent UTF-8). C'est le cas par exemple de XMPP.
Contrainte que... tu ne peux pas exprimer avec un schéma. C’est ballot, mais logique car du point de vue XML l’encodage n’est pas censé être différenciant (deux documents xml d’encodage différents mais de contenu identique une fois normalisé en utf-8 ont la même signature, par exemple). Un protocole qui impose l’encodage va quelque part à l’encontre de la norme.
En outre, là où XML va avoir une étape de validation générique au niveau de ton parseur (que tu n'as donc en général pas à implémenter dans le code; en utilisant une bibliothèque XML externe, on se contente de fournir le schéma et la validation est faite pour nous)
Valider uniquement avec un schéma est complètement casse gueule (cf exemple précédent :) ). C’est complètement insuffisant, tu as quand même une validation à faire en complément. L’intérêt de la validation XSD est réel, mais je ne me reposerai pas dessus, et certainement pas comme première passe avant lecture car en plus c’est coûteux. C’est plus utile en validation de données produites, par contre.
Si tu veux un exemple simple, une contrainte comme « date < date_du_jour » (contrainte métier tout à fait raisonnable) n’est pas exprimable. Au final, la validation xsd ne te dispense pas de faire ton boulot correctement.
Quant à des fichiers de conf (si on prévoit édition par un humain), je n'utiliserais ni json ni XML, mais un format simple "attribut: valeur" ou "attribut = valeur", type fichiers INI.
Par curiosité, comment tu fais quand tu as des données arborescentes à représenter dans tes fichiers de conf (ou simplement des listes) à plat ? Parce que pour l’instant, tous les trucs que j’ai vus relèvent du bricolage vraiment pas beau (cf les fichiers que pond QSettings).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: XML sapu et autres billevesées
Posté par whity . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 1.
Ce n’est pas le cas de soap (par exemple). La compression HTTP ne s’est pendant très longtemps faite que pour la réponse (je crois que désormais il y a aussi des choses pour le faire sur la requête, mais je ne suis pas sûr que ça soit tout standardisé). J’avais développé des extensions pour de la compression de requête, vers la fin des années 2000, il n’y avait à l’époque rien de standard. Ça fonctionnait bien, mais ce n’était plus du tout interopérable, du coup (on s’en foutait car on maîtrisait le client et le serveur, mais de manière générale c’est un manque).
La différence entre
<toto attr="tutu" />et<toto><attr>tutu</attr></toto>. Sémantiquement, c’est compliqué de savoir lequel est la « forme à utiliser ».Oui, ça veut dire que ton parseur doit connaître tous les encodages de la terre (ou qu’on puisse lui apprendre).
Contrainte que... tu ne peux pas exprimer avec un schéma. C’est ballot, mais logique car du point de vue XML l’encodage n’est pas censé être différenciant (deux documents xml d’encodage différents mais de contenu identique une fois normalisé en utf-8 ont la même signature, par exemple). Un protocole qui impose l’encodage va quelque part à l’encontre de la norme.
Valider uniquement avec un schéma est complètement casse gueule (cf exemple précédent :) ). C’est complètement insuffisant, tu as quand même une validation à faire en complément. L’intérêt de la validation XSD est réel, mais je ne me reposerai pas dessus, et certainement pas comme première passe avant lecture car en plus c’est coûteux. C’est plus utile en validation de données produites, par contre.
Si tu veux un exemple simple, une contrainte comme « date < date_du_jour » (contrainte métier tout à fait raisonnable) n’est pas exprimable. Au final, la validation xsd ne te dispense pas de faire ton boulot correctement.
Par curiosité, comment tu fais quand tu as des données arborescentes à représenter dans tes fichiers de conf (ou simplement des listes) à plat ? Parce que pour l’instant, tous les trucs que j’ai vus relèvent du bricolage vraiment pas beau (cf les fichiers que pond QSettings).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0