>> 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.
>
> Both of the above are sounding a bit like like our convention concept.

Indeed, they are basically equivalent.

The difference is that you'd have one convention (or one convention with
one subconvention) per status object. With prefixes, you can mix more
than one convention in the same object and one of them doesn't have to
be the main one.

>> 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.
>
> TILT / face palm / segment fault.
>
> Why is this not in the remit of Schemeregistry?  If only to help
> people building new interfaces that share some characteristics
> beyond the most common 15-50?

I absolutely agree that properties should go into the registry, and
different status sources returning similar information should strive to
use the same property names with compatible data types and semantics.

> How is this even vaguely practical?   In your vision that knowledge
> will be smeared across the Internet, the Wayback Machine, etc., or
> worse, require bothering a developer for something you could just
> look up in the registry?

No, we should definitely strive to keep the registry as comprehensive as
possible. But I've learned to approach things from the standpoint that
implementations are primary, and if a standard is too fancy,
implementors start to diverge.

The IANA MIME type registry is a good example. People coin new MIME
types all the time that are not in the registry. Perhaps the IANA
submission process is heavyweight (it is) or something. Whatever the
reason, the MIME types out there in the wild have to be primary, with
the IANA registry serving as documentation.

Ideally a registry serves as a specification, but if the rules are too
strict, it is reduced to incomplete documentation. Documentation must be
primary.

>> You'd think all SQL databases use SQLSTATE codes, but maybe not.
>
> In that case, we'd expect the interface writer to notice his database
> that speaks (some) SQL doesn't return SQLSTATEs, and not use the
> 'sqlstate convention.  But he'd likely pick up some clues as to what
> to use from looking at that convention, or perhaps a 'no-sql
> convention if there's enough commonality in that class of databases
> to create such a top level convention, etc. etc.

SQLSTATE and errno are examples of standard error code templates to
which it's useful to translate the native codes from other systems.

How do we tell ahead of time which error sets are useful targets for
such translation, and which are not? If someone wants to translate some
kind of errors to their Windows API equivalents and also retain the
original native error codes for reference, what do we do?

>> What we're doing is kind of like duck typing in OOP.
>
> That's what you're doing.  We're saying that if you want to get more
> sophisticated than the 'error or 'status conventions, we'd really like
> you to search for prior art on the registry, and register new stuff
> you come up with *with explanations for your new properties*.
>
> Of course, we'll have keys who's properties in the wild have subtle or
> vast differences, won't be registered, etc. etc.  Maybe John and my
> vision is unrealistic....

I don't think it's unrealistic but I suspect that it's incomplete. We
may run into corner cases that are difficult to fit into it. The case of
returning synthetic errno values from the Windows API, and of SQLite
missing SQLSTATE, starts to get into the territory I'm thinking of.

I think our main point of disagreement/misunderstanding is how
predictable the world is. I'm heavily biased against organizing and
making decisions that don't have to be made, because I've seen many
standards that made decisions turning out bad or suboptimal. When it
comes to foreign systems, I generally prefer the alternative that is
simpler, makes fewer decisions and leaves more options open. I guess
that's the root of why I argue for my position. I just don't trust that
people can write specs, and I don't want to specify things that will be
used in a context that I don't yet understand.