Gregory, Arofan wrote: > > 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. But I am not calling for alphanumeric codes for human consumption. What I am calling for is use of unambiguous, national language independent numeric codes for use by validation engines. For human consumption, I would promote the display and use of meaningful, readable text. But that said, how can I claim that USA is the most meaningful representation for a given reader? Isn't it true that a French reader might prefer Etats-Unis over United States . Numeric characters can be placed in a code list just as easily as the alphabetic characters being proposed now. That is, I can use the characters 840 in an enumerated type just as easily as I can use USA . > 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 Absolutely. Three character code list values are not suggested for use as tag names (I hope.) > (2) Make sure that our presentation of code values has a simple default > that doesn't rely on the implementer's interpretation of it Then ROM or ROU ? Which is more precise and clear? Neither. It is the numeric identifier that is stable and best used for validation. But neither 642 , ROM nor ROU is very good for presentation. > (3) Make things human-readable where there is no good reason not to Sure. But the case we discuss of ROM or ROU provides a good reason, instability, not to use them. And I can hardly believe I here about the readability of ROU . Give me a break. Outside of the present context of this discussion, which of us, presented with these three characters would grok Romania ? USA , well sure, we all know what that is. But ROU ? Isn't that Kanga's kid? > 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. I don't think that we ARE conveying anything complex here. These are not country names, they are country codes. Country code B has no significant semantic value over country code 2 . And a decent user interface would let a user type in ROU , map this value to 642 before actual validation. > 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. In my opinion, ROU is not any better presentation than displaying a number. Neither should be displayed. The display should be Romania for English speakers and Roumanie if you prefer French. > (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...) Not an issue. Either way, 840 or USA is the same size. Either could be used by a validation tool, but the first one is a stable value and the second subject to change. Neither should ever be displayed to provide meaning to a human, but should be used locally to identify a piece of text suitable to the language of the reader. For data entry? Who knows which is best. My wife's an accountant and would probably prefer entering 840 on a numeric key pad. I'd probably opt for usa and expect it to work regardless of case. Phil > Cheers, > > Arofan > >