>> These rely on the fact that some property names only make sense with
>> particular foreign interfaces. 'oracle-ORA only makes sense with Oracle....
>>
>> Likewise, 'sqlstate only makes sense with SQL databases; if you FIND it....
>
> Emphasis added to "find".
>
> And I'm sorry I failed to communicate my question.  *Exactly* how
> would the library developer consulting registry.scheme.org discover
> "'sqlstate" and "'oracle-ORA"?  Would he navigate to a sub-page and
> ^F/F3 search for likely things, like "database", "RDMBS", "sql", etc.?
>
> If there is such a sub-page, what limiting principle, if any, would
> be used to decide which names to include in it, vs. ones that might
> be in a sub-sub-page like fiddly details only relevant to Oracle
> ORAs, PostgreSQL status returns, etc.?

We have a tentative list of 15 properties at
<https://registry.scheme.org/#foreign-status-property>. Assume we wrap
so many foreign systems that the list grows to 50 properties, making it
difficult to navigate at a glance.

Options for managing that level of complexity:

* Use prefixes: e.g. start SQL-related property names with `sql`
   and HTTP-related ones with `http`.

* Have little groups of two or three properties that are conventionally
   used together and interpreted in light of each other. We started with
   `set`, `code/number`, and `name/symbol`. That would be one set where
   all three help interpret the others.

* I originally thought it would make sense to divide all or most
   properties by set, not only code/number and name/symbol. But it
   soon became apparent that most properties are probably naturally
   set-independent. For example, a `line-number` property could
   potentially make sense for dozens of different systems, since
   all kinds of things deal with line numbers.

I think the issue you're getting at is: "Suppose I'm interfacing to
sqlite; how do I know which properties I can expect to be filled in by a
foreign status object coming from the sqlite interface? I could test for
all 50 properties, but that doesn't make much sense."

I think that is a question that would make sense to pose to the people
who wrote each interface, not to the registry. Suppose you're the person
writing the sqlite binding. You'd go through the manual for SQLite's C
API, looking at what information it returns. You'd then look at the full
list of 50 properties in the registry, picking out the ones that have a
sensible mapping to something coming from the SQLite C API, and leave
out the rest.

E.g. the C API gives you an error code and corresponding error message,
so your Scheme wrapper would fill in the 'code and 'message properties.
Likewise, if we had a 'foreign-system or 'foreign-library property or
some such, you'd put 'sqlite or 'sqlite3 in there. If SQLite returned a
SQLSTATE code, you'd store it in a 'sqlstate property. But I don't think
it does; this illustrates that the flexibility in not unnecessarily
coupling properties is useful. You'd think all SQL databases use
SQLSTATE codes, but maybe not. Things like that.

What we're doing is kind of like duck typing in OOP. Dynamic languages
are kind of based on the insight that you can leave out constraints that
everyone thinks are mandatory for basic programming sanity and
everything can still work just fine. Many OOP people thought you need to
know the class of an object you're calling, but it turns out that if you
get some object that implements the methods you want, you don't really
need to know its class and things still work fine.