Customer Information Quality (CIQ) Specifications Version 3.0 – General Introduction and Overview

Public Review Draft 02

15 June 2007


Specification URIs:


This Version:



Previous Version:



Latest Version:



Technical Committee:

OASIS Customer Information Quality TC



Ram Kumar (



Ram Kumar (


Related work:

This version of the CIQ specifications replaces or supercedes:

·         OASIS CIQ extensible Name Language (xNL) V2.0 Committee Specification

·         OASIS CIQ extensible Address Language (xAL) V2.0 Committee Specification

·         OASIS CIQ extensible Name and Address Language (xNAL) V2.0 Committee Specification

·         OASIS CIQ extensible Customer Information Language (xCIL) V2.0 Committee Specification




This document provides a quick and general introduction and overview about the CIQ TC and the specifications it has developed for industry



This document was last revised or approved by the OASIS CIQ TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.


Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at


For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (


The non-normative errata page for this specification is located at



Copyright © OASIS® 1993–2007. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.


OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The names "OASIS", “CIQ”, “xNL”, “xAL”, xNAL”, “xPIL”, “xPRL”, “xCIL”, “xCRL” , “Genericode”, and “UBL” are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see for above guidance.


Table of Contents

1     Introduction.. 5

2     Name, Address and Party.. 6

2.1 Definitions. 6

2.2 General Applications of Party Information.. 6

2.3 Problems due to lack of an industry standard to manage party related data.. 7

2.4 OASIS CIQ TC Specifications to address party data related issues. 8

2.5 What are not defined in CIQ Specifications?. 8

2.6 CIQ TC’s Formula for Successful Data Interoperability.. 9

2.7 Using Party Related Data - Use Case Scenarios. 9

3     OASIS Customer Information Quality (CIQ) Technical Committee. 11

3.1 Goals of CIQ TC.. 11

3.2 Evolution of CIQ TC specifications. 12

3.2.1 Evolution of xNL, xAL and xNAL Specifications. 12

3.2.2 Evolution of xCIL/xPIL Specifications. 13

3.2.3 Evolution of xCRL/xPRL Specifications. 14

4     CIQ TC and its contributions to Industry.. 15

4.1 CIQ TC Specification Versions Released.. 15

4.2 Extensible Name Language (xNL) 15

4.3 Extensible Address Language (xAL) 16

4.4 Extensible Name and Address Language (xNAL) 17

4.5 Extensible Party Information Language (xPIL) 17

4.6 Extensible Party Relationships Language (xPRL) 18

4.6.1 Person to Person Relationships. 18

4.6.2 Person to Organization Relationships. 18

4.6.3 Organization to Organization Relationships. 18

5     CIQ TC Specifications – Industry adoption and comparison with other similar initiatives   19

5.1 Adoption of CIQ TC Specifications by Industry Types. 19

5.2 Industry Applications using CIQ TC Specifications Family.. 19

5.3 Other Relevant Initiatives in Industry.. 20

A.       Acknowledgements.. 22

B.       Intellectual Property Rights, Patents, Licenses and Royalties.. 23

C.       Revision History.. 24



1        Introduction

This document provides a general introduction, overview and history of OASIS Customer Information Quality Technical Committee (CIQ TC) and the specifications it has produced for industry namely,

·         xNL : extensible Name Language

·         xAL: extensible Address Language

·         xNAL: extensible Name and Address Language (combines xNL and xAL)

·         xPIL: extensible Party Information Language (formerly known as extensible Customer Information language (xCIL)), and

·         xPRL: extensible Party Relationships Language (formerly known as extensible Customer Relationships Language (xCRL))


The main goal of this document is to provide any type of reader (business or technical) with sufficient general understanding about the CIQ TC specifications.







2        Name, Address and Party

2.1 Definitions


Name of a person or an organization


A physical location or a mail delivery point


A Party could be of two types namely,

·         Person

·         Organization

An Organization could be a company, association, club, not-for-profit, private firm, public firm, consortium, university, school, etc.

Party data consists of many attributes. However, a person or organization’s name and address are the key identifiers of a “Party”.  A “customer” is of type “Party”.

2.2 General Applications of Party Information

Party specific data are very commonly and widely used entities across different domains. We broadly categorise the applications of party specific data as follows:

Point to point data exchange

Organisation A exchanges data with Organisation B. Both organisations have different data models for Party, but they agree on the way they map their data models to the schemas to minimise the implementation effort.

Organisation A captures stores and uses party data in many different ways to meet various business requirements. To uniquely identify a party within the organization, the organization synchronizes party data between various applications through a common data model for party information.

Open data exchange

A number of diverse organisations exchange data in an open fashion. All systems are different, but still can be mapped to party schemas. All participants rely on the original TC specification, but some restrictions and modifications are still possible to suit the application and locale.

Database modelling

Party schemas and the data models they reflect can be used as a reference for design and implementation of relational or XML databases in regard to party entities.

Reuse by other standards and schemas

All party schemas are built for reuse. They can be easily included in other schemas when describing party details.





2.3 Problems due to lack of an industry standard to manage party related data

Following are some of the key problems due to the lack of a standard to manage party related data in organisations. The aim of CIQ Specifications is to assist organisations in minimising these problems:

·         Party data and in particular, name and address, as a data type, is very difficult to manage. This data is often volatile… customers/parties come and go, addresses change, names change. Name and address is subjective…it can be written in a number of different ways and still convey the same meaning. This problem is further compounded by the different ethnic backgrounds impacting name and address data in a global market. Organisations collect party data in various formats for various purposes namely, marketing, sales, billing, security, data matching, data exchange, etc. 

·         Today’s increasing security requirements at the national and international level due to cross border terrorism and other unlawful activities around the world requires party profile data exchange between countries, high reliability in party identity screening and verification, regardless of country, language, culture and geographical boundaries. Party industry standards play a significant role to meet this serious, but important requirement.

·         Party data plays a critical role in uniquely recognizing/identifying a person/organization in order to get a complete, clear and consistent understanding of the person/organization to provide effective and efficient services. To date this is an outstanding critical issue for most organizations as they have multiple information systems and databases capturing and representing party data in many different ways. As a result, the systems and databases are either poorly integrated, or in many cases, not integrated at all. This fragmentation creates a major barrier to ever achieving a consolidated view of the each customer – the foundation for successful Party Relationship Management (e.g. CRM), Business Intelligence (BI), data warehousing and other party/customer-centric initiatives.

·         Challenges in the treatment of party name and address and key party profiles occur mostly during data entry particularly in a global e-commerce environment. For example, the order in which address elements are naturally provided varies from country to country. In some countries the house number is provided before the street name, in other countries the house number is given after the street name. For some countries the house number is essential to determine the postcode, for other countries a simple city input is sufficient. Correct entry of an address in an international environment becomes heavily dependent on the knowledge of the person performing the data entry, or the ability to interpret the appropriate address elements. Lack of a standard way of capturing and representing international addresses compounds this problem further.

·         Organizations want to exchange and manage party related data between different applications using a standard set of data interfaces. For example, one might want to move all the party related data and relationships from one application to another.

·         A party-centric “Global” or “International” organization could use its party details data for some or all of the following applications:

·         Party/Customer Profiling/Management

·         Party/Customer Marketing initiatives

·         Party/Customer recognition/identification and relationship management initiatives

·         Data Quality initiatives covering,

·         Name and address parsing, searching, matching, de-duping and validation

·         Initiatives for Bulk Mail discounts (Postal services)

·         E-commerce (purchase, shipment, invoicing, etc)

·         Fraud Detection and Management


With a global world as the market for an organization such as the above, the serious problems faced are multiple formats to represent party data to meet application specific requirements, and point to point integration to exchange party data between applications resulting in numerous interfaces that are expensive to maintain.

2.4 OASIS CIQ TC Specifications to address party data related issues

Party data standards ensure the consistency, accuracy, integrity and validity that are critical to the success of party related IT initiatives of an organisation.

Some of the key issues with capturing, representing, using and managing party data are evident in the earlier section. But despite the realisation by organizations on the importance of these issue and party information management particularly in a global e-business environment, no XML specifications specifically concentrating on party profile/information management and importantly, independent of specific application requirements have been developed.

Though there are a number of XML specifications/standards addressing party data and in particular name and address available throughout the world, to a large extent, these specifications/standards have been designed with a particular business requirement in mind. For example, the expedient delivery of a piece of mail, purchasing, invoicing, shipment, tax, accounting, human resources, health, exchange of party related data in an e-business environment, etc. While the particular standard is appropriate for the purpose for which it was designed, frequently it is not suitable for a variety of other purposes. This puts pressure on organisations dealing with customers at a global level to capture and represent party data via more than one party standard.

The best strategic solution is to use a single standard throughout the organisation to capture, represent and exchange core party data (such as name, address and key identifiers) that can then be extended to support multiple application requirements. For example, organizations implementing an enterprise wide common information/data model to integrate many applications can use CIQ specifications for party related data as part of its common information model. This common information model can be used to map the model with the transactional system(s)/application(s) data models. This avoids point to point mapping of party data between different transactional systems and at the same time enables consistent exchange of party data within an enterprise.

When XYZ Ltd uses different industry standards to meet specific application requirements, say, human resources management, purchasing and invoicing, customer views, customer identification, etc, it is forced to implement party related components of the standards it uses for the listed applications, more than once. But CIQ Specifications help to avoid this duplication by enabling XYZ Ltd to implement one single standard (CIQ Specification) to represent party related data once throughout the organisation and then implement application specific standards around this CIQ Specifications by reusing it. This is due to the fact that CIQ specifications are independent of vertical industry applications. This is the key differentiator between the CIQ family of specifications and similar initiatives (in particular, name and address specifications) in industry that are designed for a specific application requirement:

There is a definite need for a single, global and open party (includes name and address) industry standard/specification, implemented using XML schemas to address and manage the above discussed issues with party data. This is the precise objective of OASIS CIQ TC that led to development of the CIQ Specifications.

2.5 What are not defined in CIQ Specifications?

CIQ Specifications deal only with representation of party related data (limiting to party name, address, party centric attributes and relationships) in a standard format, and does not deal with:

·         Transactional "customer/party information" such as recent purchases, payment history, etc.

·         Message envelopes that carry CIQ payload

·         Formatting of the CIQ represented data

·         Privacy and security issues connected to exchanging and storing personal information

·         Data exchange methods and procedures for party information

·         Messaging protocol for exchange of party information 

·         Validation/verification of party information

·         Formatting, labeling, or sorting of party information

·         API specifications


CIQ specifications are not a quality enhancing process as commonly understood or akin to a certificate of test results against some objective specification.

2.6 CIQ TC’s Formula for Successful Data Interoperability

We at OASIS CIQ TC strongly believe in the following “Data Interoperability Success Formula”:


Data Interoperability = Open Data Architecture + Data Integration + Data Quality + Open Data Standards + Data Semantics + Data Governance


All components on the right hand side of the above formula are important for successful data interoperability. It is important to emphasis here that the quality of any information management/processing system or any data exchange/interoperability system is only as good as the quality of the data it processes/stores/manages. To structurally represent the data, understand the semantics of the data to integrate and interoperate the data, quality of the data is critical. CIQ specifications have been designed with the above formula in mind. The term “Open” used here indicates artifacts that are independent of any proprietary solution (e.g. open industry artifacts or artifacts that are open within an enterprise).

2.7 Using Party Related Data - Use Case Scenarios

Numerous use case scenarios can be listed to demonstrate how party data is used in organizations to conduct business as any sort of business involves one or more party associated with it, and they could be employee, customer, prospect, buyer, supplier, partner, contractor, etc. The following diagram provides few of the many broad categories of subject areas where party related data plays a critical role. Each category can have numerous applications with each have many use case scenarios.



3        OASIS Customer Information Quality (CIQ) Technical Committee

Customer Information Quality (CIQ) technical committee was formed under OASIS in 2000 to address the party data management problems discussed above. The first face to face meeting of the committee was held at the XML Conference in Washington, USA in December 2000.

Mastersoft, a customer information management solutions organisation from Australia founded this technical committee with its Chief Architect, Ram Kumar, as the founding chairman. Mastersoft provided the initial contribution to the committee in the form of Name and Address Markup Language (NAML), Customer Identity Markup Language (CIML), and Customer Relationships Markup Language (CRML) XML specifications. AND Solutions, a global address data management company from The Netherlands provided its Global Address data XML specifications to the committee.

These specifications were used as the initial reference models to develop the party information standards under the CIQ TC.

3.1 Goals of CIQ TC

The goals of the CIQ TC to develop specifications for party profile/information are to be  

·         application independent

·         platform independent

·         vendor neutral

·         truly “open”, meaning

·         free of royalties

·         free of patents

·         free of licenses

·         free of Intellectual Property Rights (IPRs)

·         freely available for public to download and implement the specifications without any restrictions, and importantly

·         developed in an open process environment

·         independent of language, cultural and geographical boundaries

·         have the ability and flexibility to represent global party data and specifically with the ability to handle

·         about 36+ party name formats

·         addresses of 240+ Countries

·         about 130+ Address Formats, and

·         5,000+ languages (dialects)


3.2 Evolution of CIQ TC specifications

In this section, we summarise the evolution of OASIS CIQ TC Specifications.

3.2.1 Evolution of xNL, xAL and xNAL Specifications

The diagram below summarises the evolution of xNL, xAL and xNAL Specifications since 1999.




3.2.2 Evolution of xCIL/xPIL Specifications

The diagram below summarises the evolution of xCIL/xPIL Specifications.



3.2.3 Evolution of xCRL/xPRL Specifications

The diagram below summarises the evolution of xCRL/xPRL Specifications.


4        CIQ TC and its contributions to Industry

The CIQ TC has delivered the following approved committee specifications to the industry since its inception in 2000:

·         Extensibile Name and Address Language (xNAL) Version 2.0

·         Extensibile Name Language (xNL)  Version 2.0

·         Extensibile Address Language (xAL) Version 2.0

·         Extensible Customer Information Language (xCIL) Version 2.0, and

·         Extensible Customer Relationships Language (xCRL) Version 1.1

xCIL is renamed as extensible Party Information Language (xPIL) and xCRL as extensible Party Relationships Language (xPRL) in Version 3.0.

4.1 CIQ TC Specification Versions Released

Following are the different versions of specifications (CIQ technical committee approved) released by the CIQ TC since its inception in 2000.







Version 1.0

May 2001

May 2001

May 2001

May 2001


Version 1.1





July 2002

Version 2.0

July 2002

July 2002

July 2002

July 2002


Version 3.0

June 2007

June 2007

June 2007

June 2007


4.2 Extensible Name Language (xNL)

xNL defines an XML format to represent party name information. A party name could be a “Person” or an “Organization”. An “Organization” could be educational institutions like school, university, college, etc, clubs, associations, industry groups, not-for-profit bodies, consortiums, user groups, etc.

xNL is designed to handle international name data that are culture- and geography- specific. For example, the concept of given name and family names do not exist in some countries such as India (some regions), so the traditional FirstName/LastName or GivenName/FamilyName approach is not always applicable.

xNL is designed to party names names in over 36 formats internationally.


4.3 Extensible Address Language (xAL)

xAL defines an XML format to represent address data. An address could be any of the following address types and xAL has been carefully designed (based on use cases and address structures around the world) to handle them. Following are some of the key address types that xAL can be used to represent:

·          Airport

·          Business/Commercial Parks

·          Caravan Parks

·          Community Developments

·          Dual (Primary and Secondary)

·          Educational institutions

·          Entertainment/Recreation Parks

·          Hospitals

·          Large Mail Users (e.g. Hospitals, industrial zones)

·          Marinas

·          Military

·          Ports

·          Postal Delivery Points (e.g. P.O.Box, Mailbag, Mail Stop, Pigeon Holes)

·          Retirement Villages

·          Resorts

·          Royal Highness

·          Rural (with land, air and water access)

·          Sporting Venues

·          Territories

·          Tribal

·          Simple Urban

·          Complex Urban

·          Utility Urban

·          Ranged Urban

·          Villages

·          Canals

·          Banks

·          Vacant lands (e.g. Lot)

·          Location type reference addresses

·          Landmark based reference addresses


xAL is designed to support addresses of 240+ countries of the world and in over 130 formats, and represent them as fully parsed, semi-parsed and unparsed data.


4.4 Extensible Name and Address Language (xNAL)

xNAL defines XML specifications to represent party name and address data together. xNAL uses xNL and xAL specifications. An example of xNAL could be:

Attention: Mr. Ram Kumar


XYZ Corporation

23 Archer Street

Chatswood, NSDW 2067


4.5 Extensible Party Information Language (xPIL)

xPIL defines XML specifications to represent party centric data. Party centric data includes:

·         Name

·         Address

·         Electronic address identifier details (including VoIP)

·         Contact numbers (Mobile, Pages, Fax, Landline, etc)

·         Identification details (e.g. passport, license number, identification card, etc)

·         Vehicle details

·         Account details (e.g. bank account, club account, etc)

·         Hobbies

·         Reference Contacts

·         Birth details

·         Qualification details

·         Physical details

·         Revenues

·         Relationships

·         Nationality details

·         VISA details

·         Membership details

·         Key event details,

·         Preferences,

·         Communication Language details

·         Person characteristics (e.g. marital status, physical status), and

·         Organisation characteristics (e.g. Registration details, business nature)




4.6 Extensible Party Relationships Language (xPRL)

xPRL defines XML specifications to represent implicit and explicit party relationships. Party relationships could be:

·         Person to Person relationships

·         Person to Organization relationships, and

·         Organisation to Organization relationships

4.6.1 Person to Person Relationships

Some examples of Person to Person relationships are:

·         Mrs Mary Johnson and Mr.Patrick Johnson, where Mary is the "Wife" of Patrick and Patrick is the "Husband" of Mary

·         Mrs Mary Johnson and Mr.Patrick Johnson "IN TRUST FOR" Mr.Nick Johnson, where Mary and Patrick are the trustees of Nick and Nick is the beneficiary

·         Mrs. Mary Johnson, Care of Mr.Patrick Johnson, where Mary is dependent on Patrick

·         Complete Organization Structure (Employee-Employee Relationship)

4.6.2 Person to Organization Relationships

Some examples of Person to Organization relationship are:

·         Mrs. Mary Johnson and Mr.Patrick Johnson "DOING BUSINESS AS" Johnson & Associates, where Mary and Patrick are persons who are jointly doing a business under the name of a company called Johnson & Associates.

·         Mrs and Mr. Jonhson "IN TRUST FOR" Mr.Patrick Johnson "DOING BUSINESS AS" Jonshon & Associates

·         Mrs and Mr. Venkatachalam "IN TRUST FOR" Mr Ram Kumar and Mr Laxmana Samy "ADMINISTRATORS OF" Sakthisoft Pty. Ltd "TRADING AS" Mantra Corporation

·         Mr. Ram Kumar, Care of Sakthisoft Pty. Ltd, where Ram is the person and Sakthisoft Pty. Ltd is the company.

·         Organization structure

4.6.3 Organization to Organization Relationships

Some examples of Organization to Organization relationship are:

·         Company A "TRADING AS" Company B

·         Company A is the subsidiary of Company B

·         Company A is the parent of Company B

·         Company A, Company B and Company C are the subsidiary companies of Company D


5        CIQ TC Specifications – Industry adoption and comparison with other similar initiatives

Party information and in particular, name and address is the widely used data in industry. Wherever a party is associated with an application, name and address data plays the leading role.  In the following sections, we look at other similar initiatives (in particular, name and address specifications) around the world and how CIQ Specifications are different to them.

The goal of OASIS is not to ask interested parties to register their interest to use the specifications. The specifications in OASIS are for anyone to download without the need to register. This results in potential users to download the specifications and use the specifications without any restrictions. Therefore, it is not possible for CIQ TC to track the use of CIQ specifications in industry. However, over time, the CIT TC has received feedback and information about the use of CIQ Specifications in industry. This information have been collated and presented in this section.

5.1 Adoption of CIQ TC Specifications by Industry Types

CIQ TC specifications have been widely adopted by different groups around the world and some of the key types of groups are as follows (for confidentially reasons, we are not in a position to publish the names of the groups):

·         Governments, including e-Government

·         Insurance Companies

·         Banks

·         Solution providers

·         Telecommunication companies

·         Product Vendors

·         Retail companies

·         Standard Bodies/Groups/Consortiums

·         OASIS Technical committees (e.g. Election and Voter Services, HumanMarkUp, UBL, DITA)

·         Address Map Providers

·         Open Source Community for CRM

·         Postal Companies

·         Manufacturing companies

·         Financial Service Providers  (e.g. credit cards)

·         Automotive industry

·         Justice Sector

·         Health

5.2 Industry Applications using CIQ TC Specifications Family

Following are a selection of some of  the key broad categories of applications that have implemented CIQ TC Specifications:

·         Single Party View

·         Address Maps (geo spatial information)

·         Party recognition/identification

·         Enterprise party data management

·         Data Quality (e.g. parsing, matching, de-duping, verification, validation and enhancement)

·         Party profiling

·         Purchase orders, invoicing and shipping

·         Party relationships management

·         Party services

·         Postal services

·         Election services

·         Justice, Legal and Corrective services

·         Business Intelligence

·         Party data interoperability frameworks

·         Front end data capture

·         Party data synchronization


5.3 Other Relevant Initiatives in Industry

CIQ TC is not the only body to attempt to create a set of standards for representing Party details. Though CIQ was the first to create a global XML standard for party name and address data, a number of other efforts are underway around the world to either define party related specifications/standards that is part of a particular application standard effort and not dedicated to defining specifications for party details from a global perspective. Following are the some of the other key industry initiatives that define party name/address/party details specifications/standards as part of its overall objective:

·         British Standard 7666

·         Address Data Interchange Specification (ADIS)

·         HR-XML, Human Resource Markup Language

·         UK GovTalk Address

·         Universal Postal Union (UPU)

·         Address Data Content Standard

·         Australia-New Zealand Standard for Client Information Exchange (AS 4590)

·         HL7

·         OASIS UBL Library Subcommittee

·         UN/CEFACT Core Components, TBG 17 Working Group

·         ISO 11180:1993

·         CEN WG331

·         USIRA Address Standard

·         STAR

·         ACORD

·         OAG

·         ROSETTANET

·         XBRL

·         OTA

·         IETF – vCard

·         GJXDM

·         FOAF


All the above standards/specifications were analyzed by CIQ TC in terms of their support for name and address and party data models and their global, industry and application independence nature.

All of these standards/specifications have been designed with a particular business requirement or application in mind, for example, the expedient delivery of a piece of mail, invoicing and purchasing, health, and human resources, etc. or specifically designed for a country or a group of countries. This has generally meant that while the particular standard/specification is appropriate for the purpose for which it was designed, it is frequently not suitable for a variety of other purposes across the different industries and different types of applications and importantly, on a global scale. For example, a standard might be suitable to represent party name and address data for postal purposes, but may not be suitable to use it for a data cleansing and quality application which may require all name and address fields to capture in its atomic form.

CIQ TC is the only dedicated international standards group that concentrates specifically on developing “international party specifications” for the industry that is not tied to or is part of any particular industry application specifications (e.g. supply chain, human resources, health, accounting, postal services, e-commerce, CRM, Geospatial, etc) . CIQ TC is also the first standards group to build party “name” and “address” XML specifications for industry that is truly “global”, “open”, and “application independent”.

A.   Acknowledgements

The following individuals have participated in the creation of this specification and are gratefully acknowledged:



John Glaubitz

Vertex, Inc

Member, CIQ TC

Max Voskob


Former Member, CIQ TC

Hidajet Hasimbegovic


Member, CIQ TC

Robert James


Member, CIQ TC

Joe Lubenow


Member, CIQ TC

Mark Meadows

Microsoft Corporation

Member, CIQ TC

John Putman


Former Member, CIQ TC

Michael Roytman

Vertex, Inc

Member, CIQ TC

Colin Wallis

New Zealand Government

Member, CIQ TC

David Webber


Member, CIQ TC

Graham Lobsey


Member, CIQ TC

George Farkas

XBI Software, Inc

Member, CIQ TC


OASIS CIQ Technical Committee (TC) also wishes to acknowledge contributions from former members of the TC since its inception in 2000. Also, the TC would like to express its sincere thanks to the public in general (this includes other standard groups, organizations and end users) for their feedback and comments that helped the TC to improve the CIQ specifications.

Special thanks to Mr.Hugh Wallis, Director of Standards Development of extensible Business Reporting Language (xBRL) International Standards Group ( for working closely with the CIQ TC in jointly implementing W3C xLink specification that is now used by both xBRL and CIQ Specifications to enable interoperability between the two specifications.

Special thanks to Mr.Carl Reed, Chief Technology Officer of Open Geospatial Consortium (OGC – for his guidance and assistance to the TC in referencing the work of OGC on GeoRSS and Geo-Coordinates for addresses/locations as part of CIQ Address Specifications.

Special thanks to Mr.Ken Holman, Chair of OASIS Code List TC ( for his assistance to the TC in releasing the OASIS Code List version of CIQ V3.0 XML Schemas.

Last but not least, the TC thanks all users of the CIQ TC specifications in real world and for their continuous feedback and support.


B.   Intellectual Property Rights, Patents, Licenses and Royalties

CIQ TC Specifications (includes documents, schemas and examples1 and 2) are free of any Intellectual Property Rights, Patents, Licenses or Royalties. Public is free to download and implement the specifications free of charge. 



Address examples come from AS/NZ 4819:2003 standard of Standards Australia and are subject to copyright



Address examples come from a variety of sources including Universal Postal Union (UPU) website and the UPU address examples are subject to copyright.



This schema was provided by the xBRL group in December 2006.


C.   Revision History




Changes Made

V3.0 PRD 01

13 April 2006

Ram Kumar and Max Voskob

Prepared 60 days public review draft from Committee Draft 01

V3.0 PRD 02

15 June 2007

Ram Kumar

Prepared second round of 60 days public review draft from Committee Draft 02 by including all public review comments from PRD 01. Also included is implementation of OASIS Code list specification