ordering elements in a list

21 views
Skip to first unread message

ingwhe...@gmail.com

unread,
May 18, 2015, 10:50:28 AM5/18/15
to libne...@googlegroups.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čí

unread,
May 19, 2015, 8:07:03 AM5/19/15
to ingwhe...@gmail.com, libne...@googlegroups.com
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):
Reply all
Reply to author
Forward
0 new messages