Sie haben während Ihrer Studien der XDR- und XSD-Schemata bereits mehrfach XML- Namensräume verwendet. Sie werden sich daran erinnern, dass ein XML-Prozessor Namensräume während des Validierprozesses verwendet, damit sie ihm bei der Identifizierung der XDR- und XSD-Schemata helfen. Heute werden Sie Folgendes lernen:
Das Datenmodell, das XML-Auszeichnungen charakterisiert, besteht normalerweise aus einem Baum von Elementen. Die Baumstruktur hilft dabei, die hierarchische Struktur von XML-Dokumenten zu definieren. Sie haben am 2. Tag Baumdiagramme für einfache XML-Dokumente erzeugt, als Sie im Detail erforschten, was eine wohl geformte XML- Syntax ist.
Die Baumstruktur bei XML werden Sie am 12. Tag näher untersuchen, wenn Sie lernen, mit der Applikations-Programmierschnittstelle (API) des Document Object Models (DOM) auf XML-Dokumente zuzugreifen. Eine DOM-API stellt Ihnen die programmatischen Mittel zur Verfügung, um auf Knoten - wie etwa Elemente, Attribute und Kommentare - zuzugreifen, die den XML-Dokumentbaum ausmachen.
Bei der Auszeichnung mit XML hat jedes Element einen Namen für den Elementtyp - auch Tag-Namen genannt - und es kann entweder Attribute enthalten oder nicht. Sie wissen bereits, dass alle Attribute für ein bestimmtes Element im Start-Tag des Elements eingeschlossen sind, das sie modifizieren. Jedes Attribut besteht aus einem Namen und einem korrespondierenden Wert. Das W3C nennt die Kombination aus Elementtyp- Namen und Attributs-Namen das Auszeichnungsvokabular (http://www.w3.org/TR/REC- xml-names/).
Anwendungen, die zur Verwendung von XML-Daten programmiert werden, verwenden in der Regel das Auszeichnungsvokabular, um zu bestimmen, wie jedes Element zu verarbeiten ist. Elemente mit anderen Namen werden häufig anders gehandhabt, wogegen diejenigen mit einem gemeinsamen Namen auf die gleiche Weise verarbeitet werden. nachricht-Elemente können zum Beispiel anders verarbeitet werden als antwort- Elemente, aber es ist anzunehmen, dass alle nachricht-Elemente in einer Dokument- Instanz gleich behandelt werden.
Es funktioniert gut, Namenskonventionen auf diese Art zu behandeln, wenn Sie - der Dokumentautor - sicherstellen, dass alle Elemente und Attribute, die einmalig sein sollen, auch einen eindeutigen Namen bekommen. Selbstverfasste Namen haben jedoch die Tendenz, in einer öffentlichen Umgebung wie dem Web Schwierigkeiten zu machen, weil es dort üblich ist, Daten gemeinsam zu verwenden oder Dokumente zu verschmelzen. Bei vielen Transaktionen im E-Business etwa kommt es zu einer Verschmelzung von Daten aus mehreren Ursprungsressourcen. Wo dies der Fall ist, kann es dazu kommen, dass Element- oder Attributs-Namen doppelt vorkommen und die Verarbeitung schwieriger oder unmöglich wird. Wenn zum Beispiel zwei Geschäftspartner XML-Daten austauschen und jeder das nachricht-Element zur Darstellung anderer Datentypen oder Klassen verwendet, wird die verarbeitende Anwendung nicht in der Lage sein, zwischen den beiden zu unterscheiden. Das Resultat ist, dass nachricht in einer einzigen Dokument- Instanz zwei unterschiedliche Bedeutungen hat - ein Namenskonflikt.
Sie haben gesehen, dass XML Ihnen erlaubt, strukturierte Daten in eine Textdatei einzufügen, und dass die Art dieser Struktur bereits Kenntnisse über die auszuzeichnenden Daten einschließt. Werden Elementtyp-Namen, die unterschiedliche Datenklassen darstellen, in die gleiche Dokument-Instanz eingefügt, sind diese Kenntnisse und die Datenwerte nichts mehr wert.
Sie haben zahlreiche Beispiele dafür gesehen, wie vielfältig die Auszeichnungsmöglichkeiten bei XML sind, einschließlich der Möglichkeit, dass Sie Ihre eigenen Tags erstellen. Natürlich können auch diejenigen, mit denen Sie Daten gemeinsam benutzen oder verschmelzen, ihre eigenen Tags erzeugen, wie bei obigem Beispiel aus dem Bereich des E-Commerce. Es ist möglich, dass beide Beteiligten unterschiedliche Elemente erzeugen, die den gleichen Namen haben - das ist sogar sehr wahrscheinlich. Wenn dies geschieht, kommt es zu Namenskonflikten und eine Anwendung kann den Unterschied zwischen den identisch benannten Elementen nicht erkennen.
Als Beispiel nehmen wir an, Sie zeichnen ein Dokument zur Struktur eines Komitees aus, die ein Element namens chair (Vorstand) enthält, mit dem eine Person aus dem Vorstand oder der Komiteeleitung identifiziert wird. Das Dokument listet die Mitglieder dann namentlich auf. Listing 8.1 zeigt eine solche XML-Dokument-Instanz.
Listing 8.1: Ein einfaches XML-Dokument, das eine Komitee-Struktur anzeigt - komitee.xml
1: <?xml version="1.0"?>
2: <!-- Listing 8.1 - komitee.xml -->
3:
4: <komitee>
5: <chair>Kathy</chair>
6: <mitglied>Merrenna</mitglied>
7: <mitglied>Doug</mitglied>
8: <mitglied>Greg</mitglied>
9: <mitglied>Kristen</mitglied>
10: </komitee>
Beachten Sie, dass es sich bei diesem XML-Dokument um eine bloße Namensliste handelt, bei der eine Person als chair, Vorstand des Komitees, bezeichnet wird. Die anderen Komiteemitglieder folgen in den mitglied-Elementen.
Später wird dieses Dokument mit Daten zusammengefügt, die der Veranstalter der Sitzung liefert und die die Sitzordnung der einzelnen Komiteemitglieder bei einer bevorstehenden Veranstaltung festlegt. Die Auszeichnungen des Veranstalters enthalten ebenfalls das Element chair (Sitzplatz), das den Sitzplatz identifizieren soll, den jedes Komiteemitglied am Konferenztisch erhält. Listing 8.2 zeigt dieses Dokument:
Listing 8.2: Die XML-Dokument-Instanz einer Sitzordnung - sitzordnung.xml
1: <?xml version="1.0"?>
2: <!-- Listing 8.2 - sitzordnung.xml -->
3:
4: <sitzplatz>
5: <chair>tischende</chair>
6: <chair>erster links</chair>
7: <chair>zweiter links</chair>
8: <chair>erster rechts</chair>
9: <chair>zweiter rechts</chair>
10: </sitzplatz>
Verschmilzt man beide Dokumente, führt dies zu einiger Verwirrung, weil das Element chair in den jeweiligen Instanzen des Originaldokuments zwei verschiedene Elemente beschreibt. Listing 8.3 zeigt das zusammengefügte Dokument.
Listing 8.3: Konferenzplanung mit einem Namenskonflikt - konferenz.xml
1: <?xml version="1.0"?>
2: <!-- Listing 8.3 - konferenz.xml -->
3:
4: <konferenz>
5: <chair>Kathy</chair>
6: <chair>tischende</chair>
7: <mitglied>Merrenna</mitglied>
8: <chair>erster links</chair>
9: <mitglied>Doug</mitglied>
10: <chair>zweiter links</chair>
11: <mitglied>Greg</mitglied>
12: <chair>erster rechts</chair>
13: <mitglied>Kristen</mitglied>
14: <chair>zweiter rechts</chair>
15: </konferenz>
Der Namenskonflikt beim chair-Element im resultierenden verschmolzenen Dokument stellt eine Anwendung, die diese Daten verarbeiten soll, vor ein Problem. Die Anwendung erkennt keinen Unterschied zwischen dem chair-Element in Zeile 5, das aus der Komitee- Auszeichnung stammt, und den Elementen, die ihren Ursprung in der Sitzordnung haben und in den Zeilen 6, 8, 10, 12 und 14 der verschmolzenen Dokument-Instanz auftreten. Für die Anwendung hat dieses Dokument nur eine Datenklasse, zu der das Element chair gehört. Ein Mensch kann diesen Unterschied meistens gleich erkennen, aber eine Anwendung kann die beiden Klassen von chair-Elementen ohne zusätzliche Informationen nicht unterscheiden. Deshalb wird die Verarbeitung problematisch, solange die Anwendung nicht davon informiert wird, dass zwei verschiedene Typen von chair- Elementen in Betracht gezogen werden müssen.
Mit den Namensräumen steht Ihnen ein Mechanismus zur Verfügung, mit dem Sie identisch benannte Elemente, die zu unterschiedlichen Datenklassen gehören, eindeutig identifizieren können. Wie dieser Mechanismus funktioniert, werden Sie gleich sehen, aber zunächst wollen wir ein weiteres Beispiel von XML-Daten untersuchen, die einen Namenskonflikt enthalten.
Angenommen, Sie haben ein XML-Dokument, das die Gegenstände in einem Büro beschreibt. Es gibt dort Bücher und Kunstwerke, die Sie in Ihrem XML-Dokument Punkt für Punkt auflisten wollen. Das XML-Dokument wird daher zwei verschiedene Klassen von gegenstand enthalten - Bücher und Kunstwerke.
Jeder gegenstand in der auflistung bekommt ein beschreibung-Element, ein titel- Element und ein Element, das den Schöpfer des Gegenstands identifiziert, den autor für die Bücher und den kuenstler für die Kunstwerke. Listing 8.4 zeigt ein Beispiel für eine solche Auflistung, die in XML ausgezeichnet wurde. Erkennen Sie neben dem Element gegenstand weitere Elemente, die Beispiele für einen Namenskonflikt sind?
Listing 8.4: Ein XML-Dokument mit Namenskonflikten - auflistung.xml
1: <?xml version="1.0"?>
2: <!-- Listing 8.4 - auflistung.xml -->
3:
4: <auflistung>
5:
6: <gegenstand>
7: <beschreibung>Ein Buch ueber XML</beschreibung>
8: <titel>M + T, XML in 21 Tagen, Zweite Ausgabe</titel>
9: <autor>Devan Shepherd</autor>
10: </gegenstand>
11:
12: <gegenstand>
13: <beschreibung>ein grossartiges Gemaelde</beschreibung>
14: <titel>Bermuda Longtails</titel>
15: <kuenstler>E. Anthony</kuenstler>
16: </gegenstand>
17:
18: </auflistung>
Potenzielle Namenskonflikte gibt es in diesem Beispiel bei gegenstand, das zu den Datenklassen Bücher und Kunst gehört. Mit anderen Worten, ein gegenstand Buch bedeutet etwas anderes als ein gegenstand Kunst. beschreibung ist bei Büchern anders als bei Kunstwerken; beide gehören zu verschiedenen Datenklassen. Das Element titel bei beiden Typen von Gegenständen ist ein anderer Problemfaktor. Diese kollidierenden Elementtyp-Namen sind problematisch, weil eine Anwendung, die diese Daten verwendet, bei den Elementen gegenstand, beschreibung und titel nicht differenzieren kann. Sie werden sehen, wie man diese Konflikte durch die Deklaration von Namensräumen auflösen kann.
Ein XML-Namensraum ist ein Bezeichner, der eindeutig auf eine Auflistung von Namen verweist, die in einem XML-Dokument als Elementtyp-Namen oder als Attributs-Namen verwendet werden können. Wenn man für eine bestimmte Datenklasse einen Namensraum festlegt, informiert man dadurch die XML-Anwendung, dass ein bestimmtes Element oder Attribut zu dem spezifizierten Namensraum oder dem Satz von Namen gehört, der diese Datenklasse kennzeichnet.
Im Endeffekt dient ein Namensraum dazu, Elementtyp-Namen und Attributs-Namen im Web oder einem anderen öffentlichen System eindeutig zu qualifizieren und Namenskonflikte bei Elementen gleichen Namens zu verhindern. Im Beispiel zur Konferenzplanung, das Sie vorhin untersucht haben, können Sie einen Namensraum komitee festlegen, der den chair-Elementtyp enthält, der den Komiteevorstand betrifft, und einen Namensraum sitzordnung, der den chair-Elementtyp einschließt, der die Sitzplätze am Konferenztisch identifiziert. Sie werden diese Namensräume später erzeugen, aber zunächst erhalten Sie die Gelegenheit, die Syntax und die Bestandteile, die eine Namensraum-Deklaration ausmachen, kennen zu lernen.
Sie haben in den vergangenen Tagen verschiedene Beispiele für eine XML-Namensraum- Deklaration kennen gelernt. Sie können sich diese Namensräume noch einmal ansehen, ebenso wie später die anderen, die Sie auf der Grundlage der Standardsyntax für die XML- Namensraum-Deklaration erzeugen werden. Ein XML-Namensraum beginnt mit einem reservierten Schlüsselwort für ein Attribut (xmlns), dem optional ein Doppelpunkt und ein Präfix folgen. Doppelpunkt und Präfix dienen später in der XML-Instanz als Proxy für Elementtyp- und Attributs-Namen, die in den Namensraum eingebunden sind, der durch den Attributswert in Form einer URI-Darstellung qualifiziert wird. Die beiden für einen XML-Namensraum typischen Formen enthalten eine einfache Deklarationsform, wie
xmlns="URI".
Es folgt ein Beispiel für eine einfache Deklaration mit einer imaginären URI:
xmlns="http://shepherdnamensraum.com/XML"
Wenn Sie einer XML-Instanz mit einem bestimmten Namensraum mehrere Elemente zuweisen wollen, ist es sinnvoll, eine Deklaration wie die folgende zu verwenden, die ein Präfix enthält, das als Proxy für diesen Namensraum dienen kann:
xmlns:praefix="URI"
Es folgt eine Namensraum-Deklaration, die ein vom Anwender definiertes Präfix und eine imaginäre URI enthält:
xmlns:komitee="http://shepherdnamensraum.com/XML/komitee"
Namensräume können als Standard-Namensräume deklariert werden, die zunächst die Form xmlns="URI" annehmen. Ein Standard-Namensraum umfasst den gesamten Bereich einer XML-Dokument-Instanz. In diesem Bereich wird ein Namensraum deklariert, der für alle Elemente dieses Bereichs gilt, und es wird kein Präfix gesetzt. Ein Standard- Namensraum umfasst alle Elementtypen und Attribute, die nicht in den Bereich einer expliziten Namensraum-Deklaration eingeschlossen sind.
Bei einer expliziten Deklaration, wie im zweiten Beispiel (xmlns:praefix="URI") definiert man eine Kurzform oder ein Präfix, das den vollständigen Namen des Namensraums als Proxy-Kennzeichnung für die spätere Dokument-Instanz ersetzt. Man verwendet dieses Präfix, um alle Elementtyp-Namen oder Attributs-Namen, die zu diesem spezifischen Namensraum gehören, zu qualifizieren und nicht für den Standardsatz.
Zu Beginn der heutigen Lektion erinnerten wir Sie daran, dass es sich bei XML- Dokumenten um hierarchische Baumstrukturen handelt, die aus verschiedenen Knoten aufgebaut sind. Explizite Deklarationen sind dann nützlich, wenn ein bestimmter Dokumentknoten Elementtypen oder Attribute aus anderen Namensräumen enthält.
Die Syntax für Elementtypen oder Attribute in einer Dokument-Instanz, die zu einem expliziten Namensraum gehören, schließen das kennzeichnende Präfix ein, dem ein Doppelpunkt sowie der Elementtyp- oder Attributs-Name folgen, wie in:
praefix:element
praefix:attribut
<komitee:vorstand>Kathy</komitee:vorstand>
<dateiname komitee:Listing="8.1">komitee.xml</dateiname>
In dem gezeigten Beispiel haben der Elementtyp vorstand und das Attribut listing ein Präfix code, mit dem angezeigt wird, dass sie zum Namensraum http:// shepherdnamensraum. com/XML/komitee gehören. Vergessen Sie nicht, dass diese URI nur eine Kennzeichnung zur Identifikation einer bestimmten Ansammlung von Elementen und Attributen ist, auch wenn sie wie eine Webadresse aussieht. Die Anwendung versucht nicht, eine Verbindung zu shepherdnamensraum.com herzustellen.
Das Präfix dient als Abkürzung, um es dem Dokumentautor zu ersparen, für jeden Elementtyp und jedes Attribut den kompletten Namensraum explizit deklarieren zu müssen, zu dem sie gehören. Das vollständig qualifizierte Element und Attribut, das ein XML-Parser so auflöst, dass er es zu einer vollständigen Namensraum-Deklaration erweitert, würde so aussehen:
<name xmlns="http://shepherdnamensraum.com /XML/komitee">
Ein einfaches XML-Dokument,
das eine Komiteestruktur anzeigt</name>
<dateiname code:Listing="8.1"
xmlns:code="http://shepherdnamensraum.com /XML/komitee">
komitee.xml</dateiname>
Eine URI für einen XML-Namensraum dient bloß als eindeutige Kennzeichnung für die Auflistung von Elementen und Attributen, die sie identifiziert. Es sollte Ihnen klar sein, dass die URI nur eine Reihe von Zeichen ist, die zur Unterscheidung von Namen verwendet werden.
Eine URI, die in einem XML-Namensraum verwendet wird, ist nur eine Kennzeichnung oder ein Zeichenstring, der den Namensraum eindeutig identifiziert. Worauf eine URI zeigt - wenn überhaupt -, macht keinen Unterschied. Eine URI dient lediglich dazu, der Auflistung von Elementtyp-Namen und Attributs-Namen, die sie charakterisiert, eine eindeutige Bezeichnung zu geben.
Manche Leser verwirrt es, dass bestimmte URI-Zeichenströme, die in manchen XML- Technologien verwendet werden, eine bekannte Form haben. Einige URIs schließen zum Beispiel URLs mit ein. Sie werden sich erinnern, dass die URI, die wir am 6. Tag verwendet haben, um ein XML Schema Definiton (XSD)-Schema für den XML-Parser zu identifizieren, im Wurzelelement des Schemas deklariert wird und immer folgende Form annimmt:
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
Das sieht sicherlich so aus, als wäre der Attributswert xmlns:xsd eine URL. Versuchen Sie einmal, den URL-Teil dieses Strings in einen Webbrowser einzugeben, um zu sehen, was dabei herauskommt. Wenn Sie diese Website mit dem Microsoft Internet Explorer 5.0 oder höher betrachten, erhalten Sie eine umgewandelte Ansicht des XML-Schemas, das zur Validierung eines XSD-Schemas benutzt wird. Mit anderen Worten, das W3C hat vorhergesehen, dass die Leute - vielleicht nur aus Neugier - versuchen würden, diese URL, die Teil des XSD-Namensraums ist, aufzulösen, und hat an der Stelle dieser URL ein XML-Dokument abgelegt.
Legen Sie zu Grunde, was Sie bisher gelernt haben: Glauben Sie, dass ein XML-Parser diese URL auflöst, wenn er eine Validierung nach den Beschränkungen durchführt, die in einem XSD-Schema programmiert wurden? Anders gesagt, es stellt sich die Frage, ob der XML-Parser das Schema herunterlädt, das Sie unter http://www.w3.org/2000/10/ XMLSchema gesehen haben, wenn er Ihr XML-Dokument validiert? Die Antwort ist in beiden Fällen »Nein«! Denken Sie daran, dass ein Namensraum nur eine Kennzeichnung ist. Die URI ist einfach ein eindeutiges Kennzeichen. Wenn die URI nun eine URL enthält, löst ein XML-Parser diese Webadresse nicht auf, wenn der Namensraum deklariert wird.
Warum sollte man aber eine URL verwenden, um einen Namensraum zu identifizieren? Es ist so, dass eine URL im gesamten Internet weltweit einzigartig ist. Wenn Sie einen Host- oder Domain-Namen registrieren, machen Sie ihn sich unter gegenwärtig etwa 450 Millionen aktueller Domain-Namen (Schätzung laut Internic News, Network Solutions, Inc., 2001) zu eigen. Die Internic, ein Dienst für die Domain-Registrierung, erlaubt in einer URL derzeit die Registrierung von Domain-Namen mit bis zu 22 Zeichen vor dem »Punkt«. Diese Zeichen umfassen eine beliebige Kombination aus englischen alphanumerischen Zeichen sowie dem Minuszeichen oder Gedankenstrich, wenn dieser nicht das erste Zeichen im String ist. Für Mathematikliebhaber: die gesamte mögliche Auswahl einzigartiger Namen für URL-Adressen vor dem Punkt sind somit 37 Zeichen an 22 verschiedenen Positionen permutiert, was einer Summe von 3.17× 10 hoch 34 oder 31.700.000.000.000.000.000.000.000.000.000.000 verschiedenen Möglichkeiten entspricht.
Wenn Sie an Ihre eigene einmalige Domain-Adresse Informationen anhängen, können Sie also ganz sicher sein, dass Sie eine einmalige Kennzeichnung für Ihren Namensraum erzeugen. Das ist genau der Gedanke, den das W3C verfolgte, um einen eindeutigen Namensraum für das XMD-Schema, das Sie am 6. Tag bei Ihren Übungen deklariert haben, zu erstellen.
Eine URI kann statt mit einer URL auch in Form eines Uniform Resource Name (URN) erzeugt werden. Am 5. Tag haben Sie gelernt, wie man mit der Sprache XML-Data Reduced (XDR) von Microsoft Schemata erzeugt. Sie erinnern sich vielleicht daran, dass Sie zwei Namensräume im Wurzelelement jedes XDR-Schemas, das Sie geschrieben haben, deklarierten. Diese Namensräume waren URNs, keine URLs; es handelte sich nicht um einen Uniform Resource Locator, der der Syntax einer Webadresse folgt. Per Definition ist ein URN jede URI, die etwas anderes als eine URL ist. Das mag wie eine übermäßig vereinfachte Definition aussehen, ist aber hilfreich bei der Unterscheidung von URNs und URLs. Bei den XDR-Schemata enthielten die Namensräume, die Sie programmierten, die folgenden URNs:
xmlns="urn:schemas-microsoft-com:xml-data"
xmlns:dt="urn:schemas-microsoft-com:datatypes"
Die erste Deklaration legte den Namensraum fest, der dem gesamten XDR-Dokument zugehörig ist und auch Standard-Namensraum genannt wird. Sie werden später mehr über Standard-Namensräume erfahren. Sie erinnern sich vielleicht, dass in der zweiten Deklaration ein Präfix identifiziert wurde, das als Proxy für den Datentyp-Namensraum dient, mit dem die Datentyp-Attribute, die bei XDR als Validierbeschränkungen eingesetzt werden, identifiziert werden. In der späteren XDR-Instanz konnten Sie dt:type-Attribute einsetzen, die Bedingungen für die Gültigkeit von Datentypen bei einem Element oder Attribut stellten. In dem Beispiel
<AttributeType name="kauf_datum" dt:type="date" required="ja"/>
etwa ist das Attribut kauf_datum für ein bestimmtes Element nur gültig, wenn der Wert für
dieses Attribut als Datenstring ausgedrückt wird, der der vorgeschriebenen Datentyp-Syntax
entspricht. Hier ist der einzige Name, der zum Namensraum für den Datentyp gehört, das
Attribut type, das als dt:type eingegeben wurde. Das AttributeType-Element und die
Attribute name und required gehören zum Standard-Namensraum
urn:schemas-microsoft-com: xml-data.
Es gibt eine Gruppe, die als Internet Engineering Task Force (IETF) bekannt ist und die, angeregt von einer anfänglichen Äußerung von R. Moats von AT&T im Mai 1997, an einer vordefinierten Syntax für URNs arbeitet. Diese Syntax wird Internet-Protokollnamen für die Auflösung bereitstellen, die eine größere Beständigkeit haben als die gegenwärtig im Internet vorkommenden Host- und Domain-Namen, die URLs verwenden. Wenn der Ansatz der IETF erfolgreich ist, sind Uniform Resource Names am Ende vielleicht URI-Schemata, die mit der Zeit den URLs gegenüber verlässlicher sein werden, was ihre Authentizität, ihre Replikation und ihre Verfügbarkeit angeht.
Ein Dokumentautor kann buchstäblich jeden Namen für einen Namensraum verwenden außer dem reservierten Namensraum xml, der intellektuelles Eigentum des W3C ist.
In den heute besprochenen Beispielen bieten die Namensräume für XSD und XDR wichtige Informationen für die XML-Anwendungen, die sie erkennen. Die Verwendung dieser vorgeschriebenen Namensräume ist keine bloße Konvention; Anwendungen, die XML-Dokument-Instanzen validieren, machen sie erforderlich. Auch wenn ein XML- Parser eine URL nicht auflöst, indem er die Beschränkungen für ein XSD-Schema validiert, erfordert er doch, dass dieser besondere Namensraum vorhanden ist. Trifft der Parser auf einen genau festgelegten Namensraum, kann er die XSD-Syntaxregeln anwenden, die der Anwendung eingebaut sind. Das gilt auch für andere XML- Anwendungen. Ein Namensraum ist nur eine Kennzeichnung wie ein Flag in anderen Computersprachen. Dieser Flag weist die Anwendung an, Elementtypen und Attribute, die zu der Auflistung gehören, die diese Kennzeichnung benennt, auf eine bestimmte Weise zu verarbeiten. Die Regeln zur Verarbeitung der Elementtypen und Attribute sind der Anwendung schon eingebaut, bevor sie das XML-Dokument parst.
Sie kennen jetzt die Syntax und die Theorie, die hinter Namensraum-Deklarationen stehen. Öffnen Sie also nun einen Texteditor und erzeugen Sie explizite Namensräume, um die Namenskonflikte aus den vorherigen Beispielen aufzulösen.
Fangen wir mit dem Beispiel des Konferenzplans für ein Komitee an. Deklarieren Sie explizite Namensräume für die Elementtypen aus dem komitee.xml-Markup und für diejenigen, die aus dem Quelldokument sitzordnung.xml stammen. Erstellen Sie für die Elementtypen aus dem Komitee-Dokument einen Namensraum, der das Präfix kmte hat, und verwenden Sie folgende URI:
http://shepherdnamensraum.com/XML/komitee
Vergessen Sie nicht, dass es ohne Belang ist, ob diese URI auf eine tatsächliche Website verweist, auch wenn sie wie eine gültige URL aussieht. Die URI ist nur eine intern vom XML-Prozessor verwendete Kennzeichnung. Bestimmen Sie nun für die Elementtypen zum Sitzplan einen Namensraum mit dem Präfix sitz, der eine URN einschließt:
urn:XML_in_21_Tagen:sitzplan
Speichern Sie Ihr Ergebnis in der revidierten Konferenz-Datei als konferenz02.xml, wenn Sie fertig sind. Sie sollten ein Resultat erhalten, das aussieht wie der Code in Listing 8.5.
Listing 8.5: Ein XML-Konferenz-Dokument mit Namensraum-Deklarationen - konferenz02.xml
1: <?xml version="1.0"?>
2: <!-- Listing 8.5 - konferenz02.xml -->
3:
4: <konferenz
xmlns:kmte="http://shepherdnamensraum.com/XML/komittee"
5: xmlns:sitz="urn:XML_in_21_Tagen:sitzordnung">
6: <kmte:chair>Kathy</kmte:chair>
7: <sitz:chair>tischende</sitz:chair>
8: <kmte:mitglied>Merrenna</kmte:mitglied>
9: <sitz:chair>erster links</sitz:chair>
10: <kmte:mitglied>Doug</kmte:mitglied>
11: <sitz:chair>zweiter links</sitz:chair>
12: <kmte:mitglied>Greg</kmte:mitglied>
13: <sitz:chair>erster rechts</sitz:chair>
14: <kmte:mitglied>Kristen</kmte:mitglied>
15: <sitz:chair>zweiter rechts</sitz:chair>
16: </konferenz>
Die XML-Namensräume, die Sie erzeugt haben, werden als Werte der xmlns-Attribute im Wurzelelement konferenz deklariert. Der Namensraum Komitee, http://shepherdnamensraum.com/XML/komitee, zeigt ein Präfix kmte, das jedem Namen der Elementtypen in den Start- und Schluss-Tags der Elemente angefügt wird, die zu diesem Namensraum gehören. Diese sehen Sie in den Zeilen 6, 8, 10, 12 und 14.
5: xmlns:sitz="urn:XML_in_21_Tagen:sitzordnung">,schließt die Namensraum-Deklaration für die Elementtypen ein, die aus dem Quelldokument sitzordnung.xml stammen. Das Präfix sitz wird jedem der chair-Elemente angefügt, die zum sitz-Namensraum gehören. Diese Elemente stehen in den Zeilen 7, 9, 11, 13 und 15.
Führen Sie nun den gleichen Prozess für das XML-Dokument zur Auflistung der Bürogegenstände durch, das in Listing 8.4 gezeigt wurde. Sie erinnern sich bestimmt, dass es Elementtypen aus zwei Datenklassen enthielt: einen mit dem Merkmal Bücher und einen mit dem Merkmal Kunstwerke. Erzeugen Sie mit einem Texteditor ein neues Dokument, auflistung02.xml, das einen Standard-Namensraum für die Bücher-Elemente mit der URI http://www.devan.org/buecher enthält, sowie einen expliziten Namensraum mit dem Präfix kunst, der die URI urn:meinedinge:kunstwerke einschließt. Wenn Sie damit fertig sind, vergleichen Sie Ihr Resultat mit dem Beispiel in Listing 8.6.
Listing 8.6: Das Auflistungs-Dokument mit XML-Namensraum-Deklarationen - auflistung02.xml
1: <?xml version="1.0"?>
2: <!-- Listing 8.6 - auflistung02.xml -->
3:
4: <auflistung xmlns="http://www.devan.org/buecher"
5: xmlns:kunst="urn:meinedinge:kunstwerke">
6:
7: <gegenstand nummer="1">
8: <beschreibung>ein XML-Buch</beschreibung>
9: <titel>M + T, XML in 21 Tagen, Zweite Ausgabe</titel>
10: <autor>Devan Shepherd</autor>
11: </gegenstand>
12:
13: <kunst:gegenstand nummer="1">
14: <kunst:beschreibung>ein grossartiges
Gemaelde</kunst:beschreibung>
15: <kunst:titel>Bermuda Longtails</kunst:titel>
16: <kunst:kuenstler>E. Anthony</kunst:kuenstler>
17: </kunst:gegenstand>
18:
19: </auflistung>
Die Zeilen 4 und 5 zeigen das Wurzelelement für das XML-Dokument mit einem Standard-Namensraum (in Zeile 4) und einem expliziten Namensraum mit einem Präfix (kunst) in Zeile 5.
Da das erste gegenstand-Element (Zeilen 7-11) und seine abgeleiteten Elemente zum Standard-Namensraum gehören, wird in den Element-Tags kein Präfix eingefügt. Das zweite gegenstand-Element und seine Ableitungen dagegen gehören zum Namensraum urn:meinedinge:kunstwerke; daher schließt jedes Start- und Schluss-Tag dieser Elemente das Präfix kunst in den Elementtyp-Namen ein.
Sie konnten bereits XDR- und XSD-Namensräume kennen lernen sowie einige andere. Tabelle 8.1 bietet eine Referenzliste für mehrere Standard-Namensräume bei XML, die allgemein verwendet werden. Einige davon werden wir in den nächsten Tagen verwenden.
Sie haben heute gelernt, dass Namenskonflikte auftreten können, wenn Dokumente aus verschiedenen Quellen zusammengefügt werden. Dokumentautoren können ihre eigenen Elementtyp- und Attributs-Namen nach Belieben auswählen; daher können bei verschmolzenen Auszeichnungsvokabularien identische Tag-Namen vorkommen. Namensräume bieten eine Methode für Entwickler, Namenskonflikte zu vermeiden, indem sie gleich benannten Elementen verschiedener Datenklassen eine eindeutige Identität verschaffen. Jede Datenklasse kann einem spezifischen Namensraum zugewiesen werden. Auf diese Weise wird der Namensraum zu einer Ansammlung von Elementtyp- und Attributs-Namen, die diese bestimmte Datenklasse charakterisieren.
Namensräume werden mit URIs identifiziert, die URLs oder URNs einschließen können. Dokumentautoren verwenden URIs, um so weit wie möglich sicherzustellen, dass jeder Namensraum weltweit einzigartig ist. Diejenigen URIs, die URLs umfassen, werden von der XML-Anwendung nicht aufgelöst. statt dessen bieten URIs nur eine Kennzeichnung, die die Anwendung anweist, Elemente und Attribute gemäß einer bereits zu Grunde liegenden Logik auf eine bestimmte Weise zu verarbeiten.
Eine Reihe standardmäßiger Namensräume werden von bestimmten Technologien identifiziert. Einige XML-Anwendungen verlangen die Verwendung dieser spezifischen Namensräume.
Frage:
Was ist ein Namenskonflikt?
Antwort:
Ein Namenskonflikt tritt auf, wenn zwei verschiedene Elementtypen oder
Attribute, die auf zwei Datenklassen verweisen, den gleichen Namen in einem
Auszeichnungsdokument haben.
Frage:
Wann kann ein Namenskonflikt auftreten?
Antwort:
Namenskonflikte treten meist dann auf, wenn XML-Daten aus mehreren Quellen
in einer einzigen Dokument-Instanz zusammengefügt werden. In einem solchen
Fall ist es möglich, dass zwei identisch benannte Elementtypen oder Attribute auf
völlig unterschiedliche Datentypen verweisen.
Frage:
Wie kann man Namenskonflikte verhindern?
Antwort:
Namensräume bieten einem Entwickler einen einfachen Mechanismus, um
gleichbenannte Tags eindeutig zu identifizieren und zu unterscheiden und
vermeiden so mögliche Namenskonflikte.
Frage:
Wie unterscheidet sich die Syntax eines Standard-Namensraums von einem explizit
definierten Namensraum, der in der gleichen Dokument-Instanz vorkommt?
Antwort:
Einem Standard-Namensraum ist kein Präfix eingefügt, das als Proxy in der
gesamten restlichen XML-Dokument-Instanz eingesetzt wird. Elementtyp-Namen
und Attributs-Namen, die kein Präfix einschließen, gehören zum Standard-
Namensraum. Ein expliziter Namensraum schließt dagegen ein Präfix mit ein, das
den Elementtyp- und Attributs-Namen in den Start- und Schluss-Tags der
Elemente, die zum expliziten Namensraum gehören, eingefügt wird.
Frage:
Warum muss man einen spezifischen Standard-Namensraum verwenden, um XML-
Elemente zu identifizieren, die zum XSD-Schema gehören?
Antwort:
Der spezifische Namensraum (http://www.w3.org/2000/10/XMLSchema) wird von
allen XML-Anwendungen und Parsern erkannt, denen die Syntaxregeln für XSD
eingebaut sind. Der spezifische Namensraum ist eigentlich der einzige, mit dem
man Elemente und Attribute von XML-Dokumenten als Teil der XSD-Sammlung
identifizieren kann; deshalb gibt es keine andere Möglichkeit, einen Parser zu
veranlassen, das XML-Instanzdokument mit den in XSD programmierten
Beschränkungen zu validieren.
Die Übung soll Ihre Kenntnisse dessen, was Sie heute gelernt haben, überprüfen. Die Lösungen finden Sie in Anhang A.
In der ersten Woche haben Sie eine wohl geformte XML-Instanz erzeugt, um eine CD- Sammlung auszuzeichnen. Später haben Sie dieses Dokument mit DTDs, den XDR- und XSD-Schemata validiert und ihm einige Entities angefügt. Heute fügen Sie Ihrer Music Collection Markup Language (MCML) eine neue Datenklasse hinzu. Die neue Datenklasse verwenden Sie, um Datenverzeichnisse auszuzeichnen, bei denen es sich um Vinyl-LPs handelt, nicht um CDs.
