...
This would give rise to constant time look up in such cases. If this solution is not implemented, users can work around this problem wrapping lists in container nodes, with the container being included in the descendant query, e.g. instead of //books[@title='Matilda'], change the model and use //books/book[@title='Matilda'] as a query. This would then have O(1) performance.
Note: if we wish to avoid creating additional database fields, using list/container name field would offer the best balance of performance, e.g.
| id | parent_id | anchor_id | xpath | container |
|---|---|---|---|---|
| 1 | NULL | 3 | /bookstore | bookstore |
| 2 | 1 | 3 | /bookstore/categories[@code='1'] | categories |
| 3 | 2 | 3 | /bookstore/categories[@code='1']/books[@title='Matilda'] | books |
| 4 | 2 | 3 | /bookstore/categories[@code='1']/books[@title='The Gruffalo'] | books |
In this case, attributes for any list element path component would need to be looked up (so it would no longer be index-only).
Work Breakdown for Implementation
...