Fact: Saxon’s API is very impractical, not made for expression transformation or even inspection at all. Given how deep we’d have to delve to get anything working, it’s likely that version updates would break everything anyway.
We could maintain our own XPath parser. This would abstract us from Saxon/Jaxen and individual versions thereof, and allow us to identify more optimisation opportunities. Given an AST, we can perform optimising transformations, and identify rulechain visits, then dump it to an XPath expression string and let Saxon parse it to its own representation. This parser could also be used in the designer, as suggested in #1192
Interesting things that could be done with that:
//N[$reportNs=true()] | //M[$reportMs=true()]
. The value of the property never changes at run time, which Saxon can’t know (we use a dynamic context). But if e.g. $reportMs
is set to false, then the M branch can be safely discarded, and only one rulechain visit would be added.//A/(B | C)/X
-> //A/B/X | //A/C/X
, which is currently ignored by Jaxen IIRC)Things to care about:
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4