RE: OASIS CIQ - next iteration GlobalAddress / CIQ Address

[Vincent Buller <vincent@and.nl>]

Hi Ram,

a single response to your two mails:


> Just a few quick comments:
>
> > 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".
>
> 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 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.



>
> > - 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.



>
> > - 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.

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).

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.

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
>