Discussion :

[Bousk]

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

Voil� � quoi ressemble un xml valide simple:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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.

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

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 !

[tsuji]

Error line 69 : cannot resolve the name "Member"

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

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

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 xsd :

S�lectionner tout - Visualiser dans une fen�tre � part

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�!

[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
J'essayerai de transposer �a lundi, merci

[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.

[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