XML und NETCONF XML Management Protocol Konventionen – Übersicht

Request-and-Response-Tag-Elemente

Ein Request-Tag-Element wird von einer Client-Anwendung generiert, um Informationen über den aktuellen Status oder die aktuelle Konfiguration eines Geräts anzufordern oder die Konfiguration zu ändern. Ein Request-Tag-Element entspricht einem CLI-Betriebs- oder Konfigurationsbefehl. Es kann nur innerhalb eines <rpc> Tags auftreten. Informationen zum <rpc> Element finden Sie unter Senden von Anforderungen an den NETCONF-Server.

Ein Antworttag-Element stellt die Antwort des NETCONF-Servers auf ein Request-Tag-Element dar und tritt nur innerhalb eines Tags auf <rpc-reply> . Informationen zum <rpc-reply> Element finden Sie unter Analysieren der NETCONF-Serverantwort.

Das folgende Beispiel stellt einen Austausch dar, in dem eine Clientanwendung das <get-interface-information> Request-Tag-Element mit dem <extensive/> Flag ausgibt und der NETCONF-Server das <interface-information> Antworttag-Element zurückgibt.

Client-Anwendung

NETCONF-Server

Hinweis:

Dieses Beispiel zeigt, wie alle anderen in diesem Leitfaden, jedes Tag-Element in einer separaten Zeile in den Tag-Streams, die sowohl von der Clientanwendung als auch vom NETCONF-Server ausgegeben werden. In der Praxis muss eine Client-Anwendung keine Zeilezeichen zwischen Tag-Elementen enthalten, da der Server solche Leerzeichen automatisch verwirft. Weitere Informationen finden Sie unter Spaces, Newline Characters und Other White Space.

Informationen zu den Attributen im öffnende <rpc-reply> Tag finden Sie unter Analysieren der NETCONF-Serverantwort. Informationen zum xmlns Attribut im öffnende <interface-information> Tag finden Sie unter Anfordern von Betriebsinformationen mithilfe von NETCONF. Informationen zur ]]>]]> Zeichenfolge finden Sie unter Generieren von wohlgeformten XML-Dokumenten.

Untergeordnete Tag-Elemente eines Request-Tag-Elements

Einige Anforderungs-Tag-Elemente enthalten untergeordnete Tag-Elemente. Für Konfigurationsanforderungen stellt jedes untergeordnete Tag-Element ein Konfigurationselement (Hierarchieebene oder Konfigurationsobjekt) dar. Für Betriebliche Anforderungen stellt jedes untergeordnete Tag-Element eine der Optionen dar, die Sie in der Befehlszeile bereitstellen, wenn Sie den entsprechenden CLI-Befehl ausstellen.

Einige Anforderungen haben obligatorische untergeordnete Tag-Elemente. Um eine Anfrage erfolgreich zu stellen, muss eine Client-Anwendung die obligatorischen Tag-Elemente innerhalb der öffnenden und schließenden Tags des Request-Tag-Elements ausgeben. Wenn es sich bei den untergeordneten Elementen um Container-Tag-Elemente handelt, muss das öffnenD-Tag für jedes einzelne der darin enthaltenen Tag-Elemente auftreten, und das schließenD-Tag muss vor dem öffnen des Tags für ein anderes Tag-Element auf Hierarchieebene erfolgen.

In den meisten Fällen kann die Clientanwendung untergeordnete Elemente ausgeben, die auf derselben Ebene innerhalb eines Container-Tag-Elements in beliebiger Reihenfolge auftreten. Die wichtige Ausnahme ist ein Konfigurationselement mit einem Bezeichner-Tag-Element, das das configuration-Element von anderen Elementen seines Typs unterscheidet. Das Identifier-Tag-Element muss das erste untergeordnete Tag-Element im Container-Tag-Element sein. Am häufigsten gibt das Identifier-Tag-Element den Namen des konfigurationselements an und heißt <name>. Weitere Informationen finden Sie unter Zuordnung von Objekten mit einem Bezeichner.

Untergeordnete Tag-Elemente eines Response-Tag-Elements

Die untergeordneten Tagelemente eines Response-Tag-Elements stellen die einzelnen Datenelemente dar, die vom NETCONF-Server für eine bestimmte Anforderung zurückgegeben werden. Die untergeordneten Elemente können entweder einzelne Tag-Elemente (leere Tags oder Tag-Element-Triples) oder Container-Tag-Elemente sein, die ihre eigenen untergeordneten Tag-Elemente umschließen. Für einige Container-Tag-Elemente gibt der NETCONF-Server die untergeordneten Elemente in alphabetischer Reihenfolge zurück. Bei anderen Elementen werden die untergeordneten Elemente in der Reihenfolge angezeigt, in der sie in der Konfiguration erstellt wurden.

Die Menge der untergeordneten Tag-Elemente, die in einer Antwort oder innerhalb eines Container-Tag-Elements auftreten können, kann in späteren Versionen der Junos XML-API geändert werden. Clientanwendungen dürfen sich nicht auf das Vorhandensein oder Fehlen eines bestimmten Tag-Elements in der Ausgabe des NETCONF-Servers oder auf die Reihenfolge untergeordneter Tag-Elemente innerhalb eines Response-Tag-Elements verlassen. Für den zuverlässigsten Betrieb, fügen Sie Logik in die Client-Anwendung ein, die das Fehlen erwarteter Tag-Elemente oder das Vorhandensein unerwarteter Elemente so elegant wie möglich behandelt.

Leerzeichen, Newline-Zeichen und anderer Leerraum

Wie durch die XML-Spezifikation vorgeschrieben, ignoriert der NETCONF-Server Leerzeichen (Leerzeichen, Tabulatoren, Newline-Zeichen und andere Zeichen, die Leerzeichen darstellen), die zwischen Tagelementen im Tag-Stream auftritt, die von einer Clientanwendung generiert werden. Client-Anwendungen können, müssen aber nicht, Zwischenraum zwischen Tag-Elementen enthalten. Sie dürfen jedoch keinen Leerraum in ein öffnendes oder schließendes Tag einfügen. Wenn sie Leerzeichen im Inhalt eines Tag-Elements enthalten, das sie als Änderung an die Kandidatenkonfiguration übermitteln, behält der NETCONF-Server den Leerraum in der Konfigurationsdatenbank bei.

In seinen Antworten enthält der NETCONF-Server Leerzeichen zwischen Tag-Elementen, um die Lesbarkeit der in einer Datei gespeicherten Antworten zu verbessern: Er verwendet Zeilenzeilen, um jedes Tag-Element in seine eigene Zeile zu setzen, und Leerzeichen, um untergeordnete Tag-Elemente rechts im Vergleich zu ihren eltern. Eine Clientanwendung kann den Leerraum ignorieren oder verwerfen, insbesondere, wenn sie keine Antworten für eine spätere Überprüfung durch menschliche Benutzer speichert. Es darf jedoch nicht vom Vorhandensein oder Fehlen von Leerraum an einem bestimmten Ort abhängen, wenn der Tag-Stream analysiert wird.

Weitere Informationen zum Leerraum in XML-Dokumenten finden Sie in der XML-Spezifikation des World Wide Web Consortium (W3C), Extensible Markup Language (XML) 1.0, unter http://www.w3.org/TR/REC-xml/ .

XML-Kommentare

Clientanwendungen und der NETCONF-Server können zu jedem Zeitpunkt XML-Kommentare zwischen Tag-Elementen im generierten Tag-Stream einfügen, nicht jedoch innerhalb von Tag-Elementen. Clientanwendungen müssen Kommentare in der Ausgabe vom NETCONF-Server problemlos verarbeiten, dürfen aber nicht vom Inhalt abhängig sein. Clientanwendungen können auch keine Kommentare verwenden, um Informationen an den NETCONF-Server zu übermitteln, da der Server alle erhaltenen Kommentare automatisch verwirft.

XML-Kommentare werden in die Zeichenfolgen <!-- und -->, eingeschlossen und dürfen die Zeichenfolge -- nicht enthalten (zwei Bindestriche). Weitere Informationen zu Kommentaren finden Sie in der XML-Spezifikation unter http://www.w3.org/TR/REC-xml/ .

Im Folgenden ist ein Beispiel für einen XML-Kommentar:

Vordefinierte Entitätsreferenzen

Nach der XML-Konvention gibt es zwei Kontexte, in denen bestimmte Zeichen nicht in ihrer regulären Form angezeigt werden können:

• In der Zeichenfolge, die zwischen öffnenden und schließenden Tags angezeigt wird (der Inhalt des Tag-Elements)

• In dem Zeichenfolgenwert, der einem Attribut eines Öffnen-Tags zugewiesen wird

Wenn ein nicht zulässiges Zeichen in einen dieser Kontexte aufgenommen wird, müssen Clientanwendungen den entsprechenden vordefinierten Entitätsverweis ersetzen, bei dem es sich um eine Zeichenfolge handelt, die das nicht zulässige Zeichen darstellt. Da der NETCONF-Server dieselben vordefinierten Entitätsreferenzen in seinen Antworttag-Elementen verwendet, muss die Clientanwendung in der Lage sein, diese bei der Verarbeitung von Response-Tag-Elementen in tatsächliche Zeichen zu konvertieren.

Tabelle 1 fasst die Zuordnung zwischen nicht zulässigen Zeichen und vordefinierten Entitätsreferenzen für Zeichenfolgen zusammen, die zwischen den öffnenden und schließenden Tags eines Tag-Elements angezeigt werden.

Tabelle 1: Vordefinierte Ersetzung von Entitätsreferenzen für Tag-Inhaltswerte

Unzulässiger Charakter	Vordefinierte Entitätsreferenz
und (amperund)	und
> (größer als Zeichen)	>
< (weniger als Zeichen)	<

Tabelle 2 fasst die Zuordnung zwischen nicht zulässigen Zeichen und vordefinierten Entitätsreferenzen für Attributwerte zusammen.

Tabelle 2: Vordefinierte Ersetzung von Entitätsreferenzen für Attributwerte

Unzulässiger Charakter	Vordefinierte Entitätsreferenz
und (amperund)	und
' (Apostroph)	'
> (größer als Zeichen)	>
< (weniger als Zeichen)	<
" (Anführungszeichen)	"

Nehmen Wir beispielsweise an, dass die folgende Zeichenfolge der Wert ist, der <condition> im Tag-Element enthalten ist:

Das <condition> Tag-Element sieht so aus (es wird nur zur Lesbarkeit auf zwei Zeilen angezeigt):

Wenn der Wert für das Attribut des <example> heading Tag-Elements lautet, sieht Peer’s "age" <> 40das öffnend-Tag wie folgt aus: