Rick hi
> But it is a kind of fake interopability, isn't it: a kind of
> nominalism?
Depends how it's done. Non-interoperability is endemic to the world of
RDBMS connections (and to the DBs themselves), so "an" interoperable
mechanism is not achievable, I think.
Faced with that, I think what is needed is a mechanism that can
accommodate the various non-interoperable options out there.
> It could give the comfort of looking neutral, without actually being
> neutral at all, because the incompatible semantics would be shoved off
> into the values.
Yes, but there could then be an opportunity for alterative sets of
values for different ways of making the connection.
> We want to expose non-interoperable dependencies, not
> hide them away, even though it may offend our desire for abstraction.
I think what we want is a way for user A who has a database-connected
document to exchange that with user B and have it work, with neither
user being mandated to use Java/JDBC in the process (though of course
they may).
I think by moving Java-specific (or ODBC-specific) settings into an
informative annex, we *would* be highlighting the interop issues in play
...
- Alex.
