[YANGTOOLS-877] Add yang-model-api model of an XPath expression Created: 02/May/18 Updated: 02/Aug/18 Resolved: 02/Aug/18 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | parser |
| Affects Version/s: | None |
| Fix Version/s: | 2.0.10 |
| Type: | New Feature | Priority: | Medium |
| Reporter: | Robert Varga | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
Current RevisionAwareXPath is quite deficient in expressing the XPath stored therein. More specifically it requires anyone attempting to use it infer the prefix/namespace mapping and then parse the expression itself. Instead of going through these hoops, we really should have an object model of the expression, similar to org.jaxen.expr.Expr, which would act as an intermediate representation format, where all prefixes would already be properly resolved so that we are dealing with QNames instead of prefix+localnames. The parser should also bind function invocations for YANG-defined functions, so that their arguments are resolved to proper types. |
| Comments |
| Comment by Robert Varga [ 02/May/18 ] |
|
Note that this layer of XPath model needs to provide for predicates for node lookups, unlike YANGTOOLS-878, which should further extend the model to resolve them to PathArgument lookups. The possibility of binding expression (literals, identity references, etc.) to Java types should be evaluated – it needs to happen in places where we can statically infer the type and should happen either in scope of this issue or in YANGTOOLS-878. It is okay to have a partial type binding, as the XPath evaluation engine needs to be able to cope with both. |
| Comment by Robert Varga [ 01/Aug/18 ] |
|
This is still missing an implementation. |