Discussion :

[jfchretien]

Bonjour à tous.

Je crois surtout que les gens ont oublié un point fondamental: XML a été conçu à l'origine pour encoder des documents textuels, or aujourd'hui beaucoup veulent l'utiliser pour encoder des structures de données, ce pourquoi il n'a pas été conçu. Pas étonnant donc qu'il ne réponde pas à 100% à la problématique.

Un texte, c'est quelque chose de fondamentalement linéaire : prenez un document Docbook, ôtez toutes les balises mais maintenez l'ordre, vous verrez que l'ensemble reste compréhensible. Avec des structures de données c'est le contraire: quand vous spécifiez par exemple un objet Personne, peu importe que le nom vienne avant ou après le prénom, par contre si vous gardez le contenu sans les balises, ça devient ambigu.

Je pense que tu n'as pas assez poussé ton analyse. On va partir du postulat que les données sont des objets (au sens propre, pas au sens informatique). Chaque objet peut-être décrit de manière syntaxique et/ou sémantique. Je m'explique.

Un objet à des caractéristiques atomiques (composantes syntaxiques) et ensemblistes (composantes sémantiques).
Le sens d'une composante syntaxique est contenu dans le couple définition + contenu (nom=marie, prénom=pierre, taille=160, poids=80) et l'objet auquel elle se rattache. L'ordre des caractéristiques n'a alors pas ou peu d'importance.
Une composante sémantique contient (généralement) sa propre définition CHAPITRE est composé de PARAGRAPHE est composé de PHRASE est composé de MOT. Par contre, si la définition n'est pas forcément nécéssaire, les ensembles n'ont de sens que s'ils sont ordonnés.
Dans tous les cas, XML est suffisament ouvert pour que ses balises permettent de définir des composantes qu'elles soient syntaxiques ou sémantiques.

Résultat?
XML est utilisé de plein de façons différentes. Dites-moi un peu : comment encodez-vous un tableau en XML? Je suis presque sûr que si plusieurs personnes répondent à mon message vous aurez autant de façons totalement différentes, sans qu'on puisse dire avec certitude qu'une est meilleure que l'autre dans tous les cas.

Oui tout à fait. D'ailleurs à ton avis, un tableau est une composante syntaxique ou sémantique ? Comme c'est une composante sémantique, c'est sa destination qui va en partie définir la façon de le coder.

Pour ce qui est de la question attribut vs. balise, la vraie question à se poser est : est-ce une composante ou une information sur la composante ?
Par exemple un individu pèse 80 kg : On peut l'écrire en XML

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<INDIVIDU><POIDS><VALEUR>80</VALEUR><UNITE>kg</UNITE></POIDS></INDIVIDU>

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<INDIVIDU><POIDS unite="kg">80</POIDS></INDIVIDU>

Mais dans le cadre d'un individu, l'information "kg" est-elle une composante qui a un sens ? Pas forcément, car elle est un qualificatif de la composante "poids". Il en va de même pour un style de paragraphe, la fonte d'un titre, ... On devrait donc utiliser les balises pour les composantes et les attributs pour les qualificatifs des composantes. Toutefois, je dis bien "on devrait" car celà va dépendre de la destination du fichier XML...

D'ailleurs en parlant de destination...
Pour ce qui est du choix TEXTE / CSV / JSON / YAML / XML, j'utilise le raisonnement suivant :
Fichier de conf. écrit et lu par l'application => Texte / CSV (à charge de l'application de gérer le typage et les erreurs sur les données, en écriture et en lecture)
Fichiers d'initialisations écrits par l'utilisateur et lus par l'application pour générer db, templates, docs, ... => JSON / YAML. (à charge de l'application de gérer le typage et les erreurs de données lors de la lecture)
Sérialisation et échange d'objets "simples" intra ou inter-applications => JSON / YAML (à charge des applications de gérer le typage et les erreurs sur les données)
Sérialisation et échange d'objets "complexes" intra ou inter-applications => XML (les développeurs ont accès aux spécifications du XML et les intègrent dans les applications)
Transfert de composantes syntaxiques/sémantiques (données) => XML + XSD + XSLT (les applications ne décident pas des spécifications et/ou de la transformation des données)

Après tout va dépendre des attendus, sachant que vitesse ne rime pas avec robustesse. Si je veux un traitement rapide, je prendrai TEXTE / CSV, tout en sachant que si l'application est mal développée, les risques d'erreur sont assez grands. Si je veux de la robustesse, alors XML + XSD + XSLT. Sachant que l'impact sur la taille des données(occupation réseau, mémoire et disque) et les temps de traitement sera assez fort.

Deux remarques sur le contenu de l'article :

• self describing : le document XML devrait être suffisant pour obtenir les données sans ambigüité
• round tripping : la conversion de la représentation interne des données dans un logiciel (comme un objet à l’intérieur d’une application Java, des structures dans une solution C, des lignes d’une table Oracle, etc.) au format XML et vice-versa, devrait produire les mêmes données. En d’autres termes : data == DecodeFromXML(EncodeToXML(data)).

Justement non ! Et c'est là toute la puissance d'XML. D'ailleurs l’ambiguïté se trouve à quel niveau ? Soit au niveau de celui qui a implémenté le XML et qui n'a pas suffisamment bien pensé et spécifié la structure, soit au niveau de celui qui va traiter le XML et qui n'a pas tout les éléments pour comprendre ce qu'il a et comment il doit le traiter.
Pour ce qui est du round tripping, c'est pareil, aux développeurs de produire une structure XML et des procédures d'import/export adaptées...
Encore une fois XML/XSD/XSL définit de la syntaxe et de la sémantique. Rien de plus.


Pour finir et pour répondre à l'article :

Êtes-vous d’accord avec cette conclusion ?
Non. En effet, la phrase (un peu tape-à-l'oeil) "le problème qu’il résout n’est pas difficile et il ne le résout pas bien" pourrait aussi bien s'appliquer à Java, Perl, LaTeX et tout autre langage ou format... Tout va dépendre du problème posé et du contexte dans lequel s'inscrit ce problème.

Que pensez-vous du langage ? Qu'est-ce qui lui manque le plus ?
Très puissant si on l'utilise correctement pour résoudre les bons problèmes. Très lourd et parfaitement inéfficace dans de nombreux cas.
Il lui manque sûrement plein de choses, mais à trop vouloir en faire un langage universel et respectant pléthore de contraintes, on risque d'en faire une usine à gaz inexploitable et impossible à mettre en oeuvre.

Quelle est l’essence du XML pour vous ?
Permettre le stockage, l'échange et le traitement/transformation de composantes syntaxiques et/ou sémantiques dans des contextes hétérogènes et/ou complexes.

[Graffito]

Quelle est l’essence du XML pour vous ?
jfchretien : permettre le stockage, l'échange et le traitement/transformation de composantes syntaxiques et/ou sémantiques dans des contextes hétérogènes et/ou complexes.

Si c'était vraiment cela l'objectif principal du XML, il est effectivement rempli de façon peu satisfaisante sur le plan de la taille et du temps de parsing.
L'ASN1 avec encodage CANONOCAL-PER qui assure le "round tripping" est bien plus performant et propose un encoding extrèmement compact.

Le principal avantage de l'XML réside dans la possibilité de le visualiser ou de le saisir sans outil dédié via un simple éditeur de texte.

En ce qui concerne, l'aspect "self describing", XML ne résoud cet aspect qu'assez partiellement, si il n'est pas complété d'un XSD.

[Freem]

mais aussi par exemple YAML. Mais c'est vrai que sous leur forme actuelle ces formats ont un défaut : ils ne sont pas typés et ne proposent pas de formalisme pour décrire une structure

L'idée de fond de YAML est que toute donnée peut être représentée par une combinaison de listes, tableaux (de hachage) et données scalaires. YAML décrit ces formes de données (les représentations YAML)

YAML autodetects simple types. Data types can be divided into three categories: core, defined, and user-defined. Core are ones expected to exist in any parser (e.g. floats, ints, strings, lists, maps, ...). Many more advanced data types, such as binary data, are defined in the YAML specification but not supported in all implementations. Finally YAML defines a way to extend the data type definitions locally to accommodate user defined classes, structures or primitives (e.g. quad precision floats).

Pour le coup, il semble que tu te trompes sur YAML puisque, selon wikipedia (pardonnes le mixage des langues, mais je préfère les articles français. Manque de chance ils sont souvent moins complets que leurs alter-égos anglais donc j'utilise souvent les deux) YAML semble:
_ reconnaître les types
_ reconnaître la structure (surtout que YAML sert justement, selon ce que j'ai compris, à gérer des représentations objet des structures... Plus structuré qu'un objet, je connais pas)

A noter que JSON est bien plus proche de XML que YAML, qui contrairement aux deux autres (YAML) "Ain't Markup Language" (ahh ces acronymes récursifs...) du coup je comprend mal que tu utilises dans la même situation YAML/JSON et dans une autre XML?
Y aurait-il quelque chose qui m'aie échappé?

Le principal avantage de l'XML réside dans la possibilité de le visualiser ou de le saisir sans outil dédié via un simple éditeur de texte.

C'est sûr que c'est son avantage principal, sauf que... bah... quand on finit par avoir une profondeur de champ variable et importante sur un fichier de plusieurs dizaines de Kio, je ne trouve pas vraiment le XML si lisible que ça sans outil.
Question de goût, je suppose.

[jfchretien]

Si c'était vraiment cela l'objectif principal du XML, il est effectivement rempli de façon peu satisfaisante sur le plan de la taille et du temps de parsing.
L'ASN1 avec encodage CANONOCAL-PER qui assure le "round tripping" est bien plus performant et propose un encoding extrèmement compact.
Le principal avantage de l'XML réside dans la possibilité de le visualiser ou de le saisir sans outil dédié via un simple éditeur de texte.

Oui mais dans ce cas tu es bien dans la transmission de composantes syntaxiques. Je ne suis pas sûr que tu puisses transmettre des composantes sémantiques. En clair, peux-tu décrire/exprimer un document word avec ASN.1 ? Je n'ai pas la réponse par manque de compétence.

Pour t'expliquer là ou XML (à mon sens) apporte un réel plus, je vais partir sur un cas concret.

Avant de commencer, je tiens à préciser que mon propos n'a valeur, ni de vérité absolue, ni de généralité. Il me semble évident que comparer des langages ou formats ne peut se faire que de manière contextuelle. Il me semble hasardeux de comparer deux solutions hors d'un cadre problème + contexte bien précis. Pour un même problème, dans deux contextes différents, le résultat de la comparaison de deux solution différentes peut être presque opposé.

Une petite explication sur mes composantes syntaxiques et sémantiques car je suis pas sûr que tout le monde comprenne, ni que j'utilise toujours le bon vocabulaire.
Prenons l'exemple d'un objet "boite" caractérisé par son volume, sa description et sa représentation mathématique dans l'espace. Chaque caractéristique est une composante syntaxique de la boite.
Le volume est un nombre or un nombre est une composante sémantique composée d'un ou plusieurs chiffres. Le chiffre étant la composante syntaxique du nombre. Pour ramener celà à de la POO, un objet est composé de variables qui sont aussi des objets, eux-même composés de variables... En clair, au niveau d'un objet on parle de variables (composantes syntaxiques) et le contenu de cette variable peut-être un objet (composante sémantique).

Postulat de départ.
Une entreprise produit des conteneurs de différentes formes faites dans différentes matières et réalise ses ventes sur la zone Euro. Il y a un service production, un service commercial, un service communication et la direction de l'entreprise.
Les composantes syntaxiques du conteneur sont :

• référence : code barre EAN13 - référence unique
• description : description textuelle du produit - une dans chaque langue
• modelisation : modèlisation mathématique permettant de représenter le conteneur dans l'espace
• volume utile : double exprimant le volume en m3
• coût : double exprimant le coût de production HT en euros - coût unique
• prix : double exprimant le prix HT de vente en euros - un pour chaque pays

Le service production édite des fiches techniques au format LaTeX pour chaque conteneur (référence + description en anglais + visualisation 2D + coût).
Le service commercial édite une extraction interne au format OpenOffice Calc (référence + coût + prix pour chaque pays). La formalisation est imposée par la direction.
Le service commercial édite un catalogue interne au format OpenOffice Writer (référence + description en anglais + coût + prix pour chaque pays)
Le service commercial édite un catalogue externe au format Scribus pour chaque pays(référence + description dans la langue du pays + visualisation 2D + prix pour le pays). La formalisation est imposée par le service communication.

Le format XML généré par l'extraction de la bdd respecte une XSD unique accessible par tous les services.
Les extractions sont spécifiques pour chaque service et ne contient que les données nécessaires.
Les extractions sont réalisées par l'application Java qui gère une bdd Oracle.

Le service production gère de manière autonome le XSLT qui permet de générer les documents LaTeX.
Le service commercial utilise le XSLT fourni par la direction pour générer un document OOCalc qui respecte la DTD du format OpenOffice.
Le service commercial utilise son propre XSLT pour générer un document OOWriter qui respecte la DTD du format OpenOffice.
Le service commercial utilise le XSLT fourni par la communication pour générer un document Scribus qui respecte la DTD du format Scribus.

Ces différents documents sont générés via une application PHP de gestion documentaire (GED) unique pour l'entreprise.

Evidemment, la visualisation 2D sous LaTeX se fait en LaTeX... Celle sous Scribus se fait en SVG... Et puis, la référence, selon le document, sera sa valeur EAN13 ou sa représentation en code-barre (qui selon l'application sera dans un format graphique particulier)...

J'allais oublier... Un petit nouveau vient d'arriver dans l'entreprise pour mettre en place la vitrine web. Evidemment, il veut ajouter de l'interactivité et fournir une visualisation 3D interactive lorsque le client accède à une fiche produit...

Pour moi, l'avantage du XML, réside dans le fait que la gestion du format des données et des documents n'est pas géré directement par l'applicatif.
Il devient donc possible de mettre en place une nouvelle GED dans un langage différent (on était en PHP, on passe en Python, Java, ...) sans avoir à recoder les procédures de transformation.
Il est possible de modifier XML, XSD, XSLT pour mettre à jour les évolutions structurelles des données ou les évolutions de transformation à partir de n'importe quel outil (script shell ou perl ou PHP, via un éditeur Vim ou Notepad++, via une application dédiée).
Il est également possible de créer de nouvelles XSD / XSLT pour de nouveaux formats de documents.

C'est celà que j'entend par :

Permettre le stockage, l'échange et le traitement/transformation de composantes syntaxiques et/ou sémantiques dans des contextes hétérogènes et/ou complexes.

Au delà de ça, il est vrai que tous les formats ne sont pas textuels (formats binaires ou propriétaires) et qu'il sera sûrement nécéssaire de coder certaines transformations directement dans l'applicatif avec usage d'API spécifiques (PDF, Word avant 2007, ...)

En ce qui concerne, l'aspect "self describing", XML ne résoud cet aspect qu'assez partiellement, si il n'est pas complété d'un XSD.

Entièrement d'accord avec toi !

[esperanto]

Y aurait-il quelque chose qui m'aie échappé?

Oui, parce que ce n'est pas du tout ce que j'entendais par "langage non typé".
Ce que dit la page Wikipedia en anglais, c'est que quand tu écris "Personne: 3" dans YAML le langage est capable d'inférer que la valeur de droite est un entier.
Ce que je dis moi, c'est qu'il est impossible en l'état actuel des choses de définir une règle conduisant au rejet d'un document parce que la valeur de Personne ne serait pas du bon type. Tu ne peux le faire qu'après avoir lu le document entier et en utilisant ton langage de programmation, pas YAML.

du coup je comprend mal que tu utilises dans la même situation YAML/JSON et dans une autre XML?

Le point commun, tu l'as donné toi-même :

toute donnée peut être représentée par une combinaison de listes, tableaux (de hachage) et données scalaires

Dans JSON comme dans YAML, tu retrouves les 3 types fondamentaux des langages de script. Pas dans XML, il n'y a pas intrinsèquement de notion de tableau, tout nœud est soit terminal (texte, commentaire, instruction de process) soit non terminal (une balise qui a des sous-noeuds). Tout simplement parce que XML n'a pas été pensé pour définir des structures de données mais du texte enrichi : c'est un dérivé de SGML et je n'ai jamais entendu qu'on créait des fichiers de config en SGML. Après, si vous voulez l'utiliser pour des structures de données, vous devez définir une convention pour savoir comment représenter une liste ou un hachage. Et si comme le dit l'auteur de l'article ça ne répond pas complètement à la problématique, ce n'est pas parce que le langage est mauvais mais parce qu'on l'utilise pour ce qu'il n'est pas.

[Logan Mauzaize]

Je pense que le XML pourrait être simplifié, ou une déclinaison de ce format rétro-compatible pourrait exister.

Les contraintes de cette déclinaison pourraient être les suivantes : [...]

Comme tout langage, c'est à toi de définir tes règles de codage... Surtout qu'on parle d'un langage pour en décrire un autre.
C'est comme dire en utilisant les lettres latines, on écrit du Français, c'est naze faudrait utiliser la gramme anglaise !

En ce qui concerne, l'aspect "self describing", XML ne résoud cet aspect qu'assez partiellement, si il n'est pas complété d'un XSD.

C'est toujours plus parlant :

Code XML :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<Personne>
  <Nom>DUPONT</Nom>
  <Prenom>Jean</Prenom>
</Personne>

que

Code JSON :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 {
"DUPONT",
"Jean"
}

Sans savoir à qui il est destiné, il n'est pas traitable. De plus, impossible pour une application de savoir si ça lui est adressé ou non.

[MiaowZedong]

Comme tout langage, c'est à toi de définir tes règles de codage... Surtout qu'on parle d'un langage pour en décrire un autre.
C'est comme dire en utilisant les lettres latines, on écrit du Français, c'est naze faudrait utiliser la gramme anglaise !
C'est toujours plus parlant :

Code XML :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<Personne>
  <Nom>DUPONT</Nom>
  <Prenom>Jean</Prenom>
</Personne>

que

Code JSON :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 {
"DUPONT",
"Jean"
}

Sans savoir à qui il est destiné, il n'est pas traitable. De plus, impossible pour une application de savoir si ça lui est adressé ou non.

En même temps, le deuxième sera parsé beaucoup plus vite et toutes les données n'ont pas à être lisibles par des humains.

Il ne faut pas oublier que le XML est l'eXtensible Markup Language, que cette contrainte d'extensiblité est une contrainte forte et qu'elle est incompatible avec certaines autres contraintes (vitesse, compression...). Si on a besoin de définir une structure custom pour ses données et que celle-ci doit être explicite, le XML est approprié. Sinon....

[_skip]

Comme tout langage, c'est à toi de définir tes règles de codage... Surtout qu'on parle d'un langage pour en décrire un autre.
C'est comme dire en utilisant les lettres latines, on écrit du Français, c'est naze faudrait utiliser la gramme anglaise !

Ca c'est le piège...
Pousses ton raisonnement un peu plus et tu finiras par te dire qu'après tout, on peut bien oublier tout ça et bosser avec du fichier plat et définir la structure qu'on veut .
Je peux effectivement formaliser mes idées et les appliquer dans le monde tel qu'il est aujourd'hui, mais je serai le seul à le faire donc ce n'est pas intéressant du tout en l'absence de norme communément acceptée.

Mon constat est simplement le suivant : coder un parseur pour un document d'origine externe est franchement fastidieux et merdique. Si on mettait d'accord tout le monde sur une structure qui contiendrait la description du contenu ET les données de façon propre et normalisée, on pourrait générer des parsers validants et efficaces sans effort à partir d'un simple échantillon.

Je parles pas de remplacer XML par autre chose, simplement définir un standard basé sur XML qui résolve de façon élégante 75% des problèmes liés à ce format, soit les types, l'auto-description, la validation et le fameux "round-tripping" mentionné par l'article.
Coté API pour la lecture écriture, ça permettrait de prendre SAX ou Stax et d'en shooter 80% de la complexité.

[jfchretien]

Ca c'est le piège...
Pousses ton raisonnement un peu plus et tu finiras par te dire qu'après tout, on peut bien oublier tout ça et bosser avec du fichier plat et définir la structure qu'on veut .
Je peux effectivement formaliser mes idées et les appliquer dans le monde tel qu'il est aujourd'hui, mais je serai le seul à le faire donc ce n'est pas intéressant du tout en l'absence de norme communément acceptée.

Mon constat est simplement le suivant : coder un parseur pour un document d'origine externe est franchement fastidieux et merdique. Si on mettait d'accord tout le monde sur une structure qui contiendrait la description du contenu ET les données de façon propre et normalisée, on pourrait générer des parsers validants et efficaces sans effort à partir d'un simple échantillon.

Je parles pas de remplacer XML par autre chose, simplement définir un standard basé sur XML qui résolve de façon élégante 75% des problèmes liés à ce format, soit les types, l'auto-description, la validation et le fameux "round-tripping" mentionné par l'article.
Coté API pour la lecture écriture, ça permettrait de prendre SAX ou Stax et d'en shooter 80% de la complexité.

Encore une fois, XML définit des composantes syntaxiques et/ou sémantiques. Essaye de pousser un peu le typage. Pour toi c'est quoi un type ? Par réflexe tu vas sûrement me citer les différents types liés aux langages informatiques que tu utilises (int, double, char, ...).

Or XML permet de définir des types en rapport avec le langage métier, pas forcément le langage informatique.

Si je t'envoie un XML généré pour traiter des couleurs dans l'univers du graphisme, je vais utiliser un schéma XML avec une balise <couleur standard=""></couleur> pouvant prendre comme attribut PANTONE ou RAL (deux standards de couleurs) et en valeur, la référence de la couleur dans le standard concerné. Pour moi (et mon métier), c'est bien un type formalisé et limité à une liste décrit par les référentiels PANTONE et RAL. Pour toi, ce sera une simple chaine de caractère.

Les types au sens informatique ne sont qu'un tout petit sous-ensemble syntaxique et sémantique de ce qui peut éxister dans le monde réel. Ce que toi tu vois en tant que développeur n'est qu'une conversion d'un type vers un autre type pour le représenter.

Ce qui m'interesse avec XML, c'est de pouvoir formaliser une syntaxe et une grammaire (sémantique) correspondant à mon langage métier.

[Tommy31]

Code JSON :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 {
"DUPONT",
"Jean"
}

Sans savoir à qui il est destiné, il n'est pas traitable. De plus, impossible pour une application de savoir si ça lui est adressé ou non.

L'équivalent serait plutôt ceci:

Code JSON :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 {
   "nom":"DUPONT",
   "prenom":"Jean"
}

[_skip]

Encore une fois, XML définit des composantes syntaxiques et/ou sémantiques. Essaye de pousser un peu le typage. Pour toi c'est quoi un type ? Par réflexe tu vas sûrement me citer les différents types liés aux langages informatiques que tu utilises (int, double, char, ...).

Or XML permet de définir des types en rapport avec le langage métier, pas forcément le langage informatique.

Les types au sens informatique ne sont qu'un tout petit sous-ensemble syntaxique et sémantique de ce qui peut éxister dans le monde réel. Ce que toi tu vois en tant que développeur n'est qu'une conversion d'un type vers un autre type pour le représenter.

Je regrette mais ça ne me contredit en rien.

Car je ne suis pas en train de dire qu'il faut changer XML en un autre format moins riche. Je dis juste que dans le cas d'utilisation très populaire qu'est l'échange de données informatique entre entreprises ( du style importation journalière et consolidation de documents XML de sources et de structures diverses), on profiterait énormément d'une spec plus limitante avec description du contenu *inclue*. Celle-ci elle-même basée sur XML.

Cela constituerait un milieu entre des DTD qui ne décrivent les contraintes que très vaguement et les schémas externes qui sont trop complexes et intrusifs pour les cas simples et cela ouvrirait la porte à la génération simple et efficace de parsers auto-validants.

[Logan Mauzaize]

En même temps, le deuxième sera parsé beaucoup plus vite et toutes les données n'ont pas à être lisibles par des humains.

Je parlais du "Self Describe".

Ca c'est le piège...
Pousses ton raisonnement un peu plus et tu finiras par te dire qu'après tout, on peut bien oublier tout ça et bosser avec du fichier plat et définir la structure qu'on veut .

Sauf que tu parles d'un sous-ensemble d'XML. Il existe donc déjà. Tous comme les outils qui vont avec.
Il suffit juste d'utiliser une grammaire adaptée (XSD ou Relax NG).

Je peux effectivement formaliser mes idées et les appliquer dans le monde tel qu'il est aujourd'hui, mais je serai le seul à le faire donc ce n'est pas intéressant du tout en l'absence de norme communément acceptée.

Le problème c'est qu'on résonne trop en termes de structure Objet. Dans ce cas tu peux considérer que JAXB est la norme que tu cherches ...

Mon constat est simplement le suivant : coder un parseur pour un document d'origine externe est franchement fastidieux et merdique. Si on mettait d'accord tout le monde sur une structure qui contiendrait la description du contenu ET les données de façon propre et normalisée, on pourrait générer des parsers validants et efficaces sans effort à partir d'un simple échantillon.

Un parser validant c'est juste un parser auquel on a spécifié la(es) grammaire(s) à utiliser.

Je parles pas de remplacer XML par autre chose, simplement définir un standard basé sur XML qui résolve de façon élégante 75% des problèmes liés à ce format, soit les types, l'auto-description, la validation et le fameux "round-tripping" mentionné par l'article.
Coté API pour la lecture écriture, ça permettrait de prendre SAX ou Stax et d'en shooter 80% de la complexité.

Je trouve très bien d'avoir quelque chose de souple et normer que l'on peut spécialiser, sans avoir à le normer.

Pour le "round tripping", faudrait déjà que les applications lise et écrive les mêmes données. Et pour celles qui le font je pense qu'elle respecte ce principe sinon c'est qu'elles perdent de l'information.

L'équivalent serait plutôt ceci:

Code JSON :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 {
   "nom":"DUPONT",
   "prenom":"Jean"
}

C'est pas plutôt une map que tu viens de me décrire ?
(J'y connais rien à JSON, je ressors juste ce que je me rappelle avoir lu à ce sujet).

[_skip]

Je parlais du "Self Describe".
Sauf que tu parles d'un sous-ensemble d'XML. Il existe donc déjà. Tous comme les outils qui vont avec.
Il suffit juste d'utiliser une grammaire adaptée (XSD ou Relax NG).

Tu veux savoir sur près de 130 entreprises que je compte parmi mes clients, combien ont une exportation au format XML avec un schéma et des namespaces?

Le problème c'est qu'on résonne trop en termes de structure Objet. Dans ce cas tu peux considérer que JAXB est la norme que tu cherches ...

Cette techno doit être la 2 ou 3e plus moisie que je connaisse en java. A tel point que j'ai renoncé à l'utiliser. A moins qu'elle ne se soit beaucoup amélioré en 5 ans elle amène presque plus de problèmes qu'elle n'en résout.

Un parser validant c'est juste un parser auquel on a spécifié la(es) grammaire(s) à utiliser.

Et bien dans ce cas je me demande pourquoi il n'existe presque aucun parser qui implémente la validation XSD à 100% feature complete. Sûrement parce que c'est aussi simple que tu le dis.
Et va trouver des parsers XSD aware en dehors du monde java, c'est pas si facile...

Je bosse presque au quotidien avec des flux XML, et je peux juste dire que dans le cas d'échange et de consolidation de données, les choses pourraient être grandement simplifiées si on avait un modèle de document XML auto-décrit et une façon moins élastique de représenter les choses.

[jfchretien]

Je regrette mais ça ne me contredit en rien.

Car je ne suis pas en train de dire qu'il faut changer XML en un autre format moins riche. Je dis juste que dans le cas d'utilisation très populaire qu'est l'échange de données informatique entre entreprises ( du style importation journalière et consolidation de documents XML de sources et de structures diverses), on profiterait énormément d'une spec plus limitante avec description du contenu *inclue*. Celle-ci elle-même basée sur XML.

Cela constituerait un milieu entre des DTD qui ne décrivent les contraintes que très vaguement et les schémas externes qui sont trop complexes et intrusifs pour les cas simples et cela ouvrirait la porte à la génération simple et efficace de parsers auto-validants.

Tu veux savoir sur près de 130 entreprises que je compte parmi mes clients, combien ont une exportation au format XML avec un schéma et des namespaces?

...

Et bien dans ce cas je me demande pourquoi il n'existe presque aucun parser qui implémente la validation XSD à 100% feature complete. Sûrement parce que c'est aussi simple que tu le dis.
Et va trouver des parsers XSD aware en dehors du monde java, c'est pas si facile...

Je bosse presque au quotidien avec des flux XML, et je peux juste dire que dans le cas d'échange et de consolidation de données, les choses pourraient être grandement simplifiées si on avait un modèle de document XML auto-décrit et une façon moins élastique de représenter les choses.

Je commence à comprendre ou tu veux en venir. Effectivement dans certains cas ce peut être une bonne chose, dans la mesure ou comme tu le dis, on reste sur un document 100% XML.

Mon seul soucis étant qu'il faut créer une balise racine pour avoir un code de type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
<xml...>
<conteneur>
   <xsd...>
   ...
   </xsd>
   <contenu>
   ...
   </contenu>
   <xsl...>
   ...
   </xsl>

Je sais pas si ce serait vraiment conforme XML car il faudrait utiliser deux à trois namespaces (un pour xsd, un pour xsl et éventuellement un pour la partie contenu) ou un seul namespace pour conteneur. Mais dans ce cas comment ajouter le namespace pour contenu dans un namespace normalisé. Merci aux spécialiste du format de m'éclairer car là je patauge complet.

Après je vois déjà certains te dire qu'on peut faire pareil en mettant le doc xml, le xsd et le xslt dans une archive tar ou zip, comme un document openXML... Mais ce n'est pas ton propos donc on oublie.

[Logan Mauzaize]

Tu veux savoir sur près de 130 entreprises que je compte parmi mes clients, combien ont une exportation au format XML avec un schéma et des namespaces?

Hélàs, la pratique l'emportera toujours sur le bon sens, y compris et surtout les bonnes pratiques.
Cependant quand tu as l'initiative de créer un nouveau "schéma" (ou que tu es suffisamment en amont du déploiement), insistes pour ce que ce soit mis en place et suivant tes recommandations que tu auras bien décrites dans un "XML Developer Guide" ;-)

Cette techno doit être la 2 ou 3e plus moisie que je connaisse en java. A tel point que j'ai renoncé à l'utiliser. A moins qu'elle ne se soit beaucoup amélioré en 5 ans elle amène presque plus de problèmes qu'elle n'en résout.

Il y a 5 ans je faisais pas de Java donc je peux pas trop te dire. Mais je te donnerai la même réponse que pour XML, ca dépend de ce que tu veux en faire. Sur des projets, je sérialize/désérialize des objets Java plus ou moins complexes sans soucis. Notre seul problème pour le moment mais je pense que JAXB a une option pour ça, c'est la re-synchronisation des classes Java quand le schéma évolue, on doit recopier tout ce qu'on a rajouté manuellement.

Et bien dans ce cas je me demande pourquoi il n'existe presque aucun parser qui implémente la validation XSD à 100% feature complete. Sûrement parce que c'est aussi simple que tu le dis.
Et va trouver des parsers XSD aware en dehors du monde java, c'est pas si facile...

Je plaide complètement mon côté "Je connais que Java". Pour moi, ca devrait être la norme pour une librairie XML : SAX, StaX, DOM, XPath, XSD/DTD, XSLT. Bref tout ce que tu retrouves sous JAXP (Java API for XML Processing).

Après je connais pas XSD sur le bout des doigts, mais je reconnais qu'il y ait des vérifications très complexes, voir trop complexes pour une simple API de manipulation XML. Seulement ce que tu préconises reste très simple à exprimer et vérifier.

Je bosse presque au quotidien avec des flux XML, et je peux juste dire que dans le cas d'échange et de consolidation de données, les choses pourraient être grandement simplifiées si on avait un modèle de document XML auto-décrit et une façon moins élastique de représenter les choses.

Qu'est-ce que tu entends par "un modèle de document XML auto-décrit" ?

Je commence à comprendre ou tu veux en venir. Effectivement dans certains cas ce peut être une bonne chose, dans la mesure ou comme tu le dis, on reste sur un document 100% XML.

Mon seul soucis étant qu'il faut créer une balise racine pour avoir un code de type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
<xml...>
<conteneur>
   <xsd...>
   ...
   </xsd>
   <contenu>
   ...
   </contenu>
   <xsl...>
   ...
   </xsl>

Je sais pas si ce serait vraiment conforme XML car il faudrait utiliser deux à trois namespaces (un pour xsd, un pour xsl et éventuellement un pour la partie contenu) ou un seul namespace pour conteneur. Mais dans ce cas comment ajouter le namespace pour contenu dans un namespace normalisé. Merci aux spécialiste du format de m'éclairer car là je patauge complet.

Après je vois déjà certains te dire qu'on peut faire pareil en mettant le doc xml, le xsd et le xslt dans une archive tar ou zip, comme un document openXML... Mais ce n'est pas ton propos donc on oublie.

Ce que tu décris c'est le fonctionnement actuel ... c'est-à-dire trois fichiers. Comme dans beaucoup d'autres "technologies" :

1. xsd : un descripteur de données (structure, classe, etc.)
2. contenu : les données
3. xsl : un traitement

[davcha]

Mon impression sur cette discussion est la suivante :

1: Le rapport entre la masse de travail à fournir pour "bien utiliser" xml et le temps disponible pour effectuer tout le boulot n'est peut-être pas en la faveur d'une bonne utilisation d'xml, dans la pratique.

La question que je me pose, du coup, est la suivante :

Peut-il exister un format de donnée qui réponde aux critères énoncés dans le papier et qui ne présente pas le problème 1 ?

Est-ce que la description de données n'est pas, intrinsèquement, quelque chose qui prend du temps, qu'on peut ne pas respecter, etc... ?

[jfchretien]

Ce que tu décris c'est le fonctionnement actuel ... c'est-à-dire trois fichiers. Comme dans beaucoup d'autres "technologies" :

1. xsd : un descripteur de données (structure, classe, etc.)
2. contenu : les données
3. xsl : un traitement

En fait ma question est : "est-il possible d'avoir XSD + XML (+ XSL éventuellement) dans un seul fichier XML plutôt que dans plusieurs ? Donc est-il possible d'utiliser plusieurs namespaces dans un seul fichier XML ?
Si oui, serait-il interessant d'avoir des fichiers XML autodécrits avec une norme/namespace XSD simplifiée ?
En clair, ton unique fichier XML, contient à la fois le descripteur, les données et éventuellement les traitements.

[Logan Mauzaize]

Mon impression sur cette discussion est la suivante :

1: Le rapport entre la masse de travail à fournir pour "bien utiliser" xml et le temps disponible pour effectuer tout le boulot n'est peut-être pas en la faveur d'une bonne utilisation d'xml, dans la pratique.

La question que je me pose, du coup, est la suivante :

Peut-il exister un format de donnée qui réponde aux critères énoncés dans le papier et qui ne présente pas le problème 1 ?

Est-ce que la description de données n'est pas, intrinsèquement, quelque chose qui prend du temps, qu'on peut ne pas respecter, etc... ?

J'ai envie de dire le format original de la donnée !? Le soucis (mais tout l'intérêt) d'un système informatique est justement la transformation et la représentation sous une forme nouvelle et correlée des données.

Sinon tout format correctement outillé et/ou capable de comprendre d'autres formats de descripteur devraient couvrir ces besoins. Par exemple, générer un schéma à partir d'un fichier source .java ou .h. Ce que font les APIs de (dé)sérialisation des langages modernes.

Ceci dit l'avantage d'XML est qu'il utilise la même notation pour décrire la structure, les données et les transformations qui permettent de passer d'une structure à une autre.

En fait ma question est : "est-il possible d'avoir XSD + XML (+ XSL éventuellement) dans un seul fichier XML plutôt que dans plusieurs ? Donc est-il possible d'utiliser plusieurs namespaces dans un seul fichier XML ?

On peut très bien utilisé autant de namespace que l'on veut, on peut même les mixer. Exemple <a:element b:attribut="c:value" xmlns:a="namespace A" xmlns:b="namespace B" xmlns:c="namespace C"/>.

Si oui, serait-il interessant d'avoir des fichiers XML autodécrits avec une norme/namespace XSD simplifiée ?
En clair, ton unique fichier XML, contient à la fois le descripteur, les données et éventuellement les traitements.

Je vois pas trop en quoi ca serait interressant ?

La validation de la grammaire sert juste à définir si un traitement bien conçus pour cette grammaire peut fonctionner. Il est évident que lancer un traitement sur des entrées non valides n'a pas de sens. Au mieux ca part en erreur au pire ca sort n'importe quoi sans que personne ne s'en rende compte.
Je vois pas ce que pourrait faire une application (ou une personne) avec une grammaire qu'il ne connait pas et savoir si un fichier est valide ou non au sens de cette grammaire (à part un validateur).
Et en l'état, les validateurs que je connaisse repose sur une séparation des deux. Même s'il est possible par API de le faire à la condition que le descripteur arrive avant les données sur le flux.

Concernant les traitements, c'est aussi peu interressant. Les données sont émises par un système, et le traitement est conçu par le receveur. Sinon c'est le système émetteur qui ferait les traitements. La seule utilitée ce serait pour "compresser" les données, mais je pense que les algorithmes dédiés font beaucoup mieux !
Et pareillement les outils de transformation que je connais repose sur une séparation des feuilles XSL et des données. Mais on peut également par API programmée une séparation des deux.

[GrandFather]

En fait ma question est : "est-il possible d'avoir XSD + XML (+ XSL éventuellement) dans un seul fichier XML plutôt que dans plusieurs ? Donc est-il possible d'utiliser plusieurs namespaces dans un seul fichier XML ?

Bien sûr, et c'est même pour cela que les espaces de noms existent, pour éviter les collisions de noms dans un document intégrant plusieurs vocabulaires XML différents. Un document ODF, par exemple, comporte typiquement une quinzaire d'espace de noms correspondant à des domaines d'application souvent très différents (SVG, Dublin Core, xlink, etc.)

En clair, ton unique fichier XML, contient à la fois le descripteur, les données et éventuellement les traitements.

Théoriquement possible, en pratique inexploitable : ces différentes composantes sont généralement générées et exploitées à des « strates » (ou tiers) différentes du système d'information ; ainsi, les données XML seront généralement directement produites par le SGBDR, tandis que le code XSLT sera géré lui par la couche présentation.

[davcha]

Ce que je voulais dire c'est que derrière XML, il y a surtout beaucoup de théorie des langages, des automates, transducteurs et autres joyeusetés du genre.

Définir un format pour déterminer si un fichier est "bien écrit", conforme à une norme définie, que ce soit dans un fichier externe ou non... C'est comme définir un langage L pour reconnaître qu'un texte est bien écrit dans un langage L'.

Ce sont des choses qui, en pratique, prennent du temps. Académiquement, c'est merveilleux. Mais le retour immédiat sur "investissement" dans l'industrie.... Faut le chercher loin. Et c'est là qu'est le problème finalement, non ?