[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]