[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ubl-lcsc] Aligning 'address' with CIQ xAL
Good Morning, afternoon, evening, WAKE-UP! Bill reported to me that he did not receive the message that I referenced yesterday and its quicker to resend rather than check the archives. Marion A. Royal 202.208.4643 (Office) 202.302.4634 (Mobile) ----- Forwarded by Marion A. Royal/MEB/CO/GSA/GOV on 10/30/2002 08:10 AM ----- "David RR To: "INTERNET:marion.royal@gsa.gov" <marion.royal@gsa.gov> Webber - cc: XMLGlobal" Subject: Re: [ubl-lcsc] Aligning 'address' with CIQ xAL <Gnosis_@compu serve.com> 10/28/2002 11:15 AM Marion, Thanks for the note. The key here is the ebXML work on assembly. Why? As the note from Tim shows tying CIQ terminology (or any address rules) into local usage is vital to gain acceptance. The CIQ team is looking at this with the US Gov, the USPS, HR-XML and the EECMA, to develop a layered approach to address using assembly as the enabling technology. (Samples for USPostal and HR-XML addresses are being worked on). Put simply the CIQ definitions form the basic primative lexicon and 'lego' bricks from which you layer over the local use. However there are 207 countries with postal addresses, with typically five different 'levels' of address, based around business use, quality of information, and cost of delivery (discount schemes). Simple math gives you about 1,000+ ways to write a postal address. And its not just about the address format - critical is the business rules around the information. And bear in mind CIQ is not just postal address, its a general address useful for utility companies, engineering facilities and other types of address too. So what is the way forward? The goal is interoperability. The basic tokens that CIQ provides are the means to provide interoperability via the assembly layer. We call it Town and the French call is Ville, and the Germans Stadt, etc. The assembly allows that local use - and references the CIQ item via the UID to show at the interoperability level that these items are actually the same logical unit of information. Then business rules can be applied as needed. Forinstance in the USA the town name cannot be longer than 30, and if it is - strict abbreviation rules apply - not just truncation. EECMA have developed their own non-XML proprietary assembly system - but they are looking strongly at ebXML assembly as the right means - ensuring it covers all the functional pieces they need - but becuase its XML based it allows them to do so much more, and a means to actually have executable formats - rather than just paper spec's. So if UBL is interested in adopting CIQ our suggestion is that the deliver around address is aligned at the LAYER level, down thru to the CIQ primitives. This will allow UBL to cope with address localization - while providing via assembly the means to give global interoperability. While this at first appears challenging - it provides a clean an elegant way to migrate from legacy payload definitions to next generation ebXML based payloads, with enhanced interoperability; ability to take core components and then derive the normalized local realization and deploy them. And this is key for getting adoption. In a lot of cases end users need not change their legacy payloads, but simply provide a valid assembly definition to the CIQ equivalent definitions. Hope this is helpful. Thanks, DW. ======================================================= Message text written by INTERNET:marion.royal@gsa.gov > David, UBL is considering CIQ and I would like to see a single standard for name and address. However, I am not versed enough to support the xAL in debate. Would you like to weigh in on this? I would be happy to forward your viewpoint to the list. marion <
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC