Skip to content

Issue with key order in YANG list instances #4

@EstherLerouzic

Description

@EstherLerouzic

Problem Description

I've encountered an issue with oop-libyang-libyang regarding the order of keys in JSON list instances. Libyang seems to require that list keys appear first in the json object and in the same order as defined in the YANG model, even though the JSON format doesn't normally impose any order for key-value pairs.

Concrete Example

Consider a list defined in a YANG model as follows:

list ttp-transceiver {
  key "transponder-ref transceiver-ref";
  // other definitions...
}

If in my JSON instance I have the reverse order:

{
  "ietf-optical-impairment-topology:ttp-transceiver": [
    {
      "transceiver-ref": "1",
      "transponder-ref": "42010107",
      // other properties...
    }
  ]
}

oopt-gnpy-libyang generates the following error:

libyang[0]: List instance is missing its key "transponder-ref". (path: Data location "/ietf-network:networks/network[network-id='NPA_LANNION']/node[node-id='42']/ietf-te-topology:te/tunnel-termination-point[tunnel-tp-id='AAAAABkKO88=']/ietf-optical-impairment-topology:ttp-transceiver[transceiver-ref='1'][transponder-ref='42010107']", line number 1.)
Even though the transponder-ref key is present in the instance, but not in the first position.

Impact

This behavior causes several issues:

It doesn't comply with the JSON specification which doesn't guarantee property order
It makes interoperability difficult with other tools that don't preserve key order
It requires additional processing of JSON data before validation

Expected Behavior

Libyang should recognize list keys regardless of their order in the JSON instance, as long as all required keys are present.

Is this intentional behavior or a bug? If intentional, is there a technical reason for this constraint?
I asked about this on libyang github, but this issue does not seem to exist in libyang: CESNET/libyang#2435

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions