RE: OASIS CIQ - next iteration GlobalAddress / CIQ Address

[Vincent Buller <vincent@and.nl>]

Ram,
that is okay as I will be incommunicado for the next two weeks. 
Vince

> -----Original Message-----
> From: Ram Kumar [mailto:rkumar@msi.com.au]
> Sent: Thursday, March 22, 2001 11:54 PM
> To: ciq@lists.oasis-open.org
> Subject: RE: OASIS CIQ - next iteration GlobalAddress / CIQ Address
> 
> 
> 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/
> > 
> > 
> > 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ciq-request@lists.oasis-open.org
>