> I don't think so.  Let's take 'sqlstate.  Some databases might be able
> to use it as is, have no quirks that demand a sub-convention like
> 'postgresql (but see below).  Let's look at my example from the
> document: https://htmlpreview.github.io/?https://raw.githubusercontent.com/johnwcowan/srfi-198/master/srfi-198.html
>
> '(convention sqlstate
>    sub-convention postgresql
>    sqlstate "28P01"
>    category exception
>    class-text "Invalid Authorization Specification"
>    condition-name invalid_password
>    scheme-procedure open-database-connection
>    foreign-interface query-message
>    message "open-database-connection: 28P01: incorrect password"
>    args ("localhost" 5432 "ecb" "ecb"))

It basically looks like a good object to me, with a lot of nice detail.

You're using 'convention to mark it as sqlstate, but the 'sqlstate
property would be unambiguous even with no explicit convention.

Saying that the status comes from PostgreSQL is good. However, that info
could also be relayed via 'database-engine 'postgresql or the like.

The concept "convention" conflates the two concepts "source" and
"interpretation". "PostgreSQL" would be the source; "sqlstate", or more
precisely "PostgreSQL-flavored sqlstate" would be the interpretation.

I take it you mean convention and sub-convention to give the
interpretation, not the source. This distinction also significant for
things like synthetic vs actual errno values. A WinAPI error converted
to an errno would have 'convention 'errno 'sub-convention 'windows or
something? Or 'convention 'windows 'sub-convention 'errno?

'foreign-interface only makes sense to interpret in light of what I call
"source" above. If you don't know that the source if PostgreSQL, you
don't know how to make sense of 'foreign-interface. Except if you have a
good guess for what the source probably is. For example,
'foreign-interface 'fcntl almost certainly comes from a POSIX interface.

'condition-name looks like it's specific to PostgreSQL since it has an
underscore. In this case, we could specify that if the interpretation
(or the source) is PostgreSQL, 'condition-name comes from a particular
set of names associated with that database.

The "source" property I propose is still not that precise. We can talk
to Postgres via its C library, its C++ library, or via sockets. All of
those talk to the same Postgres backend so the DB engine is the same in
all cases. The C library and the C++ library are both libraries, but
sockets/subprocess is not a library.

> But the exact meanings of 'category, 'class-text, and 'condition-name
> ***might be different in another convention***.

Agree.

> ***And they get their
> precise meaning from inheritance*** from the 'convention and perhaps
> 'sub-convention.*

Don't agree that the meaning has to come from inheritance. It can come
from a trait/interface/mixin.

> This is almost worth emphasizing in all caps.  In your vision as I
> understand it, the issues of naming and meaning are much more stark,
> because if 'category for example became one of the 15-50 standard
> keys, it could have only one meaning.

No, I agree with you that its meaning can depend on other properties.

What I propose is that if those other properties are lacking, the
meaning can simply be vague. Programmers often have to make use of vague
information, but that information is somewhat useful in anyway because
the programmer can infer the context from knowledge gained elsewhere.

The reason I'd permit vagueness in foreign status objects is that I
suspect it will be too difficult to banish it in practice. The worst
option IMHO is when a system gives vague information but makes it look
like it's precise.

> I've not yet tried to construct statuses for any other database;

IIRC MySQL and Oracle have native status codes that are unrelated to
SQLSTATE codes. But they can also map those to SQLSTATE codes. I assume
the mapping is lossy.

> on
> the other hand, the status needs to have *some* key and property to
> tell you this is a PostgreSQL foreign status so you know where to look
> up "28P01" without requiring a general search engine, or consulting
> the code, or just happening to know PostgreSQL is the database engine.

Definitely.

In the particular case of SQLSTATE codes, those happen to have a
well-defined structure across DB engines, but in general your point
stands. And even with SQLSTATE codes you can infer more precise things
if you know the particular DB engine it came from.

>> Maybe we should solve this by sketching examples of real use cases.
>
> I tried to do so in the SRFI text; let's avoid the POSIX errno example
> where some properties can have many valid keys, we'd just need to
> decide which are which, and go to the simplest, a UNIX(TM) style
> 'generic-c-lib that to the very limited extent I've exercised it, only
> returns 0 on success and -1 on failure, and as I recall you don't get
> anything more in any way:
>
> (convention generic-c-lib
>   sub-convention libsodium
>   scheme-procedure generate-key
>   foreign-interface sodium-init
>   message "generate-key: ecb-generate-key could not initialize sodium library\n")
>
> Here the sub-convention is just to tell you that it came from
> libsodium instead of, say, something interacting with a cloud API, the
> other keys are bog standard ones that are also used in the above
> PostgreSQL example.

Sure, that's also reasonable.

I'd differentiate between the meaning of the error code, and where it
came from (source). You put the source in 'sub-convention as with
postgres. That's one way to do it. Also with a 'generic-c-lib convention
a more specific interpretation is not really needed?

>> - I believe a single-inheritance class hierarchy would 1) add complexity
>> we don't need;
>
> I believe we need the complexity you fear, and that it also reduces
> ... if not complexity, intensity needed to define the "standard" keys
> without painting ourselves into a corner when for example a new
> foreign interface uses a word or words of art that are already one of
> the existing 15-50 standard keys.

This we cleared up above; I agree with you that some properties should
affect the interpretation of other properties. (Or at least make a
precise interpretation possible where it would otherwise be vague.)

> The real world is messy, not sure the cost of the above dilemma is
> greater than the cost of my vision.

>> It also seems to me that your main opposition to my approach is that you
>> think it's 1) confusing to the user receiving status objects; 2)
>> unreliable to the user receiving status objects.
>
> My main objections are WRT to the user creating status objects, but as
> illustrated above, the consumer of them is of course also in play.  If
> a convention tightly defines what a key's property means, 1) should not
> be an issue aside from looking that data up in the library documentation
> or the Schemeregistry, 2) I don't understand your question.

Unreliable as in the receiver can't figure out what a particular status
means if there's no clear hierarchy.

It seems we notice the same risks but weigh their likelihoods
differently. So the glass-half-full interpretation is that we almost
agree :)