Discussion :

[awnet]

Bonjour,

Je souhaiterais valider un fichier XML incluant plusieurs éléments inconnus et élément requis.

Voici un exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
<orders>
    <order>
     <require1>**</require1>
     <require2>**</require2>
     <unknow>***</unknow>
    </order>
    <order>
     <require1>**</require1>
     <require2>**</require2>
     <unknow1>***</unknow1>
     <unknow2>***</unknow2>
    </order>

Voici le XSD que j'utilise pour valider :

Code :

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

1
2
3
4
5
6
7
8
9
10
<xs:element name="orders">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="order" maxOccurs="unbounded" minOccurs="0">
<xs:complexType>
 
            <xs:choice maxOccurs="unbounded" minOccurs="2">
              <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>
               <xs:element type="xs:string" name="require1"/>
              <xs:element type="xs:string" name="require2"/>

Cependant cela ne fonctionne pas. Quand je rajoute un champs non présent dans le XSD, j'ai une erreur de validation de ce type :

cvc-complex-type.2.4.a : Contenu non valide trouvé à partir.

Quelqu'un saurait-il m'indiquer ce qui ne va pas ?

Merci d'avance pour votre aide.

[thelvin]

namespace="##other" signifie que seuls les éléments ayant un autre namespace que les autres éléments du document, sont acceptés.

Vu ce que tu décris, tu veux accepter n'importe quoi, peu importe le namespace. Il n'y a donc pas de raison de mettre ça.

[awnet]

Merci Thelvin pour ton retour sur mon problème,
j'ai positionné ce namespace car j'avais une erreur un peu plus critique dans la validation.
Si je ne positionne pas de namespace dans la balise xs:any voici ce que me retourne la validation :

Failed to resolve endpoint: validator://orders.xsd due to: cos-nonambig : WC[##any]

et id (ou des éléments de leur groupe de substitution) violent la règle d'attribution de particule unique (Unique Particle Attribution). Au cours de la validation par rapport à ce schéma, ces deux particules peuvent devenir ambiguës..
http://en.wikipedia.org/wiki/Unique_...le_Attribution

As tu une idée?

[thelvin]

Ah, effectivement. Un <xs:any> accepte tout, y compris les éléments que tu veux avoir obligatoirement.
Du coup, si tu mets les deux dans un choice, c'est ambigu : quand on tombe sur un de tes éléments obligatoires, on ne sait pas si c'est la règle du any, ou la règle de l'élément qui s'applique.

En XML Schema les grammaires ambigües sont interdites, donc je ne pense pas qu'on puisse avoir des balises obligatoires, mélangées dans n'importe quel ordre avec n'importe quelles balises.
Il vaudrait mieux une séquence, qu'un choice.

[awnet]

Merci Thelvin, j'avais en effet un petit doute cependant la documentation crosoft et w3c indique que le container xsd:choice peut être utilisé avec un xs:any. Mais comme tu l'évoques avec une énumération de champs en plus il peut se mélanger les pinceaux, je comprends mieux cette erreur grace à ton explication.

Donc un xsd sequence, mince je voulais un xml assez souple et ne pas être perturbé sur l'ordre d'apparition des éléments.
<inconnu/>
<inconnu/>
<connu>
Cela m'oblige à intercaler dans ma xsd avant et après chaque élément un xs:any. Je trouve ça un peu lourd mais il n'y a pas trop de solution apparemment.

Merci beaucoup Thelvin.

[thelvin]

Ben, il y pas assez flexible, ou trop flexible. Tu pourrais juste ne pas imposer les deux éléments.

[awnet]

En effet, cependant en pratique, j'impose certains éléments car ils sont critiques pour le cheminement dans mon SI.
Après le "fournisseur" externe du fichier xml peut rajouter s'il le souhaite d'autres informations optionnels sans compromettre le fonctionnement.
Voilà un petit peu le concept que j'avais du mal à faire passer techniquement via la xsd.