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.

The format chosen should be easy to parse using regular expression for ease of conversion from full version to simplified on and vice-versa.

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's important to separate the XPath fields used to store the data fragment from the XPath parameter used to query the data.
The first case is mainly internal CPS implementation and main requirements are ease and reliability of query. The actual data clients may
require the more simple API to use.

The template (actually naming convention) used to uniquely define the node type allows accepting simplified request parameters (also XML compatible)
which can be reliably transformed into fully qualified ones for internal use. 

/* Request parameters (single namespace and revision case) */
{ 
	xpath: "/parentType[@attr1='value1']/childType[@attr2='value2']",
	namespace: "org:onap:sample",
	revision: "2020-01-01"
}

/* Request parameters (mapped namespaces) */
{ 
	xpath: "/ns1:parentType[@attr1='value1']/ns2:childType[@attr2='value2']",
	namespaces: {
		ns1: {namespace: "org:onap:sample", revision: "2020-01-01"},
		ns2: {namespace: "org:onap:sample", revision: "2020-02-02"}
	}
}

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 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