Types de données de modèle XSD

Article
06/15/2023

Le type de données XSD_DEFINED utilise des schémas pour la définition du type de données. Vous pouvez définir n’importe quel ComplexType ou SimpleType.

*DataType : XSD_DEFINED crée une définition de type de données à l’aide des éléments XML xsd :complexType> ou < xsd :simpleType> standard<. La valeur de données instance sera sortie en tant que contenu d’un élément XML dont xsi :type est spécifié par la valeur de *XMLDataType qui apparaît dans ce modèle. Cette sortie vous permet d’utiliser XSD pour dériver de nouveaux types simples ou complexes et de les utiliser dans des attributs GDL.

Les directives suivantes sont utilisées pour définir complètement le type de données XSD_DEFINED :

*XMLDataType (obligatoire). Nom (NCName) qui a été attribué au type de données XSD que ce modèle définit. Ce nom est la valeur de l’attribut name dans l’élément <complexType> ou <simpleType> défini par la directive *XSDTypeDefinition. Ce nom doit être unique à tous les types XSD_DEFINED et ENUMERATOR. Pour éviter les conflits avec les types de données que l’analyseur GDL définit, vous devez éviter les noms commençant par « GDL_ » et « GDLW_ ». La norme XML définit la syntaxe d’un NCName et peut imposer des restrictions supplémentaires.
*XSDTypeDefinition (obligatoire). XSD bien formé qui définit le type de données. Seuls les <éléments complexType> ou <simpleType> peuvent apparaître au niveau du contexte le plus proche de la racine. Plusieurs <éléments complexType> ou <simpleType> peuvent apparaître en tant que frères dans le contexte le plus racine si au maximum un seul d’entre eux est effectivement référencé comme type valeur d’un attribut GDL. Le nom du type référencé comme type valeur d’un attribut GDL est celui qui apparaît dans la directive *XMLDataType. Les types de données restants ne peuvent être référencés qu’à partir d’autres <définitions complexType> ou <simpleType> .

Les définitions de type peuvent également référencer d’autres définitions de type définies dans d’autres modèles. Lorsque vous référencez des définitions de type dans une directive *XSDTypeDefinition qui ont été créées à l’aide de la directive *XSDTypeDefinition, vous devez utiliser le préfixe d’espace de noms gdl :.

Si le XSD occupe plusieurs lignes ou s’il enfreint les règles de syntaxe GDL, il doit être entouré de <délimiteurs Begin/EndValue> . Le XSD défini dans ces délimiteurs sera inséré dans le schéma XSD généré par l’analyseur GDL. Notez que les <définitions complexType> qui seront référencées en tant que ValueType d’un attribut GDL ne peuvent pas déclarer d’attributs XML. Dans le schéma produit par l’analyseur GDL, l’espace de noms XSD étant l’espace de noms par défaut, les noms d’éléments tels <que complexType> ou <sequence> ou <element> n’ont pas besoin d’un qualificateur d’espace de noms. L’espace de noms cible est associé au préfixe gdl :.
*Complextype? (TRUE) | FALSE) (Facultatif). Si cette directive a la valeur TRUE, l’analyseur GDL référencera cette définition en tant que <complexContent> lors de l’extension de ce type de données ; sinon, la définition est référencée en tant que <simpleContent>. Si cette directive n’est pas spécifiée, l’analyseur suppose qu’elle est FALSE.
*ArrayLabel (facultatif). Si cette directive est spécifiée, le filtre de l’analyseur s’attend à ce que les valeurs instance de ce type soient entourées de parenthèses, précédées de l’étiquette de tableau spécifiée.

La syntaxe de la valeur instance déclarée de ce type de données doit respecter la syntaxe définie par le XSD que la directive *XSDTypeDefinition fournit. L’analyseur fournit les balises de début et de fin de l’élément, et la valeur instance données doit fournir uniquement le contenu de l’élément. Si la syntaxe XML est en conflit avec les règles de syntaxe GDL de base, la valeur (ou simplement la partie en conflit) doit être placée dans <les constructions Begin/EndValue :> .

Les valeurs XML avec de telles syntaxes incompatibles, ou dont la syntaxe est incompatible avec la syntaxe utilisée par les types de données composés, ne peuvent pas apparaître en tant que membre d’un type de données composé. Notez également que l’analyseur GDL n’échappe pas aux caractères XML spéciaux tels que les crochets ouvrants ou fermants (< ou >) ou un ampersand (&). Le créateur de la valeur instance est responsable de la conformité à la syntaxe XML pour les données de caractères.

Par exemple, considérez le modèle suivant.

*Template:  USAddress
{
    *Type:  DATATYPE
    *DataType:   XSD_DEFINED
    *ComplexType?: TRUE
    *XMLDataType: "USAddress"
    *XSDTypeDefinition:<BeginValue:XSD>
    <complexType name="USAddress">
        <sequence>
            <element name="name"   type="string"/>
            <element name="street" type="string"/>
            <element name="city"   type="string"/>
            <element name="state"  type="string"/>
            <element name="zip"    type="gdl:zipCode"/>
        </sequence>
    </complexType>

<simpleType name="zipCode">
 <restriction base="integer">
  <minInclusive value="10000"/>
  <maxInclusive value="99999"/>
 </restriction>
</simpleType><EndValue:XSD>
}

L’exemple précédent définit un type défini par XSD nommé « USAddress » qui peut être référencé par un attribut GDL en tant que ValueType. Cet exemple XSD définit en fait deux types de données : USAddress et zipCode. Le type zipCode ne peut pas être référencé par un attribut GDL et ne peut être référencé qu’à partir d’une autre définition de type de données XSD.

Dans l’exemple suivant, le type zipCode est référencé dans la déclaration de l’élément <zip> . Notez qu’il est référencé à l’aide du préfixe d’espace de noms gdl :. zipCode peut également être référencé à partir d’une définition de type de données XSD dans un autre modèle.

La définition de modèle précédente entraîne la création de l’entrée de schéma XML suivante (il s’agit de la valeur de *XSDTypeDefinition inchangée).

    <complexType name="USAddress">
        <sequence>
            <element name="name"   type="string"/>
            <element name="street" type="string"/>
            <element name="city"   type="string"/>
            <element name="state"  type="string"/>
            <element name="zip"    type="gdl:zipCode"/>
        </sequence>
    </complexType>

    <simpleType name="zipCode">
        <restriction base="integer">
            <minInclusive value="10000"/>
            <maxInclusive value="99999"/>
        </restriction>
    </simpleType>

L’analyseur construit automatiquement un autre type de données qui définit un nouveau type dérivé du type USAddress, mais qui a des attributs XML supplémentaires qui peuvent apparaître dans le instantané. Si vous utilisez le type de données d’origine, vous recevez des erreurs de validation de schéma, car le type d’origine n’a pas autorisé l’affichage d’attributs XML. Avec cette approche, vous n’avez pas besoin de coder en dur des attributs XML synthétisés dans vos modèles, et si des attributs supplémentaires sont ajoutés à des versions ultérieures du instantané, vous n’avez pas besoin de modifier les modèles existants.

L’exemple de code suivant montre la définition de type de données supplémentaire.

    <complexType name = "GDLW_USAddress">
        <complexContent>
            <extension base="gdl:USAddress">
                <attribute name="Name" type="string" use="optional"/>
                <attribute name="Personality" type="string" use="optional"/>
            </extension>
        </complexContent>
    </complexType>

Note Le type de données GDLW_USAddress est déclaré complexContent<>, car le modèle pour USAddress définit *ComplexType ?: TRUE.

Considérez l’entrée GDL suivante.

*Address: <BeginValue:XML> 
   <name>Alice Smith</name>
   <street>123 Maple Street</street>
   <city>Mill Valley</city>
   <state>CA</state>
   <zip>90952</zip>
<EndValue:XML>

Considérez également le modèle ADDRESS, qui déclare l’attribut *Address GDL aAttribute pour avoir un *ValueType défini par le modèle USAddress, comme le montre l’exemple de code suivant.

*Template:  ADDRESS
{
    *Name: "*Address"
    *Type:  ATTRIBUTE
    *ValueType:  USAddress
}

Si l’entrée GDL précédente est interprétée à l’aide du modèle ADDRESS, la sortie XML résultante se produit.

    <GDL_ATTRIBUTE Name="*Address"  xsi:type="GDLW_USAddress" >
    <name>Ben Smith</name>
    <street>123 Maple Street</street>
    <city>Mill Valley</city>
    <state>CA</state>
    <zip>90952</zip>
    </GDL_ATTRIBUTE>

L’attribut XML xsi :type définit cette instance de l’élément ATTRIBUTE pour contenir un type de données défini par XSD nommé GDLW_USAddress. La valeur entière de l’attribut GDL instance est insérée en tant que contenu d’élément dans l’élément <> GDL_ATTRIBUTE dans le instantané XML sans aucune modification. Par conséquent, la valeur doit être du code XML valide et doit suivre toutes les règles de syntaxe XML, comme la représentation de caractères spéciaux.

Partager via

Types de données de modèle XSD

Commentaires

Ressources supplémentaires