UBL Naming and Design Rules SC

 View Only

Re: [ubl-ndrsc] [Fwd: Fwd: ISO 3166-1 -- Change of Alpha-3CodeElement for Romania]

  • 1.  Re: [ubl-ndrsc] [Fwd: Fwd: ISO 3166-1 -- Change of Alpha-3CodeElement for Romania]

    Posted 02-11-2002 14:35
    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.
    
    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.
    
    I don't see the problem.  Is there something here I'm missing???
    
    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
    >
    >