Operating System: All
Platform: All

Another issue with the XML parser is the SchemaNode parameter that is used when
creating an XmlParserStream instance. Currently, it represents a schema
node that is the parent node of the root XML element. However, this
parameter should correspond to the root XML element itself.

Fix: https://git.opendaylight.org/gerrit/#/c/59036/

Follow-up fix for the BGPCEP project:
https://git.opendaylight.org/gerrit/#/c/59268/

Actually, ignore the first two comments.

It is irrelevant if the root XML element corresponds to the SchemaNode parentNode parameter or not. The SchemaNode parameter represents the parent SchemaNode of the YANG-modeled data that are wrapped inside the root XML element.

The actual flaw is that the parser wraps the parentNode parameter inside a CompositeNodeDataWithSchema which emits only its child nodes into the provided NormalizedNodeStreamWriter. The parentNode itself is not emitted which is a problem.

Here is an example which illustrates the issue.
Let's say we have a YANG module which looks like this:

module foo {

...

container foo-cont { list foo-list

}

...

}

We want to parse the foo-cont node, so we provide a corresponding foo-cont ContainerSchemaNode as the parentNode parameter to the XmlParserStream.

Now, imagine we have an XML source which looks like this:

<foo-cont xmlns="foo">
<foo-list> ...some other nodes... </foo-list>
</foo-cont>

If we parse this XML into a NormalizedNode tree, we will end up with a root NormalizedNode which corresponds to the foo-list node. However, it should be the foo-cont node.

Therefore we need to check the parentNode type and put it into a corresponding ...NodeDataWithSchema.
In the example above, it would be a ContainerNodeDataWithSchema.