XML 和 NETCONF XML 管理协议约定概述
客户端应用程序必须符合 XML 和 NETCONF XML 管理协议约定。来自客户端应用程序的每个请求都必须是 格式正确的 XML 文档;也就是说，对于请求中编码的信息类型，它必须遵守 NETCONF 和 Junos XML 文档类型定义 （DTD） 中定义的结构规则。客户端应用程序必须按所需的顺序发出标记元素，并且只能在合法上下文中发出。如果 Junos OS 或 NETCONF 协议发生变化，兼容的应用程序更易于维护。
同样，来自 NETCONF 服务器的每个响应都构成一个格式正确的 XML 文档（NETCONF 服务器遵循 XML 和 NETCONF 约定）。
以下各节介绍了 NETCONF XML 管理协议约定：
请求和响应标记元素
请求标记元素是由客户端应用程序生成的元素，用于请求有关设备当前状态或配置的信息，或者更改配置。request 标记元素对应于 CLI作或配置命令。它只能出现在标记中<rpc>。
响应标记元素表示 NETCONF 服务器对请求标记元素的回复，并且仅在标记中<rpc-reply>发生。
下面的示例表示一个交换，其中客户端应用程序发出带有<extensive/>标志的<get-interface-information>请求标记元素，而 NETCONF 服务器返回<interface-information>响应标记元素。
客户端应用程序
<rpc>
<get-interface-information>
<extensive/>
</get-interface-information>
</rpc>
]]>]]>
NETCONF 服务器
<rpc-reply xmlns="URN" xmlns:junos="URL">
<interface-information xmlns="URL">
<!-- children of <interface-information> -->
</interface-information>
</rpc-reply>
]]>]]>
与本指南中的所有其他示例一样，此示例在客户端应用程序和 NETCONF 服务器发出的标记流中的单独行中显示每个标记元素。实际上，客户端应用程序不需要在标记元素之间包含换行符，因为服务器会自动丢弃此类空格。有关进一步的讨论，请参阅 空格、换行符和其他空格。
请求标签元素的子标签元素
某些请求标记元素包含子标记元素。对于配置请求，每个子标记元素表示一个配置元素（层次结构级别或配置对象）。对于作请求，每个子标签元素都表示发出等效的 CLI 命令时在命令行上提供的选项之一。
某些请求具有必需的子标记元素。若要成功发出请求，客户端应用程序必须在请求标记元素的开始和结束标记中发出必需的标记元素。如果任何子项本身就是容器标记元素，则每个子项的开始标记必须出现在它包含的任何标记元素之前，并且结束标记必须出现在另一个标记元素的开始标记之前。
在大多数情况下，客户端应用程序可以以任意顺序发出容器标记元素中在同一级别出现的子级。重要的例外是具有 标识符标记元素的配置元素，该元素将配置元素与其类型的其他元素区分开来。标识符标记元素必须是容器标记元素中的第一个子标记元素。最常见的是，标识符标记元素指定配置元素的名称，并称为 <name>。有关更多信息，请参阅 具有标识符的对象的映射。
响应标签元素的子标签元素
响应标记元素的子标记元素表示 NETCONF 服务器为特定请求返回的单个数据项。子元素可以是单独的标签元素（空标签或标签元素三元组），也可以是包围自己的子标签元素的容器标签元素。对于某些容器标签元素，NETCONF 服务器将按字母顺序返回子元素。对于其他元素，子元素将按照它们在配置中的创建顺序显示。
响应中或容器标记元素中可能出现的子标记元素集在 Junos XML API 的更高版本中可能会发生更改。客户端应用程序不得依赖于 NETCONF 服务器输出中特定标记元素的存在与否，也不得依赖于响应标记元素中子标记元素的排序。为了实现最可靠的作，请在客户端应用程序中包含逻辑，以尽可能优雅地处理预期标记元素的缺失或意外标记元素的存在。
空格、换行符和其他空格
根据 XML 规范的规定，NETCONF 服务器会忽略客户端应用程序生成的标记流中的标记元素之间出现的空格（空格、制表符、换行符和其他表示空格的字符）。客户端应用程序可以（但不需要）在标记元素之间包含空格。但是，它们不得在开始或结束标记中插入空格。如果他们在作为对候选配置的更改而提交的标记元素的内容中包含空格，则 NETCONF 服务器将保留配置数据库中的空格。
在其响应中，NETCONF 服务器在标记元素之间包含空格，以增强保存到文件的响应的可读性：它使用换行符将每个标记元素放在自己的行上，并使用空格将子标记元素与其父元素相比向右缩进。客户端应用程序可以忽略或丢弃空白区域，特别是当它不存储响应以供人类用户以后查看时。但是，在解析标记流时，它不能依赖于任何特定位置是否存在空格。
有关 XML 文档中的空格的更多信息，请参见万维网联盟 （W3C） 的 XML 规范，可 扩展标记 语言 （XML） 1.0，第 http://www.w3.org/TR/REC-xml/ 页。
XML 注释
客户端应用程序和 NETCONF 服务器可以在它们生成的标记流中的标记元素之间的任意点插入 XML 注释，但不能在标记元素内插入。客户端应用程序必须正常处理 NETCONF 服务器输出中的注释，但不得依赖于其内容。客户端应用程序也不能使用注释将信息传达到 NETCONF 服务器，因为服务器会自动丢弃它收到的任何注释。
XML 注释包含在字符串和 <!-- -->中，不能包含字符串 -- （两个连字符）。有关注释的更多详细信息，请参阅 http://www.w3.org/TR/REC-xml/ 上的 XML 规范。
以下是 XML 注释的示例：
<!-- This is a comment. Please ignore it. -->
预定义实体引用
按照 XML 约定，在两种上下文中，某些字符不能以常规形式出现：
在开始标记和结束标记之间显示的字符串中（标记元素的内容）
在分配给开始标记的属性的字符串值中
在任一上下文中包含不允许的字符时，客户端应用程序必须替换等效的预定义实体引用，该引用是表示不允许的字符的字符串。由于 NETCONF 服务器在其响应标记元素中使用相同的预定义实体引用，因此客户端应用程序在处理响应标记元素时必须能够将它们转换为实际字符。
表 1 总结了出现在标签元素的开始和结束标记之间的字符串的不允许的字符和预定义实体引用之间的映射。
不允许的字符 |
预定义实体引用 |
|---|---|
&（与号） |
& |
>（大于符号） |
> |
<（小于符号） |
< |
表 2 总结了属性值的不允许字符和预定义实体引用之间的映射。
不允许的字符 |
预定义实体引用 |
|---|---|
&（与号） |
& |
'（撇号） |
' |
>（大于符号） |
> |
<（小于符号） |
< |
“（引号） |
“ |
例如，假设以下字符串是 tag 元素包含的 <condition> 值：
if (a<b && b>c) return "Peer’s not responding"
<condition> tag 元素如下所示（它出现在两行上，仅用于清晰易读）：
<condition>if (a<b && b>c) return "Peer’s not \
responding"</condition>
类似地，如果 tag 元素heading的属性值<example>为 Peer’s "age" <> 40，则开始标记如下所示：
<example heading="Peer's "age" <> 40">