You can do join _operations_,
I would appreciate further clarification for the distinction which you present here.
but you aren't doing them on tables(unless you did extra work to represent the tables hierarchically)
Some “tables” can be transformed into XQuery sequences, can't they?
and there's absolutely no need for the keywords because the existing more general mechanisms work fine.
I see further development challenges in this area for the safe and convenient application of join conditions (or constraints).
I guess that you prefer to refer to them as “predicates within steps” so far (according to path expressions). https://www.w3.org/TR/xquery-31/#id-predicate
Use your functions to create maps where the keys come from that id element's string value.
Customised data structures can be created together with XQuery maps and arrays. But I find that a join operation would be needed before based on available identification data.
(: bind to the sequence of id values :) for $id in $interesting_stuff1 return (: run the function per-id :) my_fun:do_something($id,$interesting_stuff2($id),$interesting_stuff3($id))
You could decide to skip the for clause and use
return $interesting_stuff1 ! my_fun:do_something(.,$interesting_stuff2(.),$interesting_stuff3(.))
instead.
How do you think about to work without an extra identification sequence variable?
Will any further comparisons evolve for the provided functionality?
Don't think so. I find the trick with XQuery is to not fight with it about being some other language.
Internalizing the sequence concept takes work; …
Would you like to extend programming interfaces for the management of relationships with various entities?
Regards, Markus