> To join something, you minimally need at least two expressions which find
> the things to be joined,

I am still trying to clarify corresponding development possibilities according to
bigger numbers of entities together with for clauses.
(I hope that other meanings can be better distinguished from related applications
of a function like “string-join”.)


> some kind of rule for how to perform the join,
> and a destination for the result of the join.

This is usual.


> [predicates aren't joins]

How does this feedback fit to other documentations which describe the role of
predicates for join operations?


> A join requires the results of two expressions to be combined.
>
> (db:open('thing1'),db:open('thing2'))/descendant::patienti-identifier[local:check-range($interesting,.)]
>
> can be interpreted as a performing a join, you can re-write it as
>
> (db:open('thing1')/descendant::patient-identifier[local:check-range($interesting,.)],db:open('thing2')/descendant::patient-identifier[local:check-range($interesting,.)])
>
> but the predicate isn't doing the joining, the predicate is narrowing
> the selection of the XPath expressions.

This can be a desirable effect.


> In this case, the comma operator is doing the joining.

This example refers to another variant of a join operation for the construction
of a sequence.
(Such a XQuery code fragment does not use for clauses.)


> > Do you care for the number of involved items here?
>
> No.

Would you like to adjust this view according to the usage of for clauses?
https://www.w3.org/TR/2017/REC-xquery-31-20170321/#id-joins

Regards,
Markus