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