RE: new ECML v 2 requirements from Nokia

We are just updating our tax and shipping calculator so this is quite
relevant to us at the moment.
 
Currently the ISO codes give us a reasonable number of countries.  However
there are a number of different issues.
 
E.g. Isle of Man has different tax implications for shipping from the UK and
may have different costs.
 
It does not appear to have an ISO 2 letter or 3 letter code but has a
Numerical Code.  The ISO Alpha 3 code does seem more comprehensive than the
2 letter codes however it is not freely available.
http://unstats.un.org/unsd/methods/m49/m49alpha.htm
<http://unstats.un.org/unsd/methods/m49/m49alpha.htm> 
vs
http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/inde
x.html
<http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/ind
ex.html>   <http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1/> 
 
The ISO codes are easy to find however, I had a quick trawl 
through http://www.xcbl.org <http://www.xcbl.org>  
and http://www.oasis-open.org/committees/ubl/
<http://www.oasis-open.org/committees/ubl/> 
 
and I was not able to find the current Othercountries list which is clearly
going to be vital for interoperability.
 
A link would be much appreciated.
 
There are large numbers of principalities and tax havens in the world and a
common way of referencing them would be nice.
 
Regards -- Ronald

-----Original Message-----
From: Burdett, David [mailto:[email protected]]
Sent: 11 June 2002 16:02
To: 'Chris Smith'; Donald Eastlake 3rd
Cc: Eric Brunner; [email protected]; [email protected];
[email protected]
Subject: RE: new ECML v 2 requirements from Nokia



Chris, Donald, Eric and others 

It's a sad but real fact that Standards groups always lag behind the real
world. ISO with their country codes (and currency codes) is no exception.
However the alternative of not following any standard is worse since you
don't get the interoperability we all seek. 

We've faced this exact problem several times before and came up with the
following solution which, although not ideal actually works and is being
used in eCommerce today which. It involves the use of two codes:

1. CountryCode which MUST contain either an ISO3166-1997 compliant country
code or the text "Other" 
2. CountryCodeOther, which contains some other, mutually agreed code to
identify a country if "CountryCode" on those few occasions when an ISO3166
code will not suffice. It is only used if CountryCode contains the text
"Other".

This idea is taken from the XML Common Business Language - xCBL (
http://www.xcbl.org <http://www.xcbl.org> ) which is a set of XML Business
Document definitions that Commerce One developed and is now being taken as
the basis for the UBL standards initiative (
http://www.oasis-open.org/committees/ubl/
<http://www.oasis-open.org/committees/ubl/> ).

We often come under pressure to add new country codes and, even more, new
currency codes, to xCBL but have always resisted since it is impossible to
do this in a fair way. We simply say, when ISO comes up with a new list we
will use it, but not until.

I hope these ideas help. 

David 


-----Original Message----- 
From: Chris Smith [ mailto:[email protected] <mailto:[email protected]> ] 
Sent: Monday, June 10, 2002 9:47 PM 
To: Donald Eastlake 3rd 
Cc: Eric Brunner; [email protected]; [email protected]; 
[email protected] 
Subject: Re: new ECML v 2 requirements from Nokia 


Previously, Donald Eastlake 3rd and Eric Brunner wrote: 

> > The big issue is jurisdiction, from which the regulatory circumstances
and 
> > taxation consequences of a transaction arise. 

> > > I'm not quite so clear on country codes but if you include the codes 
> > > reserved in ISO 3166 but not actually issued, I think you cover the
entities 
> > > in the Universal Postal Union.  Can you give an example of a
jurisdiction 
> > > not covered by that which would be of any significance in this
protocol? 

There needs to be a decision regarding a geographical basis vs a 
political basis. ISO 3166 refers to "areas of geopolitical 
interest", and won't completely resolve the issue for you. 

Many embassies are in Washington DC, U.S.A, but the embassies 
proper are considered sovereign. Jurisdiction and location 
can be independent at times. 

> The Navajo Nation, etc., are subordinate entities that are 
> "soveriegn" only to the extent that the US allows. 

Subject to occasional court decisions, both ways... 

> Since you talk about tax consequences, it can vary in the US 
> not just on state/indian-nation but also city, county, 
> special districts, and who knows what else... 

Don't forget parish. Yes, accomodating this could be difficult. 
If it was easy we would be done by now... 

> So you don't like iso3166. What exactly is your alternative? You make a 
> reasonable argument that there is some benefit in being able to extend 
> iso3166 codes, the same way the IETF standard lets you extend ISO 
> language codes, 

Even ISO 3166 documents some of the 'extensions' - witness the 
addition of "ca-nu". But it also clear that in some cases, the 
chain of jurisdiction does not flow all the way back to "ca". 

So, the choice would appear to be between 

1) ISO 3166 codes and restricting the field as such 
2) allow ISO and private codes with a way to distinguish 
3) provide one ISO field and one 'Jurisdiction' field 

1) is tough and inflexible 
2) tends towards non-interoperable 
3) is growing the complexity 

It depends on what the goal is - what IS the goal for 
this field, anyway? 

---------------------------------------------------------------------- 
Chris Smith                                       <[email protected]>