XML および NETCONF XML 管理プロトコル表記規則の概要

リクエストおよびレスポンス タグ要素

リクエスト タグ エレメントは、デバイスの現在のステータスや設定に関する情報を要求したり、設定を変更したりするために、クライアント アプリケーションによって生成されたエレメントです。リクエスト タグ 要素は、動作コマンドまたは設定コマンドCLI対応しています。これはタグ内でのみ実行 <rpc> できます。要素の詳細については <rpc> 、「 NETCONF サーバーへのリクエストの送信 」を参照してください。

レスポンス タグ 要素は、NETCONFサーバーがリクエストタグ要素に応答し、タグ内でのみ発生 <rpc-reply> します。この要素の詳細については <rpc-reply> 、「 NETCONF サーバーレスポンスを解析する 」を参照してください。

次の例は、クライアント アプリケーションがフラグを持つリクエスト タグ 要素を送信し、NETCONF サーバーが応答タグ要素を返す交換を <get-interface-information> <extensive/> <interface-information> 表しています。

クライアント アプリケーション

NETCONF サーバー

メモ：

この例では、このガイドの他のすべての例と同様に、クライアント アプリケーションと NETCONF サーバーの両方から送信されたタグ ストリーム内の各タグ 要素が別々の行で示されています。実際には、クライアント アプリケーションはタグ要素の間に新しい文字を含める必要はしません。サーバーはこのような空白を自動的に破棄します。詳細については、「 Spaces 、Newline Characters、その他の空白 」を参照してください。

開始タグの属性については、「 NETCONF サーバーレスポンスを解析する <rpc-reply> 」を参照してください。開始タグ内の xmlns 属性の詳細については、「 NETCONF を使用して運用情報をリクエストする 」 <interface-information> を参照してください。文字シーケンスの詳細については、「 ウェル形成 XML ]]>]]> ドキュメントを生成する 」を参照してください。

リクエスト タグ要素の子タグ要素

リクエスト タグ要素の中には、子タグ要素が含まれているものがあります。設定要求の場合、各子タグ要素は構成要素(階層レベルまたは設定オブジェクト)を表します。運用リクエストの場合、各子タグ要素は、同等のタグコマンドを発行する際にコマンドラインで提供するオプションの1つCLIします。

リクエストには必須の子タグ要素が含まれています。リクエストを正常に実行するには、クライアント アプリケーションがリクエスト タグ 要素の開始タグと終了タグ内に必須のタグ要素を送信する必要があります。すべての子がそれ自体コンテナ タグ要素である場合、各タグの開始タグは含まれているタグ要素の前に必ず発生し、階層レベルで別のタグ要素の開始タグが開始される前に終了タグが発生する必要があります。

ほとんどの場合、クライアント アプリケーションは、コンテナ タグ要素内で同じレベルで発生する子を任意の順序で送信できます。重要な例外は、識別子タグ要素を持つ構成要素で、そのタイプの他の要素と要素を識別します。識別子タグ 要素は、コンテナ タグ要素の最初の子タグ 要素である必要があります。識別子タグ要素は、最も頻繁に、要素の名前を指定して、 と呼び出されます <name> 。詳細については、「 識別子を持つオブジェクトのマッピング 」を参照してください。

レスポンス タグ要素の子タグ要素

レスポンス タグ 要素の子タグ要素は、特定のリクエストに対して NETCONF サーバーから返された個々のデータ アイテムを表します。子要素には、個々のタグ要素(空のタグまたはタグ要素のトリプル)またはそれ自身の子タグ要素を囲むコンテナ タグ要素のいずれかを使用できます。一部のコンテナ タグ要素では、NETCONF サーバーは子をアルファベット順に返します。他の要素の場合、子は設定で作成された順序で表示されます。

レスポンス内またはコンテナ タグ要素内で発生する可能性がある子タグ要素のセットは、XML API の新しいリリースでJunosされる場合があります。クライアント アプリケーションは、NETCONF サーバーの出力における特定のタグ 要素の有無に依存したり、応答タグ要素内の子タグ要素の順序に依存したりし限定しません。最も堅牢な操作を実現するには、クライアント アプリケーションに、予想されるタグ要素がない、または予期しないタグ要素が存在しない場合を可能な限り適切に処理するロジックを含める必要があります。

スペース、改行文字、その他の空白

XML 仕様に従う場合、NETCONF サーバーは、クライアント アプリケーションによって生成されたタグ ストリーム内のタグ要素間で発生する空白(スペース、タブ、新規行の文字、空白を表すその他の文字)を無視します。クライアント アプリケーションでは、タグ要素間に空白を含めできますが、必ずしも必要ではありません。ただし、開始タグまたは終了タグ内に空白を挿入する必要があります。受験者の設定に変更として送信するタグ要素のコンテンツに空白が含まれる場合、NETCONF サーバーは設定データベースに空白を保持します。

その応答では、NETCONF サーバーにはタグ要素間に空白が含まれているので、ファイルに保存される応答の読みやすさを高めることができます。つまり、各タグ要素をそれ自体の行に置くには新しい文字を使用し、スペースを使用して子タグ要素を親と比較して適切な位置に指定します。クライアント アプリケーションは、特に人間によるレビューのための応答が保存されていない場合に、空白を無視または破棄できます。ただし、タグ ストリームを解析する際、特定の場所に空白が存在するか存在しないかによって異なる必要があります。

XML ドキュメントの空白の詳細については、 World Wide Web Consortium(W3C)、Extensible Markup Language(XML) 1.0(英語) の XML 仕様を参照http://www.w3.org/TR/REC-xml/。

XML コメント

クライアント アプリケーションと NETCONF サーバーは、タグ要素内ではなく、生成したタグ ストリーム内のタグ要素間の任意のポイントに XML コメントを挿入できます。クライアント アプリケーションは NETCONF サーバーからの出力のコメントを適切に処理する必要がありますが、内容に依存する必要はありません。クライアント アプリケーションも、コメントを使用して NETCONF サーバーに情報を伝えすることはできません。サーバーは、受信したコメントを自動的に破棄します。

XML コメントは文字列内で囲み、文字列(2 つのハイフン) <!-- --> -- を含めず、コメントの詳細については、 の XML 仕様 を 参照http://www.w3.org/TR/REC-xml/。

XML コメントの例を以下に示します。

事前定義されたエンティティリファレンス

XML の表記規則では、特定の文字を通常の形式で表示できない 2 つのコンテキストがあります。

• タグの開始と終了の間に表示される文字列(タグ要素の内容)

• 開始タグの属性に割り当てられた文字列値

どちらの状況でも、許可しない文字を含めた場合、クライアント アプリケーションは、許可された文字を表す文字の文字列である、定義済みの同等のエンティティ リファレンスの代わりとなる必要があります。NETCONF サーバーは、応答タグ要素に同じ定義済みエンティティ リファレンスを使用します。ため、クライアント アプリケーションは、応答タグ要素を処理する際に、それらを実際の文字に変換する必要があります。

表 1 は 、タグ要素の開始タグと終了タグの間に表示される文字列に対する、許可されない文字と事前定義されたエンティティ リファレンスの間のマッピングを要約しています。

表 1:タグコンテンツ値の定義済みエンティティ リファレンス置換

許可を解除した文字	事前定義されたエンティティリファレンス
& (ampersand)	&
>(兆候よりも大きい)	>
<(兆候以外)	<

表 2 は 、属性に対する許可された文字と事前定義されたエンティティ参照とのマッピングをまとめたモデルです。

表 2:属性に対する定義済みエンティティ リファレンス置換

許可を解除した文字	事前定義されたエンティティリファレンス
& (ampersand)	&
' (アポストロフィ)	'
>(兆候よりも大きい)	>
<(兆候以外)	<
」(引用符)	"

たとえば、以下の文字列がタグ要素に含まれる値だと <condition> します。

タグ <condition> 要素は次のように見えます(読み取り専用として2行に表示されます)。

同様に、タグ要素の属性の <example> 値が 次のように heading Peer’s "age" <> 40 見えます。