Comment créer un & # 8220; État américain & # 8221; réutilisable tapez un schéma XML?

Question

J'ai un schéma XML qui comprend plusieurs adresses:

<xs:element name="personal_address" maxOccurs="1">
  <!-- address fields go here -->
</xs:element>
<xs:element name="business_address" maxOccurs="1">
  <!-- address fields go here -->
</xs:element>

Dans chaque élément d'adresse, j'inclus un "État américain". énumération:

<xs:simpleType name="state">
    <xs:restriction base="xs:string">
        <xs:enumeration value="AL" />
        <xs:enumeration value="AK" />
        <xs:enumeration value="AS" />
                ....
            <xs:enumeration value="WY" />
        </xs:restriction>
</xs:simpleType>

Comment puis-je écrire le " État américain " énumération unique et réutilisation dans chacun de mes éléments d'adresse? Je m'excuse par avance s'il s'agit d'une question n00b - je n'ai jamais écrit de XSD auparavant.

Mon premier essai est le suivant:

<xs:element name="business_address" maxOccurs="1">
  <!-- address fields go here -->
  <xs:element name="business_address_state" type="state" maxOccurs="1"></xs:element>
</xs:element>

Answer 1

Je pense que vous êtes sur la bonne voie. Je pense que cela a plus à voir avec les espaces de noms XML. Essayez ce qui suit:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.example.org/foo"
    xmlns:tns="http://www.example.org/foo"
    elementFormDefault="qualified">
    <xs:element name="business_address">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="business_address_state"
                    type="tns:state" maxOccurs="1" />
            </xs:sequence>
        </xs:complexType>
    </xs:element>
    <xs:simpleType name="state">
        <xs:restriction base="xs:string">
            <xs:enumeration value="AL" />
            <xs:enumeration value="AK" />
            <xs:enumeration value="AS" />
            <xs:enumeration value="WY" />
        </xs:restriction>
    </xs:simpleType>
</xs:schema>

Notez que le type est tns: state et pas seulement state

.

Et voici comment vous l'utiliseriez:

<?xml version="1.0" encoding="UTF-8"?>
<business_address xmlns="http://www.example.org/foo"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.example.org/foo foo.xsd ">
    <business_address_state>AL</business_address_state>
</business_address>

Notez que ce code XML utilise un espace de noms par défaut identique à celui de l'espace cibleNames du XSD

.

Answer 2

Alors que les espaces de noms permettent de garder les schémas organisés et d'éviter les conflits, ce n'est pas l'espace de noms ci-dessus qui permet la réutilisation, c'est le placement du type en tant qu'enfant immédiat de < xs: schema > racine cela en fait un type global. (Utilisable dans l’espace de noms sans le qualificateur d’espace de noms et à partir de l’endroit où l’espace de noms tns est visible avec le qualificatif tns:.)

Je préfère construire mes schémas en suivant le "jardin d’Eden". Cette approche optimise la réutilisation des éléments et des types (et peut également faciliter le référencement logique externe du type / élément unique soigneusement créé à partir, par exemple, d’un dictionnaire de données stocké dans une base de données.

Notez que, bien que le "Jardin d’Eden" modèle de schéma offre la réutilisation maximale, il implique également le plus de travail. Au bas de cet article, j'ai fourni des liens vers les autres modèles abordés dans la série de blogs.

& # 8226; L'approche du jardin d'Eden http: //blogs.msdn.com/skaufman/archive/2005/05/10/416269.aspx

Utilise une approche modulaire en définissant tous les éléments de manière globale et, à l'instar de l'approche en aveugle vénitien, toutes les définitions de type sont déclarées de manière globale. Chaque élément est défini globalement comme un enfant immédiat du nœud et son attribut de type peut être défini sur l'un des types complexes nommés.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="TargetNamespace" xmlns:TN="TargetNamespace" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:element name="BookInformation" type="BookInformationType"/>
    <xs:complexType name="BookInformationType">
        <xs:sequence>
            <xs:element ref="Title"/>
            <xs:element ref="ISBN"/>
            <xs:element ref="Publisher"/>
            <xs:element ref="PeopleInvolved" maxOccurs="unbounded"/>
        </xs:sequence>
    </xs:complexType>
    <xs:complexType name="PeopleInvolvedType">
        <xs:sequence>
            <xs:element name="Author"/>
        </xs:sequence>
    </xs:complexType>
    <xs:element name="Title"/>
    <xs:element name="ISBN"/>
    <xs:element name="Publisher"/>
    <xs:element name="PeopleInvolved" type="PeopleInvolvedType"/>
</xs:schema>

L'avantage de cette approche est que les schémas sont réutilisables. Étant donné que les éléments et les types sont définis globalement, ils peuvent être réutilisés. Cette approche offre le maximum de contenu réutilisable. Les inconvénients sont que le schéma est détaillé. Cette conception serait appropriée lorsque vous créez des bibliothèques générales dans lesquelles vous ne pouvez vous permettre aucune hypothèse sur la portée des éléments et des types de schéma et sur leur utilisation dans d'autres schémas, notamment en ce qui concerne l'extensibilité et la modularité.

Etant donné que chaque type et chaque élément possède une définition globale unique, ces particules / composants canoniques peuvent être liés un à un aux identifiants d'une base de données. Et bien que maintenir les associations entre les particules / composants XSD textuels et la base de données puisse sembler une tâche manuelle fastidieuse, SQL Server 2005 peut en fait générer des identifiants de composants de schéma canoniques via la déclaration

.

CREATE XML SCHEMA COLLECTION

http://technet.microsoft.com/en-us/library /ms179457.aspx

Inversement, pour construire un schéma à partir des particules canoniques, SQL Server 2005 fournit le

SELECT xml_schema_namespace function

http://technet.microsoft.com/en-us/library /ms191170.aspx

ca & # 183; non & # 183; i & # 183; cal     Relatif aux mathématiques. (d'une équation, coordonnée, etc.)         "sous la forme la plus simple ou standard"          http://dictionary.reference.com/browse/canonical

Autre, plus facile à construire, mais moins résistant / plus "dénormalisé / redondant" Les modèles de schéma incluent

& # 8226; L’approche de la poupée russe http: / /blogs.msdn.com/skaufman/archive/2005/04/21/410486.aspx

Le schéma comporte un seul élément global, l'élément racine. Tous les autres éléments et types sont imbriqués progressivement, lui donnant son nom, du fait que chaque type s’intègre dans celui qui le précède. Les éléments de cette conception étant déclarés localement, ils ne seront pas réutilisables via les instructions d'importation ou d'inclusion.

& # 8226; L’approche Salami Slice http: //blogs.msdn.com/skaufman/archive/2005/04/25/411809.aspx

Tous les éléments sont définis globalement mais les définitions de type sont définies localement. De cette façon, d'autres schémas peuvent réutiliser les éléments. Avec cette approche, un élément global avec son type défini localement fournit une description complète du contenu de l'élément. Cette information 'slice' est déclarée individuellement, puis agrégée et peut également être reconstituée pour construire d'autres schémas.

& # 8226; L’approche des aveugles vénitiens http: / /blogs.msdn.com/skaufman/archive/2005/04/29/413491.aspx

Similaire à l'approche de la poupée russe en ce sens qu'ils utilisent tous deux un seul élément global. L'approche Venetian Blind décrit une approche modulaire en nommant et en définissant toutes les définitions de types de manière globale (par opposition à l'approche Salami Slice qui déclare les éléments globalement et les types localement). Chaque type défini globalement décrit une "lame" individuelle. et peut être réutilisé par d'autres composants. De plus, tous les éléments déclarés localement peuvent être qualifiés d'espace de nom ou non qualifiés (les lamelles peuvent être "ouvertes" ou "fermées") en fonction du paramètre d'attribut elementFormDefault situé en haut du schéma.