FW: UBL Address format vs. CIQ

["Ram Kumar" <RKumar@msi.com.au>]

CIQ TC,

 

FYI regarding UBL and CIQ from Tim McGrath of UBL.

 

Michael,

 

You have promised to look into the compatibility between

NDR of UBL and CIQ. Can you please advise of your progress

on this? Thanks.

 

Regards,

Ram

Ram Kumar
General Manager
Software R&D and Architecture
MSI BUSINESS SYSTEMS
Suite 204A, 244 Beecroft Road
Epping, NSW 2121, Australia
Direct: +61-2-9815 0226
Mobile: +61-412 758 025
Fax: +61-2-98150200
URL: www.msi.com.au

 

---

From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: Tuesday, October 12, 2004 10:43 AM
To: Colin.Wallis@ssc.govt.nz
Cc: jon.bosak@sun.com; Ram Kumar
Subject: Re: UBL Address format vs. CIQ

thank you for your support of UBL.  i will attempt to address 
(pun intended) your comments, but this is merely my own opinion and not 
necessarily that of the UBL technical committee.

personally, i had 
thought UBL had shifted towards xNAL not away from it.  perhaps you can 
give some examples? we deliberately include the xNAL terms as synonymous 
business terms in our library.  in fact, we have had a continuous dialogue 
with the CIQ team throughout UBL's development.  you may also be aware that 
CIQ are not the only players working on standards for addressing and UBL has 
tried to accomodate the work of various ISO groups, the UN/ECE as well as our 
own team of ontologists.

you mention UBL's flexibility.  we have 
tried to take an 80/20 approach to business requirements.  we know that 
very few implementors will be able to use UBL without some form of 
customization.  we have tried to provide a common base on which these 
customization are built.  this is important to the points that 
follow.

the main issues why UBL could not simply 'use xNAL' are:
* 
xNAL does not define a single address structure.  it is a rich vocabulary 
that can be used to structure various different forms of addressing.  two 
parties using xNAL may not have any more compatibility than two using two 
different vocabularies. UBL must have only one way to form an address.  so 
we wwould still need a UBl implementation of xNAL that may not be the same as NZ 
Government, etc., etc..
* xNAL sometimes uses the concept of qualifying 
values for its semantic names.  you mention thoroughfare and this is a case 
in point.  unless parties subsequently agreed how to qualify thoroughfare - 
they may well use two different ways of defining street or avenue, etc.. 
 UBL could have provided these qualifiers for our requirements but this 
breaks the design philosophy UBL was built on.  i believe that taking this 
approach recreates the problems people had with EDI-based vocabularies.
* the 
requirement for addresses in UBL is not simply for postal services or CRM 
applications - xNAL's primary target.  this is why xNAL has a much more 
sophisticated data model.  
* the actual XML syntax used by xNAL is not 
the same as UBL's XML naming and design rules.  the technical people in UBL 
tell me this would make using actual xNAL schemas difficult and UBL would have 
to recreate xNAL in its own schemas.  we then have a maintenance issue with 
keeping synchronized into the future.

these are all the practical results 
of separate initiatives developing standards.  in this situation, the best 
we can hope to achieve is some form of interoperability.  specifically, 
this would mean being able to map an address presented in a UBL document to 
something equivalent in an xNAL format and vice versa.  To this end UBL 
provides the equivalent xNAL terms in our model (something we dont do for any 
other vocabulary).  but as you point out this is not a clean map - 
today.

looking forward, i am aware that the CIQ team are considering 
using UBL's XML  naming and design rules for future releases.  this 
will resolve at least one the issues above.

personally, i am a supporter 
of the work of the CIQ team and would like to see convergence.  It is 
feasible that UBL 2.0 may be closer to xNAL ?.??  but this would need to be 
evolutionary.  in fact, i am meeting Ram Kumar, the chair of the CIQ team, 
in two weeks time and we shall certainly be talking about these 
issues.


PS
i hope i am not being presumptuous by including Ram and 
Jon in this response.  i think they both have an interest in the 
matter.

Colin.Wallis@ssc.govt.nz wrote:

Hi Tim

 

I got your contact details from Jon Bosak. Jon and I talked on the phone at the recent e-gov OASIS meeting.

 

I expressed some concerns around the shift from the early UBL drafts which used CIQ exclusively, to V1 where some of those element names have been replaced. Also I am not sure if any testing of UBL address structures against UPU address structures has been done.

 

I know terms like "thoroughfare" are not the most user friendly and in NZ where xNAL is mandatory for government agencies data exchange we have had heated discussions on such issues. That said, we have stuck to it because there is logic in it, after you have used CIQ for a while. Even in our own environment, there are addresses which do not easily (semantically) fit UBL's "StreetType" and you would find that in OZ too before even looking elsewhere in the world.

 

I know UBL is flexible enough to pretty much put whatever elements you want in there, but it becomes a real pain getting that agreement across a whole spectrum of parties, altering parsers to suit etc etc.

 

I don't know how much deep thought was put into this change and if it is irreversible?

 

That said, I fully support UBL and what it is trying to achieve.

 

But I have to raise this issue as it will potentially hamper the rate of adoption in NZ govt.

 

Cheers

 

Colin

 

Colin Wallis
e-GIF Business Analyst
e-Government Unit - State Services Commission
T: 04 495 6758

http://www.e-government.govt.nz

 

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160