Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページで
 

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

クライアント アプリケーションは、XML および Junos XML 管理プロトコルの規則に従う必要があります。クライアント アプリケーションからの各要求は、 整形式の XML ドキュメントである必要があります。つまり、リクエストでエンコードされた情報の種類に関して、Junos XMLプロトコルとJunos XMLドキュメントタイプ定義(DTD)で定義された構造ルールに従う必要があります。クライアント アプリケーションは、必要な順序でタグ要素を出力する必要があり、法的コンテキストでのみ送信する必要があります。準拠アプリケーションは、Junos OS または Junos XML プロトコルに変更が加わると保守が容易です。

同様に、Junos XML プロトコル サーバーからの各応答は、適切に形成された XML ドキュメントを構成します(Junos XML プロトコル サーバーは XML および Junos XML 管理プロトコルの規則に従っています)。

以下のセクションでは、Junos XML 管理プロトコルの規則について説明します。

リクエストとレスポンスのタグ要素

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

応答タグ要素は、Junos XML プロトコル サーバーの要求タグ要素への応答を表し、タグ内<rpc-reply>でのみ発生します。要素の<rpc-reply>詳細については、 Junos XML プロトコル サーバー応答の解析を参照してください。

次の例は、クライアント アプリケーションが要求タグに <get-interface-information> フラグを付けて <extensive/> 発行し、Junos XML プロトコル サーバーが応答要素を返す交換を <interface-information> 表しています。

Request and Response Tag Elements
メモ：

この例は、このガイドの他のすべての例と同様に、クライアント アプリケーションと Junos XML プロトコル サーバーの両方から出力されるタグ ストリームの各タグ要素を個別の行で示しています。実際には、クライアント アプリケーションでは、サーバーがこのような空白を自動的に破棄するため、タグ要素間に改行文字を含める必要はありません。詳細については、 スペース、改行文字、およびその他の空白を参照してください。

開始rpc-replyタグの属性については、 Junos XML プロトコル サーバー応答の解析を参照してください。開始タグのxmlns属性については、 Junos XMLプロトコルを使用した運用情報の要求を参照してください。<interface-information>

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

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

一部のリクエストには必須の子タグ要素があります。要求を正常に行うには、クライアント アプリケーションが要求タグ要素の開始タグと終了タグ内で必須のタグ要素を発行する必要があります。子がコンテナ タグ要素である場合は、それぞれに対する開始タグが含まれるタグ要素の前に発生し、閉じるタグはその階層レベルの別のタグ 要素の開始タグの前に発生する必要があります。

ほとんどの場合、クライアント アプリケーションはコンテナ タグ要素内で同じレベルで発生する子を任意の順序で発行できます。重要な例外は、 識別子タグ要素を持つ構成要素であり、構成要素とそのタイプの他の要素とを区別します。identifier tag 要素は、コンテナー タグ要素の最初の子タグ要素である必要があります。最も頻繁に、識別子タグ要素は、構成要素の名前を指定し、 と呼ばれます <name>。

応答タグ要素の子タグ要素

応答タグ要素の子タグ要素は、特定のリクエストに対して Junos XML プロトコル サーバーから返される個々のデータ項目を表します。子は、個々のタグ要素(空のタグまたはタグ要素トリプル)または、独自の子タグ要素を囲むコンテナタグ要素のいずれかです。一部のコンテナ タグ要素では、Junos XML プロトコル サーバーは、アルファベット順で子を返します。その他 の要素の場合、子はコンフィギュレーションで作成された順序で 表示されます。

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

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

XML 仕様に従って、Junos XML プロトコル サーバーは、クライアント アプリケーションによって生成されたタグ ストリーム内のタグ 要素間で発生する空白(スペース、タブ、改行文字、および空白を表すその他の文字)を無視します。クライアント アプリケーションでは、タグ要素間に空白を含めることができますが、不要です。ただし、開始タグまたは終了タグ内に空白を挿入しないでください。候補構成の変更として送信するタグ要素のコンテンツに空白が含まれている場合、Junos XML プロトコル サーバーは設定データベースに空白を保持します。

Junos XML プロトコル サーバーの応答には、タグ要素間の空白文字が含まれており、ファイルに保存される応答の可読性を高めます。これは、改行文字を使用して各タグ要素を独自の行に配置し、子タグ要素を親と比較して右にインデントするスペースです。クライアントアプリケーションは、特に人間のユーザーによる後のレビューのための応答を保存しない場合、空白を無視または破棄することができます。ただし、タグ・ストリームを解析する際には、特定の場所における空白の有無に依存してはなりません。

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

XML コメント

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

XMLコメントは文字列内-->で囲まれており、文字列<!-- - - (ハイフン2つ)を含めることはできません。コメントの詳細については、 http://www.w3.org/TR/REC-xml/ の XML 仕様を参照してください。

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

XML 処理手順

XML 処理命令(PI)は、特定のプロトコルに関連する情報を含み、以下の形式を持っています。

Junos XML プロトコル セッション中に発行される一部の API には、クライアント アプリケーションが正しい操作を行う必要がある情報が含まれています。顕著な例は <?xml?> 、クライアント アプリケーションと Junos XML プロトコル サーバーがそれぞれ Junos XML プロトコル セッションの先頭に送信し、XML のバージョンと使用している文字エンコード スキームを指定する要素です。詳細については、「 Junos XML プロトコル セッションの開始」を参照してください。

Junos XML プロトコル サーバーは、クライアント アプリケーションが解釈する必要がない API(CLI 用の API など)も発行できます。クライアント・アプリケーションが PI を理解していない場合、エラー・メッセージを出たり生成したりするのではなく、PI をコメントとして扱う必要があります。

事前定義されたエンティティ参照

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

  • 開始タグと終了タグの間に表示される文字列(タグ要素のコンテンツ)

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

どちらのコンテキストでも許可されていない文字を含める場合、クライアント アプリケーションは、許可しない文字を表す文字の文字列である、同等の 定義済みエンティティ参照を置き換える必要があります。Junos XML プロトコル サーバーは応答タグ要素で同じ定義済みエンティティ参照を使用するため、クライアント アプリケーションは応答タグ要素を処理する際に、それらを実際の文字に変換できるようにする必要があります。

表 1 は、タグ要素の開始タグと終了タグの間に表示される文字列に対する、許可されない文字と定義済みのエンティティ参照のマッピングをまとめたものです。

表 1: タグコンテンツ値に対する事前定義されたエンティティ参照代入

許可しない文字

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

& (アンパサンド)

&amp;

> (符号より大きい場合)

&gt;

< (符号未満)

&lt;

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

表2:属性値に対する事前定義されたエンティティ参照代入

許可しない文字

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

& (アンパサンド)

&amp;

' (アポストロフィ)

&apos;

> >(符号より大きい場合)

&gt;

< (符号未満)

&lt;

" (引用符)

&quot;

例として、次の文字列が要素に含まれる <condition> 値であると仮定します。

要素は <condition> 次のようになります(読みやすさ のみを目的として 2 行に表示されます)。

同様に、要素のheading属性の<example>値が である場合、開始タグはPeer’s "age" <> 40次のようになります。