RE: OASIS CIQ - next iteration GlobalAddress / CIQ Address

[Ram Kumar <rkumar@msi.com.au>]

Vincent

Thanks for the docs. Let me go through the docs. thoroughly and
carefully. This could take a while. 

Regards

Ram

> -----Original Message-----
> From: Vincent Buller [mailto:vincent@and.nl]
> Sent: Thursday, March 22, 2001 4:53 AM
> To: ciq@lists.oasis-open.org
> Subject: OASIS CIQ - next iteration GlobalAddress / CIQ Address
> 
> 
> Hello all,
> 
> please find the current (not finished) status of the address 
> specification.
> 
> I have reduced the hierarchical complexity of the Address 
> structures to
> reduce the likeliness of errors in the interpretation by 
> non-experts, trying
> not to lose correctness and validation power. The main 
> reduction comes from
> making less or no difference between Street+DependentStreet;
> Locality+DependentLocality (both simplified) and
> Premise+PremiseWithoutStreet (now identical). This comes at only some
> expense of validation (the number of nested levels cannot be 
> defined using
> Schema, and certainly not using DTDs).
> 
> As a result the remaining structures are a bit closer to the 
> NAML structures
> (but still with a hierarchy), which made the addition of 
> "imprecise" partial
> address blocks easier. Other than in NAML, I chose for 
> unspecified partial
> address blocks ("PABs") using "AddressLines" and 
> "AddressLine" element names
> instead of specific names such as "StreetAddressBlock". This 
> was something
> that the latest NAML spec was not precise in (I found some differences
> between the DTD and document) but IMO also cannot be solved 
> in a consistent
> manner (one would need StreetAddressDetails, but maybe also
> LocalityStreetAddressBlock or StreetAddressPremiseBlock etc.)
> 
> The AddressLines/AddressLine elements at a certain level are 
> supposed to
> contain all information in a raw form, that is otherwise 
> defined in detailed
> elements lower in the hierarchy. This structure has the 
> advantage that one
> can always drill down and specify some information exact at a 
> high level
> (Country, for example) while keeping the rest in a "PAB" - 
> this would allow
> at least for exact country level processing. Users of this 
> specification
> could in this manner gradually improve on the quality of their address
> processing or interchange.
> 
> Although I believe this version is a great step in the right 
> direction, I
> would hesitate to call this version a final yet. I need to 
> check some things
> internally with our address experts, and the documentation 
> definitely needs
> some extension/updating: Note that I didn't complete the Word 
> documentation;
> I have added some things to the introduction text (and am 
> sending this to
> give you a preview) but for the reference side of things I 
> had to include
> the generated HTML file (which I think is pretty good).
> 
> I also attached the comparison list between NAML and 
> GlobalAddress elements;
> note that not all the things I wrote are comments to the 
> earlier version
> (addressing GA 1.1), but also include changes from 
> GlobalAddress 1.1 to 1.2
> (which should become the xNAL Address spec).
> 
> Questions to be discussed:
> - Do we or don't we extensively specify values for types, such as
> "apartment", "lot", "pobox", "freepost" etc.? Suggestion: 
> predefine a known
> list and allow an extension mechanism, for example using 
> names preceded by
> an underscore character. For example: define "apartment" and allow
> "_cardboardbox".
> - The necessity to split street names further into main word, type
> ("street", "highway", "alley", "square", etc), etc. Wouldn't 
> this just be of
> interest to address-buffs like us? I don't believe there's 
> any customer db
> which has this level of granularity.
> - Same for postal number (pre- and postfix)
> - Like in NAML, I made it mandatory at every level to choose 
> between using
> AddressLines or using the detailed elements. This would avoid
> inconsistencies between the two representation methods, but 
> does anyone know
> a reason why you would want to do both?
> - Addressee?
> - Organization: We do definitely need "LargeMailUser" but for 
> the internal
> mail system we need something too. For example, the 
> LargeMailUser could be
> the US Armed Forces in Europe - how is an addressee further 
> identified. By
> his name + army unit I would say (not having experience in 
> this)? The AND
> GlobalAddress spec until now stopped with its definition 
> where the postal
> authority responsibility ended, but we need this further spec.
> 
> As said, there are also some questions that I have to forward 
> internally to
> our address experts - I will get back on that.
> 
> 
> Regards,
> 
> 
> Vincent Buller
> AND Data Solutions B.V.
> Product Development
> P.O. Box 29134
> 3001 GC Rotterdam
> The Netherlands
> -------------------------------------
> Telephone +31 (0)10 8851345
> Fax            +31 (0)10 8851300
> -------------------------------------
> Email: vincent.buller@and.com
> URL: http://www.and.com/
> 
> 
>