...
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:
| Code Block | ||
|---|---|---|
| ||
XML XPath: /ns1:parentType[@attr1='value1']/ns2:childType[@attr2='value2'] CPS XPath (storage): /org:onap:sample:parentType(2020-01-01)[@attr1='value1']/org:onap:sample:childType(2020-02-02)[@attr2='value2'] |
...
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.
| Code Block | ||
|---|---|---|
| ||
/* 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)
| Code Block | ||
|---|---|---|
| ||
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'] |
...