Re: [ciq] Closing date for review of CIQ Specs. V3.0 due 16 January 2006

Subject: Re: [ciq] Closing date for review of CIQ Specs. V3.0 due 16 January 2006

On 1/18/06, Michael.Roytman@vertexinc.com <Michael.Roytman@vertexinc.com > wrote:

Ram,

I will echo Joe's comments related to parsing of lower level elements and
overall XML Schema structures. I have been looking at CIQ as being a set of
"core" components for names, addresses, relationships and how these could
be used to create structures within Tax XML. As an example I will use Tax
XML Certificate of Residence project, which requires a standard name of an
individual, birthday, nationality, current residence address. For the most
part I will be able to use the PartyNameType, BirthInfo element, and
AddressType to get most of the structure, but Nationalities is a bit
trickier. It is a container, and an element, so I have to reference it,
which will not allow me to extend it.

Also, grCommon1 could have a more meaningful name, like grDataQuality. The
types listed are code lists/enumerations and could have been named as such.

Overall, the structures do look easier to navigate and learn, but a lot of
testing by various business groups will be necessary to achieve expected
flexibility and reuse.
Thanks,

Michael Roytman.

|---------+---------------------------->
|         |           "Joe Lubenow"    |
|         |           <lubenow@msn.com>|
|         |                            |
|         |           01/16/2006 02:31 |
|         |           AM               |
|         |                            |
|---------+---------------------------->
>-------------------------------------------------------------------------------------------------------------------------------|
|                                                                                                                               |
|       To:       <ciq@lists.oasis-open.org >, "Ram Kumar" <kumar.sydney@gmail.com>                                              |
|       cc:                                                                                                                     |
|       Subject:  Re: [ciq] Closing date for review of CIQ Specs. V3.0 due 16 January 2006                                      |
>-------------------------------------------------------------------------------------------------------------------------------|

Ram,

Here are some comments on version 3.0 as you requested.

On the whole, it does seem simpler than the previous version and yet able
to handle complicated examples.  There are numerous examples provided, and
as a general rule the mappings seem quite sensible.

The documentation is very fair to point out that an unparsed field cannot
be assigned to lower level elements without parsing using rules that are
outside of the scope.  But as you state, often it is simple to combine
lower level elements into a single higher level element.  In view of this,
it perhaps should be explicitly stated that achieving interoperability may
be facilitated by having a strong parsing capability and using lower level
elements where possible.

A potential difficulty exists when a region is used for both a region
within a country and a multi-country region.  See the example from Grenada
for this.  It would be helpful to distinguish between these two situations
because a region within a country generally comes before the country name,
while a multi-country region generally comes after the country name.

The example from Saudi Arabia assigns "Diplomatic Quarter" to Premises, but
perhaps this should be a Locality.

The examples from the Russian Federation and Ukraine seem inconsistent.  In
the Ukraine example a raion (r-n) is a district and an oblast (obl) is a
region.  But in the Russian Federation example these assignments are
reversed.

Some addresses in Australia, such as Unit 12, 23 Archer Street, can also be
written in a more compact form as 12/23 Archer Street.  In this case, users
of the specification might map the whole line to thoroughfare, or they
might map 12 as a premise number.  There does not seem to be an easy way to
achieve uniformity in this sort of practice, and clearly it could have an
effect on the success of de-duplication.

In a specifically postal context, many postal services do not want to see
multiple delivery points in the same address, such as a post office box and
a street address.  These are often not just different delivery points, but
do not even have the same postal code.  In such a situation the notion of
validity is ambiguous.  A possible example of this in your sample addresses
is Switzerland.  However, such addresses are frequently observed, so the
example is not erroneous.

In the overview you refer to the GCA and IDEAlliance and the ADIS
specification.  It has now been four years since the GCA became
IDEAlliance, so you might drop the reference to GCA.  But more important,
it is not correct to say, as you currently do, that the UPU has approved
ADIS.  Rather, you could say that ADIS shares some features with the UPU
standard.

Thanks for the opportunity to comment.

Joe Lubenow

----- Original Message -----
From: Ram Kumar
To: ciq@lists.oasis-open.org
Sent: Sunday, January 15, 2006 7:00 PM
Subject: [ciq] Closing date for review of CIQ Specs. V3.0 due 16 January
2006

CIQ TC,

This is a reminder regarding the review of CIQ TC Specs. V3.0.
The reviews must be completed by 16 January 2006 as we need
to move to the next stage, i.e. vote on the specs. for approval
as a committee specs./draft.

Thanks

Regards,

Ram

ciq message