schéma dont des types dépendent d'autres valeurs texte [Résolu]

[plxpy]

Bonjour,

Tout d'abord, je précise que je me lance dans l'écriture de schémas XML aussi je ne suis pas encore très à l'aise, ni sur d'utiliser les bons termes à la suite. N'hésitez pas à me corriger si besoin.

Le schéma que j'ai écrit s'applique à des fichiers XML qui décrivent des modèles de données. On y décrit des objets géographiques et notamment leurs propriétés/attributs (élément <field> à la suite - je vous épargne le schéma dans sa totalité, ce n'est à priori pas utile).

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
    <xsd:complexType name="val_type">
        <xsd:simpleContent>
            <xsd:extension base="xsd:string">
                <xsd:attribute name="description" type="xsd:string" />
            </xsd:extension>
        </xsd:simpleContent>
    </xsd:complexType>
 
    <xsd:element name="field">
        <xsd:complexType>
            <xsd:all>
                <xsd:element name="key" type="key_type"/>
                <xsd:element name="name" type="xsd:string" minOccurs="0"/>
                <xsd:element name="mandatory" type="empty" minOccurs="0"/>
                <xsd:element name="private" type="empty" minOccurs="0"/>
                <xsd:element name="help" type="xsd:string" minOccurs="0"/>
                <xsd:element name="typedef">
                    <xsd:complexType>
                        <xsd:sequence>
                            <xsd:element name="type" type="data_type"/>
                            <xsd:element name="size" type="string_size" minOccurs="0"/>
                            <xsd:element name="count" type="xsd:positiveInteger" minOccurs="0"/>
                        </xsd:sequence>
                    </xsd:complexType>
                </xsd:element>
                <xsd:element name="predefined" type="empty" minOccurs="0"/>
                <xsd:element name="val" type="val_type" minOccurs="0"/>
                <xsd:element name="default" type="xsd:string" minOccurs="0"/>
                <xsd:element name="mode" type="mode_type" minOccurs="0"/>
                <xsd:element name="precision" type="xsd:nonNegativeInteger" minOccurs="0"/>
                <xsd:element name="min" type="xsd:string" minOccurs="0"/>
                <xsd:element name="max" type="xsd:string" minOccurs="0"/>
                <xsd:element name="step" type="xsd:string" minOccurs="0"/>
            </xsd:all>
        </xsd:complexType>
    </xsd:element>

Quelques exemples d'éléments XML correspondants pour fixer les idées :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 <field>
   <key>ACC</key>
   <name>Type de precision [1]</name>
   <help>Accuracy Category [1]</help>
   <typedef><type>shrt</type></typedef>
   <predefined/>
   <val description="Accurate">1</val>
   <val description="Approximate">2</val>
   <default>1</default>
 </field>
 
 <field>
   <key>NAM</key>
   <name>Nom [UNK]</name>
   <help>Name [UNK]</help>
   <typedef><type>pstr</type><size>200</size></typedef>
   <val description="Unknown">UNK</val>
   <default>UNK</default>
 </field>

Le schéma semble syntaxiquement correct (via xmllint, j'ai validé des modèles de données (XML) et le schéma, après plusieurs essais infructueux, a été chargé sans erreur). Mais, pour l'élément <field>, j'ai du rester très "coulant" pour le type de certains sous éléments en utilisant xsd:string comme type et je n'en suis pas très satisfait.

Dans le XML, les types de certains éléments peuvent dépendre du contenu (la partie "texte") d'un autre élément : val, default dépendent du contenu de type (l'élément de nom type).

Peut-être les fichiers XML correspondants ont-ils été, à l'origine, mal conçus/pensés mais ils sont utilisés depuis un bon bout de temps et par de nombreuses applications : il n'est guère envisageable d'en changer, sauf à reprendre toutes les applications les utilisant ...

Comment rendre "plus strict" (et est-ce même possible ?) le schéma pour que, par exemple, quand <type> contient "shrt" (entier sur 2 octets), un élément <val> contenant le texte "abcd" fasse couiner le validateur utilisant le schéma (et n'accepte que des valeurs de "-32768" à "32767") ?

Quelquechose qui marchera, à coup sur, c'est de prévoir autant de type pour <field> qu'il y a de possibilités pour le contenu/texte de <type> et, dans l'élément parent, utiliser un "choice" mais j'ai ... 15 types différents ...

Est-ce qu'il faut "jongler" avec de nombreuses déclarations de types (simple et/ou complexe) et d'éléments (les "all", "sequence", "choice", etc... je n'ai pas encore en tête toutes les possibilités) ou y a-t-il un "mécanisme" déjà prévu qui répondrait à mon problème ?

Merci d'avance pour vos réponses

[thelvin]

Envoyé par plxpy

Comment rendre "plus strict" (et est-ce même possible ?)

Non. Il faut le faire gérer par l'application utilisatrice. Pas par le validateur XSD.

Les connaisseurs aiment dire que "la validation s'occupe de valider la grammaire du format, pas sa sémantique." Les valeurs possibles que peut prendre un short, c'est une question de sémantique, pas de grammaire.

Envoyé par plxpy

Peut-être les fichiers XML correspondants ont-ils été, à l'origine, mal conçus/pensés

Possible, mais pas forcément. Ils n'ont pas été conçus pour être validés par XSD avec beaucoup de précision. Ce n'est pas toujours un défaut : ça les rend peut-être plus faciles à exploiter ou à lire.
Et de toute façon, XSD n'est pas capable d'une précision telle que demandée, quels que soit les choix pris.

[plxpy]

Merci thelvin pour ta réponse. Voici ce que ça m'inspire (n'oublie pas que je débute dans ce domaine; ce sont des réactions de novice en la matière)

Envoyé par thelvin

Non. Il faut le faire gérer par l'application utilisatrice. Pas par le validateur XSD.

Les connaisseurs aiment dire que "la validation s'occupe de valider la grammaire du format, pas sa sémantique." Les valeurs possibles que peut prendre un short, c'est une question de sémantique, pas de grammaire.

Peut-être mais je n'ai pas l'impression de faire quelque chose d'extraordinaire en demandant qu'un élément soit un entier compris entre deux valeurs. C'est bien ce qui est fait quand on utilise le type xsd:positiveInteger et non pas xsd:integer (pour ne pas dire xsd:string). C'est une restriction comme une autre que je demande, non ? Après, que les valeurs extrêmes soient directement liées à des aspects bas-niveau est dû au fait qu'on intègre ces données dans un applicatif et qu'il a prévu tel ou tel type (C/C++/autre...) pour tel champ.

Si la validation d'un XML via un schéma ne s'occupait pas des types des éléments (simples) et des attributs, ça perdrait beaucoup de son intérêt. Question format, une "digestion" brutale via une bibliothèque façon DOM me dirait si, oui ou non, le XML est bien formé. Resterait à s'occuper des inclusions possibles des éléments entre eux et de la cardinalité.

Là, pour mon exemple, si une validation via un schéma ne me fait pas "tout" ("bon formattage", tags, inclusions, cardinalités, attributs, types), je laisserai carrément tomber. En Python, ça devrait me prende moins de lignes de code que de lignes dans le schéma, et ce serait tout aussi (voire plus) maintenable dans la mesure où ça n'évolue qu'exceptionnellement.

Passer par des schémas c'était aussi une façon de "m'y mettre" et de pouvoir généraliser cette approche pour d'autres XML.

Envoyé par thelvin

Possible, mais pas forcément. Ils n'ont pas été conçus pour être validés par XSD avec beaucoup de précision. Ce n'est pas toujours un défaut : ça les rend peut-être plus faciles à exploiter ou à lire.
Et de toute façon, XSD n'est pas capable d'une précision telle que demandée, quels que soit les choix pris.

Ce que j'avais en tête, c'est le fait de n'avoir qu'un seul élément <field> et pas <field_short>, <field_long>, <field_boolean>, ... (les fameux 15 types dont je parlais). Mais j'ai espoir que ça puisse "se rattraper" par autant d'élements (ou de types XSD) que de types (l'élément XML) et par l'utilisation de choice ou union.

[plxpy]

(re) Bonjour

Ce n'est pas du tout un "up" mais je pense que j'étais un peu à côté de la plaque en lisant la réponse de thelvin et en y répondant (j'avais prévenu, je débute et il faut encore me mettre les points sur les 'i' dans ce domaine).

J'ai cru que les conseils de thelvin étaient plutôt à considérer comme des "bonnes pratiques". Mais pas comme des impossibilités.

J'ai continué mes tests avec l'espoir d'y arriver (la fameuse chance du débutant) en passant, par des "group", des "union", etc...

Voilà à quoi j'étais arrivé (le schéma n'est d'aucune utilité, sauf de valider (ou pas ...) l'approche) :

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
<?xml version="1.0" encoding="utf-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 
    <xsd:group name="specifique_entier">
        <xsd:sequence>
            <xsd:element name="val" type="xsd:positiveInteger"/>
            <xsd:element name="unite" type="xsd:string" minOccurs="0"/>
        </xsd:sequence>
    </xsd:group>
 
    <xsd:group name="specifique_chaine">
        <xsd:sequence>
            <xsd:element name="val" type="xsd:string"/>
        </xsd:sequence>
    </xsd:group>
 
    <xsd:group name="specifique">
        <xsd:choice>
            <xsd:group ref="specifique_entier"/>
            <xsd:group ref="specifique_chaine"/>
        </xsd:choice>
    </xsd:group>
 
    <xsd:complexType name="generique">
        <xsd:sequence>
            <xsd:element name="nom" type="xsd:integer"/>
            <xsd:group   ref="specifique"/>
        </xsd:sequence>
    </xsd:complexType>
 
    <xsd:element name="field_list">
        <xsd:complexType>
            <xsd:sequence>
                <xsd:element name="field" type="generique" maxOccurs="unbounded"/>
            </xsd:sequence>
        </xsd:complexType>
    </xsd:element>
 
</xsd:schema>

A la première utilisation, j'ai obtenu

Code :

1
2
3
plx@sony:~/Bureau$ xmllint --noout base.xml --schema base_plus.xsd 
base_plus.xsd:24: element complexType: Schemas parser error : complex type 'generique': The content model is not determinist.
WXS schema base_plus.xsd failed to compile

"The content model is not determinist" : je pense que ce sont les définitions de <val>, et dans le groupe "specifique_entier", et dans le groupe "specifique_chaine", qui posent problème. En y réfléchissant, comment xmllint pourrait-il valider un XML où il trouverait un élément <val>12abcd</val>, non accompagné d'un élément <unite> ? chaine valide ? entier erroné ?

J'en conclus (arrétez-moi si besoin) que, quels que soient les moyens détournés (passage par des types, des groupes, etc..., des combinaisons de tout ça) que l'on pourrait utiliser, on ne pourra faire valider deux mêmes valeurs de tags quand on les définit avec des types différents.

J'en conclus également que des XML, même bien formés (jusque là on cause seulement "chaine de caractères"), peuvent ne pas être "validables" via un schéma. Y réfléchir à deux fois quand on définit la "structure" de ces fichiers !

[thelvin]

Envoyé par plxpy

Là, pour mon exemple, si une validation via un schéma ne me fait pas "tout" ("bon formattage", tags, inclusions, cardinalités, attributs, types), je laisserai carrément tomber. En Python, ça devrait me prende moins de lignes de code que de lignes dans le schéma, et ce serait tout aussi (voire plus) maintenable dans la mesure où ça n'évolue qu'exceptionnellement.

Pareil, même si ça évolue un peu plus souvent. L'intérêt de XSD est à mes yeux bien plus limité qu'on le vend d'habitude. Ça fait perdre beaucoup de temps pour bien peu de choses, ça c'est sûr. Mais quand est-ce que ça en fait gagner au juste ? Ça arrive... Ça dépend des cas d'utilisation.
Corollaire : je m'en sers donc aussi peu que possible, et je suis loin d'être un expert. Mais je sais pourquoi je ne m'en sers pas, et je peux toujours transmettre ce savoir-là.

Envoyé par plxpy

Ce que j'avais en tête, c'est le fait de n'avoir qu'un seul élément <field> et pas <field_short>, <field_long>, <field_boolean>, ... (les fameux 15 types dont je parlais).

Bon, ça ça marche, oui, mais personnellement ça me gaverait, vraiment.

Envoyé par plxpy

Mais j'ai espoir que ça puisse "se rattraper" par autant d'élements (ou de types XSD) que de types (l'élément XML) et par l'utilisation de choice ou union.

Tu peux te baser sur la FAQ "Est-il possible de faire dépendre le contenu d'un élément de la valeur d'un attribut".

Mais cela :
- est peu pratique, comme tout le reste de XSD
- nécessite de faire évoluer les fichiers XML, pour utiliser l'attribut xsi:type au lieu de l'élément typedef, ce qui n'est pas forcément possible ou souhaitable.

Envoyé par plxpy

J'ai cru que les conseils de thelvin étaient plutôt à considérer comme des "bonnes pratiques". Mais pas comme des impossibilités.

Une erreur bien légitime, car je m'exprime en effet beaucoup sur ce que j'estime être de bonnes pratiques.
Mais là je parlais d'impossibilité pure et simple, oui.

Envoyé par plxpy

"The content model is not determinist" : je pense que ce sont les définitions de <val>, et dans le groupe "specifique_entier", et dans le groupe "specifique_chaine", qui posent problème. En y réfléchissant, comment xmllint pourrait-il valider un XML où il trouverait un élément <val>12abcd</val>, non accompagné d'un élément <unite> ? chaine valide ? entier erroné ?

Je suis pas sûr de comprendre. XSD se plaint que le modèle n'est pas déterministe. Pour le dire autrement, quand on demande à XSD de faire un choix, il doit savoir immédiatement qu'il ne fera pas les autres choix, ceux-là sont oubliés. Autrement dit, deux choix ne peuvent pas commencer par le même élément (ainsi que d'autres détails.)

Ce n'est pas quelque chose d'évident, ça aurait pu se faire autrement. Mais ça s'est fait comme ça. Ça a aussi des avantages, et beaucoup de logique, ne nous y trompons pas.

Envoyé par plxpy

J'en conclus (arrétez-moi si besoin) que, quels que soient les moyens détournés (passage par des types, des groupes, etc..., des combinaisons de tout ça) que l'on pourrait utiliser, on ne pourra faire valider deux mêmes valeurs de tags quand on les définit avec des types différents.

Je comprends pas cette histoire de mêmes valeurs de tags. Je suis désolé, il me faut encore un exemple et des contre-exemples.
(Ou alors attendre quelqu'un de plus habitué, ça marche aussi.)

Envoyé par plxpy

J'en conclus également que des XML, même bien formés (jusque là on cause seulement "chaine de caractères"), peuvent ne pas être "validables" via un schéma. Y réfléchir à deux fois quand on définit la "structure" de ces fichiers !

Absolument. On est pas obligé de réfléchir des heures quand on crée un format XML, mais on en tirera moins que si on avait bien potassé son truc.
Ce n'est pas qu'une histoire de validation, il y a aussi les questions de sélections, associations, extensibilité, fragmentation en plusieurs fichiers...
Plein de choses peuvent être améliorées si on y pense dès le début.

Au fond c'est pareil pour tout.

[tsuji]

Boujour, il me semble qu'il faut élaborer un peu de tous les côtes de choses.

[1] w3c schéma v1.0 s'etait fait dans une atmosphère de compromise étendue. Il est très vite reconnu qu'il y a des fonctionalités bien besoin naturellement qui font défauts. C'est pour ça wxsl n'a jamais monopolisé, quoique assez dominant grâce aux nombreux d'utilités développées y dépendaient, dans le domaine de valider les documents xml.

[2] Dans les fonctionnalités souvent recherchées regroupées sous le terme de "co-constraints", le langage est considéré comme beaucoup moins puissant que Schematron et Relaxng, et il laisse beaucoup à désirer.

[3] La condition recherchée sur des éléments est hors de la frontière d'applicabilité de version 1.0.

[4] Pourtant je veux aussi d'apporter quelque chose de positive. Le schéma version 1.1 est maintenant en statue de "proposed recommendation" en janvier 2012 incarne la leçon de Schematron et supporte xsd:assert élément.

[4.1] Avec v1.1, cela peut paraître comme ça. (Je ne m'occupe pas trop de détail et la implémentation de xpath de "test" n'est certainement pas unque, elle est seulement à titre d'exemple.)

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
 
<xsd:schema version="1.1" xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
    elementFormDefault="qualified">
    <!-- ... etc etc... -->
    <xsd:element name="field">
        <xsd:complexType>
            <xsd:all>
                <xsd:element name="key" type="key_type"/>
                <xsd:element name="name" type="xsd:string" minOccurs="0"/>
                <xsd:element name="mandatory" type="empty" minOccurs="0"/>
                <xsd:element name="private" type="empty" minOccurs="0"/>
                <xsd:element name="help" type="xsd:string" minOccurs="0"/>
                <xsd:element name="typedef">
                    <xsd:complexType>
                        <xsd:sequence>
                            <xsd:element name="type" type="data_type"/>
                            <xsd:element name="size" type="string_size" minOccurs="0"/>
                            <xsd:element name="count" type="xsd:positiveInteger" minOccurs="0"/>
                        </xsd:sequence>
                    </xsd:complexType>
                </xsd:element>
                <xsd:element name="predefined" type="empty" minOccurs="0"/>
                <!--
                <xsd:element name="val" type="val_type" minOccurs="0"/>
                -->
                <xsd:element name="val" type="xsd:string" minOccurs="0"/>
                <xsd:element name="default" type="xsd:string" minOccurs="0"/>
                <xsd:element name="mode" type="mode_type" minOccurs="0"/>
                <xsd:element name="precision" type="xsd:nonNegativeInteger" minOccurs="0"/>
                <xsd:element name="min" type="xsd:string" minOccurs="0"/>
                <xsd:element name="max" type="xsd:string" minOccurs="0"/>
                <xsd:element name="step" type="xsd:string" minOccurs="0"/>
            </xsd:all>
 
            <xsd:assert test="(
                (contains(typedef/type,'short') and (xsd:short(val) eq xsd:int(val)))
                or
                (not(contains(typedef/type,'short')))
            )" />
 
        </xsd:complexType>
    </xsd:element>
    <!-- etc etc... -->
</xsd:schema>

[plxpy]

Bonjour,

Envoyé par thelvin

XSD se plaint que le modèle n'est pas déterministe. Pour le dire autrement, quand on demande à XSD de faire un choix, il doit savoir immédiatement qu'il ne fera pas les autres choix, ceux-là sont oubliés. Autrement dit, deux choix ne peuvent pas commencer par le même élément (ainsi que d'autres détails.)

Effectivement. J'y étais allé un peu fort en concluant qu'on ne pouvait avoir deux éléments de même nom avec des types différents. Avec un schéma comme ça (les deux groupes ne commencent jamais par le même élément, l'élément <unite> est obligatoire dans le groupe "specifique_entier")

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
<?xml version="1.0" encoding="utf-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 
    <xsd:group name="specifique_entier">
        <xsd:sequence>
            <xsd:element name="unite" type="xsd:string"/>
            <xsd:element name="val" type="xsd:positiveInteger"/>
        </xsd:sequence>
    </xsd:group>
 
    <xsd:group name="specifique_chaine">
        <xsd:sequence>
            <xsd:element name="val" type="xsd:string"/>
        </xsd:sequence>
    </xsd:group>
 
    <xsd:group name="specifique">
        <xsd:choice>
            <xsd:group ref="specifique_entier"/>
            <xsd:group ref="specifique_chaine"/>
        </xsd:choice>
    </xsd:group>
 
    <xsd:complexType name="generique">
        <xsd:sequence>
            <xsd:element name="nom" type="xsd:string"/>
            <xsd:group   ref="specifique"/>
        </xsd:sequence>
    </xsd:complexType>
 
    <xsd:element name="field_list">
        <xsd:complexType>
            <xsd:sequence>
                <xsd:element name="field" type="generique" maxOccurs="unbounded"/>
            </xsd:sequence>
        </xsd:complexType>
    </xsd:element>
 
</xsd:schema>

on valide ce genre de chose

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?xml version="1.0" encoding="utf-8"?>
<field_list>
    <field>
        <nom>NAM</nom>
        <val>UNK</val>
    </field>
    <field>
        <nom>ACC</nom>
        <val>1</val>
    </field>
    <field>
        <nom>LEN</nom>
        <unite>meters</unite>
        <val>150</val>
    </field>
</field_list>

Mais, si j'ajoute un minOccurs="0" à ce même élément <unite>

Code :

<xsd:element name="unite" type="xsd:string" minOccurs="0"/>

avec le même XML, la validation donne :

Code :

1
2
mac1012w049:schema_xsd pascal$ xmllint --noout base.xml --schema base_plus.xsd 
base.xml:5: element val: Schemas validity error : Element 'val': 'UNK' is not a valid value of the atomic type 'xs:positiveInteger'

Le schéma est toujours OK mais xmllint ne sait plus distinguer les deux groupes et invalide mon XML.

Enfin, bref, la "bête" est chatouilleuse (problème général ou spécifique xmllint ?). En tout cas, difficile de bâtir une stratégie sur ce principe si on n'a pas prévu, à la base, des éléments radicalement différents.

Merci pour vos réponses. Je regarderai plus tard dans le détail le lien vers la FAQ et le schéma de tsuji mais là "faut que j'avance".

Il y a de grande chance que ça se termine, à court terme, par une validation "cool" (xsd:string pour les <val> et <default>, j'ai déjà le schéma), un réarrangement du XML avec une "remontée" de l'élément <type> pour avoir des parties bien distinctes (par applicatif - ça doit aussi pouvoir se faire via XSLT mais, question nouveautés, ça commence à faire beaucoup) et une revalidation plus musclée (le schéma "musclé" correspondra, peut-être, à une nouvelle version des modèles de données, à voir)

@thelvin : ça ne va pas dans le sens de tes conseils mais c'est dû au contexte :

• on a une directive européenne sur les métadonnées en guise d'épée de Damoclès : du XML, on va "en bouffer"
• là où je bosse, il n'y a pas d'informaticiens de formation, seulement des ingénieurs dont certains, mais c'est une forte minorité, développent (et certains très bien, si si !) : structurer les données et écrire un schéma peut être fait par quelqu'un qui ne développe pas et les développeurs sont une "ressource" extrêmement rare.