Resources
- CPS-235 - Getting issue details... STATUS
- https://www.softwaretestinghelp.com/xpath-writing-cheat-sheet-tutorial-examples/
- https://www.freeformatter.com/xpath-tester.html
*Note when using online xpath testers, ensure that laves are expressed as xml attributes and not like other xml elements like json-to-xml convertors will do.
| Incorrect | Correct | Bookstore XML extract for testing xPath Queries online |
|---|---|---|
<categories>
<code>01</code>
<name>SciFi</name>
<books>
</books>
</categories>
| <categories code=01 name='SciFi'>
<books>
</books>
</categories>
| Bookstore <bookstore name="Chapters">
<bookstore-name>Chapters</bookstore-name>
<categories code="01" name="SciFi">
<books>
<book name="Feersum Endjinn"/>
<book name="Chapters"/>
</books>
</categories>
<categories code="02" name="kids" />
<categories code="03" name="Chapters" />
</bookstore>
|
Queries
Scope of queries
- The assumes scope for all below Queries is one Dataspace and oen Anchor.
- It will be relatively easy to extend the scope to multiple anchors in a later user story.
- There is no need to extend the scope beyond one Dataspace
xpath functions
| Slogan | cpsPath | Jira | Notes | Priority / When do we need this? | |
|---|---|---|---|---|---|
| 1 | get (list element) by xpath | /bookstore/categories[@code='01'] | CPS-71 - Getting issue details... STATUS | This is not really a query as code is the key attributes and this xpath is stored with the target fragment | Already implemented |
| 2 | filter list element by other (then key) leaf value | /bookstore/categories[@name='SciFi'] | CPS-231 - Getting issue details... STATUS | Compare to #1, notice how from a cpsPath perspective it is not clear which is a get and which is a query. The customer might not know either! See issue #1 | Required for E2E Slicing see CPS-200 study |
| 3 | partial xpath combined with leafvalue filter (split in 2 scenarios) | //categories[@name='SciFi'] | Client ignore/does not care/does not know the preceding xpath | Investigate if needed for E2E Slicing. | |
| 4 | filter on leaf value without any path | //*[@name='Chapters'] | This will return anything with that name, might be useful when working with small models | ||
| 5 | allow any element from list ie. find something under any possible list entry | /bookstore/categories/books/book[@name='Chapters'] | Not obvious but since /categories is not indexed (no key defined using [@...] notation) it will return a book from any categories | ||
| 6 | partial xpath, wildcard in the middle of the path . Could be seen as combination of starts-with and end-with | /bookstore/categories//book[@name='Chapters'] | using // in the middle of a path is like a wildcard for any containers or lists between /categories and /book | ||
| 7 | combining several leaf values (and, or etc.) Can bee seen too for composite list-keys and does work in scenario #1 above (but is order dependent) | [@id1 = x and @id2 = y] | just for illustration purposes | ||
| 8 | (string) leave value contains something | [contains()] | just for illustration purposes |
Note 1. All cpsPath queries can be fulfilled by just 1 REST endpoint and Java API method (as agreed earlier). We just need to document the capabilities (xpath functions) support by our cpsPath...
Note 2. At the start the cpsPath can probably be examined using regular expression to distinguish between the queries. But at some stage we might need to write a more advanced parsing using tools like Antlr. There might also be existing utilities breaking down xpaths?
Updates
| Slogan | Jira | Notes | Priority / When do we need this? | |
|---|---|---|---|---|
| 1 | Replace DataNode(tree) | CPS-58 - Getting issue details... STATUS | This is powerful update method that can fulfill all below scenarios too. However it is a crude and inefficient for scenario with children. Ada a child at the top of the tree will required the client to re-submit all existing data of the siblings and their descendants. replacing all of them in the DB layer which of course could lead to very lengthy update operations. | Already being implemented. Need to investigate if E2E Slicing requires the 'with descendants' option |
| 2 | Update Single attribute on single DataNode | Client provides on full xpath and single attribute and value. Internal it might required to get the target node form the DB, update and then validate | Probably required for E2E Slicing | |
| 3 | Update Multiple attributes on single DataNode | This could a simple extension of the previous method (#2) by instead of providing one key-value pair it could be map of many. Question remains if we ant to Java-API methods, or one. And if just it could be handled by one user story instead, depending on team preference | ||
| 4 | Add Child DataNode | should be possible to add node with just the data for the new node (which includes a full xpath so that the parent an be identified) further descendant can easily be included (should not require additional work ie. separate user story) | Investigate if needed for E2E Slicing. But seems likely this is needed soon and to address the technical debt of the solution in #1 | |
| 5 | Add DataNode to List | should be possible to add node with just the data for the new node (which includes a full xpath so that the parent an be identified) question: should the xpath for the list entry be generated (using the model and keyfield(s) data) or included in the dat provided by the client | Investigate if needed for E2E Slicing. But seems likely this is needed soon and to address the technical debt of the solution in #1 | |
| 6 | Remove DataNode | Assume this will also cover removing DataNode from a list | Investigate if needed for E2E Slicing. But seems likely this is needed soon and to address the technical debt of the solution in #1 | |
| 7 | Add element to Leaf-List | Nice-to-have. From experience in similar project this use-case never was prioritized. It can always be done using #3 or #4 instead. My recommendation is to not consider this until a client specially requests it and argues the need for it. | ||
| 8 | Remove Element from Leaf-List | Nice-to-have. From experience in similar project this use-case never was prioritized. It can always be done using #3 or #4 instead. My recommendation is to not consider this until a client specially requests it and argues the need for it. |