Hmm, the old language-specific argument. The usual solution to this is to use a binary encoding, the theory being that by avoiding words, you avoid chauvinism. I'd still rather have a textual format, even if the attribute names have to be translated for speakers of other languages (they'd have to translate a binary encoding into their own language anyway). If we wanted to inconvenience everyone equally, the attribute names could be gibberish.
I'm not convinced that the slight inefficiency matters, particular for a message format. We do build indices in /lib/ndb to speed searches, but that's for searching, not just encoding for transmission. If you're thinking of binary-decimal conversion overheads, one could insist upon using octal representation (as tar does), which can be converted more quickly than decimal, though that does make it a little less human-friendly. There has to be mapping between message format and something like a C struct (some internal representation). ASN.1 attempts to describe both, as I understand it, to facilitate conversion between the two.
