Hi Hans-Jürgen,
One reason why I would favor to have an XQuery implementation first is because it would allow us to define the semantics behind this function. There are currently lots of questions that are unclear to me, so it’s mostly conceptual questions that would need to be solved before such a function could be realized.
I had a closer look at your examples:
let $query := "/descendant::OutboundFlight[Status = 'Booked'][1]/FlightDeparture/DepartureTime"
let $query := "/descendant::OutboundFlight[FlightDeparture/DepartureDate][1]/FlightDeparture/DepartureDate" return xquery:data-paths($query) => //OutboundFlight/FlightDeparture/DepartureTime, //OutboundFlight/Status
Probably the result of the second query refers to your first example, right?
To be strict, "/descendant::OutboundFlight" is not identical to "//OutboundFlight"; but it is equivalent. So I would have expected to get the following paths as output:
/descendant::OutboundFlight/child::FlightDeparture/child::DepartureTime, /descendant::OutboundFlight/child::Status
"//OF[1]" could lead to:
/descendant-or-self::node()/child::OF
Next, we would need to sort out if/how to handle axes other than descendant-or-self, descendant and child. Moreover, as XQuery allows us to have all kinds of expression nearly everywhere, sth. like "A[B = 'c']" or "A[B]/C" are rather special (albeit common) query patterns that could be written in many different ways. The most obvious patterns could probably nailed down and realized pretty quickly, but there would be a lot of potenzial for optimizing the query output and considering corner cases, and this is usually something that costs a lot of time.
As I assume that you have some specific patterns in mind that would be helpful for you, would you be interested in providing an initial solution in XQuery that we could adopt as Java function later on?
Christian