Page History

Addresses: 

Problem description

The fully qualified XPath for XML includes unique node identifiers in a format /<namespace> : <node name>[ <index> or <extra conditions> ]/
where namespace  and node name are used for unique type identification while namespace definition (mapping to known schema) isn't a part of XPath.

For YANG models we also have namespaces defined however there is additional parameter (revision) which is also a part of unique type definition.

Proposal

It makes sense to use both full namespace (not alias as in XML) and a revision to to be stored in database.

...

Example:

/* XML XPath: */
/ns1:parentType[@attr1='value1']/ns2:childType[@attr2='value2']

/* CPS XPath for internal use (storage): */
/org:onap:sample:parentType(2020-01-01)[@attr1='value1']/org:onap:sample:childType(2020-02-02)[@attr2='value2']

...

It also should be taken into account the full type hierarchy matters if data is stored by fragments and the XPath property is being used as a
model revision identifier as well. If parent model is changed while child model remains the same (revision) the child data fragment  will also
differ depending on fragment became
dependent on parent (revision) context. It makes a requirement the fully qualified type definitions should be stored with data fragments (XPath)
for all the nodes

/* clear parent context difference: */
/org:onap:sample:parentType(2020-01-01)[@attr1='value1']/org:onap:sample:childType(2020-02-02)[@attr2='value2']
/org:onap:sample:parentType(2020-02-02)[@attr1='value1']/org:onap:sample:childType(2020-02-02)[@attr2='value2']

/* unclear parent context (if only current node type is stored in database): */
/parentType[@attr1='value1']/childType[@attr2='value2']

To discuss and clarify

• the naming convention for ease of parse/ store/ query by XPath
• using indexes in XPAth like /node[0] if no keys defined in model
• ordering multiple keys for composite key models on storage and requests 
• or alternative approach for unique node type definition (in CPS XPath) with taking into account YANG models variations

Discussion results (Nov 16, 2020)

For now there is no need to store full module identifier in the xpath field. The namespace, revision, parent module context will be taken
into account using references through dedicated fields (module_id, parent_id).

Limitation determined: only keyed collections are supported. No node identification by index is expected.

The attribute order for composite keys to be handled as dedicated task.
Both requested xpath and stored one expected to sort key attributes by attribute (leaf) name