Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Addresses:  CPS-72 - Getting issue details... STATUS

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  will also
differ depending on context. It makes a requirement the fully qualified type definitions should be stored with data fragments (XPath)

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



  • No labels