Discussion :

[hlr]

Voilà mon souci : je suis en train de reprendre des XSD définis par d'autres personnes, et je me pose une question.
Dans le XSD, j'ai ce fragment :

Code :

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

1
2
3
4
	<xs:simpleType name="TauxTVAType">
		<xs:restriction base="xs:double"/>
	</xs:simpleType>
	<xs:element name="TauxTVA" type="tva:TauxTVAType"/>

Ma question est : quel est le réel intérêt de définir l'élément TauxTVA dans ce XSD ?
Lors de l'utilisation, quelles sont les différences entre

Code :

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

          <xs:element minOccurs="0" ref="tva:TauxTVA"/>

et

Code :

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

          <xs:element minOccurs="0" name="TauxTVA" type="tva:TauxTVAType"/>

(à part le fait que dans la 2e déclaration, je peux remplacer le nom de l'élément par autre chose que TauxTVA

Merci de vos réponses

[GrandFather]

Bonjour,

du point de vue de la validation proprement dite, cela revient au même ; par contre, ça ne l'est pas pour ce qui concerne la conception et les possibilités d'évolution du XSD.

on peut imaginer qu'un élément TauxTVA puisse se retrouver en plusieurs endroits du schéma ; dans ce cas, on a tout intérêt à le définir une seule fois comme élément de premier ordre (directement sous xs:schema) puis à le référencer avec l'attribut « ref » partout où c'est nécessaire. Un genre de factorisation, quoi.

[keb83]

tout à fait d'accord avec GrandFa,

sur la forme qu'un xml doit avoir pour satisfaire le schéma, c'est la même chose.

mais si on envisage par exemple une évolution future du format, il sera plus facile d'effectuer les changement en un seul endroit.

j'y vois aussi un autre interet, si le schéma est utilisé pour généré un méta-modèle via un outil automatisé (EMF par exemple) on aboutira pas à la même chose :

dans le cas factorisé : une seul classe représentant l'élément

dans le cas non factorisé : une ribambelle de classes, identiques sauf que leurs noms forment une succession du style NomElem NomElem1 NomElem2 ....
et il est ensuite difficile de gérer efficacement et de façon générique ses différent types qui ont en réalité le même sens dans un fichier xml

bon me suis mal exprimé, mais par exemple, je suis confronté à une série de neufs schémas interdépendants, formant un ensemble de 1500 lignes à peu près, et où l'utilisation d'une factorisation ou alors d'un élément à part est faite de façon assez hasardeuse, le modèle généré était complètement b........ je peux vous dire que j'ai du passé cinq jours à dés-emmêler le truc !

pour résumer, si on veut penser à ceux d'après : définir les types, puis les elem, en préférant faire des ref à des éléments déjà définis plutôt que d'en créer.
Idem pour les attributs qui ont même nom et même sens ...

Bon dimanche

[RomainVALERI]

A ce propos je me demandais : vos remarques concernent-elles uniquement la forme avec des "ref", genre :

Code xml :

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

1
2
3
4
 
<xs:element name="machin" type="xs:string"/>
 
<xs:element ref="machin"/>

ou bien aussi la forme qui consiste à définir des types :

Code xml :

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

1
2
3
4
5
6
 
<xs:simpleType name="type_machin">
   <xs:restriction base="xs:string"/>
</xs:simpleType>
 
<xs:element name="machin" type="type_machin"/>

^^ ?