Re: [clr-dev] Philosophy behind the CVA contracts

[ericdes <eric@vcardprocessor.com>]

Hi Ken,

I understand that ISO added a numeric value in the country list, 
probably because it's a best practice to have a primary key that doesn't 
carry a meaning in the relational database world.

But if these keys exist, then programs should use them. The problem is 
we all know there are reasons why people won't use them IN GENERAL. And 
I believe the CVA contracts are a much better way of representing the 
world as it is, i.e. denormalized.

I dreamed about doing things differently. I had this UBL sample in mind:

<PostalAddress>
<Country>
<IdentificationCode>US</IdentificationCode>
</Country>
</PostalAddress>

 From this sample, the XML record tells us that we're looking at an 
address label, and that we're going to derive the country name from its 
identification code. Country becomes CountryName in my mind because of 
the context set by PostalAddress. I'm then looking up the code US in the 
ISO list and find 'UNITED STATES'. And following my reasoning my label 
should say 'U.S.A.' because it's how I want to write the country name of 
'UNITED STATES' on a mailing label.

If a CVA partner wants to use the code 'USA' and that our agreed-upon 
code list says:

       <Row>
          <Value ColumnRef="code">
             <SimpleValue>USA</SimpleValue>
          </Value>
          <Value ColumnRef="name">
             <SimpleValue>UNITED STATES</SimpleValue>
          </Value>
       </Row>

Then a program could easily find that it relates to the same country 
because the value 'UNITED STATES' is identical in both lists. But it's 
implying that 'UNITED STATES' becomes kind of a universal key and it's a 
really bad practice to use strings for keys.

So let's take the case where our agreed-upon code list says:

       <Row>
          <Value ColumnRef="code">
             <SimpleValue>USA</SimpleValue>
          </Value>
          <Value ColumnRef="name">
             <SimpleValue>United States of America</SimpleValue>
          </Value>
       </Row>

It's obvious that human minds will make the link that both codes relate 
to the same country, but computers will get confused. Also, it's strange 
to notice that the ISO writes 'UNITED STATES' when the unambiguous name 
is 'United States of America'. These kinds of approximations will 
probably occur in customized agreed-upon code lists and don't play well 
with computerization.

I think that code lists should link the codes to unambiguous 
definitions. A bit like this:

       <Row>
          <Value ColumnRef="code">
             <SimpleValue>USA</SimpleValue>
          </Value>
          <Value ColumnRef="name">
             <SimpleValue>UNITED STATES</SimpleValue>
          </Value>
          <Definitions>
 
<Definition>http://en.wikipedia.org/wiki/United_States</Definition>
 
<Definition>http://legal-dictionary.thefreedictionary.com/United+states+of+america</Definition>
          </Value>

       </Row>

Rather than publishing a universal primary key that might work for 
countries but won't work for many other entities. We could imagine a 
program knowing some of these definitions and being able to understand 
external data through whatever they possess in memory.

Eric.