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?
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 https://www.w3.org/TR/1999/REC-xpath-19991116/#section-Node-Set-Functions. Lists without keys are mentioned in https://tools.ietf.org/html/rfc7950#section-7.8.2 - i.e. lists representing configuration MUST have keys, other lists MAY.
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.
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.
from Ch 6.11 “Operational data lists without keys” of confd-user-guide
And your statements
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.