...
Alternative solutions - pros and cons
The initial proposals described 2 simplified approached:
Data Input / Output Consistency
In order to make custom root pointer solution (described above) work properly, it should point to parent of data node being updated.
At the same time the JSON data require to be presented as a single entry explicitly defining a type of a current node.
From other hand when same data node is requested for output (GET) it addressed by direct xpath and value returned is a data
unwrapped (as is: multiple top level elements).
The difference in same parameters meaning depending on action performed (while addressing same data fragment) makes the
exposed API inconsistent.
Below is example using a data fragment referencing ran-network2020-08-06.yang model
...
| Code Block | ||
|---|---|---|
| ||
// xPath: /ran-network/NearRTRIC[@idNearRTRIC='11']/GNBDUFunction[@idGNBDUFunction='1']/NRCellDU[@idNRCellDU='103594001']/attributes
{
"pLMNInfoList": [{
"mcc": "310",
"mnc": "410",
"sNSSAIList": [{
"sNssai": "10000100",
"status": "INACTIVE",
"configData": [{
"configParameter": "maxNumberOfConns",
"configValue": 5000
}]
}]
}]
} |
However pointing to parent node in order to parse the child correctly is only an internal requirement. It means there could be
dynamic update of both incoming parameters (as internal logic):
- shortening the xpath by 1 entry to address parent
- wrapping incoming JSON with