Mike, Mike Rawlins wrote: > > This discussion has hit enough different points that I'm somewhat unclear about > the original point. However, there have been a few things said that I find > somewhat discomforting or not on target. > > May I offer a few bottom-line points regarding codes, representations, etc : > Codes are generally used for dictates imposed by business applications, and that > is where we really need to base our decisions. If a code lists offers both a > numeric representation and an alphanumeric one for the code value (there may be > some, but I've never seen any that do), then we choose the one most used by > business applications. That should be a no-brainer. Country codes have both an alphabetic and a numeric format. The alphabetic format is subject to change, as illustrated by the request of Romania to change their designation - but not their country number. > In addition, most code lists are neutral to spoken languages when we consider > the code value (which is what appears in the datastream) and not the code > description. This may be true for many business codes. But it is clear from the change from ROM to ROU that the former spelling comes close to English and new spelling to French. > I don't see the problem. Is there something here I'm missing??? No problem. Just use 642 and you've got a stable identifier that's independent of national language. :-) Phil > Cheers, > > Mike > > 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. > > > > 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 > > > >