5  XPath Reference

The XPath 1.0 path specification language is supported in all YumaPro Tools programs, as specified in the YANG language specification.  There are also some additional variables and XPath functions, available in all XPath expressions.

A custom XPath implementation is used, which is based on the internal data structures maintained within the program (i.e., object tree or data tree).  No CPU or memory is wasted converting these data structures to actual XML documents for XPath processing.

5.1  XPath 1.0

All functionality defined in the XPath 1.0 specification is supported.

There are some restrictions, which are specific to the YANG standard:

5.1.1  XML Namespaces

The XPath implementation allows a more liberal syntax than the XPath 1.0 specification allows.

Specifically, if a node identifier does is unqualified (i.e., there is no namespace specified with a default namespace or an explicit namespace declaration), then all known XML namespaces known by the program will be checked for a top-level element with the same name.

 

 

Example request using XML namespaces in an XPath expression:

 

 

<?xml version="1.0" encoding="UTF-8"?>

<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"

   message-id="2"  

   xmlns:sys="http://netconfcentral.org/ns/yuma-system">

   <nc:get>

      <nc:filter type="xpath" select="/sys:system"/>

   </nc:get>

</nc:rpc>

 

 

Note the text:

 

xmlns:sys="http://netconfcentral.org/ns/yuma-system"

 

 

This 'xmlns' attribute does not have to appear exactly as specified, or within the <rpc> element.  It can appear in any legal manner.  Refer to the XML Namespaces 1.0 specification for more details.

 

Example request not using XML namespaces in an XPath expression:

 

 

<?xml version="1.0" encoding="UTF-8"?>

<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"

   message-id="3">

   <nc:get>

      <nc:filter type="xpath" select="/system"/>

   </nc:get>

</nc:rpc>

 

 

If the 'yuma-system.yang' module is loaded within the program, and if the 'system' node is enabled (e.g., not removed via a YANG deviation), then the XML prefix ('sys:' in this example) can be omitted.

5.2  YANG Specific XPath Behavior

The YANG language requires some minor changes and additions to the XPath 1.0 specification:

5.3  Custom XPath Variables

The XPath specification supports system variables to be accessed within XPath expressions.

Within the yangcli-pro program, all user and system variables available to a script are also available as XPath variables within XPath expression evaluation (e.g., if, eval, and while commands).

For example, a variable named 'myvar' would be accessed within an XPath expression as '$myvar'.

 

5.3.1  user

An XPath variable called 'user' is supported in the yangcli-pro and netconfd-pro programs.  It is equal to the NETCONF user name associated with the session evaluating the XPath expression. It is provided to be used in data rules within the NETCONF Access Control Model (NACM).

 

5.4  Custom XPath Functions

The following XPath functions are added to the XPath 1.0 Function Library, in addition to the 'current' function from XPath 2.0.

5.4.1  module-loaded

The module-loaded function tests whether the specified module is loaded within the program.

boolean module-loaded (module-name [, revision-date])

Parameters:

Returns: Boolean

Errors:

Example:

 

yangcli-pro> if "module-loaded('yuma-system', '2009-12-27')"

yangcli-pro>    log-info 'correct yuma-system module loaded'

yangcli-pro> else

yangcli-pro>    log-error 'Wrong yuma-system module loaded'

yangcli-pro> end

 

 

 

5.4.2  feature-enabled

The feature-enabled function tests whether the specified YANG feature is enabled within the program.

boolean feature-enabled (module-name, feature-name)

Parameters:

Returns: Boolean

Errors:

Example:

 

 

yangcli-pro> if "feature-enabled('mymodule', 'myfeature')"

yangcli-pro>    log-info 'myfeature is enabled'

yangcli-pro> else

yangcli-pro>    log-error 'myfeature is not enabled'

yangcli-pro> end