RE: OASIS CIQ - next iteration GlobalAddress / CIQ Address

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

Vincent


> >
> > > - 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".
> >
> > I personally feel that this is dangerous because as such we
> > do not know
> > how many values for types are available. Instead, if we
> > provide them the
> > tag for type definition, customer can always wrap the value
> > for types using
> > this tag and it makes it easy for them to process the data.
> > Using attributes
> > in XML where we are not definite about the different values
> > for it, always
> > restricts the language. This is my opinion. For example, let
> > us say that we
> > have identified 50 possible values for a type. When we take
> > this language to
> > all countries, we could end up with more than 300 values.
> > This makes the
> > language complex.
>
> I think my proposal covers this. We DO know a number of
> common classifiers
> (many of which are not defined by us but by the postal
> authorities), and it
> would be very helpful if at least for these a common language
> is used (not
> depending on individual agreements between trading partners).
> My proposal is
> a way to do this, while at the same time allowing for a *controlled*
> (recognizable) extension mechanism.
>
> Anyway, we do not have identified 50 classifiers and I do not
> believe we
> will ever reach 300 ;-)

The question then is, do we want to cover the postal rules assigned by the
postal autohority of a country  in our language? I guess not. I am afraid
that it
is not easy to define a common language for the classifiers and expect  the
users to follow it. If we leave it open with a tag for common classifiers,
users
then have the choice to wrap their existing data variations with our
language. This is
my suggestion.

>
> >
> > > - 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)
> >
> > Well, not true. Infact, all our customers (blue chips namely,
> > insurance,
> > govt. agencies,
> > Telcos., retail, etc) in Australia, NewZealand, USA and
> > Canada store this
> > level of granularity
> > in their database to perform de-dup and validation and for
> > data quality
> > audit purposes.
> > This level of granularity is needed by these companies. I, therefore
> > strongly uggest that we have
> > this granularity level in xNAL.

We need this level of detail in the current version. Otherwise, customers
like ours (MSI) will not be in a position to use this language.

> > > - 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?
> >
> > Normally it is either or. Either detailed level or a higher level.
> > I do not see both are being used at the same time, but I
> > could be wrong!
>
> Let's keep it his way then - it prohibits inconsistencies
> which is what this
> is all about.
>
>
> > > - Addressee?
> >
> > I am not clear about this question. Can you please explain further?
>
> And to no surprise :-)  I was thinking about the need to
> represent a person
> also. There are two cases here:
> - GlobalAddress used to (see below) cover only the Postal
> Authorities (PA)
> responsiblity, and any internal mail handling after the PA
> had delivered to
> the mailbox was kept out. This is an issue with
> LargeMailUsers (see below),
> but if we solve it there we may as well solve it for normal
> companies and
> home addresses also.
> - In some cases the person name is mandatory even for the PA
> delivery: in
> case of a "Poste Restante" delivery to a post office (I
> believe in the UK
> also called "to be called for") only an officially identified
> person may
> pick up the mail. The GlobalAddress spec covers delivery to a
> post office,
> but then stops and not includes the persons name (yet).
>
> The question was: I am thinking about this further, but
> wondered if you had
> some ideas as well.

Well, users can always use the name component of the xNAL
to define the name that must go with the address. Given that the
name component is flexible (optional fields for both high level
representation and detailed level representation), users can pick and
use the tags they want.

> > > - 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.
> >
> > Agreed. We have to work on this.
> >
> > I will get back with more feedback after having gone through
> > the specs.
> >
> > Regards
> >
> > Ram
> > >
> > > As said, there are also some questions that I have to forward
> > > internally to
> > > our address experts - I will get back on that.
> > >
> > >
> > Further thought:
> >
> > We have to be careful in defining "mandatory" fields as it
> puts lot of
> > restrictions on the end users. Here the role of xNAL is not
> to define
> > how an address structure should be, it is intended to be a language
> > that can adopt to different address representations that
> > exist in customer
> > databases that enables interchange of data across platforms, tools
> > and products. xNAL is for data interchangeability and not
> for defining
> > a global name and address structure in XML.
> >
> > For example, an organisation might not have stored postcode as part
> > of its data. In such a case, if they use xNAL, they will be
> > forced to fill
> > in postcode that does not exist if xNAL makes postcode mandatory.
>
>
> I agree, and I am not suggesting to stretch the number of
> required field to
> the max. However, there are mandatory fields which are
> prescribed not by us,
> but by the PAs.

As I mentioned in my previous section, as soon as we start tuning
xNAL to support the rules prescribed by PAs, we could end up
making the language complex. Many countries do not have the
concept of postal rules and probably, they will never. Therefore,
my suggestion is to forget the rules of PAs and concentrate on
providing enough flexibility to users that will enable them to move their
existing data into xNAL.

>
> So from your example, yes I do believe should make postcode
> mandatory if we
> could (we don't because this is country dependent, and the
> formal spec is
> not. Maybe later we could by further detailing). If an
> address does not meet
> the specifications (one does not have the PC in the data while it is
> mandatory in the spec), it is possible to specify that in a
> PAB (Partial
> Address Block).

We must make postcode mandatory only if the user wants to break postcode
into individual elements. Otherwhise, we do not want to make it mandatory.
By doing this, we need to change the language in any way to handle countries
without postcodes. What do you think?

>
> As an example, a fully specified address in the Netherlands is:
> <GlobalAddress>
> 	<Country>
> 		<CountryCode Scheme="iso" Code="NL" />
> 		<CountryName NameType="official"
> xml:lang="en">Netherlands</CountryName>
> 		<CountryName NameType="official"
> xml:lang="nl">Nederland</CountryName>
> 		<CountryName NameType="synonym">Holland</CountryName>
> 		<Locality>
> 			<LocalityName>Leiden</LocalityName>
> 			<Street>
> 				<StreetName>Klikspaanweg</StreetName>
> 				<Premise>
>
> <PremiseNumber>107</PremiseNumber>
> 					<PostalCode>
>
> <PostalCodeNumber>2324 LV</PostalCodeNumber>
> 					</PostalCode>
> 				</Premise>
> 			</Street>
> 		</Locality>
> 	</Country>
> </GlobalAddress>
>
> In the current spec, the postal code is optional (for reasons
> mentioned
> above), but if it would be mandatory and the sender does not have this
> information, the address could be sent as:
>
> <GlobalAddress>
> 	<Country>
> 		<CountryCode Scheme="iso" Code="NL" />
> 		<CountryName NameType="official"
> xml:lang="en">Netherlands</CountryName>
> 		<CountryName NameType="official"
> xml:lang="nl">Nederland</CountryName>
> 		<CountryName NameType="synonym">Holland</CountryName>
> 		<Locality>
> 			<LocalityName>Leiden</LocalityName>
> 			<Street>
> 				<AddressLines>
>
> <AddressLine>Klikspaanweg 107</AddressLine>
> 				</AddressLines>
> 			</Street>
> 		</Locality>
> 	</Country>
> </GlobalAddress>
>
> The receiver then knows that these addresslines should
> contain street and/or
> postal code, but also that this information is not thoroughly
> checked and
> guaranteed correct.

No, what I am saying is that the user must be able to break the
address lines also (in the second example code above) along with
the option of using a postcode or not. Given that
<PostalCode> is optional, the user need not specify. If the postal
code has to be specified, the user should have two options:

- Represent the postal code at a higher level
- represent the postal code at an elementised level

Eg. if the postal code is 12345-6789,

the higher level representation is:

<PostalCode>12345-6789<PostalCode>  {PostCode is optional}

If the user wants to represent the postal code at a detailed level,
then the detailed level fields are mandatory as shown below:

<PostalCodeDetails> {PostCodeDetails is otional}
  <PostCode>12345</PostCode>  {PostCde is mandatory}
  <ExtendedPostCode>6789</ExtendedPostCode> {ExtendedPostCode is mandatory}
</PostCodeDetails>

By doing this, we are not forcing the user with madatory fields.
We are infact providing flexibility to the user.


Regards

Ram

>
> Adios,
> Vince
>
>
>
> >
> > Mandatory fields  will be important in cases where one prefers to
> > go for a detailed level. For example, let us take the following
> > example:
> >
> > 23 Archer Street
> > Boulder, CO 12345-1234
> >
> > At a higher level, the representation in XML will be:
> >
> > <street>23 Archer Street</street>
> > <locality>Boulder</locality>
> > <state>Co</state>
> > <postcode>12345-5678</postcode>
> >
> > But, if the user wants to use a detailed level of representation for
> > postcode so that it is:
> >
> > <postcodedetails>
> >  <postcode>12345</postcode>
> >  <extendedpostcode>5678</extendedpostcode>
> > </postcode>
> >
> > then postcode and extendedpostcode becomes mandatory fields under
> > the postcodedetails tag of xNAL.
> >
> > Cheers
> >
> > Ram
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ciq-request@lists.oasis-open.org
> >
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ciq-request@lists.oasis-open.org
>