RE: [ciq] follow up on David Putman's comments

["John D. Putman" <jdputman@fedex.com>]

"COMMENT"s in body of you Email. 

-----Original Message-----
From: Max Voskob [mailto:max.voskob@paradise.net.nz] 
Sent: Monday, May 02, 2005 5:19 AM
To: ciq@lists.oasis-open.org
Subject: [ciq] follow up on David Putman's comments

Hi David,

I was going thru your comments that I printed out some time ago.

I think I reflected some of your suggestions, but I'd like to clarify some
others.


--- Order of elements ---
On the one hand the order of free text address must be preserved, on the
other, the presentation is locale dependent.
I suggest the only requirement:
1. The order must be preserved

How the address is presented is for the implementation to decide.
Ultimately, it is the humans that will use the address or the address must
go thru a parser to be used by machines for some sorting or delivery
purposes.

COMMENT: Okay, but that order SHOULD preserve all of the data within the
address.  That SHOULD include punctuation (some of which is critical to the
"meaning" of the address!).

-------------------------

--- Administrative area vs. Locality --- I agree that the boundary is very
vague. Shall we merge them and make a hierarchical structure where one area
is included in the other?
It is unlikely to go down further than 3 levels.

COMMENT: Unfortunately, "postal standards" as evidenced in some UPU examples
and many other "common use" examples do include more than three (at least
for "administrative area" and perhaps for "locality".  The only way to
bypass this is to either create an unbounded structure for their
instantiation or just lodge them in undifferentiated (not split up) address
lines - even in the detailed model!

----------------------------------------

--- Postal elements ---
What are the alternatives to the current structure?
You are saying it's not that good, but I can't think of anything better.
Any suggestions?

COMMENT:  Yes, I am suggesting that there be a specific sub-structure and/or
types / attributes to identify those - as those are SOMETIMES the complete
and only representation of an address.  This "complete and only" is mostly
contained in the address lines NOT associated with city, state, and country
("adminstrativer areas").  However, "unique ZIP" type addresses in the USA
can be comprised only and totally of what one might term "postal elements".
That is, only a ZIP code (a postal element) is required and the "city" can
actually be a firm name.  In USA internal addressing (as with most other
countries!), NO country is present (only implied).
-----------------------

--- Care of ---
Look, I'm confused myself here who's in care of who. We need revisit this
with more use cases.
---------------

COMMENT:  Okay.  But basically, ANYONE / ANYTHING can be put in (after) a
"care of" indication for any one of a number of valid and needed purposes.
It might be the person normally residing at an address (say, accepting
delivery for a guest who is designated as the primary recipient).  It can be
another person / function / department at a business address for any one of
a number of reasons (defunct department; person acting for a person on
leave; temporary running of a function in another area, etc.); it can also
be used for specifying a physical or logical "mail stop" to which the mail
should be delivered (a way of routing to the intended recipient via
company-internal, interoffice mail).  It might be a services organization
for a person (private mail box companies) or business (bill receiving
agency; so that "care of" specifies the "real recipient" (by name, code /
account number, etc.), while the service provider recipient actually
receives the mail and holds or forwards it to their customer (the address
provided IS "properly" associated with the service provider recipient!).
For General Delivery addresses, it can specify WHO can pick up the mail at a
post office other than the primary recipient.

--- Examples ---
Most of the examples were made up leading to poor diversity.
What we need is a bunch of realistic and diverse examples. 
Let's create and maintain a doco with examples. It will allow us to rebuild
test cases when the schema changes.
----------------

COMMENT: Good and agreed.

Cheers,
Max












---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php