Est-il valide d'avoir un "choix" d'éléments de "groupe" lors de la définition d'un schéma XML (XSD)

Question

Est-il valide d'avoir un élément 'choix' ou 'groupe' lors de la définition d'un schéma XML (XSD)

i.e. est la suivante valide

<xs:complexType name="HeaderType">
  <xs:sequence>
    <xs:element name="reservation-number" type="ReservationNumberType" minOccurs="1" maxOccurs="1" nillable="false" />
    <xs:choice minOccurs="1" maxOccurs="1">
      <xs:group ref="ReservationGroup" />
      <xs:group ref="CancellationGroup"/>
    </xs:choice>
  </xs:sequence>
</xs:complexType>

Où un message XML peut représenter, par exemple, une nouvelle réservation ou l'annulation d'une réservation existante.

Si le message concerne une réservation, il doit inclure tous les éléments définis dans le groupe ReservationGroup.

S'il s'agit d'une annulation, elle doit inclure tous les éléments définis dans le groupe CancellationGroup.

Pour une raison quelconque, mon éditeur XML (Eclipse) n’aime pas cela, mais n’indique pas pourquoi. Il montre qu’il ya une erreur sur la ligne & Lt; xs: complexType name = & "HeaderType &"; & Gt; mais ne dit pas quelle est l'erreur

Answer 1

Je ne suis pas un expert en XML, bien que je l'utilise beaucoup. Ce n'est pas la façon dont je ferais généralement ce genre de structure. Je préférerais des types complexes distincts plutôt qu'un choix de deux groupes (voir à la fin de cette réponse).

Je suppose que le problème réside dans le fait que ReservationGroup et CancellationGroup commencent par le même élément, auquel cas vous violerez la contrainte de composant de schéma: attribution unique de particules (ci-dessous).

http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cos-nonambig

  

Contrainte de composant de schéma: Unique   Attribution de particules

     

Un modèle de contenu   doit être formé de telle sorte que pendant   & # 183; validation & # 183; d'une information d'élément   séquence d'éléments, le composant de particules   contenues directement, indirectement ou   & # 183; implicitement & # 183; avec lequel   essayez de & # 183; validez & # 183; chaque élément de la   séquence à son tour peut être unique   déterminé sans examiner les   contenu ou attributs de cet article,   et sans aucune information sur le   articles dans le reste de la   séquence.

     

Remarque: cette contrainte   reconstruit pour XML Schema la   contraintes équivalentes de [XML 1.0   (Deuxième édition)] et SGML. Compte tenu du   présence de substitution d'élément   groupes et wildcards, le concis   l'expression de cette contrainte est   difficile, voir Analyse de l'unique   Contrainte d'attribution de particules   (non normatif) (& # 167; H) pour plus   discussion.

Par exemple, les deux groupes ci-dessous sont interdits dans le même choix, car chacun de leur premier élément est & "name &"; ce qui signifie que vous ne pouvez pas identifier le groupe que vous regardez. Cependant, le premier élément de ReservationGroup est différent du groupe d'annulation (resdate et cancDate peut-être), puis le qui est valide.

Modifier: Je n'avais jamais rencontré ce genre de problème auparavant. Je trouve fascinant que les définitions des groupes soient totalement légales, mais si vous les associez dans un choix, choix devient illégal à cause de la définition de chaque groupe.

Groupes qui ne peuvent pas constituer un choix légal

<xs:group name="ReservationGroup">
    <xs:sequence>
        <xs:element name="date"/>
        <xs:element name="name"/>
        <xs:element name="address"/>
    </xs:sequence>
</xs:group>

<xs:group name="CancellationGroup">
    <xs:sequence>
        <xs:element name="date"/>
        <xs:element name="name"/>
        <xs:element name="address"/>
    </xs:sequence>
</xs:group>

Groupes pouvant constituer un choix juridique

<xs:group name="ReservationGroup">
    <xs:sequence>
        <xs:element name="resDate"/>
        <xs:element name="name"/>
        <xs:element name="address"/>
    </xs:sequence>
</xs:group>

<xs:group name="CancellationGroup">
    <xs:sequence>
        <xs:element name="cancDate"/>
        <xs:element name="name"/>
        <xs:element name="address"/>
    </xs:sequence>
</xs:group>

Comme je l’ai mentionné ci-dessus, je ferais ce genre de chose avec des types complexes. Oui, cela ajoute un autre élément, mais cela semble évident et j'aime l'évidence.

<xs:complexType name="HeaderType">
  <xs:sequence>
    <xs:element name="reservation-number" type="ReservationNumberType" minOccurs="1" maxOccurs="1" nillable="false" />
    <xs:choice minOccurs="1" maxOccurs="1">
      <xs:element name="reservation" type="ReservationType" />
      <xs:element name="cancellation" type="CancellationType" />
    </xs:choice>
  </xs:sequence>
</xs:complexType>

Answer 2

Oui. C’est parce que les groupes ReservationGroup et CancellationGroup ont tous deux le même premier élément: un élément de type "type réservation" avec une valeur fixe de "Réservation" dans le groupe ReservationGroup et d’annulation "Annulation" dans le groupe Cancellation.

Answer 3

La validité de cette définition dépend du contenu des groupes: s’il s’agit de groupes de modèles "séquence" ou "choix", c’est parfaitement légal; Tous les groupes de modèles sont plus problématiques et ne sont généralement pas autorisés dans ce cas.