Idea ID: 2780777

XPath2.0 or XQuery

Status : Under Consideration
over 3 years ago
Looking to gauge the communities needs/desire/thoughts about upgrading our processing engine to support XQuery. Typically the benefit vs risk is not sufficient as XPath 1.0 supports most capabilities. This thread is intended to start a discussion around whether or not the risk is worth the reward for future releases.


  • It would be great if we could keep the existing xpath token intact and add a new xpath2 token so that existing code would work unchanged but we would have the new functionality available in new projects
  • There are so many things for which x-path is required. The product is sill shipping with a VERY old version, and there has been no indications of when we can expect to see an recent version of x-path.

    Some of the functions I miss in my daily work are: index-of, matching, lower-case, upper-case, and the list goes on.


     you could do the same as was done with the Rhino/Nashorn; have an engine setting, which would allow you not to have to re-test all the drivers ... and let us use XPath2+ when we need it (which we do).

  • The testing of this for all potential existing operations could be substantial. What are the value add benefits of doing this for IDM vs IGA future.

    For IDM, we would need to understand the effort involved which is ongoing and will consider for a 4.9.

  • Getting xPath 2.0 (and possible xQuery) would make things very much simpler. One of the major issues which many people face is that do-query is very limited, meaning it's only possible to query with fixed values, eg. wild cards are not allowed in attribute matching. Which means that sometimes a query will result in thousands of results, which one then have to loop through. With xPath it is possible to filter using wildcards (contains with xPath v1.1), and with xPath 2.0 we would get lower-case, upper-case, and last but not least matches. Matches will allow us to use regEx to filter on node sets, which would make processing of large result documents faster, and very much easier than what we are faced with today. Make it optional if one wants to use xPath 1.x or 2.0 via an ECV....
  • Dream scenario would be to have XPATH + XSLT 3.1 and streaming support added so that large XML input stops being such a bottleneck for us in driver development. A 200Mb XML input doc should not choke IDM, but it does. Having support for millions or billions of objects at Flaim level doesn't help if we can't import moderately sized raw data because we can't stream or pre-process it into discrete chunks that IDM likes. XSLT - should be a key part of the discussion regardless. It is with XSLT that we see the biggest downside to being stuck on the 1.x era tech. Implementation wise this should be enabled/disabled via an ECV on a per driver/driverset level.