Thanks for the clarification.
The data source identification is normally determined by a notion of a catalog which is implementation specific as that’s outside the scope of the specification.
For example in the reference implementation the Bindings interface defines an environment and the environment set in EvaluationSession#globals is effectively the catalog for that session. When looking up a binding, e.g. a table, the
Bindings implementation will return the corresponding value which is mapped to the correct data source. Take a look at this example, it creates a session with an in memory table bound to the name
myCsvDocument, but it could be bounding that name to a file, a table in Postgres, etc.
As I mentioned before the determining which table comes from which data store is implementation specific and what the it’s implemented in the reference implementation is a way to do it but there are multiple ways of doing it and each implementation will have to consider different trade offs when implementing it.