The result of XPath filtering could be different from Subtree filtering in some cases. In this article, there will be examples in which this difference can be illustrated.


Subtree Filtering

Conceptually, a Subtree filter is comprised of zero or more element subtrees, which represent the filter selection criteria. At each containment level within a subtree, the set of sibling nodes is logically processed by the server to determine if its subtree and path of elements to the root are included in the filter output.


Response messages contain only the subtrees selected by the filter. Any selection criteria that were present in the request, within a particular selected subtree, are also included in the response.


XPath Filtering


The XPath expression MUST return a node set. The response message contains the subtrees selected by the filter expression. For each such subtree, the path from the data model root node down to the subtree, including any elements or attributes necessary to uniquely identify the subtree, are included in the response message. Specific data instances are not duplicated in the response.



Example


The following YANG module will be used in the example:


module example {
  namespace "http://netconfcentral.org/ns/example";
  prefix "ex";

  revision "2022-01-11" {
      description
        "Initial Version.";
  }

  container sample_container {

    list sn_list {
      key "name";

      leaf name {
          type string;
      }

      leaf num23 {
        type uint32;
      }

      leaf loopback-type {
        type enumeration {
          enum port;
          enum ds;
        }
      }
    }
  }
}

The running datastore contains the following values:


    <config>
        <sample_container xmlns="http://netconfcentral.org/ns/example">
            <sn_list>
                <name>pp</name>
                <num23>123</num23>
            </sn_list>
        </sample_container>
    </config>


XPath Request


The following XPath filter request will produce an empty output since the loopback-type context-node does not match the XPath filter:


yangcli-pro> xget-config /sample_container/sn_list[name="pp"]/loopback-type


This yangcli-pro command will produce the following <get-config> request that will be send to the server.


<get-config>
    <filter type="xpath" select="/sample_container/sn_list[name='pp']/loopback-type"/>
</get-config>

As a result of this <get-config> request the serer returns an empty output.


<output xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data></data>
</output>


Subtree Request


For Subtree filter the result will be different. The following request will return an output:


yangcli-pro> sget-config /sample_container/sn_list[name="pp"]/loopback-type


This yangcli-pro command will produce the following <get-config> request that will be send to the server.


<get-config>
  <filter type="subtree">
    <sample_container xmlns="http://netconfcentral.org/ns/example">
      <sn_list>
        <name>pp</name>   <!-- content-match node; the server matches this node -->
        <loopback-type/>  <!-- Selection node; may have no match -->
      </sn_list>
    </sample_container>
  </filter>
  <source><running/></source>
</get-config>

The request may look as follows:


<output xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data>
        <sample_container xmlns="http://netconfcentral.org/ns/example">
            <sn_list>
                <name>pp</name>
            </sn_list>
        </sample_container>
    </data>
</output>

The server produces output because of the following statement from the RFC, a matching content-match node is supposed to be returned. The server MAY return keys as well (as the server currently does):


 If all specified sibling content match nodes in a subtree filter
   expression are "true", then the filter output nodes are selected in
   the following manner:

   o  Each content match node in the sibling set is included in the
      filter output.

   o  If any containment nodes are present in the sibling set, then they
      are processed further and included if any nested filter criteria
      are also met.

   o  If any selection nodes are present in the sibling set, then all of
      them are included in the filter output.


In 20.10 release the behavior of the server was changed because of this specific statement in the RFC