Fix submodule docs links

[docs.git] / docs / developer-guide / yang-tools.rst

diff --git a/docs/developer-guide/yang-tools.rst b/docs/developer-guide/yang-tools.rst
index 9486121c587e53c3e68c7d4f44314948773a5823..fede7d9b1b6abacad97b1ccf0637eee28b81bc29 100644 (file)
--- a/docs/developer-guide/yang-tools.rst
+++ b/docs/developer-guide/yang-tools.rst
@@ -1,3 +1,5 @@
+.. _yangtools-developer-guide:
+
 YANG Tools Developer Guide
 ==========================
 
@@ -282,30 +284,27 @@ work.
 Mode with active resolution of if-features makes yang statements
 containing an if-feature statement conditional based on the supported
 features. These features are provided in the form of a QName-based
-java.util.function.Predicate object. In the example below, only two
+java.util.Set object. In the example below, only two
 features are supported: example-feature-1 and example-feature-2. The
-Predicate which contains this information is passed to the method
+Set which contains this information is passed to the method
 newBuild() and the mode is activated.
 
 .. code:: java
 
-    Predicate<QName> isFeatureSupported == qName -> {
-        Set<QName> supportedFeatures == new HashSet<>();
-        supportedFeatures.add(QName.create("example-namespace", "2016-08-31", "example-feature-1"));
-        supportedFeatures.add(QName.create("example-namespace", "2016-08-31", "example-feature-2"));
-        return supportedFeatures.contains(qName);
-    }
+    Set<QName> supportedFeatures = ImmutableSet.of(
+        QName.create("example-namespace", "2016-08-31", "example-feature-1"),
+        QName.create("example-namespace", "2016-08-31", "example-feature-2"));
 
-    CrossSourceStatementReactor.BuildAction reactor == YangInferencePipeline.RFC6020_REACTOR.newBuild(isFeatureSupported);
+    CrossSourceStatementReactor.BuildAction reactor = YangInferencePipeline.RFC6020_REACTOR.newBuild(supportedFeatures);
 
-In case when no features should be supported, you should provide a
-Predicate<QName> object whose test() method just returns false.
+In case when no features should be supported, you should provide an
+empty Set<QName> object.
 
 .. code:: java
 
-    Predicate<QName> isFeatureSupported == qName -> false;
+    Set<QName> supportedFeatures = ImmutableSet.of();
 
-    CrossSourceStatementReactor.BuildAction reactor == YangInferencePipeline.RFC6020_REACTOR.newBuild(isFeatureSupported);
+    CrossSourceStatementReactor.BuildAction reactor = YangInferencePipeline.RFC6020_REACTOR.newBuild(supportedFeatures);
 
 When this mode is not activated, all features in the processed YANG
 sources are supported.
@@ -325,7 +324,7 @@ Before you use a semantic version statement in a YANG module, you need
 to define an extension for it so that the YANG statement parser can
 recognize it.
 
-.. code:: yang
+.. code::
 
     module semantic-version {
         namespace "urn:opendaylight:yang:extension:semantic-version";
@@ -353,7 +352,7 @@ semantic version processing mode being active, the foo module imports
 the bar module based on its semantic version. Notice how both modules
 import the module with the semantic-version extension.
 
-.. code:: yang
+.. code::
 
     module foo {
         namespace foo;
@@ -371,7 +370,7 @@ import the module with the semantic-version extension.
         ...
     }
 
-.. code:: yang
+.. code::
 
     module bar {
         namespace bar;
@@ -501,7 +500,7 @@ Below is an example which shows the use of this method.
 Let us show a more complex example of creating a NormalizedNode. First,
 consider the following YANG module:
 
-.. code:: yang
+.. code::
 
     module example-module {
         namespace "opendaylight.org/example-module";
@@ -712,4 +711,3 @@ Introducing specific extension support for YANG parser
 
 Diagnostics
 ~~~~~~~~~~~
-