BUG-6497: Do not lose augmentation statement order
[yangtools.git] / docs / src / main / asciidoc / developer / introduction.adoc
1 = Developer Guide
2 :rfc6020: https://tools.ietf.org/html/rfc6020
3 :lhotka-yang-json: https://tools.ietf.org/html/draft-lhotka-netmod-yang-json-01
4
5 == Overview
6 YANG Tools is set of libraries and tooling providing support for use {rfc6020}[YANG] for Java (or other JVM-based language) projects and applications.
7
8 YANG Tools provides following features in OpenDaylight:
9
10 - parsing of YANG sources and
11 semantic inference of relationship across YANG models as defined in
12 {rfc6020}[RFC6020]
13 - representation of YANG-modeled data in Java
14 ** *Normalized Node* representation - DOM-like tree model, which uses conceptual
15   meta-model more tailored to YANG and OpenDaylight use-cases than a standard XML
16   DOM model allows for.
17 - serialization / deserialization of YANG-modeled data driven by YANG
18 models
19 ** XML - as defined in {rfc6020}[RFC6020]
20 ** JSON - as defined in {rfc6020}[draft-lhotka-netmod-yang-json-01]
21 ** support for third-party generators processing YANG models.
22
23 === Architecture
24 YANG Tools project consists of following logical subsystems:
25
26 - *Commons* - Set of general purpose code, which is not specific to YANG, but
27   is also useful outside YANG Tools implementation.
28 - *YANG Model and Parser* - YANG semantic model and lexical and semantic parser
29   of YANG models, which creates in-memory cross-referenced represenation of
30   YANG models, which is used by other components to determine their behaviour
31   based on the model.
32 - *YANG Data* - Definition of Normalized Node APIs and Data Tree APIs, reference
33   implementation of these APIs and implementation of XML and JSON codecs for
34   Normalized Nodes.
35 - *YANG Maven Plugin* - Maven plugin which integrates YANG parser into Maven
36   build lifecycle and provides code-generation framework for components, which
37   wants to generate code or other artefacts based on YANG model.
38
39 === Concepts
40 Project defines base concepts and helper classes which are project-agnostic and could be used outside of YANG Tools project scope.
41
42 === Components
43
44 - yang-common
45 - yang-data-api
46 - yang-data-codec-gson
47 - yang-data-codec-xml
48 - yang-data-impl
49 - yang-data-jaxen
50 - yang-data-transform
51 - yang-data-util
52 - yang-maven-plugin
53 - yang-maven-plugin-it
54 - yang-maven-plugin-spi
55 - yang-model-api
56 - yang-model-export
57 - yang-model-util
58 - yang-parser-api
59 - yang-parser-impl
60
61 ==== YANG Model API
62 Class diagram of yang model API
63
64 image:models/yang-model-api.png[]
65
66 ==== YANG Parser
67
68 Yang Statement Parser works on the idea of statement concepts as defined in RFC6020, section 6.3. We come up here with basic ModelStatement and StatementDefinition, following RFC6020 idea of having sequence of statements, where
69 every statement contains keyword and zero or one argument. ModelStatement is extended by DeclaredStatement (as it comes from source, e.g. YANG source)
70 and EffectiveStatement, which contains other substatements and tends to represent result of semantic processing of other statements (uses, augment for YANG).
71 IdentifierNamespace represents common superclass for YANG model namespaces.
72
73 Input of the Yang Statement Parser is a collection of StatementStreamSource objects.
74 StatementStreamSource interface is used for inference of effective model
75 and is required to emit its statements using supplied StatementWriter.
76 Each source (e.g. YANG source) has to be processed in three steps
77 in order to emit different statements for each step.
78 This package provides support for various namespaces used across statement parser
79 in order to map relations during declaration phase process.
80
81 Currently, there are two implementations of StatementStreamSource in Yangtools:
82
83  - YangStatementSourceImpl - intended for yang sources
84  - YinStatementSourceImpl - intended for yin sources
85
86 ==== YANG Data API
87 Class diagram of yang data API
88
89 image:models/yang-data-api.png[]
90
91 ==== YANG Data Codecs
92 Codecs which enable serialization of NormalizedNodes into YANG-modeled data in XML or JSON format and deserialization of YANG-modeled data in XML or JSON format into NormalizedNodes.
93
94 ==== YANG Maven Plugin
95 Maven plugin which integrates YANG parser into Maven
96   build lifecycle and provides code-generation framework for components, which
97   wants to generate code or other artefacts based on YANG model.
98
99 == How to / Tutorials
100
101 === Working with YANG Model
102 First thing you need to do if you want to work with YANG models is to instantiate a SchemaContext object. This object type describes one or more parsed YANG modules.
103
104 In order to create it you need to utilize YANG statement parser which takes one or more StatementStreamSource objects as input and then produces the SchemaContext object.
105
106 StatementStreamSource object contains the source file information. It has two implementations, one for YANG sources - YangStatementSourceImpl, and one for YIN sources - YinStatementSourceImpl.
107
108 Here is an example of creating StatementStreamSource objects for YANG files, providing them to the YANG statement parser and building the SchemaContext:
109
110 [source,java]
111 ----
112 StatementStreamSource yangModuleSource = new YangStatementSourceImpl("/example.yang", false);
113 StatementStreamSource yangModuleSource2 = new YangStatementSourceImpl("/example2.yang", false);
114
115 CrossSourceStatementReactor.BuildAction reactor = YangInferencePipeline.RFC6020_REACTOR.newBuild();
116 reactor.addSources(yangModuleSource, yangModuleSource2);
117
118 SchemaContext schemaContext = reactor.buildEffective();
119 ----
120
121 First, StatementStreamSource objects with two constructor arguments should be instantiated: path to the yang source file (which is a regular String object) and a boolean which determines if the path is absolute or relative.
122
123 Next comes the initiation of new yang parsing cycle - which is represented by CrossSourceStatementReactor.BuildAction object. You can get it by calling method newBuild() on CrossSourceStatementReactor object (RFC6020_REACTOR) in YangInferencePipeline class.
124
125 Then you should feed yang sources to it by calling method addSources() that takes one or more StatementStreamSource objects as arguments.
126
127 Finally you call the method buildEffective() on the reactor object which returns EffectiveSchemaContext (that is a concrete implementation of SchemaContext). Now you are ready to work with contents of the added yang sources.
128
129 Let us explain how to work with models contained in the newly created SchemaContext. If you want to get all the modules in the schemaContext, you have to call method getModules() which returns a Set of modules. If you want to get all the data definitions in schemaContext, you need to call method getDataDefinitions, etc.
130
131 [source, java]
132 Set<Module> modules = schemaContext.getModules();
133 Set<DataSchemaNodes> dataSchemaNodes = schemaContext.getDataDefinitions();
134
135 Usually you want to access specific modules. Getting a concrete module from SchemaContext is a matter of calling one of these methods:
136
137 * findModuleByName(),
138 * findModuleByNamespace(),
139 * findModuleByNamespaceAndRevision().
140
141 In the first case, you need to provide module name as it is defined in the yang source file and module revision date if it specified in the yang source file (if it is not defined, you can just pass a null value). In order to provide the revision date in proper format, you can use a utility class named SimpleDateFormatUtil.
142
143 [source, java]
144 Module exampleModule = schemaContext.findModuleByName("example-module", null);
145 // or
146 Date revisionDate = SimpleDateFormatUtil.getRevisionFormat().parse("2015-09-02");
147 Module exampleModule = schemaContext.findModuleByName("example-module", revisionDate);
148
149 In the second case, you have to provide module namespace in form of an URI object.
150 [source, java]
151 Module exampleModule = schema.findModuleByNamespace(new URI("opendaylight.org/example-module"));
152
153 In the third case, you provide both module namespace and revision date as arguments.
154
155 Once you have a Module object, you can access its contents as they are defined in YANG Model API.
156 One way to do this is to use method like getIdentities() or getRpcs() which will give you a Set of objects. Otherwise you can access a DataSchemaNode directly via the method getDataChildByName() which takes a QName object as its only argument. Here are a few examples.
157
158 [source, java]
159 ----
160 Set<AugmentationSchema> augmentationSchemas = exampleModule.getAugmentations();
161 Set<ModuleImport> moduleImports = exampleModule.getImports();
162
163 ChoiceSchemaNode choiceSchemaNode = (ChoiceSchemaNode) exampleModule.getDataChildByName(QName.create(exampleModule.getQNameModule(), "example-choice"));
164
165 ContainerSchemaNode containerSchemaNode = (ContainerSchemaNode) exampleModule.getDataChildByName(QName.create(exampleModule.getQNameModule(), "example-container"));
166 ----
167
168 === Working with YANG Data
169 If you want to work with YANG Data you are going to need NormalizedNode objects that are specified in the YANG Data API. NormalizedNode is an interface at the top of the YANG Data hierarchy. It is extended through sub-interfaces which define the behaviour of specific NormalizedNode types like AnyXmlNode, ChoiceNode, LeafNode, ContainerNode, etc. Concrete implemenations of these interfaces are defined in yang-data-impl module. Once you have one or more NormalizedNode instances, you can perform CRUD operations on YANG data tree which is an in-memory database designed to store normalized nodes in a tree-like structure.
170
171 In some cases it is clear which NormalizedNode type belongs to which yang statement (e.g. AnyXmlNode, ChoiceNode, LeafNode). However, there are some normalized nodes which are named differently from their yang counterparts. They are listed below:
172
173 * LeafSetNode - leaf-list
174 * OrderedLeafSetNode - leaf-list that is ordered-by user
175 * LeafSetEntryNode - concrete entry in a leaf-list
176 * MapNode - keyed list
177 * OrderedMapNode - keyed list that is ordered-by user
178 * MapEntryNode - concrete entry in a keyed list
179 * UnkeyedListNode - unkeyed list
180 * UnkeyedListEntryNode - concrete entry in an unkeyed list
181
182 In order to create a concrete NormalizedNode object you can use the utility class Builders or ImmutableNodes. These classes can be found in yang-data-impl module and they provide methods for building each type of normalized node. Here is a simple example of building a normalized node:
183
184 [source, java]
185 ----
186 \\ example 1
187 ContainerNode containerNode = Builders.containerBuilder().withNodeIdentifier(new YangInstanceIdentifier.NodeIdentifier(QName.create(moduleQName, "example-container")).build();
188
189 \\ example 2
190 ContainerNode containerNode2 = Builders.containerBuilder(containerSchemaNode).build();
191 ----
192 Both examples produce the same result. NodeIdentifier is one of the four types of YangInstanceIdentifier (these types are described in the javadoc of YangInstanceIdentifier). The purpose of YangInstanceIdentifier is to uniquely identify a particular node in the data tree. In the first example, you have to add NodeIdentifier before building the resulting node. In the second example it is also added using the provided ContainerSchemaNode object.
193
194 ImmutableNodes class offers similar builder methods and also adds an overloaded method called fromInstanceId() which allows you to create a NormalizedNode object based on YangInstanceIdentifier and SchemaContext. Below is an example which shows the use of this method.
195
196 [source, java]
197 ----
198 YangInstanceIdentifier.NodeIdentifier contId = new YangInstanceIdentifier.NodeIdentifier(QName.create(moduleQName, "example-container");
199
200 NormalizedNode<?, ?> contNode = ImmutableNodes.fromInstanceId(schemaContext, YangInstanceIdentifier.create(contId));
201 ----
202
203 Let us show a more complex example of creating a NormalizedNode. First, consider the following YANG module:
204
205 [source, yang]
206 ----
207 module example-module {
208     namespace "opendaylight.org/example-module";
209     prefix "example";
210
211     container parent-container {
212         container child-container {
213             list parent-ordered-list {
214                 ordered-by user;
215
216                 key "parent-key-leaf";
217
218                 leaf parent-key-leaf {
219                     type string;
220                 }
221
222                 leaf parent-ordinary-leaf {
223                     type string;
224                 }
225
226                 list child-ordered-list {
227                     ordered-by user;
228
229                     key "child-key-leaf";
230
231                     leaf child-key-leaf {
232                         type string;
233                     }
234
235                     leaf child-ordinary-leaf {
236                         type string;
237                     }
238                 }
239             }
240         }
241     }
242 }
243 ----
244
245 In the following example, two normalized nodes based on the module above are written to and read from the data tree.
246
247 [source, java]
248 ----
249 TipProducingDataTree inMemoryDataTree =     InMemoryDataTreeFactory.getInstance().create(TreeType.OPERATIONAL);
250 inMemoryDataTree.setSchemaContext(schemaContext);
251
252 // first data tree modification
253 MapEntryNode parentOrderedListEntryNode = Builders.mapEntryBuilder().withNodeIdentifier(
254 new YangInstanceIdentifier.NodeIdentifierWithPredicates(
255 parentOrderedListQName, parentKeyLeafQName, "pkval1"))
256 .withChild(Builders.leafBuilder().withNodeIdentifier(
257 new YangInstanceIdentifier.NodeIdentifier(parentOrdinaryLeafQName))
258 .withValue("plfval1").build()).build();
259
260 OrderedMapNode parentOrderedListNode = Builders.orderedMapBuilder().withNodeIdentifier(
261 new YangInstanceIdentifier.NodeIdentifier(parentOrderedListQName))
262 .withChild(parentOrderedListEntryNode).build();
263
264 ContainerNode parentContainerNode = Builders.containerBuilder().withNodeIdentifier(
265 new YangInstanceIdentifier.NodeIdentifier(parentContainerQName))
266 .withChild(Builders.containerBuilder().withNodeIdentifier(
267 new NodeIdentifier(childContainerQName)).withChild(parentOrderedListNode).build()).build();
268
269 YangInstanceIdentifier path1 = YangInstanceIdentifier.of(parentContainerQName);
270
271 DataTreeModification treeModification = inMemoryDataTree.takeSnapshot().newModification();
272 treeModification.write(path1, parentContainerNode);
273
274 // second data tree modification
275 MapEntryNode childOrderedListEntryNode = Builders.mapEntryBuilder().withNodeIdentifier(
276 new YangInstanceIdentifier.NodeIdentifierWithPredicates(
277 childOrderedListQName, childKeyLeafQName, "chkval1"))
278 .withChild(Builders.leafBuilder().withNodeIdentifier(
279 new YangInstanceIdentifier.NodeIdentifier(childOrdinaryLeafQName))
280 .withValue("chlfval1").build()).build();
281
282 OrderedMapNode childOrderedListNode = Builders.orderedMapBuilder().withNodeIdentifier(
283 new YangInstanceIdentifier.NodeIdentifier(childOrderedListQName))
284 .withChild(childOrderedListEntryNode).build();
285
286 ImmutableMap.Builder<QName, Object> builder = ImmutableMap.builder();
287 ImmutableMap<QName, Object> keys = builder.put(parentKeyLeafQName, "pkval1").build();
288
289 YangInstanceIdentifier path2 = YangInstanceIdentifier.of(parentContainerQName).node(childContainerQName)
290 .node(parentOrderedListQName).node(new NodeIdentifierWithPredicates(parentOrderedListQName, keys)).node(childOrderedListQName);
291
292 treeModification.write(path2, childOrderedListNode);
293 treeModification.ready();
294 inMemoryDataTree.validate(treeModification);
295 inMemoryDataTree.commit(inMemoryDataTree.prepare(treeModification));
296
297 DataTreeSnapshot snapshotAfterCommits = inMemoryDataTree.takeSnapshot();
298 Optional<NormalizedNode<?, ?>> readNode = snapshotAfterCommits.readNode(path1);
299 Optional<NormalizedNode<?, ?>> readNode2 = snapshotAfterCommits.readNode(path2);
300 ----
301 First comes the creation of in-memory data tree instance. The schema context (containing the model mentioned above) of this tree is set. After that, two normalized nodes are built. The first one consists of a parent container, a child container and a parent ordered list which contains a key leaf and an ordinary leaf. The second normalized node is a child ordered list that also contains a key leaf and an ordinary leaf.
302
303 In order to add a child node to a node, method withChild() is used. It takes a NormalizedNode as argument. When creating a list entry, YangInstanceIdentifier.NodeIdentifierWithPredicates should be used as its identifier. Its arguments are the QName of the list, QName of the list key and the value of the key. Method withValue() specifies a value for the ordinary leaf in the list.
304
305 Before writing a node to the data tree, a path (YangInstanceIdentifier) which determines its place in the data tree needs to be defined. The path of the first normalized node starts at the parent container. The path of the second normalized node points to the child ordered list contained in the parent ordered list entry specified by the key value "pkval1".
306
307 Write operation is performed with both normalized nodes mentioned earlier. It consist of several steps. The first step is to instantiate a DataTreeModification object based on a DataTreeSnapshot. DataTreeSnapshot gives you the current state of the data tree. Then comes the write operation which writes a normalized node at the provided path in the data tree. After doing both write operations, method ready() has to be called, marking the modification as ready for application to the data tree. No further operations within the modification are allowed. The modification is then validated - checked whether it can be applied to the data tree. Finally we commit it to the data tree.
308
309 Now you can access the written nodes. In order to do this, you have to create a new DataTreeSnapshot instance and call the method readNode() with path argument pointing to a particular node in the tree.
310
311 === Serialization / deserialization of YANG Data
312 If you want to deserialize YANG-modeled data which have the form of an XML document, you can use the XML parser found in the module yang-data-codec-xml. The parser walks through the XML document containing YANG-modeled data based on the provided SchemaContext and emits node events into a NormalizedNodeStreamWriter. The parser disallows multiple instances of the same element except for leaf-list and list entries. The parser also expects that the YANG-modeled data in the XML source are wrapped in a root element. Otherwise it will not work correctly.
313
314 Here is an example of using the XML parser.
315 [source, java]
316 ----
317 InputStream resourceAsStream = ExampleClass.class.getResourceAsStream("/example-module.yang");
318
319 XMLInputFactory factory = XMLInputFactory.newInstance();
320 XMLStreamReader reader = factory.createXMLStreamReader(resourceAsStream);
321
322 NormalizedNodeResult result = new NormalizedNodeResult();
323 NormalizedNodeStreamWriter streamWriter = ImmutableNormalizedNodeStreamWriter.from(result);
324
325 XmlParserStream xmlParser = XmlParserStream.create(streamWriter, schemaContext);
326 xmlParser.parse(reader);
327
328 NormalizedNode<?, ?> transformedInput = result.getResult();
329 ----
330 The XML parser utilizes the javax.xml.stream.XMLStreamReader for parsing an XML document. First, you should create an instance of this reader using XMLInputFactory and then load an XML document (in the form of InputStream object) into it.
331
332 In order to emit node events while parsing the data you need to instantiate a NormalizedNodeStreamWriter. This writer is actually an interface and therefore you need to use a concrete implementation of it. In this example it is the ImmutableNormalizedNodeStreamWriter, which constructs immutable instances of NormalizedNodes.
333
334 There are two ways how to create an instance of this writer using the static overloaded method from(). One version of this method takes a NormalizedNodeResult as argument. This object type is a result holder in which the resulting NormalizedNode will be stored. The other version takes a
335 NormalizedNodeContainerBuilder as argument. All created nodes will be written to this builder.
336
337 Next step is to create an instance of the XML parser. The parser itself is represented by a class named XmlParserStream. You can use one of two versions of the static overloaded method create() to construct this object. One version accepts a NormalizedNodeStreamWriter and a SchemaContext as arguments, the other version takes the same arguments plus a SchemaNode. Node events are emitted to the writer. The SchemaContext is used to check if the YANG data in the XML source comply with the provided YANG model(s). The last argument, a SchemaNode object, describes the node that is the parent of nodes defined in the XML data. If you do not provide this argument, the parser sets the SchemaContext as the parent node.
338
339 The parser is now ready to walk through the XML. Parsing is initiated by calling the method parse() on the XmlParserStream object with XMLStreamReader as its argument.
340
341 Finally you can access the result of parsing - a tree of NormalizedNodes containg the data as they are defined in the parsed XML document - by calling the method getResult() on the NormalizedNodeResult object.
342
343 === Introducing schema source repositories
344
345 === Writing YANG driven generators
346
347 === Introducing specific extension support for YANG parser
348
349 === Diagnostics