ordering elements in a list

[ingwhe...@gmail.com]

Hello,

When a list with a key (or more) is defined, does/should libnetconf care about where the key shows up? (I think libnetconf shouldn't care about the ordering, but my experience is that libnetconf, or rather the rng validation, does care about it.)

For example, in the attached model, the key for list "l1", "name", is defined first.

I noticed that an <edit-config> message below that provides "name" first can be validated, but a similar <edit-config> message that provides "name" last can't be validated.

That said, when I added an <interleave> statement inside the "lr:l1" element in the rng file, also attached, I was able to get both <edit-config> message validated.

I see some inconsistencies with my fix, and so I'm wondering if there's a different fix to allow random order of elements within a list.

Thanks,
Helen

P.S.

<edit-config> that could be validated (provides "name" first):

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="106"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:lr="http://example.com/leafrefs">
<edit-config>
<target>
<running />
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<lr:l1>
<lr:name>context2</lr:name>
<lr:l2>
<lr:name>xyz</lr:name>
</lr:l2>
</lr:l1>
</config>
</edit-config>
</rpc>


<edit-config> that couldn't be validated (provides "name" last):

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="106"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:lr="http://example.com/leafrefs">
<edit-config>
<target>
<running />
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<lr:l1>
<lr:l2>
<lr:name>xyz</lr:name>
</lr:l2>
<lr:name>context2</lr:name>
</lr:l1>
</config>
</edit-config>
</rpc>

P.P.S. yang2dsdl has the same "problem" of requiring a certain ordering.

[Radek Krejčí]

Hi Helen,

ordering matters in this case. RFC 6020, section 7.8.5 says:

The list's key nodes are encoded as subelements to the list's
identifier element, in the same order as they are defined within the
"key" statement.

The rest of the list's child nodes are encoded as subelements to the
list element, after the keys.

So the keys MUST be the first and if there are multiple keys, they have to appear in the same order as they are defined in the data model.

Regards,
Radek


Dne 18.5.2015 v 16:50 ingwhe...@gmail.com napsal(a):