On Mon, Apr 18, 2022 at 10:33:19PM +0200, Markus Elfring scripsit:
This makes "source of information" too complex to define a standard operation you can call a join; …
I find that this view will need further clarification.
To join something, you minimally need at least two expressions which find the things to be joined, some kind of rule for how to perform the join, and a destination for the result of the join.
If you pass in expressions, you've replicated the language after removing an opportunity to perform static analysis. This won't work better.
If you say, no, no, pass in the _results_ of the expressions, you have to handle (at least) arbitrary sequences, and sequences are not required to have all members the same type -- a sequence can properly contain document nodes, functions, and xs:dateTimeDuration members in some arbitrary order and amount -- you still wind up replicating much of the language in the rule for performing the join.
If you're dealing with XML you have to deal with all of XDM all the time. (Or worse! XDM is the best or at least the most successful abstraction of XML.)
XDM = XPath and XQuery Data Model, https://www.w3.org/TR/xpath-datamodel-31/
[predicates aren't joins]
but still are not a join,
Under which circumstances would you interpret the specification of special conditions (or constraints) as a join operation?
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. In this case, the comma operator is doing the joining.
Finding the thing you want to join and performing the join -- producing a result that contains this thing and some other things -- are conceptually distinct, or at least I think so.
Will this view trigger further considerations?
Don't see why.
You haven't provided a use case, on the one hand, and I've done this a lot, on the other; the view arises from experience.
Would you like to extend programming interfaces for the management of relationships with various entities?
I need an example here, because I'm not following what you mean.
I guess that you are used to some approaches for the handling of joinable items. Do you care for the number of involved items here?
No.
Any expression returns a sequence; any sequence can have arbitrarily many members. Writing XQuery while remembering that this is true is generally easier than writing XQuery that is trying to be specific about how many of something will be returned by the expression. It's completely possible and sometimes necessary to count things; more than one GUID attached to the same patient is something to check for, for example. But the general case is easier when you presume you're handling a sequence with an arbitrary number of members.