Mise sur les rails vite et bien

Version imprimable

09/09/2014, 11h18
jibe74

Mise sur les rails vite et bien

Bonjour,

La question intéressera certainement beaucoup de monde : alors que je n'ai que de vagues notions de XML, je vais avoir besoin d'en générer un dans le cadre d'un protocole de communication de données avec un organisme. Cet organisme me fournit des schémas XSD et une tonne de documents divers où il est bien difficile de trouver les quelques éléments nécessaires pour créer le XML de communication tant ils sont dispersés.

Je me dis que je devrais arriver, à partir du XSD correspondant aux données que je dois transmettre, à recréer plus ou moins automatiquement le XML en m'aidant d'une bonne bibliothèque de conversion.

D'où mes questions :

1 - Que me conseillez-vous de lire comme doc, tutos ou autres cours en ligne pour acquérir rapidement les notions qui me sont nécessaires sans me fourvoyer dans un tas de trucs certainement très intéressants mais qui ne me serviront à rien (par exemple, je n'ai aucun besoin de tout ce qui concerne le XSLT) ?

2 - Y a-t-il des bibliothèques à avoir absolument ou au contraire à éviter, compte tenu de cette application précise ? (je cherche de préférence une bibliothèque sous forme de sources C/C++, que je pourrai utiliser avec n'importe quel compilateur ou environnement de développement. Licence libre pas trop restrictive sur la redistribution, genre GPL, zlib, MIT...)

3 - L'idée de générer le XML par conversion/transformation du XSD est-elle bonne ? D'une part ça me paraitrait assez logique d'après mes vagues notions, mais d'autre part je ne trouve pas grand chose d'intéressant sur ce sujet, alors qu'il y a des tonnes de documents expliquant la conversion XML->XSD. Aurais-je très mal compris ce que je crois savoir ?

Merci d'avance pour vos conseils.

J'ai eu à travailler dans un protocole xml.
Il faut comprendre que XML est un format de donnée, et qu'il possède des outils

XSD définit un schéma de document(XML Schema Definition). En ce sens, il dit comment un fichier XML doit être écrit pour lui correspondre.
Le fichier XSD permet de valider "après coup".
C'est à toi d'utiliser conformément à ce schéma une bibliothèque de génération de fichier xml.
Pour info, XSD est un format XML, et un fichier xsd peut lui-même être validé.

XSLT permet de générer un xml à partir d'un autre.
Par exemple ca peut insérer des valeurs, des noeuds, en supprimer, en modifier, etc
Avec plus de travail, ca peut aussi permettre de produire/lire un fichier non xml, mais relativement structuré (csv, par exemple).
Il est très peu problable que tu t'en serves dans le cadre du protocole.

Dans ton cas, tu va juste créer un fichier à partir de variable en mémoire dans ton programme, il suffit d'avoir une fonction bien fichue.

Par exemple, ca peut être quelque chose comme ceci:
Code:

1 2 3 4 5 6 7 void indexesToXml(std::ostream& target, std::vector<int> indexes) { target << "<indexes>\n"; for(int index : indexes) { target << "<index>"<< i << "</index>\n"; } target << "</indexes>" << std::endl; }
Cela dit, je mettrai personnellement une telle fonction en membre privé d'une classe XMLIndexReport, qui aurait pour méthode publique un toXml();

Je n'ai pas d'idée de lib xml à conseiller ou déconseiller.

Il me semble qu'on a une rubrique dédiée à l'XML, avec faq, cours et forum

09/09/2014, 15h39
jibe74

Merci :)

Grosso modo, c'est à peu près ce que je pensais savoir, et ton explication me permet de voir clairement ce que j'entrevoyais à travers le brouillard.

Citation:

Envoyé par leternel

Le fichier XSD permet de valider "après coup".

C'est bien ce que j'avais cru comprendre. Cela confirme-t-il que mon idée est complètement farfelue ?

Si j'ai posé la question de cette conversion, c'est pour deux raisons :
1 - La très mauvaise raison que ça m'arrangerait bien :lol: Le protocole est assez complexe et très longuement mais extrèmement mal décrit, à tel point que c'est presque exclusivement les XSD qui vont me permettre de le comprendre et de générer le bon XML. Donc, de là à me dire que si un code pouvait le faire directement, j'ai allègrement franchi le pas !
2 - Si je n'ai pas trouvé grand chose sur ce point, il y a quand même quelques trucs qui m'ont laissé croire que ce n'est peut-être pas vraiment idiot, voire une bonne piste, comme cette discussion ou ce convertisseur...

Alors, dois-je cesser de rêver et me mettre au boulot, probablement en procédant surtout par essais/erreurs en m'aidant de validation après coup par les XSD fournis, ou cela vaut-il la peine de creuser un peu le sujet XSD -> XML ?

Citation:

Envoyé par leternel

Je n'ai pas d'idée de lib xml à conseiller ou déconseiller.

Donc, tu n'en utilises pas ? Efectivement, tout ça n'est pas très complexe, mais je me dis toujours que, si quelque chose existe déjà et donne toute satisfaction, à quoi bon réinventer l'eau chaude ?

Citation:

Envoyé par leternel

Il me semble qu'on a une rubrique dédiée à l'XML, avec faq, cours et forum

Oui, et en général ce qu'on trouve ici est assez bien fait. Mais je n'y ai rien trouvé sur XSD->XML :P
10/09/2014, 20h43
ternel

XSD -> XML, tu pourrais peut-être trouver un générateur aléatoire.

Ca peut donner une idée pour commencer.
Après, il faudra générer proprement tes messages réels, mais ça peut faire un exemple de ce que tu veux produire.
12/09/2014, 09h05
jibe74

Bonjour,

Ok, donc ce n'est pas la solution miracle dont je rêvais ! Bon, je vais me mettre au boulot et me consoler en me disant que ça va satisfaire ma tendance au NIH !

Merci pour tes explications.
12/09/2014, 09h59
jibe74

:yaisse2:

Mon idée n'est peut-être pas si mauvaise... En tous cas, d'autres l'ont déjà eue : on vient de m'orienter là-dessus. Je vais essayer de voir ce que ça donne...
12/09/2014, 10h02
ternel

Ta solution miracle n'existe pas, parce qu'un XML porte de l'information de fond, tandis qu'XSD donne une forme.
Aucun programme n'est assez puissant pour deviner le fond à partir de la forme seule.

C'est ton travail de développement qui produira le fond, et il faudra que tu respectes la forme.
Une bonne bibliothèque d'écriture XML t'aidera à le faire, pas une mauvaise.
Mon soucis, c'est que je ne connais que quelques bibliothèques XML pour Java.
Cela dit, mon ressenti est que si tu as seulement besoin d'émettre de l'XML, tu n'as pas particulièrement besoin de quoique ce soit.

un fstream, et un peu de rigueur.
Envisage une méthode asXML dans tes classes, ou de reproduire la mécanique de l'operator<< des ostreams, mais sur une classe autre (un XML, par exemple)
12/09/2014, 10h35
ternel

A priori, ça a l'air sympa: l'outil génère des classes pour toi.
Nickel, c'est la version automatisée de ce que tu aurais eu à faire.

Attention tout de même, ce sont des classes spécifique à xml que tu obtiendras, je ne suis pas certain que tu doivent les utiliser ailleurs dans le code
12/09/2014, 12h00
jibe74

Citation:

Envoyé par leternel

Ta solution miracle n'existe pas, parce qu'un XML porte de l'information de fond, tandis qu'XSD donne une forme.
Aucun programme n'est assez puissant pour deviner le fond à partir de la forme seule.

Oui, je me doutais bien que le miracle n'irait pas jusque là ! Mais la forme est tellement mal décrite dans les tonnes de documents fournis que le moyen le plus sûr est de la déduire des XSD. C'est à partir de là que je me suis dit que si toute la structure du code C pouvait être générée, je n'aurais plus qu'à me débrouiller pour intégrer les bonnes données aux bons endroits. Ça ne simplifie pas vraiment le problème de la mauvaise doc, mais ça en élimine déjà une bonne partie !

Citation:

Envoyé par leternel

Attention tout de même, ce sont des classes spécifique à xml que tu obtiendras, je ne suis pas certain que tu doivent les utiliser ailleurs dans le code

Je ne sais pas si je comprends bien ta mise en garde, mais j'ai bien conscience que ça va me générer le XML bien formé conformément au schéma à partir des données que je vais passer en argument, mais que ça ne fera rien de plus, et que c'est bien à moi de sélectionner les bonnes données dans la base, ce en quoi ces classes automatiquement générées ne me seront d'aucun secours (si ce n'est éventuellement de m'éviter d'en oublier).

J'ai téléchargé, installé et je commence à regarder comment c'est fait. Au premier abord, ça a bien l'air d'être aussi intéressant que le laisse croire la doc, mais c'est encore trop tôt pour que je puisse être plus affirmatif : pas pu aller au bout de l'exemple le plus simple à cause d'un fichier manquant, probablement mal adressé...

J'essaierai de ne pas oublier de tenir au courant. Si ça tient vraiment ses promesses, c'est un truc bien intéressant.
15/09/2014, 10h52
ternel

En gros, mon dernier avertissement voulait dire que à l'usage, ca va te générer des classes qui auront plus ou moins pour nom celui des tags xml.
Par exemple, tu pourrais avoir un tag <bidule> dans l'XML, qui va impliquer une classe bidule.
Cette classe précise n'est qu'un avatar de l'XML, ce n'est pas la classe métier bidule, qui doit être construite indépendamment de sa représentation xml.

Notamment parce que tout le code fonctionnel n'a pas à être recompilé quand la structure de l'XML va être changé par le protocole.

D'ailleurs si ce n'est pas fait par le générateur, il faudra mettre toutes ses classes lié à XML dans un namespace dédié (au pif projet::xml)
15/09/2014, 15h51
jibe74

Bonjour,

Citation:

Envoyé par leternel;7964405Cette classe précise n'est qu'un avatar de l'XML, ce n'est pas la classe métier [I

bidule[/I], qui doit être construite indépendamment de sa représentation xml.

Notamment parce que tout le code fonctionnel n'a pas à être recompilé quand la structure de l'XML va être changé par le protocole.

Ok, merci pour l'avertissement !

D'ailleurs, ce truc est une usine à gaz qui permet tout un tas de choses (je ne dirais pas que ça tond la pelouse et fait le café, mais presque !) que je vais mettre plus de temps à découvrir comment l'utiliser correctement qu'à me débrouiller sans ! C'est peut-être très bien pour ceux qui font beaucoup de XML, mais l'investissement en temps nécessaire d'apprentissage ne me semble pas rentable pour une utilisation occasionnelle.

Merci encore pour tes précieux conseils !

Dans l'absolu, écrire de l'XML, c'est quasiment limité aux deux fonctions suivantes:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
//suppose std::
string asXmlNode(string const& tag) {
    return "<" + tag + "/>";
}
 
string asXmlNode(string const& tag, string const& value) {
    return "<" + tag + '>' + value + "</" + tag + '>';
}
 
string asXmlNode(string const& tag, string const& value, map<string, string> const& attributs) {
    ostringstream stream;
    stream << '<' << tag;
    for (pair<string, string> const& a : attributs) {
        stream << ' ' << a.first << '="' << a.second << '"';
    }
    stream << '>' << value << "</" << tag << '>';
    return stream.str();
}

Ensuite, il s'agit d'ajouter de l'indentation et des fins de ligne aux bons endroits.

Amuse-toi bien!

15/09/2014, 17h59
jibe74

Oui, mon inexpérience dans ce domaine et le volume du cahier des charges associé à sa très mauvaise présentation m'ont fait prendre peur d'avoir une vision beaucoup trop simpliste du XML. Mais finalement, tu confirmes qu'il n'y a rien de compliqué et donc que je me suis inquiété pour rien : ça se réduit à des données incluses dans des balises, avec d'éventuelles imbrications. Rien de sorcier donc, et nul besoin de bibliothèques ou d'utilitaires sophistiqués !

Je ne vais donc pas chercher plus loin, et me contenter d'écrire les quelques fonctions nécessaires inspirées des tiennes !

Merci encore ! :)