CN101686146B - 模糊查询、查询结果处理和过滤条件处理的方法及设备 - Google Patents

Abstract

本发明实施例公开了一种模糊查询、查询结果处理和过滤条件处理的方法及设备，其中基于子树过滤的模糊查询方法包括：接收待过滤数据流；通过不完全匹配的方式过滤所述数据流，处理用户没有给出完全信息的字符串形式的过滤条件。本发明实施例解决NETCONF协议子树过滤机制仅局限于精确匹配和绝对路径，数据查询中要求给出较多已知信息带来的不便。

Description

模糊查询、查询结果处理和过滤条件处理的方法及设备

技术领域

本发明涉及通信技术领域，尤其涉及一种模糊查询、查询结果处理和过滤条件处理的方法及设备。

背景技术

NETCONF(网络配置协议)是一种网管协议，使用XML(ExtensibleMarkup Language，可扩展标记语言)描述操作请求和网管数据。XML是一套语义标记的规则，将文档分成许多部件并用标记对这些部件加以标识。这些标记通常采用自然语言，因此具有很高的可读性。标记看起来如下：

<age>10</age>

<name language＝“English”>

  <first-name>George</first-name>

  <last-name>Bush</last-name>

</name>

<hobby></hobby>

<hobby/>

每一对标记由起始标记(如<age>)和结束标记(如</age>)组成，每一对标记及其内容称为一个元素(element)，在以上例子中就有<age>、<name>元素。元素可以拥有值，如<age>的值是10；也可以拥有子元素，如<name>拥有子元素<first-name>和<last-name>；也可以没有值，如<hobby>，这种情况称为空元素，可缩写记为<hobby/>；元素还可以拥有属性(attribute)，属性是一个“名字-值”对，如<name>拥有属性language，属性值是English。

元素间的层次嵌套关系经常表达为一个树型数据结构，如图1所示，因此元素也被称作节点。在一对嵌套关系中，外层节点被称作内层节点的父节点；内层节点被称作外层节点的子节点。如图1中，<a>是<b1>、<b2>、<b3>的父节点，<b1>、<b2>、<b3>是<a>的子节点。拥有同一父节点的几个节点相互称为兄弟节点，如<b1>、<b2>、<b3>彼此是兄弟节点。

在网络管理中，需要监视网络设备的配置和状态，为达到此目的，网管设备发出查询报文，描述所需要查询的数据，被管设备收到查询报文后，依照查询报文中的条件执行查询，并向网管设备应答查询结果。

NETCONF协议拥有两种查询操作：<get>和<get-config>。<get>操作用于查询当前正在运行的配置和状态数据；<get-config>用于查询不同配置数据存储中的配置数据。尽管两者的查询对象有所区别，但拥有相同的查询条件表达方式，即子树过滤和XPATH(XML路径语言)方式。

现有技术一中，子树过滤使用XML方式描述过滤条件，通过一组简单的匹配规则，对符合条件的数据元素进行选取。例1是一个子树查询的例子，<rpc>元素表明这是一个网管设备发出的请求，<get>元素表明网管设备请求执行查询操作，<filter>元素指明了查询方式和查询条件，其属性type＝“subtree”指出该查询采用子树过滤方式，<filter>包含的子节点表明：该查询希望查询命名空间″http://example.com/schema/1.2/stats″内的<top>元素中的<interfaces>元素中的某个<interface>元素，并且该<interface>元素必须具有ifName属性，ifName的属性值是″eth0″。

例1：一个使用子树查询的<get>请求：

<rpc message-id＝″101″

    xmlns＝″um:ietf:params:xml:ns:netconf:base:1.0″>

  <get>

    <filter type＝“subtree”>

      <t:top xmlns:t＝″http://example.com/schema/1.2/stats″>

        <t:interfaces>

          <t:interface t:ifName＝″eth0″/>

        </t:interfaces>

      </t:top>

    </filter>

  </get>

</rpc>

其中，<filter>元素被称为过滤器，在子树过滤中，过滤器由零到多个代表选择标准的元素子树构成。在子树的各层，被管设备对每个兄弟节点集合进行逻辑判断，以决定各兄弟节点所牵头的子树是否包含在过滤器的输出结果中。所有在过滤器子树中出现的元素，必须与服务器概念数据模型中的对应节点相匹配。

过滤器可分为5种组件，每种组件执行不同的过滤规则，包括：命名空间选择、属性匹配表达式、包含节点、选择节点、内容匹配节点。

命名空间选择：如果使用命名空间，则过滤器的输出只包含指定的命名空间中的元素。即：过滤器中”xmlns”属性的内容应与被管设备数据模型中”xmlns”属性的内容相同。在例1中<t:top

xmlns:t＝″http://example.com/schema/1.2/stats″>指出了选择的命名空间是http://example.com/schema/1.2/stats，只有该命名空间中的<top>中的子元素被输出。

属性匹配表达式：出现在过滤器中的属性是属性匹配表达式的一部分。被选择的数据除了要与过滤器中的节点匹配，还必须与过滤器的属性相匹配。如果一个元素不包含指定的属性，则该元素将不被选择。例1中，ifName＝″eth0″就是属性匹配表达式。过滤结果将输出拥有ifName属性，并且ifName的属性值是″eth0″的<interface>元素，如例2所示。例2中，<rpc-reply>元素表明这是一个应答，<data>元素表明应答的数据，应答数据的命名空间、各级子元素和属性都和过滤器中的对应部分相匹配。

例2属性匹配的查询结果：

<rpc-reply message-id＝″101″

    xmlns＝″um:ietf:params:xml:ns:netconf:base:1.0″>

  <data>

    <t:top xmlns:t＝″http://example.com/schema/1.2/stats″>

      <t:interfaces>

        <t:interface t:ifName＝″eth0″>

          <t:ifInOctets>45621</t:ifInOctets>

          <t:ifOutOctets>774344</t:ifOutOctets>

        </t:interface>

      </t:interfaces>

    </t:top>

  </data>

</rpc-reply>

包含节点：过滤器中包含子元素的节点被称为包含节点。包含节点的子元素也可以是包含节点，或其他类型的节点。例1中，<top>是一个包含节点，其子元素<interfaces>也是一个包含节点。

选择节点：过滤器中的空节点被称为选择节点，表示对数据模型的一个显式选择。如果在数据模型的兄弟节点中出现了选择节点，则只有该选择节点下的子树被选择，该选择节点的兄弟节点不被选择。如例3中，<name>元素是个选择节点。在被管设备的数据模型中，如果<user>除了<name>还有其他子节点，那么只有<name>才被选择，<name>的兄弟节点将不被选择。

例3过滤器中的选择节点：

<filter type＝“subtree”>

  <top xmlns＝″http://example.com/schema/1.2/config″>

    <users>

      <user>

        <name/>

      </user>

    </users>

  </top>

</filter>

内容匹配节点：包含文本值的叶子节点被称为内容匹配节点，表示对父节点的选择条件。例4中，<name>元素是内容匹配节点，表示所有<name>为”fred”的<user>元素(及其子元素)将被选择输出。该过滤器的查询结果如例5所示。

多个兄弟内容匹配节点间执行“与”的逻辑运算；

例4过滤器中的内容匹配节点：

<filter type＝“subtree”>

  <top xmlns＝″http://example.com/schema/1.2/config″>

    <users>

      <user>

        <name>fred</name>

      </user>

    </users>

  </top>

</filter>

例5针对内容匹配节点的应答输出：

<rpc-reply message-id＝″101″

    xmlns＝″um:ietf:params:xml:ns:netconf:base:1.0″>

  <data>

    <top xmlns＝″http://example.com/schema/1.2/config″>

      <users>

        <user>

          <name>fred</name>

          <type>admin</type>

          <full-name>Fred Flintstone</full-name>

          <company-info>

            <dept>2</dept>

            <id>2</id>

          </company-info>

        </user>

      </users>

    </top>

  </data>

</rpc-reply>

综上所述，子树过滤的流程可概括如下：

过滤器的输出开始是空的。被管设备将它所支持的数据模型与过滤器中的每个数据分枝进行比较，如果一个节点所代表的子树的所有分枝与被管设备的数据模型的对应部分实现了完全匹配，则该节点及其所有子节点包含在结果数据中。

被管设备将具有相同父节点的节点(即兄弟节点集合)集中在一起进行处理，从根节点到叶子节点。对于每个兄弟节点集合，被管设备首先确定该集合中出现的节点类型，根据不同类型的选择规则进行处理。如果集合中有某些节点被选择，则该处理过程被叠代应用到每个被选中节点的下层兄弟集合之中。算法持续到所有过滤器子树中的兄弟节点集合被处理完毕。

子树过滤中过滤条件要求较为严格，进行查询时需要较多的已知条件。协议中对子树过滤机制的描述，认为子树过滤基于简单的精确匹配，仅包含较少类型的过滤器，以对XML型子树实现用途广泛但局限较大的选择。这种选择不对数据模型做任何预处理，也不使用任何针对数据模型的特殊规范。子树过滤机制完全采用XML语言定义，并没有附加任何针对子树过滤本身的规范，故而查询和过滤功能相对较弱，需要较多的已知条件。过滤条件必须是以绝对路径表达的树形结构。因而如果对查询实体或过滤条件的组成实体在数据模型中的位置不完全清楚，则无法满足任何需求。只能舍弃过滤器，返回整个数据模型。

子树过滤只能过滤与过滤请求完全吻合的数据。所有过滤中节点名字、节点值、属性名字、属性值、命名空间等字符只能精确匹配，即过滤器中的字符串必须和数据模型中的字符串完全相同，否则会认为在数据模型中不存在符合过滤条件的节点。包括数字、日期等也必须精确匹配，不能实现范围过滤。

比如要查询一个属性为name、值为Ethernet2的<interface>元素，必须完整给出元素的路径为/netconf/routing/interface，netconf和routing节点的命名空间为um:ietf:params:xml:ns:netconf:base:1.0，interface的命名空间为urn:bupt:pris:priser:agent:module:interface:1.0，属性名为name，属性值为Ethernet2，如例6所示，很显然这个查询需要太多的已知条件：

例6查询属性name值为Ethernet2的interface元素信息：

     <filter type＝“subtree”>

         <netconf xmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″>

            <routing>

         <interface       xmlns＝″urn:bupt:pris:priser:agent:module:interface:1.0″

name＝″Ethernet2″/>

         </routing>

         </netconf>

      </filter>

子树过滤倾向于向用户返回所有的可能有需要的管理信息，容易造成冗余和混淆。例如当用户试图查询某个节点本身的信息时，子树过滤会将其所有后代一并输出，因为无法从过滤器定义中判断出用户需要的是该节点本身，还是其属性抑或是其某一个子孙。这样可能会造成在网络中传输大量不必要的加密信息以及用户人工查找信息的困难。

比如用户只想获得<interface>元素的属性信息，使用了例7所示的查询请求，该请求的结果如例8所示：

例7查询interface元素的属性：

<filter type＝“subtree”>

  <netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″>

     <routing>

        <interface xmlns＝″urn:bupt:pris:priser:agent:module:interface:1.0″/>

     </routing>

  </netconf>

</filter>

例8例7的查询结果：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:if＝″urn:bupt:pris:priser:agent:module:interface:1.0″

     xmlns:mt＝″um:bupt:pris:priser:agent:module:monitor:1.0″>

  <routing>

     <if:interface name＝″Ethernetl″ip-address＝”59.64.139.65”>

         <.../>

     </if:interface>

     <if:interface name＝″Ethernet2″ip-address＝”59.64.139.69”>

         <.../>

     </if:interface>

  </routing>

</netconf>

从过滤结果中可以看出，过滤结果不但返回了<interface>节点的全部属性信息，而且还返回了如<interface>的后代节点等信息(用<.../>表示)，对于这个用户的需求来说，这些信息是冗余的。

因此，现有技术一中的子树过滤缺少对过滤结果的统计和处理机制。除了返回xml语言规定的实体外，对这些实体的统计信息用户无法获得，同时也无法控制这些实体的返回方式，用户将无法控制返回数据量的大小。

现有技术二中，XPath即XML路径语言，是W3C关于查询XML文档的通用语言标准。从外观上看，XPath是用文件路径的形式表示XML文档查询条件的方法。例如，例4中的子树过滤用XPath表达就如例9所示。例中type＝＂xpath＂表明使用XPath查询方法，select属性的值为一个XPath表达式，指出了查询的内容和条件。

例9：XPath过滤表达式：

<filter type＝″xpath″select＝″top/users/user[name＝“fred”]″/>

XPath本质上是与具有层次结构的XML数据模型相匹配的查询语言，可以通过任何方向浏览树来选择节点，并根据节点的值和位置应用谓词。XPath遵循文档对象模型(Document Object Model，DOM)的路径格式。由于每个XML文档都可以看成是一棵拥有许多节点的树，节点的类型包括：根节点(root)、元素节点(element)、属性节点(attribute)、文本节点(text)、命名空间节点(namespace)、处理指令节点(processinginstruction)和注释(comment)。

XPath的目标是定义一种定位XML文档各个部分的语言，其功能是在数据存储区中查询某一个节点或节点集，为了实现这个目标，XPath规范定义了两个主要部分：一部分是表达式语法，另一部分是一组名为XPath核心库的基本函数。

XPath的基本语法由表达式构成，在计算表达式的值之后产生一个对象，这种对象有以下四种基本类型：节点集合、布尔型、数字型和字符串型。XPath基本上和电脑文件***中的寻找类似，如果路径是以“/“开头的，就表明该路径表示的是一个绝对路径；以“//”开头则表示在文档中的任意位置查找。通过XPath路径表达式，可以在XML文档中轻松地定位数据、确定节点。

现有技术二中的XPath机制较为复杂，难于掌握。XPath使用路径表达式来选取XML文档中的节点或者节点集，且含有超过100个内建的函数。这些函数用于字符串值、数值、日期和时间比较、节点和QName处理、序列处理、逻辑值等。包括各种轴的定义和使用，同时又不具有与XML文档相关的直观结构，掌握起来较为困难。

XPath需求以非XML结构表述，需提供额外机制进行解析和处理。在子树过滤中过滤器本身也是XML结构，使用起来相对直观，处理起来与NETCONF协议中的管理数据模块方法也基本类似。但是XPath是通过路径表达式来选取XML文档中的节点或者节点集，这样对其解析还需要另外的解析和处理方法。

XPath是通过路径表达式来选取XML文档中的节点或者节点集，每次只能获取一条查询记录，这样对于用户想一次实现多个结果的查询就无法实现，查询效率比较低。

在实现本发明的过程中，发明人发现现有技术至少存在以下缺点：

现有技术一中的子树过滤基于精确匹配和绝对路径，需要用户提供较多已知条件，缺少对过滤结果的统计和处理机制；而现有技术二中XPath机制较为复杂，难于掌握。

发明内容

本发明实施例提供了一种模糊查询、查询结果处理和过滤条件处理的方法及设备，以解决NETCONF协议子树过滤机制仅局限于精确匹配和绝对路径，数据查询中要求给出较多已知信息带来的不便；解决NETCONF协议数据模型查询中，对命名空间查询、过滤、处理手段匮乏的问题；丰富子树过滤机制的查询和过滤手段，提高子树过滤的灵活性和功能性；处理子树过滤得到的XML过滤结果文档，减少冗余信息的处理和传输；修正NETCONF协议中子树过滤部分不合理的过滤报文处理方法。

本发明实施例提供了一种基于子树过滤的模糊查询方法，包括：

接收待过滤数据流；

通过不完全匹配的方式过滤所述数据流，处理用户没有给出完全信息的字符串形式的过滤条件

本发明实施例还提供了一种子树过滤条件的逻辑组合的扩展方法，包括：

接收待过滤数据流；

采用多个属性或多个内容匹配节点对所述数据流中的元素类型节点进行过滤。

本发明实施例还提供了一种子树过滤查询结果的处理方法，包括：

在过滤器中相应节点处设置第三属性的值，表明所述节点处是否显示节点后代；

所述第三属性的取值为：第一值或者第二值，当所述第三属性默认为显示所有在同一命名空间的后代，则第三属性＝第二值；当设置第三属性＝第一值，则过滤结果只输出该节点的信息，不输出所述在同一命名空间的后代节点。

本发明实施例还提供了一种过滤器，包括：

接收模块，用于接收待过滤数据流；

过滤模块，用于通过不完全匹配的方式过滤所述数据流，处理用户没有给出完全信息的字符串形式的过滤条件。

本发明实施例还提供了一种逻辑过滤装置，包括：

接收模块，用于接收待过滤数据流；

逻辑过滤模块，用于采用多个属性或多个内容匹配节点对所述数据流中的元素类型节点进行过滤。

本发明实施例还提供了一种子树过滤查询结果处理装置，包括：

设置模块，用于在过滤器中相应节点处设置第三属性的值；

确定模块，用于根据所述设置模块设置所述第三属性的值，表明所述节点处是否显示节点后代。

本发明的实施例中，提供一种基于NETCONF子树过滤机制，以XML形式表达，对XML网络管理数据进行查询和过滤，使对NETCONF协议中管理信息的获取更为方便，也避免了为数据查询和过滤重新定义一套规范带来的诸多问题。

本发明实施例提供了一种对XML数据过滤条件的细化和组合机制。XML文档中的节点有时包含了具体的数据信息，类似于关系数据库中一个字段；有时只是封装数据信息的手段，类似于关系数据库中的一条记录。

本发明实施例中细化了节点的匹配程度，用户可以根据节点在数据存储中的具体作用选择相应的查询方法。另外，属性、命名空间方式表达的过滤条件可以以逻辑运算方式组合到一起，使查询更为灵活。

本发明实施例提供一种在过滤条件不完整的情况下，比如不能完整拼写出数据存储的节点或属性名字，或者不能完全给出数据在XML文档中定义的位置，仍可以对XML数据进行子树过滤操作，并得到用户想要的结果。

本发明实施例增加子树过滤中命名空间的查询功能，帮助用户快速的了解XML文档中数据分布的结构；弥补了NETCONF协议子树过滤中必须给出命名空间条件，但又不提供完整手段实现命名空间查询的缺陷。

本发明实施例处理对某些数据的特殊查询需求，比如时间、日期、数量等的范围查询、数据的数量查询等等。使子树过滤更能满足实际网络管理或其他实际应用中的需求。

本发明实施例实现对过滤结果的优化，实现对相同或类似数据的合并或排序；在需要时，丢弃无用的后代节点，大大减少了子树过滤结果可能存在的大量冗余信息。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单介绍，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是现有技术中一种树型数据结构示意图；

图2是本发明实施例中NETCONF协议中子树过滤***结构图；

图3是本发明实施例中总体流程图；

图4是本发明实施例中过滤控制模块工作流程图；

图5是本发明实施例中过滤控制调用名字空间处理组件流程图；

图6是本发明实施例中递归流程控制流程图；

图7是本发明实施例中结果处理实现流程图；

图8是本发明实施例二的基于子树过滤的模糊查询方法流程图；

图9是本发明实施例三的子树过滤条件的逻辑组合的扩展方法流程图；

图10是本发明实施例四的子树过滤查询结果的处理方法实现流程图；

图11是本发明实施例五的过滤器结构示意图；

图12是本发明实施例六的逻辑过滤装置结构示意图；

图13是本发明实施例七的子树过滤查询结果处理装置结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施方式，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施方式仅仅用以解释本发明，并不用于限定本发明。

本发明实施例提供一套基于NETCONF协议并对NETCONF协议中子树过滤机制加以扩展的，实现对XML语言定义的网络管理信息模型的数据查询和数据过滤功能的定义方法。定义方法包括对于子树过滤功能的详细说明和与功能定义相关的关键字定义。

为与NETCONF协议中子树过滤机制相区别，本发明实施例为<filter>节点的type属性新增取值advancedSubtree，表示其中可能含有进行子树过滤机制扩展功能操作的请求。

子树过滤扩展机制主要包括以下功能：

1.模糊匹配

模糊匹配是指在过滤流程中，处理节点名字、节点内容、属性名字、属性值、命名空间等字符串匹配中，以不完全匹配的方式处理用户没有给出完全查询信息的字符串。

由于XML文档标签对于字符串有着较为严格的限制，所以节点名、属性名等标签内容与节点内容、属性值、命名空间等文本内容的模糊匹配手段是不一样的。对于标签内容来说，仅可使用字符“_”表示匹配任何字符。

对于节点内容、属性值、命名空间等带有双引号的字符串，则进行字母匹配或者利用”*”匹配所有字符。

例10，例11：过滤<routing>节点下具有某属性值为Ethernet1的<interface>节点。过滤中找到属性值Ethernet1对应的属性和属性所在节点，将所在节点、属性名字和属性值均输出，则过滤结果如例11。

例10属性名字的模糊匹配：

<filter type＝“advancedSubtree”>

  <netconfxmlns＝“*”>

        <routing>

           <interface_＝″Ethernet1″/>

        </routing>

        </netconf>

</filter>

例11属性名字模糊查询的返回结果：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:if＝″urn:bupt:pris:priser:agent:module:interface:1.0″>

  <routing>

     <if:interface name＝″Ethernet1″ip-address＝”59.64.139.65”>

         <../>

     </if:interface>

  </routing>

</netconf>

上述实例中，过滤器中的过滤器<filter>节点指定了希望选择的数据模型中的<interface>节点的绝对路径，并通过在过滤器节点<interface>中设置属性＝＂Ethernet1＂实现了根据值查询属性的模糊查询功能。另外也可以根据属性名字查询值，只要将该<interface>中的属性改为name＝“*”(例如例12)，过滤中找到属性name的值和所在节点，将所在节点、属性名字和属性值均输出，则过滤结果与例11一致。

例12属性值的模糊匹配：

<filter type＝″advancedSubtree”>

  <netconf xmlns＝“*”>

     <routing>

        <interfacename＝“*”/>

     <routing/>

    <netconf/>

</filter>

节点名字与值的模糊查询与之类似。如模糊了<name>的值和<name>自身的查询可如下所示：

<interface><name>*</name></interface>

或者：

<interface><_>Ethernet1</_></interface>

此外，还可以实现对节点值、属性值、命名空间内容进行不完全内容匹配的模糊过滤。如例13，例14。

例13不完全内容匹配：

<filter type＝″advancedSubtree”>

  <netconf xmlns＝“*”>

     <routing>

        <interface>

           <mac-address>0006G*</mac-address>

        </interface>

     </routing>

    </netconf>

</filter>

例14不完全内容匹配的过滤结果：

    <netconf                       xmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

xmlns:if＝″um:bupt:pris:priser:agent:module:interface:1.0″>

      <routing>

         <if:interface name＝″Ethernet1″ip-address＝”59.64.139.65”>

             <if:mac-address>0006GG93KAG8</if:mac-address>

             <.../>

         </if:interface>

      </routing>

</netconf>

上述实例13、14中，希望从数据模型中选择与过滤器指定路径相匹配并且其子节点<mac-address>的文本值与0006G部分匹配的<interface>节点。在过滤器中，<mac-address>0006G*</mac-address>表示对内容进行非完全匹配。从过滤结果中看到，数据模型中存在节点<interface>，该节点的子节点<mac-address>的值可以与过滤器中相应节点的值非完全匹配。

“*”代表一个非空白字符串，可以出现在节点值、属性值、命名空间字符串等以“”标记的字符串的开头、末尾或其他地方。

由于XML文档规定，属性名字或者值不能单独出现，例如xml规定节点<interface name>为非法节点(此处interface为节点名字，name为该节点的属性名字，属性值未知)。因此如果只知道属性名字或属性值，则在过滤器的节点中应该给出利用特殊字符匹配属性名字或属性值的形式如attrName＝“attrValue”的完整形式，如<interfacename＝“*”/>或者<interface_＝″Ethernet1″/>，前者属性值未知，利用”*”来代替；后者属性名字未知，利用”_”来匹配。

除此之外，标签内的特殊字符是不被允许的，只能使用“；&lt”之类的转义字符来替换，对于用户来说非常不友好。因此只允许”_”字符匹配所有可能。

凡本文中提到的内置关键字及其可能的取值，不能够使用模糊匹配。

2.相对路径与跨层次访问

协议中子树过滤采用绝对路径匹配：即过滤器、数据模型、过滤结果必须有相同的根节点，其他所有元素必须给出从根节点开始的所有祖先，过滤结果中只包含在过滤器中的祖先和在数据模型中的祖先完全一致的节点。

为了提高过滤的灵活性，特增加相对路径匹配机制，即过滤器中的子节点对应的过滤结果节点未必是过滤器中父节点对应的过滤结果节点的子节点，也可能是其更深层次的后代；过滤器中的根节点未必是相应过滤结果中的根节点。

相对路径过滤在<filter>节点定义属性相关关键字_nodepath，且该属性_nodepath只能存在于<filter>节点之中。该属性的取值只有两个，一个是absolute，表示过滤器中所有节点采用绝对路径过滤，即过滤结果中各个节点相互之间的关系必须与过滤器中各节点之间的关系严格一致，是该属性的默认选项(此时可以不使用relative属性)；另一个是relative，表示采用相对路径过滤，即在过滤器中满足父子关系的节点可以在过滤结果中只满足祖先后代关系。

实际处理中当数据模型节点满足不了绝对路径关系时，即在数据模型对应位置上的兄弟节点中找不到与过滤器节点匹配的节点时，再在兄弟节点的后代中寻找可以匹配的节点。如果仍然找不到，那么认为该过滤器节点不存在匹配节点。

例如例15，例16希望查询数据模型中的<interface>节点，但不知其在数据模型中的具***置，所以无法在过滤器中给出该节点的绝对路径：

例15相对路径过滤：

<filter type＝“advancedSubtree”_nodepath＝″relative″>

  <interface xmlns＝”*”/>

</filter>

例16相对路径过滤的过滤结果：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:if＝″um:bupt:pris:priser:agent:module:interface:1.0″>

  <routing>

     <if:interface name＝″Ethernet1″ip-address＝”59.64.139.65”>

         <.../>

     </if:interface>

     <if:interface name＝″Ethernet2″ip-address＝”59.64.139.69”>

         <.../>

     </if:interface>

  </routing>

</netconf>

上述实例15、16中，过滤器构造了一个过滤器<filter>，该过滤器希望过滤出数据模型中所有的<interface>节点。由于过滤器未给定节点<interface>在数据模型中的路径，所以采用相对路径过滤，需要在过滤器<filter>中添加属性_nodepath＝″relative″。

在相对路径过滤中，如果有过滤器节点与数据模型节点不匹配，则并不直接退出对该节点的进一步处理，而是继续寻找数据模型中该节点后代是否有匹配于过滤器节点的节点。所以上述实例的过滤结果报文将输出数据模型中所有<interface>节点的所有父辈节点直至<netconf>根节点，并输出<interface>节点的后代节点。

如果已知interface节点所在数据模型的根节点是netconf，也可以这样改写例15为：

<filter type＝“advancedSubtree”_nodepath＝″relative″>

  <netconf>

     <interface/>

  </netconf>

</filter>

过滤结果与例16完全相同。

相对路径过滤也可以结合模糊匹配，从而能够对属性名字或属性值的直接查询。如例17和例18查询具有name属性的节点和name属性可能的值：

例17查询属性name的所有取值：

<filter type＝“advancedSubtree”_nodepath＝″relative″>

  <_name＝“*”/>

</filter>

例18属性name的查询结果：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:if＝″urn:bupt:pris:priser:agent:module:interface:1.0″>

  <routing>

     <iffinterface name＝″Ethernetl″ip-address＝”59.64.139.65”>

     ……

     </if:interface>

     <iffinterface name＝″Ethernet2″ip-address＝”59.64.139.69”>

     ……

     </if:interface>

  </routing>

</netconf>

这个实例(例17、18)的过滤器构造了一个过滤器<filter>，希望从数据模型中过滤出所有拥有属性名为name、属性值为任意值的节点，另外由于需要过滤出所有符合该条件的节点，所以过滤器无法给出各个节点的绝对路径，则需要采用相对路径过滤，在过滤器<filter>中添加属性_nodepath＝″relative″。

从过滤结果可以看出，数据模型中name属性的值可能为Ethernet1或Ethernet2，而且在数据模型中具有name属性的节点只有<interface>节点，由于过滤要求只返回节点本身的信息，所以不会返回<interface>节点的后代节点的信息。

3.查询条件细化与组合

在子树过滤中，可以采用多个属性或多个内容匹配节点对元素类型节点进行过滤。过滤条件只能完全符合或者相反，过滤条件之间默认为是“与”且只能是“与”的关系。而对于命名空间，逻辑关系“与”是不存在的。

为了提高过滤条件设置的灵活性，特增加其他两种逻辑关系：或、非，并细分以元素节点方式定义的过滤条件的匹配程度。

3.1元素节点过滤条件的逻辑关系

由于xml语言本身具有树型层次结构，可以较清晰的反应数据模型的树状层次结构。在不打乱该结构的情况下，通过在每个内容匹配节点中添加属性_matchType来表示该节点的匹配程度，并在一定程度上间接地实现节点过滤条件之间的逻辑关系组合。

注意，由于内容匹配节点的作用主要是作为从数据模型中选择特定的父节点的过滤条件，所以属性_matchType只有出现在内容匹配节点才有意义，如果过滤器中该属性出现在选择节点或者容器节点时，则该属性并无多少意义。属性_matchType的取值有三个：must(属性_matchType的默认值)，may和not。其中，must表示过滤器中内容匹配节点与数据模型中相应的节点必须完全匹配(即节点路径、节点名字、命名空间、属性、节点的文本内容等必须完全匹配)时，才将其父节点添加到过滤结果中，为默认项；may表示如果过滤器中的某个内容匹配节点与数据模型中相应的节点完全匹配(即节点路径、节点名字、属性，命名空间、节点文本内容等完全匹配)时，则将该内容匹配节点的父节点添加到过滤结果中；若不匹配，则在过滤该内容匹配节点的父节点(假设为节点<a>)时忽略该内容匹配节点，查看过滤器中是否还有其他的内容匹配节点与节点<a>的子节点相匹配；not表示如果过滤器中内容匹配节点与数据模型中相应的节点完全匹配(即节点路径、节点名字、命名空间、属性、节点的文本内容等必须完全匹配)时，则不添加该内容匹配节点的父节点到过滤结果中。

例19内容匹配节点逻辑关系组合的过滤器：

过滤包含节点<name>Ethernet1</name>并且包含节点<received>49</received>的节点<interface>，则过滤器如下所示：

<filter type＝“advancedSubtree”>

  <netconf xmlns＝″*″>

     <routing>

        <interface>

            <name_matchType＝“must”>Ethernet1</name>

            <!--<name>Ethernet1</name>-->

            <received_matchType＝“must”>49</received>

            <!--<received>49</received>-->

        </interface>

     </routing>

  </netconf>

</filter>

在上述实例19中，过滤器<filter>指定了节点<interface>在数据模型中的路径，并且要求只有同时满足拥有子节点<name>和<received>并且这两个子节点与过滤器中相应子节点的文本内容完全匹配的<interface>节点才会被添加到过滤结果中。由于数据模型中不存在与过滤器中指定的过滤条件相匹配的<interface>节点，所以过滤结果返回的报文是空。

而过滤包含<name>Ethernet1</name>或者<received>49</received>的节点<interface>，则过滤器和过滤结果分别如下例20所示：

例20内容匹配节点之间“或”逻辑关系的实现：

<filter type＝“advancedSubtree”>

  <netconf xmlns＝″*″>

     <routing>

        <interface>

           <name_matchType＝“may”>Ethernet1</name>

           <received_matchType＝“may”>49</received>

        </interface>

     </routing>

  </netconf>

</filter>

例21：例20的过滤结果：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:if＝″um:bupt:pris:priser:agent:module:interface:1.0″>

  <routing>

     <if:interface name＝″Ethernet1″ip-address＝”59.64.139.65”>

        <if:name>Ethernet1</if:name>

        <.../>

     </if:interface>

     <if:interface name＝″Ethernet2″ip-address＝”59.64.139.69”>

        <if:received>49</if:received>

        <.../>

     </if:interface>

  </routing>

</netconf>

在上述实例20中，过滤报文构造了一个过滤器<filter>，首先从数据模型中过滤出过滤器指定路径的<interface>节点，然后在这些<interface>节点中，那些拥有子节点<name>或者<received>或者两者都有，并且满足子节点<name>或者<received>的文本内容与过滤器中相应的节点完全匹配的<interface>节点才会被添加到过滤结果中。

在本实例21中，过滤结果返回两个<interface>节点，第一个<interface>节点由于其子节点<name>与过滤器中指定的内容匹配节点<name>相匹配而被选中；第二个<interface>节点由于其子节点<received>与过滤器中指定的内容匹配节点<received>相匹配而被选中。

例22，例23演示了_matchType＝“not”的例子，查询希望输出<name>节点的值不是Ethernet1的<interface>节点，因此只有<name>值是Ethernet2的<interface>节点被输出。过滤器和过滤结果分别如下所示：

例22内容匹配节点的“非”过滤条件：

<filter type＝“advancedSubtree”>

  <netconf xmlns＝″*″>

    <routing>

       <interface>

          <name_matchType＝“not”>Ethernet1</name>

        </interface>

     </routing>

  </netconf>

</filter>

例23例22的过滤结果：

<netconfximlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:if＝″um:bupt:pris:priser:agent:module:interface:1.0″>

  <routing>

     <if:interface name＝″Ethernet2″ip-address＝”59.64.139.69”>

         <if:name>Ethernet2</if:name>

         <.../>

     </if:interface>

  </routing>

</netconf>

例24，例25显示了不在同一个层次的节点的逻辑关系过滤的过滤器和过滤结果：

例24不同层次内容匹配节点逻辑关系组合：

     <filter type＝“advancedSubtree”>

       <netconf xmlns＝″*″>

           <routing>

              <interface>

                  <name_matchType＝“may”>Ethernet1</name>

                  <ipv4>

                     <address-v4

_matchType＝“may”>59.64.139.69</iaddress-v4>

                 </ipv4>

             </interface>

      </routing>

     </netconf>

</filter>

例24的结果：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:if＝″um:bupt:pris:priser:agent:module:interface:1.0″>

  <routing>

     <if:interface name＝″Ethernet1″ip-address＝”59.64.139.65”>

         <if:name>Ethernet1</if:name>

         <.../>

     </if:interface>

     <if:interface name＝″Ethernet2″ip-address＝”59.64.139.69”>

         <if:ipv4>

             <if:address-v4>59.64.139.69</if:address-v4>

             <if:flags up＝″false″/>

         </if:ipv4>

     </if:interface>

  </routing>

上述实例24过滤出了数据模型中包含<if:name>Ethernet1</if:name>子节点的<interface>节点以及包含<if:address-v4>59.64.139.69</if:address-v4>子节点的<ipv4>节点。

如果将<address-v4>的_matchType属性值设置为”must”，如下面的例25、例26，则生成的过滤器和过滤结果如下：

例25内容匹配节点逻辑关系组合的过滤器：

<filter type＝“advancedSubtree”>

<netconf xmlns＝″*″>

     <routing>

        <interface>

            <name_matchType＝“may”>Ethernet1</name>

            <ipv4>

               <address-v4_matchType＝“must”>59.64.139.69</iaddress-v4>

            </ipv4>

        </interface>

     </routing>

      </netconf>

</filter>

例26例25的过滤结果：

<netconf xmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:if＝″urn:bupt:pris:priser:agent:module:interface:1.0″>

  <routing>

     <if:interface name＝″Ethernet1″ip-address＝”59.64.139.65”>

         <if:name>Ethernet1</if:name>

         <if:mac-address>0006GG93KAG8</if:mac-address>

         <if:received>19</if:received>

     </if:interface>

     <if:interface name＝″Ethernet2″ip-address＝”59.64.139.69”>

         <if:ipv4>

             <if:address-v4>59.64.139.69</if:address-v4>

             <if:flags up＝″false″/>

         </if:ipv4>

     </if:interface>

  </routing>

上述实例25中，从数据模型中过滤出两个<interface>节点，第一个<interface>节点包含子节点<name>并且该子节点与过滤器<filter>中的内容匹配节点<name>完全匹配，但是由于它的子节点<ipv4>的子节点<address-v4>与过滤器中响应的内容匹配节点<address-v4>不匹配而且过滤器中内容匹配节点<address-v4>的_matchType属性值为must，所以输出的<interface>后代节点中没有<ipv4>子节点；另一个<interface>节点，它的子节点<ipv4>的子节点<address-v4>与过滤器中相应的内容匹配节点完全匹配，所以输出该<interface>节点的子节点<ipv4>的全部信息。

另外，允许用户对容器节点和选择节点应用属性_matchType，但是在这两种类型的节点中该属性的值只能是”must”。如果用户在容器节点或选择节点中对_matchType属性赋予了其他值(如not/may)，则过滤机制将对在这两种类型节点中出现的_matchType属性忽略其值，因为其并无意义可用。

3.2节点属性和命名空间的逻辑关系过滤

节点的多个属性间的逻辑关系可以通过向节点中添加属性_attrLogic来标示。命名空间逻辑关系条件添加_nsLogic来标示。节点的普通属性(不包括命名空间)之间可以有逻辑与“＾”、逻辑或“‖”(这两者优先级相等)，以及逻辑非“！”(优先级高于“‖”和“＾”)的关系，并可以使用( )改变其优先级；而节点的命名空间之间只有逻辑或“‖”的关系，表示可以同时从多个命名空间中查找满足其过滤条件的元素。命名空间逻辑关系与默认命名空间一样，有继承关系。即除非子节点定义了_nsLogic属性新的值比如取_nsLogic＝””表示逻辑关系无效，否则默认其与父节点有相同的命名空间逻辑组合过滤条件。

在_attrLogic引出的逻辑表达式中，节点普通属性使用逻辑表达式所在节点的其他属性的名字标记，例如name＝”Ethernet1”，可以在同一节点定义属性_attrLogic＝”！name”，属性值包含“name”表示name属性；如果节点未定义属性_attrLogic，那么按照NETCONF协议规定，各个属性之间是“与”的关系。即：

<interface name＝″Ethernet1″ip-address＝”59.64.139.69”/>

与下述定义

     <interface    name＝″Ethernet1″ ip-address＝”   59.64.139.69”

_attrLogic＝“name＾ip-address”/>

等同。

在_nsLogic引出的逻辑表达式中，命名空间使用逻辑表达式所在文档的命名空间前缀定义标记，例如文档中某处层定义xmlns:if＝”urn:bupt:pris:priser:agent:module:interface：1.0”，可以在需要多重命名空间过滤的节点处定义属性_nsLogic＝”if‖mt”，属性值包含“if”表示命名空间urn:bupt:pris:priser:agent:module:interface：1.0；mt代表了另一个命名空间；如果节点未曾定义属性_nsLogic，那么按照NETCONF协议规定，过滤时将数据模型节点的命名空间与相应过滤器节点本身的命名空间匹配。

如例27，例28所示，过滤数据模型中属性name的值为Ethernet1或者ip-address值为59.64.139.69的<interface>节点。

例27属性或逻辑关系组合查询：

       <filter type＝“advancedSubtree”>

         <netconf xmlns＝″*″>

            <routing>

               <interface     name＝″Ethernet1″    ip-address＝”    59.64.139.69”

_attrLogic＝”name‖ip-address”/>

            </routing>

         </netconf>

       </filter>

例28例27的过滤结果：

<netconf xmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:if＝″um:bupt:pris:priser:agent:module:interface:1.0″>

  <routing>

     <if:interface name＝″Ethernet1″ip-address＝”59.64.139.65”>

        <... />

     </if:interface>

     <if:interface name＝″Ethernet2″ip-address＝”59.64.139.69”>

         <.../>

     </if:interface>

  </routing>

</netconf>

从实例27中可以看到，由于使用了两个属性表达式，并用_attrLogic属性指出了两个属性表达式之间是“或”关系，因此，两个<interface>节点分别只满足了两个属性表达式中的一个，这两个<interface>节点也都被输出。

如果修改过滤条件，查询name属性值不是”Ethernet1”并且ip-address属性值是”59.64.139.69”的<interface>节点，这个查询的表达方式如下：

<interface name＝″Ethernet1″ip-address＝”59.64.139.69”_attrLogic＝“!name＾ip-address”/>

还可使用括号表达属性过滤条件的逻辑关系，如选取属性name和ip-address全部满足或者全部不满足给定值的节点：

<interface name＝″Ethernet1″ip-address＝”59.64.139.69”

          _attrLogic＝“(name＾ip-address)‖(！name＾！ip-address)”/>

例29、例30是一个节点的多重命名空间逻辑或关系查询的过滤器和过滤结果：

例29节点多重命名空间查询：

     <filter type＝“advancedSubtree”>

       <netconf xmlns＝“*”>

          <routing>

             <interface

xmlns:if＝″urn:bupt:pris:priser:agent:module:interface:1.0″

                       xmlns:mt＝″urn:bupt:pris:priser:agent:module:monitor:1.0″

_nsLogic＝“if‖mt”/>

          <routing/>

       <netconf/>

</filter>

例30例29的过滤结果：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:if＝″urn:bupt:pris:priser:agent:module:interface:1.0″

     xmlns:mt＝″urn:bupt:pris:priser:agent:module:monitor:1.0″>

  <routing>

     <if:interface name＝″Ethernet1″ip-address＝”59.64.139.65”>

         <.../>

     </if:interface>

     <if:interface name＝″Ethernet2″ip-address＝”59.64.139.69”>

         <.../>

     </if:interface>

  </routing>

</netconf>

上述实例29中，命令报文构造了一个过滤器<filter>，希望从数据模型中过滤出与过滤器指定的节点路径相匹配，属于命名空间xmlns:if＝″urn:bupt:pris:priser:agent:module:interface:1.0″或者命名空间xmlns:mt＝″urn:bupt:pris:priser:agent:module:monitor:1.0″的<interface>节点。

从实例30的返回的过滤结果可知，在数据模型中存在两个<interface>节点，这两个节点都属于命名空间xmlns:if＝″urn:bupt:pris:priser:agent:module:interface:1.0″，满足过滤器指定的节点路径，不存在属于命名空间xmlns:mt＝″urn:bupt:pris:priser:agent:module:monitor:1.0″的<interface>节点。

4.命名空间查询

命名空间查询可以获取数据模型中命名空间的定义情况，并给出命名空间的列表。命名空间查询的关键字为标签元素<_xmlns>，当过滤器<filter>的子节点为<_xmlns>，则表示对该数据模型进行命名空间相关查询；同时定义了属性相关关键字prf，该属性位于过滤返回结果的元素<_xmlns>中，表示该命名空间在此文档中对应的前缀，如果该命名空间是默认命名空间(即无前缀)，则不输出prf属性。

例如例31，例32分别显示了查询数据模型中所有命名空间的过滤器定义和过滤结果。

例31查询所有命名空间：

<filter type＝“advancedSubtree”>

  <_xmlns/>

</filter>

例32例31的过滤结果：

   <data>

     <_xmlns>um:ietf:params:xml:ns:netconf:base:1.0</_xmlns>

     <_xmlns                                 prf＝”if”>

urn:bupt:pris:priser:agent:module:interface:1.0</_xmlns>

     <_xmlns　　　　                     　  prf＝”mt”>

um:bupt:pris:priser:agent:module:module:1.0</_xmlns>

   </data>

上述实例31通过关键字元素<_xmlns>告知过滤器，查询数据模型中存在的所有命名空间。过滤结果则以<_xmlns>um:ietf:params:xml:ns:netconf:base:1.0</_xmlns>的形式将数据模型中所有的命名空间返回。

另外，还可以查询部分数据模型的命名空间，如例33所示：

例33查询部分元素的命名空间：

<filter type＝“advancedSubtree”>

  <_xmlns>

     <netconf>

        <routing/>

     </netconf>

  </_xmlns>

</filter>

过滤结果如下：

<_xmlns prf＝”if”>urn:bupt:pris:priser:agent:module:interface:1.0</_xmlns>

上述实例中，过滤器<filter>通过设置子节点<_xmlns>告知过滤器查询数据模型的命名空间，同时通过设置节点<netconf><routing/></netconf>告知过滤器具体查询的是子树/netconf/routing的命名空间，所以过滤结果中只返回了数据模型中<netconf>和<routing>节点的命名空间“urn：bupt：pris：priser：agent：module：interface:1.0”。

5.后代输出控制

当过滤器给出一个元素类型节点，过滤结果将包括该节点的所有匹配后代；某些时候，这将返回大量无用的数据。

为了提高过滤的效率及方便用户获取所需信息，可以在过滤器中相应节点处设置属性_show表明是否显示节点后代。该属性的取值为self或descendant。该属性默认为显示所有在同一命名空间的后代，即_show＝“descendant”；当设置_show＝“self”，则过滤结果只输出该节点的信息，不输出其后代节点。属性_show只能位于包含节点中。

对于内容匹配节点一类的叶子节点来说，输出其本身或输出后代并无区别。

例如例34、例35、例36、例37分别显示了如何过滤出指定节点的完整信息和部分信息。

例34输出节点完整信息的过滤器：

<filter type＝“advancedSubtree”_nodepath＝″relative″>

  <interface_show＝descendant/>

</filter>

例35例34的过滤结果：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:iff＝″um:bupt:pris:priser:agent:module:interface:1.0″>

  <routing>

     <if:interface name＝″Ethernet1″ip-address＝”59.64.139.65”>

         <.../>

     </if:interface>

     <if:interface name＝″Ethernet2″ip-address＝”59.64.139.69”>

         <.../>

     </if:interface>

  </routing>

</netconf>

例36只输出节点本身信息：

<filter type＝“advancedSubtree”_nodepath＝″relative″>

   <interface_show＝”self”/>

</filter>

例37例36的过滤结果：

<netconf xmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:if＝″urn:bupt:pris:priser:agent:module:interface：1.0″>

  <routing>

     <if:interface name＝″Ethernet1″ip-address＝”59.64.139.65”/>

     <if:interface name＝″Ethernet2″ip-address＝”59.64.139.69”/>

  </routing>

</netconf>

对比上述实例37的过滤结果，可以明显看到当在过滤器<filter>中的节点<interface>中设置属性_show＝”self”时，则只会输出节点本身的信息，可以避免返回过多的冗余信息，提高过滤效率。

6.个数查询

个数查询功能可以统计数据模型中某一类元素的个数，即同一过滤器节点对应的元素个数。通过在过滤器中某元素节点中使用_count属性实现，该属性的取值有两个：true或false。当设置_count属性值为”true”时，则过滤结果输出查询实体的个数；当设置_count属性为”false”时，则过滤结果不输出查询实体的个数，”false”是属性_count的默认值。如果过滤结果返回查询实体的个数，则在过滤结果中相应实体元素节点下面添加标签元素<_countNum>，该元素的文本值标识查询实体的个数。

例如例38、例39显示了如何查询<monitor>节点的子节点<configuration>的个数，过滤器和过滤结果如下：

例38查询指定节点的个数：

<filter type＝“advancedSubtree”>

  <netconf xmlns＝”*”>

     <monitor xmlns＝”um:bupt:pris:priser:agent:module:monitor：1.0”>

        <configuration_count＝“true”/>

     </monitor>

  </netconf>

</filter>

例39例38的过滤结果：

<netconf>

  <monitor xmlns＝”um:bupt:pris:priser:agent:module:monitor:1.0”>

     <configuration>

        <_countNum>3</_conutNum>

     </configuration>

  </monitor>

</netconf>

上述实例38的过滤器<filter>设置为在数据模型中查询出指定路径的节点<configuration>的个数。实例39的过滤结果显示，数据模型中的<monitor>节点的子节点<configuration>的个数是3。

个数查询也可以满足诸如查询属性name值为Ethernet1或者节点值为running-state的节点个数这样带有限制条件的节点个数统计：

<interface name＝”Ethernet1”_count＝“true”>

<configuration_count＝“true”>running-state</running>

7.范围条件

用于选择具有某些特定数值或者日期范围的节点。由于标签内不能使用“<”或“>”之类的符号，如果在文本内容中添加“<”或“>”，将会和标签的开始符和结束符混淆，形成非法的xml文档。所以，在表示数量或时间的选择节点中添加表示属性范围或时间范围的属性，以此将该选择节点看作是表示时间或数量范围的内容匹配节点，从而在过滤处理时作为过滤条件。

其中表示数量范围的属性关联关键字有：_morethan，表示该属性所在的选择节点的值大于该属性的值；_lessthan，表示该属性所在的选择节点的值小于该属性的值；_notmorethan，表示该属性所在的选择节点的值不大于该属性的值；_notlessthan，表示该属性所在的选择节点的值大于该属性的值；注意使用属性的过滤器节点所对应的数据模型节点必须可转化为数值类型，比如“14”、“23.6”等，否则会认为是不匹配的节点。

同时，定义了范围属性条件但没有文本内容的过滤器节点同样是内容匹配节点。

表示时间范围的属性关联关键字有：_timebefore：表示该属性所在的选择节点的时间值超前于该属性的值；_timeafter：表示该属性所在的选择节点的时间值滞后于该属性的值；_timenotbefore：表示该属性所在的选择节点的时间值等于或滞后于该属性的值；_timenotafter：表示该属性所在的选择节点的时间值等于或超前于该属性的值。注意使用属性的过滤器节点所对应的数据模型节点必须可转化为时间类型，即规范满足2007-07-0105:24:06的格式，以满足网络管理中对时间的存储读取需求。

例如欲查询<received>的值大于12且小于25的<interface>节点，过滤器表达如例40所示，其中<received_morethan＝”12”_lessthan＝”25”/>表达了这一范围条件。例41显示该查询的结果。

例40数值范围过滤的过滤器：

<filter type＝“advancedSubtree”>

  <netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

   xmlns:if＝″urn:bupt:pris:priser:agent:module:interface:1.0″>

    <routing>

      <if:interface>

         <received_morethan＝”12”_lessthan＝”25”/>>

      </if:interface>

    </routing>

  </netconf>

</filter>

例41例40的过滤结果：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

xmlns:if＝″um:bupt:pris:priser:agent:module:interface:1.0″>

  <routing>

     <if:interface name＝″Ethernet1″ip-address＝″59.64.139.65″>

        <if:received>19</if:received>

        <.../>

     </if:interface>

  </routing>

</netconf>

下面是根据时间范围条件查询的例子：

<startTime_timenotafter＝”2007-07-0105:24:06”_timeafter＝”2007-06-3005:24:06”/>

表示查询表示时间晚于但不包括2007年06月30日05:24:06，并早于且包括2007年07月01日05:24:06的<startTime>节点。

或者添加字符串匹配功能：

<startTime_timeafter＝”2005-06-3005:24:06”>*-07-*</startTime>

符合-07-格式的只有月份的表达，上述定义可以查询2005年06月30日05:24:06以后每年7月的相关数据。

8.子树排序合并

对同一个过滤器节点得到的过滤结果按照需要进行排序，如根据某个节点内容进行升序或者降序排列，合并查询结果中内容完全相同的节点。

排序通过在要排序子树根节点处设定属性_ascOrder和_descOrder实现。属性_ascOrder表示根据某节点或属性做升序排列，属性_descOrder表示根据某节点或属性做降序排列。这两个属性的取值为排序依据的节点名或属性名。排序所依据的节点应当有值，并且是该属性所在节点的子节点。以属性进行排序时需要在属性名前加“＠”，标识这是一个属性名。节点值为排序依据的索引，默认按文本方式排序；如果按数值大小排序，在节点或属性名后加标识“(n)”，比如_ascOrder＝“recived(n)”；如果该节点或属性的值为非数值类型，则向用户返回错误信息。

当需要以多个节点、属性进行排序时，多个节点名、属性名间以“＾”连接，排在前面的节点、属性名字优先级高于后面的节点、属性名字。

例如，希望按<name>节点的值以降序的顺序输出<interface>节点，具有相同<name>值的<interface>节点再按ip属性排序。这样的查询入例42所示、其中_descOrder＝”name＾＠ip”表达了这个排序要求。例43显示了排序的结果。

例42按指定节点值降序输出元素：

      <filter type＝“advancedSubtree”>

          <netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″>

              <routing>

                   <interface

xmlns＝″urn:bupt:pris:priser:agent:module:interface:1.0″

                               _descOrder＝”name＾＠ip”/>

             </routing>

           </netconf>

      </filter>

例43：例42的过滤结果如下所示：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:if＝″um:bupt:pris:priser:agent:module:interface:1.0″

     xmlns:mt＝″urn:bupt:pris:priser:agent:module:monitor:1.0″>

  <routing>

     <if:interface name＝″Ethernet2″ip-address＝”59.64.139.69”>

          <if:name>Ethernet2</if:name>

          ……

      </if:interface>

      <if:interface name＝″Ethernet1″ip-address＝”59.64.139.65”>

          <if:name>Ethernet1</if:name>

          ……

      </if:interface>

  </routing>

</netconf>

由于对同一个过滤器节点可能得到许多相同结构、相同内容的子树，所以可以在排序子树根节点处设定属性_merge来实现相同子树的合并。该属性的取值为：true或false。当_merge＝“true”，则表示对过滤结果进行相同子树合并后再返回；当_merge＝“false”，表示对过滤结果不进行子树合并，属性_merge的默认值是”false”。

假设数据模型中<interface>节点不具有任何属性，那么将对于下述报文：例44未使用合并的过滤器：

 <filter type＝“advancedSubtree”>

       <netconf xmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″>

            <routing>

                  <interface

xmlns＝″urn:bupt:pris:priser:agent:module:interface:1.0″_show＝”self”/>

         </routing>

       </netconf>

 </filter>

例45未使用合并的过滤结果：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:if＝″urn:bupt:pris:priser:agent:module:interface:1.0″

     xmlns:mt＝″urn:bupt:pris:priser:agent:module:monitor:1.0″>

  <routing>

     <if:interface/>

     <if:interface/>

  </routing>

</netconf>

此时用户实际上只想知道数据模型中是否interface节点的存在而不关心其他。如果使用_merge属性，<interface>节点修改为<interface xmlns＝″urn:bupt：pris：priser：agent：module：interface：1.0″_show＝“self”_merge＝”true”/>，过滤结果变为：

例46合并后的过滤结果：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:if＝″urn:bupt:pris:priser:agent:module:interface:1.0″

     xmlns:mt＝″um:bupt:pris:priser:agent:module:monitor:1.0″>

  <routing>

     <iff：interface/>

  </routing>

</netconf>

多个相同的<interface>节点(或者说子树)中压缩只输出一个，这在数据模型中具有大量同名节点的情况下，可能会避免大量冗余信息在管理网络中传输的弊病。

综上，本发明扩展功能的定义规范总结如表1所示：

表1子树过滤功能定义

带有“<>”表示该关键字以元素的形式存在；不带有“<>”而只带有“_”表示该关键字以属性的形式存在；两者皆不带有表示该关键字以属性值或节点值形式存在。

除此之外，本发明对NETCONF协议子树过滤机制中的以下处理情形进行了修正：

1.舍弃不匹配节点的祖先

如果有下例过滤请求：

例47不匹配节点的查询：

<filter type＝″subtree″>

       <netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″>

          <routing>

                   <interface name＝″Ethernet″

xmlns＝″urn:bupt:pris:priser:agent:module:interface:1.0″/>

               <routing/>

           <netconf/>

    </filter>

而数据模型中没有一个属性name值为Ethernet的interface节点。那么在NETCONF协议子树过滤机制中，NETCONF协议中得到的过滤结果如下：

例48NETCONF协议中对不匹配节点的过滤结果：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:if＝″urn:bupt:pris:priser:agent:module:interface:1.0″

     xmlns:mt＝″urn:bupt:pris:priser:agent:module:monitor:1.0″>

  <routing/>

</netconf>

由于数据模型中，不存在匹配的interface节点，故而不输出interface节点，但返回其祖先routing和netconf.。对于用户来说，过滤结果含义表达并不明确，也带来了无用的冗余信息。

本发明中，当所有需要匹配的节点没有匹配数据模型节点，因而全部被舍弃时，这些节点的父节点也不返回。因而例47的过滤会返回空的过滤结果：<data></data>

例49扩展功能中不匹配节点的过滤结果

2.命名空间过滤

由于NETCONF协议中的子树过滤机制将具有相同父节点的节点(即兄弟节点集合)集中在一起进行处理，从根节点到叶子节点。因此一旦匹配失败，会将不匹配节点和其所有子节点全部删除。例如在NETCONF协议中下述过滤请求：

例50：NETCONF协议中命名空间过滤：

<filter type＝″subtree″>

  <netconf xmlns＝″urn:bupt:pris:priser:agent:module:interface:1.0″/>

</filter>

处理根节点netconf时，节点的名字匹配，但命名空间不匹配，于是丢弃netconf节点，从而得到空过滤结果：

例51：NETCONF协议中命名空间过滤结果：

<data></data>

而本发明实施例中，当出现节点的命名空间不匹配时，仍然继续处理其子节点，因为可能存在其后代与给定的命名空间匹配。同时由于要保证过滤结果的层次关系仍然有效，故也可能保留命名空间不匹配的元素作为其他节点的路径。用户可以从过滤结果中很清楚的分辨出这些带有其他命名空间的元素。

例50在子树过滤功能扩展中得到的过滤结果如下：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:if＝″urn:bupt:pris:priser:agent:module:interface:1.0″

     xmlns:mt＝″urn:bupt:pris:priser:agent:module:monitor:1.0″>

  <routing>

     <if:interface name＝″Ethernet1″ip-address＝”59.64.139.65”>

         ……

     </if:interface>

     <if:interface name＝″Ethernet2″ip-address＝”59.64.139.69”>

         ……

     </if:interface>

  </routing>

</netconf>

例52扩展功能中命名空间过滤结果

实现这种机制后，可以很容易的查找文档内或某节点下所有属于某命名空间的元素。例如查询命名空间urn:bupt:pris:priser:agent:module:interface:1.0中的元素，直接将该命名空间作为过滤器中根节点的命名空间，虽然在数据模型中该命名空间与根节点的命名空间不同。

本发明实施例提供一套基于并对NETCONF协议中子树过滤机制加以扩展的，实现对XML语言定义的网络管理信息模型的数据查询和数据过滤功能的处理***。处理***详细说明了***实施的总体结构和结构中每个模块的具体功能。

本发明扩展后的NETCONF子树过滤***主要体系架构如图2所示。该***包括过滤控制模块、报文设置模块、名字空间处理模块、相对路径访问模块、递归流程控制模块、节点功能处理模块和结果处理模块。

各模块的主要功能如下：

1.过滤控制模块

过滤控制模块是整个子树过滤部分的核心，为整个子树过滤过程提供控制机制，同时可以根据报文中的参数执行协议子树过滤和XPath过滤操作。该模块解析rpc报文中过滤相关部分，并且根据报文的具体内容按顺序调用其他模块完成相应功能，相应模块功能处理完毕后需向其汇报处理结果并由过滤控制模块决定如何进行下一步的操作。在获取初始过滤结果后，如果报文中有对过滤结果进行处理的要求，此模块即调用结果处理模块对初始过滤结果进行处理，获得最终过滤结果并返回。

2.报文设置模块

即rpc报文，rpc报文中包含过滤控制模块所需的过滤信息，过滤控制模块首先判断rpc报文的正确性，如果正确则根据报文的信息设置具体的参数，包括过滤类型(子树过滤、扩展子树过滤、Xpath)和在扩展子树过滤中是否需要相对路径匹配。并将结果返回给过滤控制模块。

3.名字空间处理模块

名字空间处理模块用于处理与名字空间查询相关的操作请求，例如查询配置文档中所有节点的名字空间、查询某个子树中所有节点的名字空间等，在实现中需要递归流程模块和结果处理模块的支持。

4.相对路径访问模块

相对路径访问模块用于当rpc消息中给出的是节点的相对路径时，对配置文档进行过滤。因此避免了在协议中的条件下必须给出节点完整路径的限制，可以在不给出节点完整路径的情况下进行过滤。主要功能是为递归流程模块找到合适的配置文档节点作为参数。

5.递归流程控制模块

将配置文档由顶层到底层划分，一次处理过滤器中一群兄弟节点，将其分为容器节点、选择节点、内容匹配节点进行相关处理；每当添加节点到过滤结果时，对其进行节点功能处理。

6.节点功能处理模块

节点功能处理模块包括：模糊匹配模块、节点数量查询模块、数值范围查询模块、时间范围查询模块和逻辑关系组合模块，用于在进行过滤时对过滤器文档中的节点和数据模型中的节点的判断比较，并给出判断结果。

7.结果处理模块

结果处理模块是对过滤结果进行操作，具体包括报文封装模块、节点排序模块和节点合并模块。当过滤器为名字空间过滤时，结果处理模块需要对过滤结果进行封装，将所有的名字空间封装成xml的格式返回。当过滤器报文中要求对过滤结果进行排序时，结果处理部分根据排序的关键字对初始结果进行处理，获得排序后的结果并提交给过滤控制模块。节点合并用于对初始过滤结果中相同子树的合并。

本发明实施例提供一套基于并对NETCONF协议中子树过滤机制加以扩展的，实现对XML语言定义的网络管理信息模型的数据查询和数据过滤功能的处理方法。该处理方法包括扩展后的NETCONF子树过滤实施的总体流程和具体模块的详细流程图。

图3为本发明实施例的总体流程图，主要包括报文检错、根据关键字设置运行参数、之后将给出的过滤器对Agent本地保留的数据模型进行过滤，遇到节点调用节点处理模块，待所有节点处理完毕后，对过滤结果做进一步处理，具体包括以下步骤：

步骤3010，开始；

步骤3020，解析rpc报文；

步骤3030，判断rpc报文设置是否正确，如果正确则转步骤3050，如果不正确则转步骤3040；

步骤3040，报错；

步骤3050，判断关键字，以确定是命名空间过滤，还是跨层次访问；如果是命名空间过滤，则转步骤3060，如果是跨层次访问，则转步骤3070；

步骤3060，调用命名空间过滤，转步骤3080；

步骤3070，调用跨层次过滤，转步骤3080；

步骤3080，调用递归流程控制；

步骤3090，调用节点功能处理；

步骤3100，根据关键字，对过滤结果进行处理；

步骤3110，结束。

1.过滤控制

过滤控制模块是整个子树过滤流程的管理者，它调用其他组件完成工作，并接收其他组件工作的结果来决定下一步的工作内容。其主要流程为如图4所示，包括以下步骤：

步骤4010，调用图2中的报文设置模块；

步骤4020，判断是否采用扩展子树过滤，如果是则转步骤4030，如果否，则判断查询对象类型是否为不同配置数据存储中的配置数据，如果是则采用Xpath过滤，如果否，则判断查询对象类型是否为当前正在运行的配置和状态数据，如果是，则采用协议子树过滤；

步骤4030，根据rpc报文判断报文的正确性，如果正确则转步骤4060，否则转步骤4100；

步骤4060，进行名字空间查询，如果查到，则转步骤4070，否则，转步骤4072；

步骤4070，调用名字空间处理模块；

步骤4072，根据关键字判断是否采用跨层次过滤，如果是，则转步骤4075，否则转步骤4080；

步骤4075，调用跨层次过滤模块，转步骤4080；

步骤4080，调用递归流程控制模块，开始进行子树过滤，转步骤4090；

步骤4090，对过滤结果进行相关处理，转步骤4100；

步骤4100，将操作结果封装报文返回给相关操作。

2.名字空间处理

当filter的根节点为<_xmlns>时，过滤控制调用名字空间处理组件，声明其报文仅是名字空间的过滤条件。返回结果只包含名字空间的信息。实现方法如图5所示，包括以下步骤：

步骤5001，获取报文定义中<_xmins>元素的子节点；

步骤5010，判断是否<_xmins>无子节点，如果是，则转步骤5020，否则转步骤5030；

步骤5020，将配置文档整体作为过滤初始结果，转步骤5040；

步骤5030，执行子树过滤递归；

步骤5040，获得节点的命名空间***集合；

步骤5050，判断是否所有节点获取完毕，如果是，则转步骤5060，否则转步骤5030。

步骤5060，封装获取内容返回给过滤控制模块。

3.递归流程控制

递归流程控制与协议中实现方法基本类似，流程图如图6所示，包括以下步骤：

步骤6001，解析报文设置该节点的操作参数；

步骤6010，节点判断本身信息是否匹配，如果匹配，则转步骤6020，如果不匹配，则转步骤6015；其中，节点本身的信息包括节点类型、节点名字、节点属性、节点名字空间等，节点属性和节点名字空间可能有多种逻辑关系；

步骤6015，该节点判断是否有相对路径，如果有则转步骤6017；

步骤6017，寻找相对路径上的节点，转步骤6090；

步骤6020，该节点判断与内容匹配节点是否匹配，如果是，则转步骤6030，否则，转步骤6100；其中，内容匹配节点包括具有文本值的节点和具有数据范围等其他条件的节点，同样可能会存在多种逻辑关系，并可能存在扩展查询子句；

步骤6030，创建符合要求的当前节点副本，进入步骤6040；

步骤6040，在过滤结果中添加内容匹配节点，进入步骤6050；

步骤6050，处理选择节点，选择节点包括过滤器中不含子节点的节点及子节点为内置关键字如<_count>等。如果选择节点设定为不显示其子孙，则只复制本身；如果设定为不显示祖先，则将选择节点复制到结果根节点下；进入步骤6060

步骤6060，获取容器节点列表；

步骤6070，判断容器节点和选择节点是否都为空，如果是，则转步骤6080，否则，转步骤6090；

步骤6080，将其它节点复制到当前节点副本下，转步骤6100；

步骤6090，递归调用处理容器节点，转步骤6100；

步骤6100，退出当前流程，返回上一级递归；返回结果包括符合过滤条件的当前节点及其子孙，同时也包括由于保留其他节点而必须保留的部分不符合过滤条件的节点，不包括对用户来说没有意义的节点。

4.节点功能处理

节点功能处理模块接受递归流程控制的调用，实现针对单个节点的处理功能。该节点功能处理模块从过滤器定义中某一个节点出发，保留配置文档中符合该节点代表的过滤条件的节点，并根据其表述的要求对保留的配置文档节点做一些处理。

该节点功能处理模块的功能包括：节点的匹配、选择文本内容为特定数值的节点、选择文本内容为特定时间的节点、子节点个数查询、属性及命名空间或与非逻辑的运算，查找与当前节点相似但是路径不完全的配置文档节点。

该节点功能处理模块接受递归控制部分传递的参数，进行相应的处理，并且将处理结果返回给递归控制模块。

主要实现方法如下：

(1)模糊匹配：

判断配置文档和过滤器文档中两个节点的属性是否模糊匹配。首先将文本节点的内容进行适当预处理，然后根据正则表达式进行判断是否匹配。

(2)选择文本内容为特定数值范围的节点：

首先判断文本内容是否可以转换成数值类型，若是则继续判断数值是否在指定的数值范围内，数值范围的判断包括4个部分：大于、小于、不大于和不小于。

(3)选择文本内容为特定时间范围的节点：

首先判断文本内容是否可以转换成表示时间的数据，若是则继续判断数据是否在指定的时间范围内，时间范围的判断包括4个部分：早于、晚于、不早于和不晚于指定的时间。

(4)子节点个数查询：

设置节点计数器，当寻找到匹配节点时，计数器加1；将节点划归到过滤结果文档时只复制节点本身及其个数。

(5)查找与当前节点相似但是路径不完全的配置文档节点：

根据节点部分特性在当前节点后代中查找节点，并与当前节点进行匹配，供相对路径功能模块使用。

(6)属性、命名空间逻辑关系：

首先确定过滤器中给出的各命名空间、属性，配置文档节点是否符合。以true或false表示。然后计算布尔类型表达式的值。

5.结果处理模块实现以下功能：

报文封装：报文封装主要是将过滤结果根据过滤控制中设置的参数封装为适当的报文格式发回给过滤控制；

节点合并：合并具有相同结构的过滤结果；

节点排序：对过滤结果根据给定节点的值进行排序，并将排序后的结果返回。结果处理的基本流程如图7所示，包括以下步骤：

步骤7010，判断过滤器是否为空，如果是，则转步骤7020；

步骤7020，拷贝整个配置文档；

步骤7030，判断是否进行命名空间查询，如果是，则转步骤7040；

步骤7040，检索命名空间和前缀；

步骤7050，进行节点排序或进行节点合并；

步骤7060，封装报文返回。

本发明实施例一，

假设Agent端管理的数据模型如下例53数据模型所示：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:mt＝″urn:bupt:pris:priser:agent:module:monitor:1.0″

     xmlns:if＝＂urn:bupt:pris:priser:agent:module:interface:1.0＂>

  <routing>

     <if:interface name＝″Ethternet1″ip＝″59.64.139.65″>

         <if:name>Ethernet1</if:name>

         <if:mac-address>0006GG93KAG8</if:mac-address>

         <if:ipv4>

             <if:address-v4>59.64.139.65</if:address-v4>

             <if:flags up＝″true″/>

             <if:received>19</if:received>

         </if:ipv4>

     </if:interface>

     <if:interface name＝″Ethternet2″ip＝″59.64.139.69″>

         <if:name>Ethernet2</if:name>

         <if:mac-address>000E35A83K4K</if:mac-address>

         <if:ipv4>

            <if:address-v4>59.64.139.69</if:address-v4>

            <if:flags up＝＂false＂/>

            <if:received>49</if:received>

         </if:ipv4>

     </if:interface>

  </routing>

  <mt:monitor>

     <mt:configuration>running-state</mt:configuration>

     <mt:configuration>startup-config</mt:configuration>

     <mt:configuration>running-config</mt:configuration>

        <if:configuration>http://pris.bupt.cn/example/</if:configuration>

  </mt:monitor>

</netconf>

现对其进行查询，过滤器定义如下例54实施例过滤器定义：

 <filter type＝”advancedSubtree”_nodepath＝”relative”>

   <if:interface name＝＂Ethternet1＂ip＝＂59.64.139.65＂_attrLogic＝＂(name＾ip)

‖(！name＾！ip)＂

              xmlns:if＝＂*interface*＂/>

      <_    _count＝true/>

   </if:interface>

   <mt:monitor xmlns:mt＝＂*monitor:1.0＂>

      <configuration_nsLogic＝＂if‖mt＂_order＝＂asc＂/>

   </mt:monitor>

 </filter>

当get/get-config操作发现操作报文中含有filter节点，将之交给图2中过滤控制模块，该模块调用图2中参数设置功能模块，由filter的属性type＝”advancedSubtree”得知需要进行子树过滤扩展功能操作，并解析到需要相对路径匹配，将参数nodepath送给流程控制开始扩展子树过滤操作。如图4中步骤4020所示。

过滤器的定义主要流程如下：

操作开始前进行报文检查，没有发现语法错误。

没有找到<xmlns>元素，认为非命名空间查询后。

将filter第一个子节点interface与数据模型根节点netconf匹配。由于名字不同，匹配失败。

由于是非绝对路径，因此在netconf节点的后代中寻找到与interface匹配的节点：<if:interface name＝″Ethternet1″ip＝″59.64.139.65″\>与<iffinterfacename＝″Ethternet2″ip＝″59.64.139.69″\>。

查找匹配节点时，涉及到属性的逻辑关系组合过滤条件。name＝″Ethternet1″ip＝″59.64.139.65″_attrLogic＝″(name＾ip)‖(！name＾!ip)″表示，过滤结果中interface节点要么name和ip均满足给定条件，要么均不满足。匹配中，对于数据模型节点<if:interface name＝″Ethternet1″ip＝″59.64.139.65″>，name属性条件满足，ip属性条件也满足。则_attrLogic引出的表达式的匹配结果为：(true＾true)‖(false＾false)＝true，即该数据模型节点满足属性的逻辑关系过滤条件。类似的，routing下另一个interface节点同样满足。

查找匹配节点时，涉及到命名空间的模糊匹配。urn:bupt:pris:priser:agent:module:interface:1.0含有interface字符串，能够匹配。

由于<if:interface name＝″Ethternet″ip＝″59.64.139.65″>节点和过滤器中的interface节点匹配，则处理该节点的子节点，这些子节点是兄弟节点，同时进行处理。

过滤器interface节点下只有<_>节点，且没有属性限制条件，匹配任何命名空间包含interface字符串的元素节点。故而name、mac-address、ipv4节点均符合过滤条件。

<_>节点带有_count属性值为true，统计与<_>节点匹配的数据模型节点个数为3。从而实现统计interface子节点个数的功能。

则过滤器子树：

  <if:interface name＝″Ethternet1″ip＝″59.64.139.65″_attrLogic＝″(name＾ip)

‖(!name＾!ip)″xmlns:if＝＂*interface*″/>

     <_count＝true/>

  </if:interface>

得到的过滤结果为：

<if:interface name＝″Ethternet1″ip＝″59.64.139.65″>

  <_countNum>3<_countNum>

</if:interface>

<if:interface name＝″Ethternet2″ip＝″59.64.139.69″>

  <_countNum>3<_countNum>

</if:interface>

将匹配节点和其祖先复制到过滤结果中。

处理过滤器中interface的兄弟节点monitor。

数据模型中monitor的命名空间urn:bupt:pris:priser:agent:module:interface:1.0包含monitor：1.0字符串在末尾。无其他匹配条件，mt:monitor节点匹配。

处理过滤器monitor节点的子节点configuration。数据模型中configuration元素的命名空间有两种：urn:bupt:pris:priser:agent:module:monitor:1.0、um:bupt:pris:priser:agent:module:interface:1.0，要么匹配mt代表的*monitor:1.0，要么符合if代表的*interface*，数据模型中四个同父configuration节点均匹配。

则过滤器子树：

<mt:monitor xmlns:mt＝″*monitor:1.0″>

  <configuration_nsLogic＝″if‖mt″_order＝″asc″/>

</mt:monitor>

得到的过滤结果为：

<mt:monitor>

   <mt:configuration>running-state</mt:configuration>

   <mt:configuration>startup-config</mt:configuration>

   <mt:configuration>running-config</mt:configuration>

      <if:configuration>http://pris.bupt.cn/example/</if:configuration>

</mt:monitor>

将匹配节点和其祖先复制到过滤结果中。

过滤器中节点匹配完毕，得到初始过滤结果：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:mt＝″um:bupt:pris:priser:agent:module:monitor:1.0″

     xmlns:if＝″um:bupt:pris:priser:agent:module:interface:1.0″>

  <routing>

     <if:interface name＝″Ethternet1″ip＝″59.64.139.65″>

         <_countNum>3<_countNum>

     </if:interface>

     <if:interface name＝″Ethternet2″ip＝″59.64.139.69″>

         <_countNum>3<_countNum>

     </if:interface>

  </routing>

  <mt:monitor>

     <mt:configuration>running-state</mt:configuration>

     <mt:configuration>startup-config</mt:configuration>

     <mt:configuration>running-config</mt:configuration>

        <if:configuration>http://pris.bupt.cn/example/</if:configuration>

  </mt:monitor>

</netconf>

对过滤器中configuration节点得到的过滤结果进行排序。文本内容不为空，按升序排列。则monitor子树变为：

<mt:monitor>

 <if:configuration>http://pris.bupt.cn/example/</if:configuration>

 <mt:configuration>running-config</mt:configuration>

 <mt:configuration>running-state</mt:configuration>

 <mt:configuration>startup-config</mt:configuration>

</mt:monitor>

将排序后的过滤结果交给控制模块，返回给上级操作。

最终得到的过滤结果为例55：例54的过滤结果：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:mt＝″urn:bupt:pris:priser:agent:module:monitor:1.0″

     xmlns:if＝″um:bupt:pris:priser:agent:module:interface:1.0″>

  <routing>

     <if:interface name＝″Ethternet1″ip＝″59.64.139.65″>

         <_countNum>3<_countNum>

     </if:interface>

     <if:interface name＝″Ethternet2″ip＝″59.64.139.69″>

         <_countNum>3<_countNum>

     </if:interface>

  </routing>

  <mt:monitor>

     <if:configuration>http://pris.bupt.cn/example/</if:configuration>

     <mt:configuration>running-config</mt:configuration>

     <mt:configuration>running-state</mt:configuration>

     <mt:configuration>startup-config</mt:configuration>

  </mt:monitor>

</netconf>

现对如例53中定义的数据模型进行查询，过滤器定义如下例56实施例过滤器定义：

<filter type＝”advancedSubtree”_nodepath＝”relative”>

  <_xmlns>

     <interface>

         <received_morethan＝”12”_lessthan＝”25”_matchType＝”may”/>

         <received_morethan＝”42”_lessthan＝”55”_matchType＝”may”/>

     </interface>

  </_xmlns>

</filter>

过滤器定义的主要方法如下：

过滤控制模块解析设置过滤类型”advancedSubtree”和相关参数_nodepath＝”relative”。

经过报文语法检查后，进行扩展子树过滤操作。

检查到filter有唯一根节点_xmlns，下面进行命名空间查询，如图5所示。

得到命名空间查询所用子树

<interface>

   <received_morethan＝”12”_lessthan＝”25”_matchType＝”may”/>

   <received_morethan＝”42”_lessthan＝”55”_matchType＝”may”/>

</interface>

以此进行如图6中的正常扩展子树过滤，但是取消命名空间匹配机制。将filter第一个子节点interface与数据模型根节点netconf匹配。由于名字不同，匹配失败。

由于是非绝对路径，因此在netconf节点的后代中寻找到与interface匹配的节点：<if:interface name＝″Ethternet1″ip＝″59.64.139.65″/>与<if:interfacename＝″Ethternet2″ip＝″59.64.139.69″/>。

对于<if:interface name＝″Ethternet1″ip＝″59.64.139.65″/>继续匹配下一层兄弟节点<received_morethan＝”12”_lessthan＝”25”/>和<if:name/>、<if:mac-address/>、<if:ipv4>。均不匹配

由于是非绝对路径，因此在interface节点的后代中寻找到与received匹配的节点：<if:received>19</if:received>。

匹配涉及到数量范围条件和节点逻辑关系，对于数据模型节点<if:received>19</if:received>和过滤器内容匹配节点<received_morethan＝”12”_lessthan＝”25”_matchType＝”may”/>，_morethan、_lessthan给出的范围条件均符合。由于节点匹配方式是may，则即使其祖先节点<if:interface name＝″Ethternet1″ip＝″59.64.139.65″/>的后代received节点的值仅满足过滤器中两个received节点条件之一，但该interface节点仍然是匹配的。

数据模型节点<if:interface name＝″Ethternet2″ip＝″59.64.139.69″/>具有后代节点received，其值大于42、小于55，和过滤器节点interface也是匹配的。

将匹配节点及其祖先复制到初始过滤结果中：

<netconfxmlns＝″urn:ietf:params:xml:ns:netconf:base:1.0″

     xmlns:mt＝″urn:bupt:pris:priser:agent:module:monitor:1.0″

     xmlns:if＝″urn:bupt:pris:priser:agent:module:interface:1.0″>

  <routing>

     <if:interface name＝″Ethternet1″ip＝″59.64.139.65″>

         ……

         <if:ipv4>

             ……

             <if:received>19</if:received>

         </if:ipv4>

     </if:interface>

     <if:interfacename＝＂Ethternet2＂ip＝＂59.64.139.69＂>

         ……

         <if:ipv4>

             ……

             <if:received>49</if:received>

          </if:ipv4>

      </if:interface>

  </routing>

</netconf>

在结果处理模块中检索初始过滤结果各元素的命名空间，得到隐式命名空间um:ietf:params:xml:ns:netconf:base:1.0及带有前缀为if的命名空间um:bupt:pris:priser:agent:module:interface：1.0，封装为最后的过滤结果为例57：例56的过滤结果：

<data>

 <_xmlns>urn:ietf:params:xml:ns:netconf:base:1.0</_xmlns>

 <_xmlns prf＝”if”>um:bupt:pris:priser:agent:module:interface:1.0</_xmlns>

</data>

本发明实施例二为一种基于子树过滤的模糊查询方法，如图8所示，包括：

步骤s801，接收待过滤数据流；

步骤s802，通过不完全匹配的方式过滤数据流，处理用户没有给出完全信息的字符串形式的过滤条件。

所述字符串包括：节点名字、节点内容、属性名字、属性值或命名空间；所述不完全匹配的方式包括：路径不完整；元素名不完整、元素值不完整、属性名不完整、属性值不完整、命名空间不完整。

上述通过不完全匹配的方式过滤数据流，具体为：

通过绝对路径过滤数据流；或通过相对路径过滤数据流。

通过绝对路径过滤数据流具体为：用户给出的过滤器包含被选择节点的必须给出从根节点开始的所有祖先，过滤结果中只包含在过滤器中的祖先和在数据模型中的祖先完全一致的节点及节点后代；

通过相对路径过滤的数据流具体为：

在过滤器中满足父子关系的节点在过滤结果中至少满足祖先后代关系；在过滤器中为根节点的节点在过滤结果中至少包括非根节点。

当出现节点的命名空间不匹配时，继续处理前述节点的子节点，保留命名空间不匹配的元素作为其后代节点的路径。

本发明实施例增加子树过滤中命名空间的查询功能，帮助用户快速了解XML文档中数据分布的结构；弥补了NETCONF协议子树过滤中必须给出命名空间条件，但又不提供完整手段实现命名空间查询的缺陷。

本发明实施例处理对某些数据的特殊查询需求，比如时间、日期、数量等的范围查询、数据的数量查询等等。使子树过滤更能满足实际网络管理或其他实际应用中的需求。

本发明实施例实现对过滤结果的优化，实现对相同或类似数据的合并或排序；在需要时，丢弃无用的后代节点，大大减少了子树过滤结果可能存在的大量冗余信息。

本发明实施例三为一种子树过滤条件的逻辑组合的扩展方法，如图9所示，包括：

步骤s901，接收待过滤数据流；

步骤s902，采用多个属性或多个内容匹配节点对该数据流中的元素类型节点进行过滤。

步骤s902中多个内容匹配节点对数据流中的元素类型节点进行过滤，具体为：

使用内容匹配节点作为从数据模型中选择特定的父节点的过滤条件；

通过在所述内容匹配节点中添加第一属性表示所述节点的匹配程度，匹配程度包括必须匹配、可选匹配和不匹配；

根据所述内容匹配节点和所述匹配程度对所述数据流中的节点进行过滤。

根据所述内容匹配节点和所述匹配程度对所述数据流中的节点进行过滤，具体为：

过滤器中所有匹配程度是必须匹配的内容匹配节点都与数据模型中相应的节点完全匹配时，其父节点才可以被添加到过滤结果中；

过滤器中可选匹配程度是可选匹配的内容匹配节点中至少有一个节点与数据模型中相应的节点完全匹配时，其父节点才可以被添加到过滤结果中；

过滤器中匹配程度不匹配的内容匹配节点与数据模型中相应的节点完全匹配时，其父节点不被添加到过滤结果中。

通过向节点中添加第二属性，实现该节点的多个属性间的逻辑关系，该第二属性为_attrLogic属性。

上述多个内容匹配节点对数据流中的元素类型节点进行过滤的过程中还包括：进行命名空间查询，进行命名空间查询具体为：

获取数据模型中命名空间的定义情况，并给出命名空间的列表，其中，命名空间查询的关键字用一个元素表示。

上述多个内容匹配节点对数据流中的元素类型节点进行过滤的步骤中，过滤条件中还包括范围条件，该范围条件用于选择具有某些特定数值或者日期范围的节点，在表示数量或时间的选择节点中添加表示属性范围或时间范围的属性，将该选择节点看作是表示时间或数量范围的内容匹配节点，在过滤处理时作为过滤条件。

本发明实施例增加子树过滤中命名空间的查询功能，帮助用户快速的了解XML文档中数据分布的结构；弥补了NETCONF协议子树过滤中必须给出命名空间条件，但又不提供完整手段实现命名空间查询的缺陷。

本发明实施例处理对某些数据的特殊查询需求，比如时间、日期、数量等的范围查询、数据的数量查询等等。使子树过滤更能满足实际网络管理或其他实际应用中的需求。

本发明实施例实现对过滤结果的优化，实现对相同或类似数据的合并或排序；在需要时，丢弃无用的后代节点，大大减少了子树过滤结果可能存在的大量冗余信息。

本发明实施例四为一种子树过滤查询结果的处理方法，如图10所示，包括：

步骤s1001，在过滤器中相应节点处设置第三属性的值，表明该节点处是否显示节点后代，该第三属性为_show属性；

步骤s1002，该第三属性的取值为：第一值或者第二值，第一值为self值，第二值为descendant值，当该第三属性默认为显示所有在同一命名空间的后代，则第三属性＝第二值；当设置第三属性＝第一值，则过滤结果只输出该节点的信息，不输出在同一命名空间的后代节点。

该处理方法还包括：

通过在过滤器中某元素节点中使用第四属性实现个数查询，统计数据模型中某一类元素的个数，通过在过滤器中某元素节点中使用第四属性实现个数查询，统计同一过滤器节点对应的元素个数。该第四属性为_count属性。

该第四属性的取值有两个：第一值或第二值，该第一值为true，第二值为false，当设置第四属性值为第一值时，则过滤结果输出查询实体的个数；当设置第四属性为第二值时，则过滤结果不输出查询实体的个数。

该处理方法还包括：

对同一个过滤器节点得到的过滤结果按照需要进行排序，合并查询结果中内容完全相同的节点。

该处理方法还包括：

当所有需要匹配的节点没有匹配数据模型节点，全部被舍弃时，不返回上述节点的父节点。

本发明实施例增加子树过滤中命名空间的查询功能，帮助用户快速的了解XML文档中数据分布的结构；弥补了NETCONF协议子树过滤中必须给出命名空间条件，但又不提供完整手段实现命名空间查询的缺陷。

本发明实施例处理对某些数据的特殊查询需求，比如时间、日期、数量等的范围查询、数据的数量查询等等。使子树过滤更能满足实际网络管理或其他实际应用中的需求。

本发明实施例实现对过滤结果的优化，实现对相同或类似数据的合并或排序；在需要时，丢弃无用的后代节点，大大减少了子树过滤结果可能存在的大量冗余信息。

本发明实施例五为一种过滤器，如图11所示，包括：

接收模块1110，用于接收待过滤数据流；

过滤模块1120，用于通过不完全匹配的方式过滤该数据流，处理用户没有给出完全信息的字符串形式的过滤条件。

过滤模块1120包括：

第一过滤子模块1121，用于通过绝对路径过滤该数据流；和/或，

第二过滤子模块1122，用于通过相对路径过滤所述数据流。

本发明实施例增加子树过滤中命名空间的查询功能，帮助用户快速的了解XML文档中数据分布的结构；弥补了NETCONF协议子树过滤中必须给出命名空间条件，但又不提供完整手段实现命名空间查询的缺陷。

本发明实施例处理对某些数据的特殊查询需求，比如时间、日期、数量等的范围查询、数据的数量查询等等。使子树过滤更能满足实际网络管理或其他实际应用中的需求。

本发明实施例实现对过滤结果的优化，实现对相同或类似数据的合并或排序；在需要时，丢弃无用的后代节点，大大减少了子树过滤结果可能存在的大量冗余信息。

本发明实施例六为一种逻辑过滤装置，如图12所示，包括：

接收模块1210，用于接收待过滤数据流；

逻辑过滤模块1220，用于采用多个属性或多个内容匹配节点对该数据流中的元素类型节点进行过滤。

逻辑过滤模块1220包括：

设置子模块1221，用于设置内容匹配节点作为从数据模型中选择特定的父节点的过滤条件；

添加子模块1222，用于通过在该内容匹配节点中添加第一属性表示该节点的匹配程度，并实现该节点过滤条件之间的逻辑关系组合；

处理子模块1223，用于根据该过滤条件之间的逻辑关系组合对该数据流中的元素类型节点进行过滤。

本发明实施例增加子树过滤中命名空间的查询功能，帮助用户快速的了解XML文档中数据分布的结构；弥补了NETCONF协议子树过滤中必须给出命名空间条件，但又不提供完整手段实现命名空间查询的缺陷。

本发明实施例处理对某些数据的特殊查询需求，比如时间、日期、数量等的范围查询、数据的数量查询等等。使子树过滤更能满足实际网络管理或其他实际应用中的需求。

本发明实施例实现对过滤结果的优化，实现对相同或类似数据的合并或排序；在需要时，丢弃无用的后代节点，大大减少了子树过滤结果可能存在的大量冗余信息。

本发明实施例七为一种子树过滤查询结果处理装置，如图13所示，包括：

设置模块1310，用于在过滤器中相应节点处设置第三属性的值，该第三属性为_show属性；

确定模块1320，用于根据设置模块1310设置第三属性的值，表明所述节点处是否显示节点后代。

该处理装置还包括：

排序模块1330，用于对同一个过滤器节点得到的过滤结果按照需要进行排序，

节点合并模块1340，用于合并查询结果中内容完全相同的节点。

综上，可以看到本发明可以实现以下NETCONF协议中子树过滤机制无法实现或实现效果不好或处理方法有缺陷的功能，如表2所示：

表2扩展子树过滤机制实现附加功能

由表中可以看到：

本发明实施例提供一种基于NETCONF子树过滤机制，以XML形式表达的，对XML网络管理数据进行查询和过滤的方法，使对NETCONF协议中管理信息的获取更为方便，也避免了为数据查询和过滤重新定义一套规范带来的诸多问题。

本发明实施例提供了一种对XML数据过滤条件的细化和组合机制。XML文档中的节点有时包含了具体的数据信息，类似于关系数据库中一个字段；有时候只是封装数据信息的手段，类似于关系数据库中的一条记录。本发明中细化了节点的匹配程度，用户可以根据节点在数据存储中的具体作用选择相应的查询方法。另外，属性、命名空间方式表达的过滤条件可以以逻辑运算方式组合到一起，使查询更为灵活。

本发明实施例提供一种在过滤条件不完整的情况下，比如不能完整拼写出数据存储的节点或属性名字，或者不能完全给出数据在XML文档中定义的位置，仍可以对XML数据进行子树过滤操作，并得到用户想要的结果。

本发明实施例增加子树过滤中命名空间的查询功能，帮助用户快速的了解XML文档中数据分布的结构；弥补了NETCONF协议子树过滤中必须给出命名空间条件，但又不提供完整手段实现命名空间查询的缺陷。

本发明实施例处理对某些数据的特殊查询需求，比如时间、日期、数量等的范围查询、数据的数量查询等等。使子树过滤更能满足实际网络管理或其他实际应用中的需求。

本发明实施例实现对过滤结果的优化，实现对相同或类似数据的合并或排序；在需要的时候，丢弃无用的后代节点。大大减少了子树过滤结果可能存在的大量冗余信息。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现基于这样的理解，本发明的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种基于子树过滤的模糊查询方法，其特征在于，包括：

接收待过滤数据流；

通过不完全匹配的方式过滤所述数据流，处理用户没有给出完全信息的字符串形式的过滤条件；

其中，当出现节点的命名空间不匹配时，继续处理所述节点的子节点，保留命名空间不匹配的元素作为其后代节点的路径；

所述通过不完全匹配的方式过滤所述数据流为：

通过绝对路径过滤所述数据流；或通过相对路径过滤所述数据流；

所述通过绝对路径过滤所述数据流具体为：用户给出的过滤器包含被选择节点的从根节点开始的所有祖先，过滤结果中只包含在过滤器中的祖先和在数据模型中的祖先完全一致的节点及节点后代；

所述通过相对路径过滤所述数据流具体为：

在过滤器中满足父子关系的节点在过滤结果中至少满足祖先后代关系；在过滤器中为根节点的节点在过滤结果中至少包括非根节点。

2.如权利要求1所述的方法，其特征在于，所述字符串包括：节点名字、节点内容、属性名字、属性值或命名空间。

3.如权利要求1所述的方法，其特征在于，所述不完全匹配的方式包括：路径不完整和/或元素名不完整和/或元素值不完整和/或属性名不完整和/或属性值不完整和/或命名空间不完整。

4.一种子树过滤条件的逻辑组合的扩展方法，其特征在于，包括：

接收待过滤数据流；

采用多个属性或多个内容匹配节点对所述数据流中的元素类型节点进行过滤；

所述多个内容匹配节点对所述数据流中的元素类型节点进行过滤，具体为：

使用内容匹配节点作为从数据模型中选择特定的父节点的过滤条件；

通过在所述内容匹配节点中添加第一属性表示所述节点的匹配程度，匹配程度包括必须匹配、可选匹配和不匹配；

根据所述内容匹配节点和所述匹配程度对所述数据流中的节点进行过滤；

其中，根据所述内容匹配节点和所述匹配程度对所述数据流中的节点进行过滤，具体为：

过滤器中所有匹配程度是必须匹配的内容匹配节点都与数据模型中相应的节点完全匹配时，其父节点才可以被添加到过滤结果中；

过滤器中可选匹配程度是可选匹配的内容匹配节点中至少有一个节点与数据模型中相应的节点完全匹配时，其父节点才可以被添加到过滤结果中；

过滤器中匹配程度不匹配的内容匹配节点与数据模型中相应的节点完全匹配时，其父节点不被添加到过滤结果中。

5.如权利要求4所述的方法，其特征在于，还包括：

向节点中添加第二属性，以实现所述节点的多个属性间的逻辑关系。

6.如权利要求4所述的方法，其特征在于，还包括：进行命名空间查询：

获取数据模型中命名空间的定义情况，并给出命名空间的列表，其中，命名空间查询的关键字用一个元素表示。

7.如权利要求4所述的方法，其特征在于，过滤条件中还包括范围条件：

所述范围条件用于选择具有某些特定数值或者日期范围的节点，在表示数量或时间的选择节点中添加表示属性范围或时间范围的属性，将该选择节点看作是表示时间或数量范围的内容匹配节点，在过滤处理时作为过滤条件。

8.一种过滤器，其特征在于，包括：

接收模块，用于接收待过滤数据流；

过滤模块，用于通过不完全匹配的方式过滤所述数据流，处理用户没有给出完全信息的字符串形式的过滤条件，其中，当出现节点的命名空间不匹配时，继续处理所述节点的子节点，保留命名空间不匹配的元素作为其后代节点的路径；

所述通过不完全匹配的方式过滤所述数据流为：

通过绝对路径过滤所述数据流；或通过相对路径过滤所述数据流；

所述通过绝对路径过滤所述数据流具体为：用户给出的过滤器包含被选择节点的从根节点开始的所有祖先，过滤结果中只包含在过滤器中的祖先和在数据模型中的祖先完全一致的节点及节点后代；

所述通过相对路径过滤所述数据流具体为：

在过滤器中满足父子关系的节点在过滤结果中至少满足祖先后代关系；在过滤器中为根节点的节点在过滤结果中至少包括非根节点。

9.如权利要求8所述过滤器，其特征在于，所述过滤模块包括：

第一过滤子模块，用于通过绝对路径过滤所述数据流；或者，

第二过滤子模块，用于通过相对路径过滤所述数据流。

10.一种逻辑过滤装置，其特征在于，包括：

接收模块，用于接收待过滤数据流；

逻辑过滤模块，用于采用多个属性或多个内容匹配节点对所述数据流中的元素类型节点进行过滤；

所述逻辑过滤模块包括：

设置子模块，用于设置内容匹配节点作为从数据模型中选择特定的父节点的过滤条件；

添加子模块，用于通过在所述内容匹配节点中添加第一属性表示所述节点的匹配程度，并实现所述节点过滤条件之间的逻辑关系组合；

处理子模块，用于根据所述过滤条件之间的逻辑关系组合对所述数据流中的元素类型节点进行过滤；

其中，根据所述内容匹配节点和所述匹配程度对所述数据流中的节点进行过滤，具体为：

过滤器中所有匹配程度是必须匹配的内容匹配节点都与数据模型中相应的节点完全匹配时，其父节点才可以被添加到过滤结果中；

过滤器中可选匹配程度是可选匹配的内容匹配节点中至少有一个节点与数据模型中相应的节点完全匹配时，其父节点才可以被添加到过滤结果中；

过滤器中匹配程度不匹配的内容匹配节点与数据模型中相应的节点完全匹配时，其父节点不被添加到过滤结果中。

Images