Folks:
I must point out that one of the things that has always struck me about EDI
was that, because non-intuitive alphanumeric "codes" were used to such a
great extent, the language became arcane and subject to abuse. This leads to
expensive implementations.
This is *not* a point about the separation of presentation and content,
which can be achieved in any number of ways (at least two of which underly
the current discussion, and I'm not sure they're compatible).
I think we want to do a few simple things that EDI has failed to do with
codes:
(1) Present our semantics clearly: intuitive tag names with absolutely clear
definitions
(2) Make sure that our "presentation" of code values has a simple default
that doesn't rely on the implementer's interpretation of it
(3) Make things human-readable where there is no good reason not to
If we return to using alphanumeric codes to (supposedly) convey complex
semantics, we have merely added a layer of obscurity that doesn't really buy
us very much.
The point of separating content and presentation reads, to my way of
thinking: "don't let presentation concerns cloud your semantic definitions".
I think that this is the heritage of XML, as I understand it. Having
non-readable alphanumeric codes is a violation of this rule, to my way of
thinking, and we should not go there unles it buys us something important.
(All right, Phil: let's talk about compactness of expression now! However, I
will point you to the design principles around tag naming that Eve had us
prioritize at the F2F...)
Cheers,
Arofan