génération code et héritage complexe

Bonjour à tous,

Je ne sais pas si c'est le bon endroit pour poster, aussi n'hésitez pas à déplacer mon post. Voici mon problème :
Nous avons récemment généré des classes c++ à partir de documents xsd lourds et nous avons un problème entre les attributs des classes mère/fille :

Par exemple, nous avons classe de base (appelons la A) qui a des attributs (nom, id...). Puis une classe B qui hérite de la classe A <xs:extension base="classeA"> qui définit d'autres attributs (forme, usage...)

Le problème survient dans le parse de nos fichiers xml : le parser xerces associé commence par parcourir les attributs des classes mères, puis lorsqu'il ne trouve pas de match rend la main à la classe fille qui a son tour parcours ses attributs. Ainsi, si dans le xml les attributs ne sont pas ordonné dans l'ordre de l'héritage, on ne parvient pas à lire ces attributs.
Typiquement, si "usage" se trouve avant "nom" on aura un bug de parse.

Voilà, je suis débutant dans ce domaine, et je me demandais si quelqu'un avait déjà eu le même soucis, et si oui avait des pistes vers lesquelles m'orienter.

Cdlt,
Pdw.

Le bug de parse est dû simplement au fait que le document XML est invalide.
Si B est une extension du type A, alors les propriétés de B doivent apparaître après celles de A dans le document XML. C'est une règle de XSD, et C++ et Xerces n'ont pas leur avis à donner.

Merci beaucoup Thelvin pour ta réponse et les explication sur xsd.

Je trouve cela particulièrement restrictif pour l'utilisateur en revanche (notamment dans les cas complexes comme le notre où l'on peut avoir plusieurs niveau d'héritage, des extensions externes et des utilisateurs pas forcement expert dans le domaine).

Je suppose que le plus simple sera de notre côté de créer une méthode pour transformer un document invalide en document valide en réorganisant ses balises.

++.

Ou simplement ne pas demander à vos utilisateurs de taper du XML.
Que sont devenus les clickodrômes ?

Je suis d'accord, cela dit, que le système d'extension de types de XSD est extrêmement restrictif. Si on veut faire autrement, eh ben, il y a qu'à définir des types différents sans lien les uns avec les autres. C'est lourd, mais c'est l'usage en terme d'analyse grammaticale, le seul pilier de XSD.
XML n'est pas spécialement pensé avec le data-binding en tête, donc d'autant moins avec l'héritage de classes, et ça se voit bien avec XSD. Un autre système mieux prévu pour, par exemple que je connais JAXB ou Xstream, sera plus pragmatique.

Le problème de l'édition xml va surtout se poser lors des exports. On travail avec des chercheurs et chacun peut définir un fichier xsd qui concerne son domaine et qui doit étendre un type de base (pas le choix sur ce point, malheureusement)..Évidemment, un même objet peut-être étendu plusieurs fois, à des niveaux différents et du coup, on peut se retrouver avec des éléments xml ajoutés à la suite d'un élément d'un fichier déjà existent, avec aucun contrôle sur la façon dont le xml est managé.

Oui, je sais, je suis pas fan du tout non plus !
Au final, il va peut-être falloir effectivement s'appuyer sur une autre techno, je vais aller jeter un œil a jabx et xstream.

Encore merci.

"Aucun contrôle sur la façon dont le XML est managé" je ne vois pas pourquoi. Même en rajoutant à la porc des champs en-veux-tu-en-voilà avec des extensions XSD, il n'existe aucune difficulté pour les ajouter dans l'ordre d'insertion.

... Sauf si les gens en question tapent à la main les XSD et les XML en question et ne "devinent" pas les règles. Mais oui, forcément, quand on sait pas ce qu'on fait ça marche pas, il faut pas faire faire du XML à quelqu'un qui ne fait pas de XML.

Citation:

---

Sauf si les gens en question tapent à la main les XSD et les XML en question et ne "devinent" pas les règles.

---

C'est exactement ça ;).