Page History

...

• Extracting the DataSchemaNode (from SchemaContext) matching the xpath requested
• Update the  YangUtils.parseJsonData(..) method to utilize additional input
• Update the DataNodeBuilder logic to accept non-empty xpath when building data from NormalizedNode instance 

Alternative solutions

...

The initial proposals described 2 simplified approached:

...

The difference in same parameters meaning depending on action performed (while addressing same data fragment) makes the
exposed API inconsistent (for update case, acceptable for child addition case).

Below is example using a data fragment referencing ran-network2020-08-06.yang model 

Code Block
title GET
// xPath: /ran-network/NearRTRIC[@idNearRTRIC='11']/GNBDUFunction[@idGNBDUFunction='1']/NRCellDU[@idNRCellDU='103594001']/attributes/pLMNInfoList[@mcc='310' and @mnc='410'] { "mcc": "310", "mnc": "410", "sNSSAIList": [{ "sNssai": "10000100", "status": "INACTIVE", "configData": [{ "configParameter": "maxNumberOfConns", "configValue": 5000 }] ]} }

Code Block
title POST / PATCH
// 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 Pointing to parent node in order to parse the child correctly is only can be treated as 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 

...

• with a required type pointer (using last entry of xpath)

Also the following should be taken into account:

• the incoming data validation/parsing is required for both data node adding and updating cases, so it's preferable to use same
  logic for both cases
• extra validation is necessary to prevent key attributes change for mapped list elements
• difference in parameters for add/update cases will require extra effort for service consumer to compose a proper request

Partial Data Storage

As it was initially implemented there is no validation for parent data node existence when persisting data nodes.

It is unnecessary when the whole data tree is persisted (A). With non-empty initial xpath it makes it possible to
persist data nodes from lower levels of structure hierarchy without upper level data nodes (B).

From one hand it seems extra to persist upper level nodes if these nodes are never requested. From other hand it could lead to data inconsistency
if the parent node being added after child nodes (C). The case  however can be resolved by existing data check before inserting new entries.

Points to discuss/clarify