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

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

同様に、NETCONFサーバーからの各応答は、整形式のXMLドキュメントを構成します(NETCONFサーバーはXMLおよびNETCONFの規則に従います)。

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

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

リクエストタグ要素は、デバイスの現在のステータスや設定に関する情報を要求したり、設定を変更したりするためにクライアントアプリケーションによって生成される要素です。リクエストタグ要素は、CLI運用コマンドまたは設定コマンドに対応します。これは、<rpc>タグ内でのみ発生する可能性があります。

応答タグ要素は、リクエストタグ要素に対するNETCONFサーバーの応答を表し、<rpc-reply>タグ内でのみ発生します。

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

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

NETCONFサーバー

注:

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

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

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

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

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

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

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

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

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

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

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

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

XMLコメント

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

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

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

定義済みエンティティ参照

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

タグの開始と終了の間に表示される文字列(タグ要素の内容)
開始タグの属性に割り当てられた文字列値で

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

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

表1:タグコンテンツ値に対する定義済みエンティティ参照の置換
許可されていない文字	定義済みエンティティリファレンス
&(アンパサンド)	&
>(大なり記号)	>
<(小なり記号)	<

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

表2:属性値に対する定義済みエンティティ参照の置換
許可されていない文字	定義済みエンティティリファレンス
&(アンパサンド)	&
'(アポストロフィ)	'
>(大なり記号)	>
<(小なり記号)	<
」(引用符)	"

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

<condition> タグ要素は次のようになります (読みやすくするためにのみ 2 行に表示されます)。

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