Warum brauchen wir targetNamespace?
Ich würde gerne verstehen, den Sinn des targetNamespace-wie sowohl in XML-Schema-und WSDL. In der Tat, Dinge einfach zu halten, lassen Sie uns begrenzen, diese Frage zu XML-Schema.
Fühle ich mich wie ich voll verstehen, den Begriff der (einfachen) XML-namespaces. Per Konvention verwenden wir URI/URLs, aber wir könnten jede beliebige Zeichenfolge verwenden, die wir dann zuordnen, um ein Präfix für die Wiederverwendung von XML-Knoten und-Attributen, oder verwenden Sie einfach als Standard-namespace für den Bereich an der hand. So weit, So gut ?
Nun in XML-Schema. Für einige Grund, der Erfinder von XML-Schema spürte den Begriff der einfachen namespaces war nicht genug, und Sie hatte die Einführung der targetNamespace. Meine Frage ist : was erhebliche Vorteile hat eine targetNamespace einzuführen, konnte nicht zur Verfügung gestellt werden, die von einem normalen XML-namespace ? Wenn ein XML-Dokument verweist auf ein xsd-Dokument, entweder durch schemaLocation-Attribut oder mit einer import-Anweisung in jedem Fall gebe ich den Pfad zur eigentlichen xsd-Dokument referenziert werden. Dies ist, was definiert eindeutig das Schema möchte ich verweisen. Wenn außerdem will ich binden Sie dieses Schema, um ein bestimmtes namespace in meinem verweisenden Dokument, warum sollte ich verpflichtet sein, zu replizieren, die präzise targetNamespace bereits definierte XML-Schema ich bin Referenzierung? Warum konnte ich nicht einfach neu definieren, diesen namespace möchte ich aber innerhalb des XML-Dokuments, in dem dieser namespace wird verwendet, um zu verweisen, dass insbesondere XML-Schema-Dokument möchte ich verweisen ?
Update:
Um ein Beispiel zu geben, wenn ich das folgende in eine XML-Instanz-Dokument:
<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>
Warum z.B. die Menschen.xsd-Schema definiert werden muss targetNamespace ist "http://contoso.com/schemas/People"? Warum brauchen wir die targetNamespace-definition im xsd-Dokument überhaupt? Es scheint mir, alle, die Sie haben, um aus der namespace-Teil des schemaLocation-Attribut ist bereits enthalten in der XML-Instanz-Dokument. Was ist der Vorteil der Durchsetzung der Existenz einer targetNamespace mit gleichem Wert über die im xsd-Dokument ?
Follow-up-Frage an Paul ' s Antwort:
Können Sie mir ein konkretes Beispiel, wo solche "Zusammenstöße" zwischen xsd-element-Namen wird deutlich, und das würde erklären, die Notwendigkeit für targetNamespace ?
Ok, hier ein Versuch der Antwort auf meine eigene Frage. Lassen Sie mich wissen, wenn es scheint, kohärent zu Ihnen. Betrachten Sie die Beispiele auf der verlinkten Seite von Paul half mir.
Wenn wir die XML-Instanz, die beispielsweise in der ursprünglichen Frage erwähnt, wir haben zwei Verweise auf die definition von Fahrzeug element. Eine explizite und sichtbar in der XML-Instanz-Dokument selbst, aber wir müssen uns auch vorstellen, dass die person.xsd-XML-Schema-Referenzen das gleiche Fahrzeug definition wieder als ein zulässiges child-element der person. Wenn wir normal namespaces, in denen jedes Dokument, durften Sie definieren einen eigenen Namensraum für die Fahrzeug -, wie würden wir wissen, dass die XML-Instanz verweist, die die XML-Schema-definition für das Fahrzeug ist die person.xsd ? Die einzige Möglichkeit ist, sich mit der Durchsetzung eines Konzepts der namespace, die strenger als die ursprüngliche, einfache ein-und die müssen geschrieben werden, die genau den gleichen Weg über mehrere Dokumente.
Wenn ich nicht diese schreiben auf einem tablet, ich würde ein code-Beispiel, aber hier werde ich nur versuchen zu beschreiben, das Beispiel, das ich im Sinn haben.
Mir vorstellen, dass wir zwei verschiedene XML-Schema-Definitionen für ein Fahrzeug element. location1/Fahrzeuge.xsd enthält die definition bestätigt, dass das Beispiel aus der Frage von diesem post (mit Farbe, Räder und Sitze child-Elementen), in der Erwägung, dass location2/Fahrzeuge.xsd enthalten würde, eine völlig andere definition für ein Fahrzeug element (sagen wir, mit child-Elemente, Jahr, Modell und Lautstärke). Nun, wenn die XML-Instanz-Dokument bezieht sich auf die location1-Schema, wie in dem Beispiel oben, sondern person.xsd sagt, dass die person element enthalten kann, die ein Fahrzeug Kind-element des Typs definiert ist, in der location2-Schema, dann ohne die Vorstellung von einem targetNamespace, die XML-Instanz validieren würde, obwohl es eindeutig nicht die richtige Art von Fahrzeug wie ein Kind-element von seiner person element.
Target-namespaces, dann helfen Sie uns sicherzustellen, dass, wenn zwei verschiedene Dokumente verweisen auf dieselbe Dritte XML Schema, Sie sind beide in der Tat, verweisen auf das gleiche Schema und nicht nur ein Schema, das Elemente enthält, die ähnlich, aber nicht identisch zu einem der anderen...
Ist das sinnvoll ?
InformationsquelleAutor der Frage Student | 2012-03-24
Du musst angemeldet sein, um einen Kommentar abzugeben.
Du scheinst auf der richtigen Spur ist. Damit werde ich ein paar Punkte hier, die helfen könnten.
Ich denke, was Sie waren, vorausgesetzt ist, dass die Instanz-Dokument könnte geben Sie den namespace der Elemente und Attribute deklariert in einigen schema-Dokument, Verwendung von xsi:schemaLocation. Das funktioniert aber nicht. Für eine Sache, die der parser kann suchen andere schema-Dokumente als diejenigen, die aufgelistet ist, und es muss wissen, welchen namespace Sie sind für. Für die anderen, es würde die Argumentation über die Schemen schwierig oder unmöglich: Sie wäre nicht in der Lage, zu betrachten, ein schema und kennen die namespaces, dass alles, was gehört da, dass die Entscheidung vertagt wird eine Instanz geschrieben wurde.
InformationsquelleAutor der Antwort Kevin
A: ja, genau.
A: http://www.liquid-technologies.com/Tutorials/XmlSchemas/XsdTutorial_04.aspx
Klarstellung:
Ist der primäre Zweck von XML-Schemas zu erklären "Vokabulare".
Diese Vokabulare identifiziert werden kann, indem ein namespace angegeben wird, in dem targetNamespace-Attribut.
Schema (XML-Dokument) kann einen "namespace". Das "Vokabular" des Dokuments beschreibt, kann ein "targetNamespace".
Nur als XML-Schemata bieten einen höheren Grad der Abstraktion als SGML-DTD 's (die ursprünglichen Architekten von XML dachte DTD' s wurden ausreichend), XML-Schema "targetNamespaces" bieten eine Abstraktionsebene über "simple namespaces".
'Hoffe, das hilft
InformationsquelleAutor der Antwort paulsm4
Denke ich, hilft es zu schauen, sowohl die instanzdokument und schema-Dokument zur gleichen Zeit zu verstehen, was targetNamespace tut. Betrachten Sie diese (basierend auf den Instanz-Dokument):
Gibt es kein Standard-namespace für das Dokument angegeben wurde, aber p:* und v:* alias \ " spezifische NS-URIs. Nun nehmen Sie einen Blick auf das schema-Dokument selbst:
und
Wenn man sich die Attribute bei tags, die Standard-namespace ist "http://www.w3.org/2001/XMLSchema" sowohl die schema-Dokumente... aber der targetNamespace ist die Verwendung als alias-namespace im Dokument.
targetNamespace ist der erwartete namespace der Instanzen unabhängig von der namespace der schema-Dokumenten und beliebigen anderen namespace angegeben, der in der Instanz-Dokument.
Finde ich es hilfreich, daran zu denken, wie eine party, wo Sie haben eine Gästeliste und die Gäste tragen Namensschilder. Denke, dass der targetNamespace im schema-Dokumente, wie den Namen auf der Gästeliste. Das xmlns -, alias-oder nicht, in den Instanz-Dokumenten ist wie die name-tags auf die Gäste. Wie lange haben Sie die Gästeliste (die auf wundersame Weise umfasst eine Fotokopie von Ihrem Staat ausgestellten ID), wenn Sie jemandem begegnen, können Sie überprüfen Ihre Identität. Wenn Sie über jemand trägt einen name-tag, der nicht mit den angehängten Parametern, die Sie ausflippen können, (D. H. Fehler).
Mit dem schema/Instanzen, die Sie haben:
Schemas:
Beispiel:
... Oder jedem Gast den Spitznamen "v" , Sie begegnen überall in der Partei (sofern keine speziellen Regeln, die etwas anderes sagen), jede Etage des Hauses oder in den Garten oder in den pool, besser zu entsprechen, wird die Beschreibung für einen Gast auf die Gästeliste namens http://localhost:8080/scribble/xml/Vehicle. oder Sie sind ein Eindringling.
Diese speziellen Regeln kann sagen, so etwas wie, kann V nur hängen, wenn Sie unmittelbar neben P, oder P kann nur hängen, wenn V vorhanden ist. In diesem Fall, P zu hängen, wenn V ist es, aber V gehen kann so ziemlich überall Sie wollen, ohne dort zu sein.
Diese Weise ein schema sein kann, unglaublich flexibel, die Definition so ziemlich jede Datenstruktur, die gewünschten und zu verfolgen, was geht, wo nur durch die Zuordnung der namespaces (Standard-oder Präfix) eines gegebenen Elements zurück zu den TNS und den dazugehörigen schema.
InformationsquelleAutor der Antwort jrypkahauer
Es ist mir nicht klar, was genau Sie zu Fragen. Eindeutig ein schema enthält Definitionen von Komponenten in vielen verschiedenen namespaces, und es hat eine Art zu sagen: "Dies ist eine Erklärung des element E im namespace N". Die Designer von XSD entschieden haben, die Sprache so, dass alle Deklarationen in einem schema-Dokument gehören zum gleichen Namensraum, das sogenannte Ziel-Namensraum des Moduls. Es hätte auch anders verpackt, aber der Unterschied wäre sehr oberflächlich. Was genau denken Sie, ist falsch mit der Entscheidung zu richten-Module mit namespaces?
InformationsquelleAutor der Antwort Michael Kay