Positional index for list without keys

[lukai]

According to section 9.13 of RFC7950

The syntax for an instance-identifier is a subset of the XPath
abbreviated syntax, formally defined by the rule
"instance-identifier" in Section 14. It is used to uniquely identify
a node in the data tree. Predicates are used only for specifying the
values for the key nodes for list entries, a value of a leaf-list
entry, or a positional index for a list without keys. For
identifying list entries with keys, each predicate consists of one
equality test per key, and each key MUST have a corresponding
predicate. If a key is of type "empty", it is represented as a
zero-length string ("").

I saw that RFC introduced a word called “positional index”, and it is only “for a list without keys”. Is there any detail information for this?
I want to know how it works, how its value get arranged. Should it start from 0 or 1? negative integer also valid? If changes were done to a certain entry of the list, the index of rest entries will be revalued or not?

[per]

@lukai

I saw that RFC introduced a word called “positional index”, and it is only “for a list without keys”. Is there any detail information for this?

Well, the specific wording “positional index” actually seems to be introduced in this RFC, but since the text is discussing the syntax for an instance-identifier, which is an XPath expression, and specifically enumerates the allowed XPath predicates in an instance-identifier, it can perhaps be inferred that it is talking about the value of the XPath position() function, see XML Path Language (XPath). Lists without keys are mentioned in RFC 7950 - The YANG 1.1 Data Modeling Language - i.e. lists representing configuration MUST have keys, other lists MAY.

@lukai

I want to know how it works, how its value get arranged. Should it start from 0 or 1? negative integer also valid?

I’m not sure if you are still referring to the syntax of an instance-identifier here… As far as I can see, the value space of the XPath position() function starts at 1. If you are asking about how “lists without keys” are handled in ConfD, see the section “6.11. Operational data lists without keys” in the User Guide. I.e. in short, the application gets to choose a signed 64-bit integer “pseudo key” for each list entry.

@lukai

If changes were done to a certain entry of the list, the index of rest entries will be revalued or not?

Again I’m not sure what you are referring to, but there is no “magic” here. The XPath position() “is what it is”. The “pseudo key” is whatever the application has chosen. For the purpose of translating between the textual representation of an instance-identifier and the internal value (which is a hkeypath), ConfD maps any “positional index” to a “pseudo key” with the same integer value and vice versa.

[lukai]

Thanks per,

from Ch 6.11 “Operational data lists without keys” of confd-user-guide

To support this without having completely separate APIs, we use a “pseudo” key in the ConfD APIs for
this type of list. This key is not part of the data model, and completely hidden in the northbound agent
interfaces, but is used with e.g. the get_next() and get_elem() callbacks as if it were a normal key.
This “pseudo” key is always a single signed 64-bit integer, i.e. the confd_value_t type is C_INT64. The
values can be chosen arbitrarily by the application,

And your statements

@per

The “pseudo key” is whatever the application has chosen. For the purpose of translating between the textual representation of an instance-identifier and the internal value (which is a hkeypath), ConfD maps any “positional index” to a “pseudo key” with the same integer value and vice versa.

My understanding is that ,there is a ConfD API or somehow a method, give the textual representation of an instance-identifier as input, get a pseudo key as output. So developer need not to know the textual value of positional index. Am I correct?

[per]

@lukai

My understanding is that ,there is a ConfD API or somehow a method, give the textual representation of an instance-identifier as input, get a pseudo key as output. So developer need not to know the textual value of positional index. Am I correct?

If I understand your question correctly, yes - ConfD always translates between the textual representation in a NB protocol and the internal representation of values (and vice versa), doesn’t matter if the type is e.g. an integer or an instance-identifier.