web-dev-qa-db-fra.com

Pourquoi avons-nous besoin de targetNamespace?

Je voudrais comprendre l'objectif de targetNamespace tel qu'il est utilisé à la fois dans le schéma XML et dans WSDL. En fait, pour garder les choses simples, limitons cette question au schéma XML.

J'ai l'impression de bien comprendre la notion d'espaces de noms XML (simples). Par convention, nous utilisons des URI/URL, mais nous pouvons utiliser n'importe quelle chaîne, que nous attribuons ensuite à un préfixe pour la réutilisation par des nœuds et des attributs XML, ou utiliser simplement comme espace de noms par défaut pour la portée à portée de main. Jusqu'ici tout va bien ?

Entre maintenant dans le schéma XML. Pour une raison quelconque, les inventeurs du schéma XML ont estimé que la notion d'espaces de noms simples n'était pas suffisante et ils ont dû introduire le targetNamespace. Ma question est: quel avantage significatif un targetNamespace apporte-t-il qui ne pourrait pas être fourni par un espace de noms XML normal? Si un document XML fait référence à un document xsd, soit par schemaLocation ou avec une instruction d'importation, dans les deux cas, je donne le chemin d'accès au document xsd réel référencé. C'est ce qui définit uniquement le schéma auquel je veux me référer. Si en plus je veux lier ce schéma à un espace de noms particulier dans mon document de référencement, pourquoi devrais-je être obligé de répliquer le targetNamespace précis déjà défini dans le schéma XML auquel je fais référence? Pourquoi ne pourrais-je pas simplement redéfinir cet espace de noms comme je le souhaite dans le document XML dans lequel cet espace de noms sera utilisé pour faire référence au document de schéma XML particulier que je veux référencer?

Mise à jour:

Pour donner un exemple, si j'ai ce qui suit dans un document d'instance XML:

<p:Person
   xmlns:p="http://contoso.com/People"
   xmlns:v="http://contoso.com/Vehicles"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation=
    "http://contoso.com/schemas/Vehicles
     http://contoso.com/schemas/vehicles.xsd
     http://contoso.com/schemas/People
     http://contoso.com/schemas/people.xsd">
   <name>John</name>
   <age>28</age>
   <height>59</height>
   <v:Vehicle>
      <color>Red</color>
      <wheels>4</wheels>
      <seats>2</seats>
   </v:Vehicle>
</p:Person>

Pourquoi par exemple le schéma people.xsd doit définir un targetNamespace qui est "http://contoso.com/schemas/People"? Pourquoi avons-nous besoin de la définition targetNamespace dans le document xsd? Il me semble que tout ce que vous avez à gagner de la partie espace de noms de schemaLocation est déjà contenu dans le document d'instance XML. Quel est l'avantage d'imposer l'existence d'un targetNamespace de valeur égale dans le document xsd?

Question complémentaire à la réponse de Paul:

Pouvez-vous me donner un exemple concret où de tels "conflits" entre les noms d'éléments xsd deviennent apparents et qui expliqueraient la nécessité de targetNamespace?

Ok, voici une tentative de répondre à ma propre question. Faites-moi savoir si cela vous semble cohérent. Regarder les exemples sur la page liée par Paul m'a aidé.

Si nous prenons l'exemple d'instance XML dans la question d'origine ci-dessus, nous avons deux références à la définition de l'élément véhicule. L'une est explicite et visible dans le document d'instance XML lui-même, mais nous devons également imaginer que le schéma XML person.xsd référence à nouveau la même définition de véhicule en tant qu'élément enfant autorisé de personne. Si nous devions utiliser des espaces de noms normaux où chaque document était autorisé à définir son propre espace de noms pour véhicule, comment saurions-nous que l'instance XML fait référence à la même définition de schéma XML pour véhicule que le fichier person.xsd? La seule façon consiste à appliquer un concept d'espace de noms qui est plus strict que le simple original et qui doit être écrit exactement de la même manière sur plusieurs documents.

Si je n'écrivais pas cela sur une tablette, je fournirais un exemple de code, mais ici je vais juste essayer de décrire l'exemple que j'ai en tête.

Imaginez que nous ayons deux définitions de schéma XML différentes pour un élément véhicule. location1/vehicles.xsd contiendrait la définition qui valide l'exemple de la question de ce message (contenant la couleur, les roues et les éléments enfants des sièges), tandis que location2/vehicles.xsd contiendrait une définition entièrement différente pour un élément de véhicule, (par exemple , avec les éléments enfants année, modèle et volume). Maintenant, si le document d'instance XML fait référence au schéma location1, comme c'est le cas dans l'exemple ci-dessus, mais person.xsd dit que l'élément person peut contenir un élément enfant véhicule du type défini dans le schéma location2, alors sans la notion d'un targetNamespace, l'instance XML validerait, même si elle n'a clairement pas le bon type de véhicule comme élément enfant de son élément person.

Les espaces de noms cibles nous aident ensuite à nous assurer que si deux documents différents référencent le même troisième schéma XML, ils sont tous les deux en acte faisant référence au même schéma et pas seulement un schéma qui contient des éléments similaires, mais pas identiques l'un à l'autre. .

Cela a-t-il un sens ?

xmlnamespacesxsd
50
Student

Vous semblez être sur la bonne voie. Je ferai ici quelques remarques qui pourraient aider.

  • Dans un document d'instance, vous utilisez des espaces de noms XML pour identifier l'espace de noms dans lequel se trouve un élément ou un attribut.
  • Dans un document de schéma, vous déclarez des éléments et des attributs qui apparaîtront dans les instances. Dans quel espace de noms sont-ils déclarés? C'est à cela que sert targetNamespace.
  • L'emplacement du document de schéma et l'espace de noms ne sont pas la même chose. Il est assez courant d'avoir plusieurs documents .xsd avec le même targetNamespace. (Ils peuvent ou non s’inclure, mais s’incluront généralement.)
  • Les documents d'instance n'ont pas toujours d'élément xsi: schemaLocation pour indiquer aux parseurs où trouver les schémas. Diverses méthodes peuvent être utilisées pour indiquer à un analyseur où trouver les documents de schéma pertinents. Un XSD peut se trouver sur le disque local ou à une adresse Web et cela ne devrait pas affecter l'espace de noms des éléments qu'il contient.
    • xsi: schemaLocation est un indice. Les analyseurs peuvent localiser le schéma de l'espace de noms donné ailleurs, ce qui implique qu'ils doivent être en mesure de savoir à quel espace de noms un schéma est destiné.
    • Des outils, tels que des outils de liaison de données, précompileront les schémas et produiront du code qui reconnaît les documents valides. Ceux-ci doivent pouvoir connaître les espaces de noms des éléments déclarés.

Je pense que vous supposiez que le document d'instance pourrait spécifier l'espace de noms des éléments et attributs déclarés dans un document de schéma, en utilisant xsi: schemaLocation. Ça ne marche pas. D'une part, l'analyseur peut localiser d'autres documents de schéma que ceux répertoriés, et il doit savoir pour quel espace de noms ils sont destinés. Pour un autre, cela rendrait le raisonnement sur les schémas difficile ou impossible: vous ne pourriez pas regarder un schéma et connaître les espaces de noms dans lesquels tout appartenait, car cette décision serait reportée jusqu'à ce qu'une instance soit écrite.

17
Kevin

Q: "Par convention, nous utilisons des URI/URL, mais nous pouvons utiliser n'importe quelle chaîne, que nous attribuons ensuite à un préfixe pour la réutilisation par des nœuds et des attributs XML, ou utiliser simplement comme espace de noms par défaut pour l'étendue à portée de main."

R: Oui, exactement.

Q: "Pour une raison quelconque, les inventeurs du schéma XML ont estimé que la notion d'espaces de noms simples n'était pas suffisante et ils ont dû introduire le targetNamespace."

R: http://www.liquid-technologies.com/Tutorials/XmlSchemas/XsdTutorial_04.aspx

La division des schémas en plusieurs fichiers peut présenter plusieurs avantages. Vous pouvez créer des définitions réutilisables qui peuvent être utilisées dans plusieurs projets. Ils facilitent la lecture et la version des définitions en décomposant le schéma en unités plus petites et plus simples à gérer.

...

Tout cela fonctionne bien sans espaces de noms, mais si différentes équipes commencent à travailler sur des fichiers différents, alors vous avez la possibilité de conflits de noms, et il ne serait pas toujours évident d'où vient une définition. La solution consiste à placer les définitions de chaque fichier de schéma dans un espace de noms distinct.

Clarification:

  • Le but principal des schémas XML est de déclarer des "vocabulaires".

  • Ces vocabulaires peuvent être identifiés par un espace de noms spécifié dans l'attribut targetNamespace.

  • Le schéma (un document XML) peut avoir un "espace de noms". Le "vocabulaire" décrit dans le document peut avoir un "targetNamespace".

  • Tout comme les schémas XML fournissent un niveau d'abstraction plus élevé que les DTD SGML (les architectes originaux de XML pensaient que les DTD étaient suffisants), le schéma XML "targetNamespaces" fournit un niveau d'abstraction sur les "espaces de noms simples".

'J'espère que ça t'as aidé

14
paulsm4

Je pense qu'il est utile de regarder à la fois le document d'instance et le document de schéma en même temps pour comprendre ce que fait targetNamespace. Considérez ceci (basé sur votre document d'instance):

<p:Person
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:p="http://localhost:8080/scribble/xml/Person"
        xmlns:v="http://localhost:8080/scribble/xml/Vehicle"
        xsi:schemaLocation="
            http://localhost:8080/scribble/xml/Person
            http://localhost:8080/scribble/xml/person.xsd">
    <name>John</name>
    <age>28</age>
    <height>59</height>
    <v:Vehicle>
        <color>Red</color>
        <wheels>4</wheels>
        <seats>2</seats>
    </v:Vehicle>
</p:Person>

Aucun espace de noms par défaut n'est spécifié pour le document, mais p: * et v: * sont associés à des URI spécifiques NS. Jetez maintenant un œil au document de schéma lui-même:

<?xml version="1.0" encoding="UTF-8"?>
<schema
    xmlns="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://localhost:8080/scribble/xml/Person"
    elementFormDefault="qualified"
    xmlns:v="http://localhost:8080/scribble/xml/Vehicle">

    <import
        namespace="http://localhost:8080/scribble/xml/Vehicle"
        schemaLocation="http://localhost:8080/scribble/xml/v.xsd"/>

    <element name="Person">
        <complexType>
            <sequence>
                <element name="name" form="unqualified" type="NCName"/>
                <element name="age" form="unqualified" type="integer"/>
                <element name="height" form="unqualified" type="integer"/>
                <element ref="v:Vehicle"/>
            </sequence>
        </complexType>
    </element>

</schema>

et

<?xml version="1.0" encoding="UTF-8"?>
<schema
    xmlns="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://localhost:8080/scribble/xml/Vehicle"
    elementFormDefault="qualified">

    <element name="Vehicle">
        <complexType>
            <sequence>
                <element name="color" form="unqualified" type="NCName"/>
                <element name="wheels" form="unqualified" type="integer"/>
                <element name="seats" form="unqualified" type="integer"/>
            </sequence>
        </complexType>
    </element>
</schema>

Si vous regardez les attributs sur les balises, l'espace de noms par défaut est " http://www.w3.org/2001/XMLSchema " pour les deux documents de schéma ... mais le targetNamespace est celui utilisé comme espace de noms alias dans le document d'instance.

targetNamespace est l'espace de noms attendu des instances indépendamment de l'espace de noms des documents de schéma et de tout autre espace de noms spécifié dans le document d'instance.

Je trouve utile de penser à cela comme organiser une fête où vous avez une liste d'invités et des invités portant des porte-noms. Pensez à targetNamespace dans les documents de schéma comme les noms sur la liste des invités. Les xmlns, aliasés ou non, dans les documents d'instance sont comme les tags de nom sur les invités. Tant que vous avez la liste des invités (qui comprend miraculeusement une photocopie de leur pièce d'identité officielle), chaque fois que vous rencontrez quelqu'un, vous pouvez valider son identité. Si vous rencontrez quelqu'un portant une étiquette de nom qui ne correspond pas aux paramètres attachés, vous pouvez paniquer (c'est-à-dire lancer une erreur).

Avec le schéma/les instances, vous avez:

Schémas:

targetNamespace="http://localhost:8080/scribble/xml/Person"
targetNamespace="http://localhost:8080/scribble/xml/Vehicle"

Exemple:

xmlns:p="http://localhost:8080/scribble/xml/Person"
xmlns:v="http://localhost:8080/scribble/xml/Vehicle"

Ou ... tout invité surnommé "v" que vous rencontrez n'importe où dans la fête (sauf règles spéciales qui disent le contraire), n'importe quel étage de la maison ou dans la cour ou dans la piscine, correspond mieux à la description d'un invité sur l'invité liste nommée http: // localhost: 8080/scribble/xml/Vehicle . ou ils sont un intrus.

Ces règles spéciales peuvent dire quelque chose comme, V ne peut sortir que s'il est immédiatement à côté de P, ou P ne peut sortir que si V est présent. Dans ce cas, P doit se bloquer lorsque V est là, mais V peut aller à peu près partout où il veut sans que A soit là.

De cette façon, un schéma peut être incroyablement flexible, définissant à peu près n'importe quelle structure de données souhaitée et pouvant suivre ce qui se passe simplement en faisant correspondre les espaces de noms (par défaut ou préfixés) d'un élément donné au TNS et au schéma associé.

11
jrypkahauer

Je ne comprends pas exactement ce que vous demandez. De toute évidence, un schéma peut contenir des définitions de composants dans de nombreux espaces de noms différents, et il doit y avoir un moyen de dire "Ceci est une déclaration de l'élément E dans l'espace de noms N". Les concepteurs de XSD ont choisi de concevoir le langage de sorte que toutes les déclarations dans un document de schéma appartiennent au même espace de noms, appelé espace de noms cible du module. Il aurait pu être emballé différemment, mais la différence serait très superficielle. Selon vous, qu'est-ce qui ne va pas exactement avec la décision d'aligner les modules sur les espaces de noms?

4
Michael Kay