Discussion :

[hugo123]

Bonjour,

J'ai un problème pour créer un schéma de validation.

j'ai besoin de créer un schema xml qui me valide une suite d'élément xml de même nom mais étant différents au niveau de leurs attributs et de leur éléments fils.

Un exemple simpliste avec les 2 documents suivants :

Code :

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

1
2
3
4
5
6
7
8
9
<?xml version="1.0" encoding="UTF-8"?>
<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="grammarSimple.xsd">
  <test>test</test>
  <test>0.0</test>
  <test>true</test>
  <test>0</test>
  <test>0.0</test>
  <test>test</test>
</root>

et

Code :

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

1
2
3
4
5
6
7
8
<?xml version="1.0" encoding="UTF-8"?>
<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="grammarSimple.xsd">
  <test>test</test>
  <test>0.0</test>
  <test>true</test>
  <test>0.0</test>
  <test>test</test>
</root>

2 éléments sont optionnels, donc manquant dans ce document.

je pensais faire le schéma suivant qui n'est pas conforme :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="root">
  	<xs:complexType>
          <xs:sequence>
            <xs:element name="test" type="xs:string"/>
            <xs:element name="test" type="xs:decimal"/>
            <xs:element name="test" type="xs:boolean"/>
		<xs:element name="test" type="xs:byte" minOccurs="0"/>
		<xs:element name="test" type="xs:double"/>
		<xs:element name="test" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
  	</xs:complexType>
  </xs:element>
</xs:schema>

Dans mon cas j'ai des types complexes, mais je voulais illustrer mon pb.

D'ou ma question, comment puis je valider les 2 documents ci dessus ?
Dois je passer par des namespaces ?

[hugo123]

Toute la question que je me pose c'est, est ce que je prends le problème par le bon bout ?

Actuellement ce que je veux établir comme grammaire, c'est une séquence de balise, comme par exemple les balises "test" vu plus haut

Je pourrais éventuellement indiquer que en dessous de root j'ai une séquence de "test" et indiquer que je peux avoir tous les types possibles sous une balise "test".

Cependant, si je fais ainsi, je perds l'information sur l'ordre des séquences et leur cardinalité.

[GrandFather]

Salut,

Dans mon cas j'ai des types complexes, mais je voulais illustrer mon pb.

Ca change tout. Ca ne fonctionnera pas avec des types simples, dérivés ou non. Par contre, cela peut fonctionner avec des types complexes. Pour savoir ce qui est possible ou non, il faut connaître un peu le fonctionnement d'un validateur de schéma : à tout moment, il doit savoir quel est le modèle qu'il est en train de valider, sans ambiguïté et sans avoir à faire de choix, parce qu'il n'y a pas de retour en arrière possible pour valider un schéma alternatif.

[hugo123]

Justement je ne connais pas le principe de fonctionnement du validateur de schéma.

Quand tu dis : "à tout moment, il doit savoir quel est le modèle qu'il est en train de valider"

Il faut mettre la déclaration des types complexes avant ? Je ne suis pas sur de bien comprendre.


"parce qu'il n'y a pas de retour en arrière possible pour valider un schéma alternatif."

J'en déduis qu'il avance sur le fichier sans jamais revenir en arrière. Donc est-ce qu'il est possible qu'il détermine le type d'un élément test par les éléments a l'intérieur et que ca fonctionne tout de même ?


Je vais être un peu plus concret, voici une partie du fichier xsd actuel :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="ROOT">
  	<xs:complexType>
<xs:sequence>
            <xs:element name="T16R" type="blockA"/>
            <xs:element name="T16R" type="blockB"/>
            <xs:element name="T16R" type="blockC"/>
			<xs:element name="T16R" type="blockD" minOccurs="0" maxOccurs="1"/>
			<xs:element name="T16R" type="blockE"/>
			<xs:element name="T16R" type="blockF" minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
  	</xs:complexType>
  </xs:element>

Et plus bas j'ai la définition de mes types blockA, B etc... qui eux mêmes sont des séquences d'élément complexe ou des éléments simples.

La notion d'ordre est importante, je dois avoir le blockB après le blockA, et mon blockD peut être optionnel mais il doit se trouver entre C et E.

[GrandFather]

J'en déduis qu'il avance sur le fichier sans jamais revenir en arrière. Donc est-ce qu'il est possible qu'il détermine le type d'un élément test par les éléments a l'intérieur et que ca fonctionne tout de même ?

Justement non, parce que dans le cas où un type candidat ne serait pas le bon, cela obligerait le processeur à revenir en arrière pour tester un autre choix. Les concepteurs de la spécification ont décidé de ce fonctionnement pour faciliter l'implémentation des validateurs. Ce choix a été beaucoup critiqué.

Ce "déterminisme obligatoire" constitue le défaut majeur des W3C XML Schemas, qu'on ne retrouve pas dans d'autres langages de validation de schémas, comme Relax NG par exemple.

Dans ton cas, la seule solution que je vois personnellement serait de déclarer une séquence d'éléments T16R avec un minoccurs de 4 et un maxoccurs à "unbounded", et de lui créer un type complexe qui comprendrait toutes les variantes possibles avec un xsl:choice (et si ce n'est pas possible à l'intérieur du type à cause du même genre d'ambiguïté, appliquer récursivement ce raisonnement). C'est évidemment moins précis que la validation souhaitée au départ, mais je ne vois guère d'autres possibilités...

[GrandFather]

Je me rends compte que mon explication du déterminisme des WXS est assez nébuleuse (dénommée "Unique Particle Attribution Constraint" par la spécification), je te renvoie sur un texte qui te sera peut-être plus clair : http://www.w3.org/TR/xmlschema-1/#non-ambig

[hugo123]

Dans ton cas, la seule solution que je vois personnellement serait de déclarer une séquence d'éléments T16R avec un minoccurs de 4 et un maxoccurs à "unbounded", et de lui créer un type complexe qui comprendrait toutes les variantes possibles avec un xsl:choice (et si ce n'est pas possible à l'intérieur du type à cause du même genre d'ambiguïté, appliquer récursivement ce raisonnement). C'est évidemment moins précis que la validation souhaitée au départ, mais je ne vois guère d'autres possibilités...

J'y pensais aussi mais j'y perds ma notion d'ordre dans l'histoire.

Tu parles de relax ng (http://relaxng.org/). Est ce une bonne alternative ? Je ne connais pas donc j'ai du temps a passer dessus mais est-ce que au final je réussirais a faire ce que je souhaite ?
Et n'est ce pas hasardeux de l'utiliser si ce n'est pas un standard W3c ?
Les APIs java classiques ne font pas du relax ng, j'ai trouvé jing sur le site de relax ng (http://www.thaiopensource.com/relaxng/jing.html). Tu as des retours d'utilisation dessus ?

[GrandFather]

Je n'ai qu'une connaissance théorique de Relax NG, mais je sais que ce genre de problème ne se pose pas avec eux. De plus, sa syntaxe est bien plus simple et expressive.

Et n'est ce pas hasardeux de l'utiliser si ce n'est pas un standard W3c ?

Pas de souci pour ça c'est un standard OASIS. Beaucoup de schémas industriels comme OpenDocument (et même OpenXML si je ne me trompe pas) ont été publiés avec une syntaxe Relax NG en plus des WXS.

Les APIs java classiques ne font pas du relax ng, j'ai trouvé jing sur le site de relax ng (http://www.thaiopensource.com/relaxng/jing.html). Tu as des retours d'utilisation dessus ?

Je ne l'ai jamais utilisé (c'est en projet), mais c'est à ma connaissance la seule manière d'utiliser Relax NG avec Java. Le seul inconvénient que j'y vois, c'est que tu perds l'interopérabilité entre les parseurs (Xerces obligatoire).