Discussion :

[MathiasM]

Bonjour,

Je suis en train de decouvrir en profondeur les restrictions avec import de schema avec namespace et je trouve cela bien fastidieux.
Le validateur, Saxon8-3, ne parait pas accepter grand chose, et je voulais savoir si cela etait bien normal.

Je dois avoir deux schemas avec targetNameSpace qualified.

Le 1er :

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
 
 
<?xml version="1.0" encoding="UTF-8"?>
 
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:un="http://www.un"
 
            targetNamespace="http://www.un"
 
            elementFormDefault="qualified"
            attributeFormDefault="unqualified">
 
 
   <xsd:complexType name="totoType">
      <xsd:sequence>
         <xsd:element ref="un:pere"/>
      </xsd:sequence>
   </xsd:complexType>
 
   <xsd:element name="pere" type="un:pereType"/>
 
   <xsd:complexType name="pereType">
      <xsd:sequence>
         <xsd:element ref="un:monElement"/>
      </xsd:sequence>
   </xsd:complexType>
 
   <xsd:element name="monElement" type="un:monElementType"/>
 
   <xsd:complexType name="monElementType">
      <xsd:sequence>
         <xsd:element ref="un:titi"
                      minOccurs="0"
                      maxOccurs="unbounded"/>
      </xsd:sequence>
   </xsd:complexType>
 
   <xsd:element name="titi" type="un:titiType"/>
 
   <xsd:simpleType name="titiType">
      <xsd:restriction base="xsd:string"/>
   </xsd:simpleType>
 
</xsd:schema>

Le second doit restreindre totoType :

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
 
 
<?xml version="1.0" encoding="UTF-8"?>
 
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:deux="http://www.deux"
            xmlns:un="http://www.un"
 
            targetNamespace="http://www.deux"
 
            elementFormDefault="qualified"
            attributeFormDefault="unqualified">
 
   <xsd:import namespace="http://www.un"
               schemaLocation="un.xsd"/>
 
     <xsd:complexType name="totoType">
      <xsd:complexContent>
         <xsd:restriction base="un:totoType">
            <xsd:sequence>
 
               <xsd:element name="pere"
                            minOccurs="0"
                            maxOccurs="1"
                            form="unqualified">
                  <xsd:complexType>
                     <xsd:complexContent>
                        <xsd:restriction base="un:pereType">
                           <xsd:sequence>
 
                              <xsd:element ref="deux:monElement"/>
 
                           </xsd:sequence>
                        </xsd:restriction>
                     </xsd:complexContent>
                  </xsd:complexType>
               </xsd:element>
 
            </xsd:sequence>
         </xsd:restriction>
      </xsd:complexContent>
   </xsd:complexType>
 
   <xsd:element name="monElement" type="deux:monElementType"/>
 
   <xsd:complexType name="monElementType">
      <xsd:complexContent>
         <xsd:restriction base="un:monElementType">
            <xsd:sequence>
               <xsd:element ref="deux:titi"
                               minOccurs="0"
                               maxOccurs="1"/>
            </xsd:sequence>
         </xsd:restriction>
      </xsd:complexContent>
   </xsd:complexType>
 
   <xsd:element name="titi" type="deux:titiType"/>
 
   <xsd:simpleType name="titiType">
      <xsd:restriction base="un:titiType">
         <xsd:enumeration value="grosminet"/>
      </xsd:restriction>
   </xsd:simpleType>
 
 
</xsd:schema>

Le validateur accepte le premier schema, mais me jette sur le second avec :

"Error on line 47 of file:/home/moucha/safe/src/xsd/int/esa/safe/1.0/deux.xsd:
The content model of the complex type monElementType is not a valid restriction of the content model of the type monElementType. Restricted type allows element titi where the base type does not
Error on line 27 of file:/home/moucha/safe/src/xsd/int/esa/safe/1.0/deux.xsd:
The content model of the complex type of element pere is not a valid restriction of the content model of the type pereType. Restricted type allows element monElement where the base type does not
Error on line 18 of file:/home/moucha/safe/src/xsd/int/esa/safe/1.0/deux.xsd:
The content model of the complex type totoType is not a valid restriction of the content model of the type totoType. Restricted type allows element pere where the base type does not
Schema processing failed: The schema is invalid"


Le probleme est que mon deux:titi est bien une restriction de un:titi ! Et ainsi de suite.
Non seulement je dois semble-t-il a chaque nouvelle instance TOUT redefinir en global (avec une form unqualified sinon il me jette), mais en plus le validateur semble vraiment bloquer sur le changement de namespace.

Ex : deux:titi n'est pas une restriction de un:titi par definition semble-t-il...

Bref : je trouve les restrictions successives avec chgt de namespace absolument horribles, et j'aimerais avoir vos avis eclaires dessus svp.

Un ENORME merci pour votre aide ![/code]

[GrandFather]

Bonjour,

j'ai testé tes schemas avec XMLSpy, et j'obtiens la même erreur. Je n'ai pour l'instant pas vraiment d'explication, il semble effectivement que le changement d'espace de nom suffise à faire considérer au validateur que les modèles sont différents, sans qu'il vérifie effectivement si les types concordent ou non.

Es-tu obligé d'affecter un espace de nom au schéma importé ?

[MathiasM]

"Es-tu obligé d'affecter un espace de nom au schéma importé ?"

Oui, ce serait la raison pour laquelle on fait une restriction plutot qu'une redefinition.
Mais je m'oriente vers la redefinition car la restriction au-dela de deux etages, c'est vraiment trop la misere....

Ce que je trouve le plus domage en fait dans schema, c'est de ne pas pouvoir creer des elements de meme nom mais de different type sans passer par xsi:type.
Si les concepteurs de validateurs pouvaient creer un parseur-validateur capable de lire un element et d'aller chercher le bon template du complexType, alors on pourrait vraiment avoir des schemas de haut niveau ouverts avec instances precises.

Merci qd meme pour ton effort !

[GrandFather]

"Es-tu obligé d'affecter un espace de nom au schéma importé ?"

Oui, ce serait la raison pour laquelle on fait une restriction plutot qu'une redefinition.

Attention, les espaces de nom ne sont pas directement liés avec les dérivation de type.

Le véritable but de ma question était de savoir si le schéma importé était susceptible d'être utilisé pour valider une instance XML, où s'il ne servait qu'à fournir des types de bases destinés à être dérivés dans des schémas validants. Dans le deuxième cas, on pouvait alors ne pas affecter de namespace à ce schéma, ce qui fait qu'en l'important il est automatiquement été intégré au namespace du schéma appelant (technique dite du "caméléon"), ce qui aurait réglé le problème.

Ce que je trouve le plus domage en fait dans schema, c'est de ne pas pouvoir creer des elements de meme nom mais de different type sans passer par xsi:type.

Il est quand même possible de définir plusieurs variantes dans le modèle de contenu d'un élément. Là où ça se complique, c'est quand on dérive...

[MathiasM]

"Le véritable but de ma question était de savoir si le schéma importé était susceptible d'être utilisé pour valider une instance XML, où s'il ne servait qu'à fournir des types de bases destinés à être dérivés dans des schémas validants. Dans le deuxième cas, on pouvait alors ne pas affecter de namespace à ce schéma, ce qui fait qu'en l'important il est automatiquement été intégré au namespace du schéma appelant (technique dite du "caméléon"), ce qui aurait réglé le problème. "

Le schema importe est impose par une grande instance que je peux difficilement influencer.
Il est abstract mais possede un namespace.

[MathiasM]

Ce qui est egalement dommage, c'est le fait de ne pas pouvoir forcer la valeur d'un attribut selon que.

Ex :

Code :

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

1
2
3
4
5
6
7
8
 
totoType
   choice
      tata
      titi
   /choice
   @ID
/totoType

Si on pouvait "placer" l'attribut dans le choice, on pourrait affecter une valeur differente par exemple.

En fait il parait impossible de poser des conditions d'interdependance (si mon element truc est la, alors son Id est toto....)

[GrandFather]

Ce qui est egalement dommage, c'est le fait de ne pas pouvoir forcer la valeur d'un attribut selon que.

Ex :

Code :

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

1
2
3
4
5
6
7
8
 
totoType
   choice
      tata
      titi
   /choice
   @ID
/totoType

Si on pouvait "placer" l'attribut dans le choice, on pourrait affecter une valeur differente par exemple.

En fait il parait impossible de poser des conditions d'interdependance (si mon element truc est la, alors son Id est toto....)

C'est une plainte récurrente concernant les XML Schema. Personnellement, je ne la trouve pas légitime.

La spécification XML est déjà complexe à implémenter pour les éditeurs, ajouter des contrôles d'interdépendance n'arrangera rien, bien au contraire... C'est le rôle de l'application qui "consomme" le flux XML de procéder à ce contrôle, pas au XML Schema qui n'assure qu'une validation structurelle de ce flux.

Il est très facile de contourner ce genre de problème. Je vais prendre un exemple issu de Docbook, une DTD de description de document.

Le modèle de contenu d'un paragraphe, pour Docbook, peut prendre deux types de formes :

- une forme "simple", c'est à dire que le paragraphe ne contient que du texte ou des balises "inline" permettant de mettre éventuellement du texte en gras, etc.

- une forme "complexe", le paragraphe peut contenir les balises autorisées dans le type simple et accepter également des éléments de type "block", comme les images, tableaux, listes, etc.

Comment formaliser qu'un paragraphe (désigné par la balise <para>) peut contenir ces deux modèles, mais un seul à la fois par instance ? La réponse qui vient intuitivement est celle-ci:

Code :

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

<para type="simple">...</para>

Dans cet exemple, l'attribut type indique que le modèle de l'élément para est simple (noeuds textes et balises inline seulement). OK. Maintenant, comment valide-t-on un fichier avec ce schema ? Le drame est qu'on ne peut pas, pas plus avec les XML Schema qu'avec les autres procédés de validation XML (RelaxNG par exemple).

La seule façon de s'en sortir est d'enrichir le schéma en définissant un élément pour les paragraphes de type "simple", et un autre pour les paragraphes de type "complexe". C'est ce qu'a fait Docbook avec les balises <simpara> et <para>.

Bref, les relations d'interdépendances dans un schéma XML sont le plus souvent révélatrices d'un schéma XML mal pensé.

[MathiasM]

Code :

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

1
2
 
"La seule façon de s'en sortir est d'enrichir le schéma en définissant un élément pour les paragraphes de type "simple", et un autre pour les paragraphes de type "complexe". C'est ce qu'a fait Docbook avec les balises <simpara> et <para>.

Je reve que ce soit possible dans ce que je suis en train de faire. Malheureusement, je suis au tout depart une restriction d'un schema impose extremement ouvert.

Code :

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

1
2
 
Bref, les relations d'interdépendances dans un schéma XML sont le plus souvent révélatrices d'un schéma XML mal pensé."

Ou trop ouvert ? Trop generique ?[/code]