> Now comes the XML weenie lecture on "semantic markup".

I've internalized that, but still wonder about elements vs attributes :)

> We do have a dynamically typed programming language here, and this is an
> opportunity to take advantage of it.  What's important about a code
> value is that it is, semantically, a status code, pretty much
> meaningless to anyone except programmers and machines.  Whether it is
> represented within Scheme as a number, a symbol, or a string is entirely
> secondary,

I agree in principle, and this is a good demonstration of where dynamic
typing is nicer than static. However, more below.

> though we should give guidance like "If a code is numeric and
> leading zeros are not used, represent it as an exact integer; if it fits
> the rules for a symbol, use a symbol, but prefer strings to escaped
> symbols.  In any case, all the codes in a set should have the same
> Scheme type."

LGTM.

> I think that is clear without being restrictive, and much
> better than using different keys for what is semantically the same thing
> just because of type.  Yes, it's possible to fail to match because you
> don't know what the internal type is, but that can happen anywhere in
> Scheme programming.

Here the type is basically the meaning. It's like talking about "bold"
and "italic" in the context of a word processor. The meaning of 'number
is that it's the error number; the meaning of 'symbol is to be the error
symbol. We could call them 'error-number and 'error-symbol for extra
clarity, but as we've agreed they are not necessarily errors, and anyway
all error object properties would be something about errors.