création xsd : cannot resolve type definition

Version imprimable

Salut,

je n'ai pas utilisé xsd depuis ~6 ans, j'essaye de valider un xml (relativement simple), et bien sûr ça passe pas : mon xsd n'est même pas valide :aie:

Voilà à quoi ressemble un xml valide simple:

Code:

1
2
3
4
5
6
7
8
9
10
11
<List file="toto.h">
  <Node name="MyNode1">
    <Member name="abc" type="bool" />
    <Member name="def" type="int32" collection="array" maxsize="42" />
  </Node>
  <Node name="MyNode2">
    <Member name="abc" type="int32" min="0" max="8" />
    <Member name="def" type="float64" decimals="5" />
  </Node>
  <Node name="MyNode3" />
</List>

Et les règles dégrossises:
- un xml contient un List avec un file
- le List contient des Node
- chaque Node a un name et peut contenir des Member
- Member a forcément un nom
- Member a forcément un type dans la liste bool, int32, float64
- Certains types peuvent avoir des attributs supplémentaires, certains optionnels, d'autres pas
- Member peut avoir une collection, dans ce cas il doit avoir un maxsize

Voilà où je suis rendu (qui est surement moche):

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="Integer_1_10">
	<xs:restriction base="xs:unsignedByte">
		<xs:minInclusive value="1" />
		<xs:maxInclusive value="10" />
	</xs:restriction>
</xs:simpleType>
<!-- Collections -->
<xs:simpleType name="BaseCollection">
	<xs:restriction base="xs:string">
		<xs:enumeration value="array" />
		<xs:enumeration value="vector" />
	</xs:restriction>
</xs:simpleType>
<xs:complexType name="Collection">
	<xs:attribute name="name" type="xs:string" use="required" />
	<xs:attribute name="collection" type="BaseCollection" use="required" />
	<xs:attribute name="maxsize" type="xs:unsignedInt" use="required" />
</xs:complexType>
<!-- Types -->
<xs:complexType name="Bool">
	<xs:attribute name="name" type="xs:string" use="required" />
	<xs:attribute name="type" type="xs:string" fixed="bool" use="required" />
</xs:complexType>
<xs:complexType name="Int32">
	<xs:attribute name="name" type="xs:string" use="required" />
	<xs:attribute name="type" type="xs:string" fixed="int32" use="required" />
	<xs:attribute name="min" type="xs:int" use="optional" />
	<xs:attribute name="max" type="xs:int" use="optional" />
</xs:complexType>
<xs:complexType name="Float64">
	<xs:attribute name="type" type="xs:string" fixed="float64" use="required" />
	<xs:attribute name="decimals" type="Integer_1_10" use="required" />
</xs:complexType>
 
<!-- Collection of types -->
<xs:complexType name="Int32Collection">
	<xs:complexContent>
		<xs:extension base="Int32">
			<xs:attribute name="collection" type="BaseCollection" use="required" />
			<xs:attribute name="maxsize" type="xs:unsignedInt" use="required" />
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
 
<xs:element name="Member">
	<xs:complexType>
		<xs:choice>
			<xs:element name="Member" type="Bool" />
			<xs:element name="Member" type="Int32" />
			<xs:element name="Member" type="Int32Collection" />
			<xs:element name="Member" type="Float64" />
		</xs:choice>
	</xs:complexType>
</xs:element>
 
<xs:element name="Node">
	<xs:complexType>
		<xs:sequence>
			<xs:element name="Member" type="Member" />
		</xs:sequence>
		<xs:attribute name="name" type="xs:string" use="required" />
	</xs:complexType>
</xs:element>
 
<xs:complexType name="List">
	<xs:sequence>
		<xs:element name="Node" type="Node" />
	</xs:sequence>
	<xs:attribute name="file" type="xs:string" use="required" />
</xs:complexType>
 
</xs:schema>

L'idée, si tenté que cela soit possible, était de créer différent types pour supporter les cas, puis avoir un méta-type qui soit un type parmi ceux-là et utilisé comme sequence pour Node::Member. :cfou:

Seulement quand je le teste sur http://www.utilities-online.info/xsd.../#.WqK3yujFKUk

Citation:

Error line 69 : cannot resolve the name "Member"

Qui est pourtant déclaré un peu plus haut.
Je suis peut-être proche du résultat, ou pas du tout, ou ce que je veux faire est impossible, mais ça fait bien 2h que je bloque à ce stade maintenant, toute aide est la bienvenue !

Citation:

Error line 69 : cannot resolve the name "Member"

Ceci allude aux lignes pour la définition de Member, je pense:

Citation:

Code:

1
2
3
4
5
6
7
8
9
10
<xs:element name="Member">
	<xs:complexType>
		<xs:choice>
			<xs:element name="Member" type="Bool" />
			<xs:element name="Member" type="Int32" />
			<xs:element name="Member" type="Int32Collection" />
			<xs:element name="Member" type="Float64" />
		</xs:choice>
	</xs:complexType>
</xs:element>

Pas seulement qu'il n'y a pas Member comme enfant d'un parent qui s'appelle Member comme les lignes signifient, mais plus gravement l'élément si je peux deviner l'intention, le Member définit globalement ne peut pas acquérir un type multiple au choix - ce n'est pas permis pour w3c schéma. Pour cette raison, les constructions pour Bool, Int32, Int32Collection et Float64 sont rendues inutilisables. La raison plus profonde encore c'est que le w3c schéma exprime mal, voire impossible d'exprimer, les contraints dits "co-occurrence constraints" qui sont partout dans ce désigne conçu du schéma. Si on veut rester dans le cadre du w3c schéma, il faut tout au moins au premier temps sacrifier ces "co-occurrence constraints". Faites un schéma strictement valable pour valider les instances de xml, et puis revenez aux "co-occurrence constraints" après.

Ceci est une version possible pour une base concrète.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
<xs:schema version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema">
 
<!-- [6] Define type Member. -->
<xs:complexType name="Member">
    <xs:attributeGroup ref="requiredGroup" />
    <xs:attributeGroup ref="collectionGroup" />
    <xs:attributeGroup ref="Int32Group" />
    <xs:attribute name="decimals" type="Integer_1_10" use="optional" />
</xs:complexType>
 
<!-- [5] Regrouping some attributes for clarity. -->
<xs:attributeGroup name="requiredGroup">
    <xs:attribute name="name" type="xs:string" use="required" />
    <xs:attribute name="type" type="type" use="required" />
</xs:attributeGroup>
 
<xs:attributeGroup name="collectionGroup">
    <xs:attribute name="collection" type="BaseCollection" use="optional" />
    <xs:attribute name="maxsize" type="xs:unsignedInt" use="optional" />
</xs:attributeGroup>
 
<xs:attributeGroup name="Int32Group">
    <xs:attribute name="min" type="xs:int" use="optional" />
    <xs:attribute name="max" type="xs:int" use="optional" />
</xs:attributeGroup>
 
<!-- [4] Define some attribute's types that are not of any built-in type. -->
<xs:simpleType name="Integer_1_10">
    <xs:restriction base="xs:unsignedByte">
        <xs:minInclusive value="1" />
        <xs:maxInclusive value="10" />
    </xs:restriction>
</xs:simpleType>
 
<xs:simpleType name="BaseCollection">
    <xs:restriction base="xs:string">
        <xs:enumeration value="array" />
        <xs:enumeration value="vector" />
    </xs:restriction>
</xs:simpleType>
 
<xs:simpleType name="type">
    <xs:restriction base="xs:string">
        <xs:enumeration value="bool" />
        <xs:enumeration value="int32" />
        <xs:enumeration value="float64" />
    </xs:restriction>
</xs:simpleType>
 
<!-- [3] This is hard to correct, In any case it shouldn't be element Member containing element Member. Leave type="Member" open for the moment. -->
<!--
<xs:element name="Member">
    <xs:complexType>
        <xs:choice>
            <xs:element name="Member" type="Bool" />
            <xs:element name="Member" type="Int32" />
            <xs:element name="Member" type="Int32Collection" />
            <xs:element name="Member" type="Float64" />
        </xs:choice>
    </xs:complexType>
</xs:element>
-->
 
<!-- [2] Again need to add facets to xs:element name="Member" -->
<xs:complexType name="Node">
    <xs:sequence>
        <!-- xs:element name="Member" type="Member" / -->
        <xs:element name="Member" type="Member" minOccurs="0" maxOccurs="unbounded" />
    </xs:sequence>
    <xs:attribute name="name" type="xs:string" use="required" />
</xs:complexType>
 
<!-- [1] Need to add facets to xs:element name="Node" -->
<xs:complexType name="List">
    <xs:sequence>
        <!-- xs:element name="Node" type="Node" / -->
        <xs:element name="Node" type="Node" maxOccurs="unbounded" />
    </xs:sequence>
    <xs:attribute name="file" type="xs:string" use="required" />
</xs:complexType>
 
<!-- 
     [0] At least, add of course an xs:element for List.
-->
<xs:element name="List" type="List" />
</xs:schema>

Revenons aux contraintes co-occurrence. En restant au w3c schéma, deux solutions envisageables.
[1] Une, valider toutes contraintes co-occurrence par l'application logicielles en contexte (je veux dire classique comme java, dotnet, c, tous quoi) juste après une validation sans, et puis selon le cas, ajouter les valeurs par défaut ou fixes comme "bool" etc... et puis verifer co-occurrence comme @collection et @maxsize etc.
[2] Passer progressivement et doucement au schéma v1.1 qui est tout à fait capable de faire valider ce genre de contraintes à la manière Schematron. Mais ça nous ramène loins.

Voilà ce que je vois le problème relevé!

09/03/2018, 23h18
Bousk

Effectivement j'ai testé en déclarant Member en complexType, ce qui a plus de sens, mais ça échoue également parce que Member a plusieurs fois un noeud Member :(
Je crois que je vois à peu près où tu veux en venir même si j'avoue ne pas comprendre tous les termes :aie:
J'essayerai de transposer ça lundi, merci :)
10/03/2018, 00h57
thelvin

En XSD tu ne peux pas avoir de contrainte du genre "si l'élément <Member> définit une collection, il doit avoir un attribut maxsize, mais sinon, il ne doit pas". Un élément <Member> c'est un élément <Member>, il obéit toujours aux mêmes règles. Son contenu ne fait pas changer ces règles.

Enfin, tu peux, mais alors il faut que dans tes documents XML, l'élément Member ait un attribut xs:type="Int32Collection". Ce qui permet à XSD de décider de son type autrement qu'avec juste son nom. Tu ne choisis pas comment s'appelle cet attribut. Pourquoi pas, au fond, mais en général c'est peu utilisé.

Ce genre de choses deviennent vaguement possible en XSD 1.1, mais :
- XSD 1.1 n'est pas franchement un standard adopté. En général tu ne trouveras rien ni personne pour le gérer.
- Ce n'est pas fait pour. C'est un bricolage tiré d'un effet de bord qui rend cela possible. On n'arrive à rien en décidant d'utiliser une technologie puis en cherchant à la forcer à fonctionner autrement. Si elle ne fonctionne pas comme tu veux, prends-en une ou fais-en une qui fonctionne comme tu veux.

La solution habituelle, c'est de ne pas demander à XSD de vérifier ça. XSD vérifie la grammaire d'un document XML. Ça c'est de la sémantique, ce n'est pas son rayon.
La sémantique c'est le boulot du programme qui va lire le fichier XML pour s'en servir. C'est à ce programme de vérifier que la sémantique du fichier XML est cohérente.
10/03/2018, 08h40
Bousk

Je vois, c'est ce que je craignais : ce que j'avais en tête n'est pas réellement possible :?
Merci pour ces informations, je vais alors simplifier le xsd pour vérifier la syntaxe (qu'un member au lieu d'un Member ne se glisse pas dans le fichier) et améliorer les détections et retours d'erreur lors du parsing du fichier.

Merci à vous deux :)