Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Rédacteur/Modérateur

    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    5 519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 5 519
    Points : 24 046
    Points
    24 046

    Par défaut création xsd : cannot resolve type definition

    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 !
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  2. #2
    Membre chevronné
    Inscrit en
    octobre 2011
    Messages
    1 264
    Détails du profil
    Informations forums :
    Inscription : octobre 2011
    Messages : 1 264
    Points : 2 225
    Points
    2 225

    Par défaut

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

  3. #3
    Rédacteur/Modérateur

    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    5 519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 5 519
    Points : 24 046
    Points
    24 046

    Par défaut

    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
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  4. #4
    Modérateur

    Profil pro
    Inscrit en
    septembre 2004
    Messages
    11 576
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 11 576
    Points : 19 650
    Points
    19 650

    Par défaut

    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.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  5. #5
    Rédacteur/Modérateur

    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    5 519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 5 519
    Points : 24 046
    Points
    24 046

    Par défaut

    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
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Création d'un formulaire type
    Par claire.martin dans le forum Access
    Réponses: 7
    Dernier message: 06/01/2006, 15h35
  2. [XSD] Incompatibilité des types xs:ID et xs:IDREF ?
    Par Cpt.FLAM dans le forum Valider
    Réponses: 6
    Dernier message: 08/04/2005, 15h54
  3. Cannot resolve collation conflict for equal to operation !
    Par mcrocher dans le forum MS SQL-Server
    Réponses: 5
    Dernier message: 07/03/2005, 13h08
  4. [XSD] Complexe de type all mais avec maxoccur
    Par Je@nb dans le forum Valider
    Réponses: 3
    Dernier message: 06/02/2005, 20h18
  5. [setParameter]cannot resolve symbole
    Par DEC dans le forum Servlets/JSP
    Réponses: 7
    Dernier message: 07/07/2004, 21h15

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo