1 Introduction

This document provides answers to frequently asked questions about OASIS Customer Information Quality Technical Committee version 3.0 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)

· xPRL: extensible Party Relationships Language (formerly known as extensible Customer Relationships Language (xPRL) – Release data for this specification not set yet

2 Frequently Asked Questions – Technical and Non Technical

The following common questions were collected from public who raised them with OASIS CIQ TC since its inception in 2000.

What is the need for CIQ specifications?

“CIQ TC – General Introduction and Overview” document clearly explains the need for CIQ specifications. When this TC was formed in 2000, there was no specification developed to deal with party related data.

Who should use CIQ Specifications?

Any organization dealing with party related data that has to be represented in a standard consistent manner in the organization and/or exchanged between internal applications and systems and with external partners in a standard and consistent manner that is not proprietary in nature and is an industry standard.

Who should be involved in the development of CIQ Specifications?

Anyone dealing with party related data should consider CIQ as a standard way of representing and exchanging party data between applications. Anyone with an interest in helping to produce a common standard for exchanging party information between various processes, applications and systems that are not tied to specific industry, culture, country, or geographical boundaries.

Who will benefit from this work and how?

· Any organization that is planning to define a common standard for party information across its various lines of business and its various applications.

· Any organization that wants to leverage their party information in a B2B environment.

· Any organization that processes party information differently for different applications (e.g. simple customer registration/point of contact to name and address validation).

· Any organization that deals with global customers

· Any organization that wants to have a consistent and standard representation of party data

· Any organization that wants to represent party data by using an open industry standard with one or more of the following characteristics:

· Open

· Vendor Neutral

· Can represent international party data

· Application independent

· Industry independent

· Developed in an open process environment

· Free of any IPRs, licenses, royalties, patents, etc

· Readily available to use without any restrictions

· Developed by global experts in party information management

· Developed by public for the public

What does CIQ Specifications not cover?

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

How does this work compare with related efforts at other standards organizations?

Numerous groups that work on party data standards in some form have been studied by CIQ TC. It is clear that OASIS CIQ TC is the only international standards group that is specifically dedicated to build party information standards that are application and industry independent and importantly, developed from a global/international perspective (i.e., not limited to a particular country or group of countries (e.g. western world). Other groups develop party information standards from a specific application or industry perspective (e.g. Postal addressing, human resources, health, billing, shipping, purchasing, travel).

What are the major entities defined by CIQ Specifications for Party Information?

CIQ Specifications are based around the following three party entities (person or organization) namely,

· Name

· Address, and

· Party Centric Information

Why developing Party information standard is such a “big deal”?

This is the statement we commonly hear from people who look at it. But the main point they miss is that they look at say, Party Name and Address from a specific context such as from a specific application perspective or a cultural perspective or a geographical perspective. A standard for Party Name and Address should deal with the following constraints and this is what OASIS CIQ Specifications has achieved that no other standard is able to:

· Represent names and addresses of 241+ Countries that are specific to race, religion, ethnicity, culture and geography/location

· Name and addresses represented in 5,000+ languages/dialects

· With 130+ Address Formats, and

· With 36+ Personal Name formats

· Independent of specific applications. For example, an application might just need Address Line 1, Address Line 23 and Address Line 3 to represent an address, while some other application might need to store and manage quality data by breaking down the address into street details, Premises details, suburb, post code, state, etc.

· Industry independent. For example, not to just deal with postal related services or Customer Relationship Management initiatives

We are living in a world of global commerce where anyone can do business with anyone on this earth without having to deal with each other physically. Party data is the key to any global commerce and exchange of party data between global parties and handling global party data within your applications and systems in a standard and consistent manner, and importantly not proprietary or application specific is becoming increasingly important. This is what CIQ specifications achieve. Global terrorism and crime is another major issue and one way of dealing with it is to exchange the right information at the right time to the right place in the right format and in the right context between the appropriate parties, and CIQ Specification provides the opportunity to exchange party related data (here, terrorists and criminal related data) in a standard and consistent

What are the specifications produced by OASIS CIQ TC?

The following committee specifications have been produced by OASIS CIQ TC so far since its inception in 2000:

· extensible Name and Address Language (xNAL) to represent party name and address together

· extensible Name Language (xNL) to represent party name only

· extensible Address Language (xAL) to represent party address only

· extensible Party/Customer Information Language (xPIL/xCIL) to represent party centric data that uniquely identifies a party (in addition to name and address)

· extensible Party/Customer Relationships Language (xPRL/xCRL) to define party to party relationships

The specifications are modular, i.e. users can pick what specifications they want as they are independent of each other. For example, a user can just decide to use CIQ Specification for defining party name only and ignore the rest.

How did CIQ TC manage to produce a global specification and was it tested?

It took over 2 years for the CIQ TC just to build the address specification to handle 241+ countries that is application and industry independent. Extensive research work and involvement of address management experts and contributions from end user community enabled the TC to produce this work.

Numerous use of the specification all over the world has been reported and any feedbacks provided have been used to improve the specifications. The TC continues to test the specifications with international data.

Are there any IP, Patent or Royalty issues for CIQ Standards?

CIQ Standards are free of any IP issues, Patent, License, or Royalty. It is free of any licensing/commercial issues. Anybody can download and use the CIQ standards for free. It is advisable to read the OASIS Copyright notice and policy on IP.

What are the criteria and business value to an organization for selecting CIQ over the other similar standards in defining the organizations baseline architecture?

If your organization wants to use name and address not for just postal services, but also for other purposes as well (e.g. customer profile management, contact management, employee information, CRM application, customer identification, name and address parsing and validation, etc), then CIQ is the best choice as it is designed to accommodate all these applications.

If your organization wants to use name and address standard that can be extended to other party information (e.g. telephone, fax, email, URL, customer id, customer relationships, etc.) that are unique to the customer, then CIQ is the best choice.

Is CIQ TC working with other similar standard groups?

CIQ TC is committed to collaborative work. CIQ TC continues to strive hard all these years to foster alignment with other similar standard initiatives. Given that CIQ has already done the important base work of defining standards that are global and application independent, it makes life easier for other groups to extend the standard for domain specific applications such as postal services. CIQ and OASIS in general, are open for any collaborative work in an "open" process manner to ensure that there is no duplication of work.

CIQ is speaking and has spoken to many groups and most of the time. CIQ TC has initiated this process. It is hard to collaborate politically, but it is easier technically.

Are CIQ Standards such as xNAL designed for the CRM world only?

Definitely not. They have been designed to be application independent. Let us say, for example, in an organization or a government sector, there are many applications dealing common data such as name and address. The applications using say, name and address could be a CRM, user registration on web, billing, marketing, sales, name and address cleansing and quality, etc. The optimal way to interoperate name and address data is to store the name and address information in a common format that can be applied or reused across different applications. But organizations often end up storing name and address data in many different formats specific to the applications and hence, are unable to integrate different applications to meet business needs (e.g. integrate applications to get all info. about a party). To store name and address information in a common format, you need a standard that is flexible enough to be applied to different requirements of the application. This is precisely what CIQ standards have been defined for and this is why it is flexible to store simple user registration data (e.g. address line 1, address line 2, city, state, postcode, country) to detailed level of data for complex applications like name and address parsing and matching which requires detailed level of elementization of the name and address data.

Why did you decide to release a new version (3.0)?

See “CIQ TC Technical Overview (version 3.0)” document that outlines the reasons behind this decision.

Isversion 3.0 of CIQ Specifications backward compatible with version 2.0?

No, version 3.0 of CIQ Specifications is not backward compatible with version 2.0 of CIQ Specifications. However, any party related data represented in version 2.0 can be represented in version 3.0.

I feel that CIQ Specifications are very rich to handle complex name and address structures. I want something that provides a simple representation of name and address. Can CIQ provide me this?

Yes, definitely. CIQ V3.0 has been designed to enable users to extend or customize the CIQ XML Schemas to meet their specific application requirements. Users have been provided the following features in the specifications:

· Restrict the use of different elements and attributes defined in the CIQ specifications

· Add more semantics to the data that is represented using CIQ specifications

· Add more attributes from non target namespaces to extend the schemas

· Write business rules outside of the CIQ schema to constrain the grammar of the CIQ schemas

· Extend the schema by adding more attributes from non target namespaces

So, for example, if a user wants to represent an address structure with address lines only, or a combination of address lines with structured data fields, or by using only structured data fields, CIQ provides these capabilities using the approaches outlined above. This features also assists users to customize CIQ name and address XML schemas to be specific to their country name and address structure.

A simple address example is shown below:

Simple Representation of an Address (Unstructured)

16 Patterson Street, OCEAN REEF, WA

<a:Address>

<a:FreeTextAddress>

<a:AddressLine>16 Patterson Street</a:AddressLine>

<a:AddressLine>OCEAN REEF</a:AddressLine>

<a:AddressLine>WA</a:AddressLine>

</a:FreeTextAddress>

</a:Address>

Semi Complex Representation of an Address (Semi Structured)

16 Patterson Street, OCEAN REEF, WA

<a:Address>

<a:FreeTextAddress>

<a:AddressLine>16 Patterson Street</a:AddressLine>

</a:FreeTextAddress>

<a:AdministrativeArea a:Type=”State”>

<a:NameElement>WA</a:NameElement>

</a:AdministrativeArea>

<a:Locality a:Type=”Suburb”>

<a:NameElement>OCEAN REEF</a:NameElement>

</a:Locality

</a:Address>

Complex Representation of an Address (Structured)

16 Patterson Street, OCEAN REEF, WA

<a:Address>

<a:AdministrativeArea a:Type=”State”>

<a:NameElement>WA</a:NameElement>

</a:AdministrativeArea>

<a:Locality a:Type=”Suburb”>

<a:NameElement>OCEAN REEF</a:NameElement>

</a:Locality>

<a:Thoroughfare a:Type=”Street”>

<a:Name>Patterson</a:Name>

<a:Number>16</a:Number>

</a:Thoroughfare>

</a:Address>

See “CIQ TC - Name, Address and Party Specifications” document and “CIQ Technical Overview” document of version 3.0 specifications that explain how to customise the schemas to meet your requirements.

How can I customise Name and Address CIQ Specifications, i.e., I want a simplified version (light weight) of xNL and xAL specifications?

Version 3.0 of CIQ xNL and xAL specifications have been designed to be lightweight compared to Version 2.0. See “CIQ TC - Name, Address and Party Specifications” document of version 3.0 specifications that explains how to customise the schemas to meet your requirements.

Is there any reason why enumeration lists are used extensively in place of fixed element names, like FirstName, MiddleName, LastName for party names and for other specifications of CIQ in version 3.0?

CIQ specifications have been designed from a global/international perspective where cultural and geographical boundaries determine how party names and addresses are represented. Earlier versions of CIQ specifications made it harder for countries to implement CIQ that is semantically correct in terms of the “terms” used. For example, the concept of First Name, Middle Name, Last Name, SurName or Family Name does not exist in many cultures. Earlier versions forced those countries to use these concepts defined in CIQ specifications though they are not semantically correct. This is the reason why it was decided in CIQ V3.0 to allow users to define the semantic meaning of the data that is represented using CIQ. Enumeration lists provide the semantics to the data and is customisable by users.

Does CIQ have any working relationship with xBRL?

Yes, CIQ party data can be interoperated with xBRL. The xLink schema used in CIQ (xLink-2003-12-31.xsd) was jointly developed by CIQ TC and xBRL to achieve interoperability when it comes to linking party data.

Does CIQ have any working relationship with OGC?

Yes, CIQ Specifications reference the work of Open Geospatial Consortium (OGC – http://www.opengeospatial.org) for defining location coordinates and this work was done with the assistance of OGC.

Does CIQ have any working relationship with OASIS Code List Representation Technical Committee?

Yes, CIQ Specifications use the work of OASIS Code List Representation TC (http://www.oasis-open.org/committees/codelist) to define genericode based approach for code list representation and for two pass validation. CIQ TC worked closely with the OASIS Code List TC to get this implementation done.

Are there implementations of xLink parsers?

Yes, there are many. For more details, go to http://www.w3.org/XML/Linking

Are CIQ Specifications flexible enough to allow users to customize them to meet their specific requirements?

Yes, CIQ Specifications are flexible and provides the following features to the users to customize them to meet their specific requirements:

· Ability to users to choose the elements and attributes used in CIQ XML Schemas they want to use

· Ability to reuse only the CIQ entities they want as Name, Address, and Party centric information are independent components

· Provides two ways to customize code lists that add semantic meaning to the data. This customization can also be achieved using an industry standard approach without modifying the core CIQ XML Schemas

· Ability to write business rules using an industry standard approach to constrain the core CIQ XML Schemas without modifying the Schemas

By customizing the CIQ Specifications using Code Lists approaches, will this not break compatibility with the specification and interoperability?

Customisation of the specifications without touching the core XML schemas provided the CIQ entities namely, Name, Address and Party does not break the compatibility. But customising the specifications using code lists approaches and business rules, requires agreement with other parties that are involved in data exchange with your application/system that have implemented CIQ specifications to ensure interoperability. One cannot fully automate interoperability without some agreement (e.g. service level agreement, interoperability agreement) between the parties that are involved in data exchange. So, agreement between the parties regarding customisation of CIQ specifications is extremely important to achieve interoperability.

CIQ Specifications are rich and my application does not need such complexity to define, say name and address of a customer. What do I do?

This is the statement we commonly hear from people who look at it. But the main point they miss is that the specification aims at application and industry independency, i.e. not specific to a particular application area, and hence is rich in nature. But version 3.0 allows users the option to customize the specifications to meet their application specific requirements without touching the CIQ core schemas, but at the same time maintain compatibility and conformity with the specifications. For example, take address specification (xAL). If a user wants to just use free text address lines and a few of the address entities (e.g. locality, and postcode), they can define business constraint rules outside of the core schema that ignores the unwanted address entities. See “CIQ TC - Name, Address and Party Specifications” document of version 3.0 specifications that explains how to do this. The following example demonstrates the flexibility provided by CIQ Specifications:

Example - Simple Representation of Party Name and Address Data

Mr H G Guy, 9 Uxbridge Street, Redwood, Christchurch

<nal:Record>

<n:PartyName>

<n:NameLine>Mr H G Guy</n:NameLine>

</n:PartyName>

<a:Address>

<a:FreeTextAddress>

<a:AddressLine>9 Uxbridge Street</a:AddressLine>

<a:AddressLine>Redwood</a:AddressLine>

<a:AddressLine>Christchurch</a:AddressLine>

</a:FreeTextAddress>

</a:Address>

</nal:Record>

Example – Complex Representation of Party Name and Address Data

Mr H G Guy, 9 Uxbridge Street, Redwood, Christchurch

<xnal:Record>

<n:PartyName>

<n:PersonName>Mr H G Guy

<n:NameElement n:ElementType=”Title>Mr</n:NameElement>

<n:NameElement n:ElementType=”FirstNameInitial”>H</n:NameElement>

<n:NameElement n:ElementType=”MiddleNameInitial”>G</n:NameElement>

<n:NameElement n:ElementType=”LastName”>Guy</n:NameElement>

</n:PersonName>

</n:PartyName>

<a:Address>

<a:AdministrativeArea>

<a:NameElement>Christchurch</a:NameElement>

</a:AdministrativeArea>

<a:Locality>

<a:NameElement>Redwood</a:NameElement>

</a:Locality>

<a:Thoroughfare>>

<a:Name>Uxbridge Street </a:Name>

<a:Number>9</a:Number>

</a:Thoroughfare>

</a:Address>

</xnal:Record>

Given that xNL and xAL supports all types of international names and addresses, my requirement is only to support a particular country names or addresses. How can I achieve this?

The easiest way to tailor the schema to your requirements is to make changes to the code list/enumerations that are placed in separate files for this purpose. Two types of approaches are provided to customize code lists/enumerations.

It is also possible to restrict the CIQ XML schemas to meet your application specific requirements by not modifying the default CIQ XML schemas and at the same time keeping the restrictions compatible with the CIQ Specifications. Read “CIQ TC - Name, Address and Party Specifications” document of version 3.0 specifications that explains how to customise the schemas to meet your requirements.

Given that xNL and xAL supports all types of international names and addresses, my requirement is only to support a particular country names or addresses. How can I achieve this?

The easiest way to tailor the schema to your requirements is to make changes to the code list/enumerations that are placed in separate files for this purpose and/or define business rules using industry standard approach outside of the CIQ core XML schemas to constrain the schemas. Two types of approaches are provided to customize code lists/enumerations.

CIQ schemas are complex for what I’m trying to do. Do you have some really simple schemas, i.e. “xAL lite”?

No, there is no lighter version. Version 3.0 is far simpler and lighter than version 2.0 and it is a pretty flat structure. You can tailor the schemas to meet your specific requirements. You can make the schemas much simpler while keeping the concept intact. Read “CIQ TC - Name, Address and Party Specifications” document of version 3.0 specifications that explains how to customise the schemas (without modifying the schemas to meet your requirements. A sample example as part of the specification package shows how the base xAL schema can be customised to handle only Singapore country address structure.

Why do I want to represent the party data in parsed format?

If you are required to understand the semantics of party data and ensure that the quality of party data is managed, you need to parse the party data and represent them in parsed format. Parsed data helps in performing data validation and matching against reference data or any other data sets.

I do not want to break/parse the address/name data elements into atomic elements? Can CIQ schemas handle unparsed data elements?

Yes, you do not need to break your data elements to atomic elements to use CIQ schemas. CIQ schemas help you to store parsed/unparsed data elements. However, to enable clean interoperability of your data elements, it is advised to break to unparsed data elements into atomic elements which add semantics to your data elements. This also enables to keep your databases clean with quality information/data. Note that the quality of any information processing/management system is only as good as the quality of the data it stores/processes. Below is an example that demonstrates this:

Example – Unstructured/Not Parsed Simple Name Representation

Dr Jeremy Apatuta Johnson III PhD

<n:PartyName>

<n:PersonName>

<n:NameLine>Dr Jeremy Apatuta Johnson III PhD</n:NameLine>

</n:PersonName>

</n:PartyName>

Example – Structured/Parsed Complex Name Representation

Dr Jeremy Apatuta Johnson III Phd

<n:PartyName>

<n:PersonName>

<n:NameElement Abbreviation="true" ElementType="Title">Dr</n:NameElement>

<n:NameElement ElementType="FirstName">Jeremy</n:NameElement>

<n:NameElement ElementType="MiddleName">Apatuta</n:NameElement>

<n:NameElement ElementType="LastName">Johnson</n:NameElement>

<n:NameElement ElementType="GenerationIdentifier">III</n:NameElement>

<n:NameElement ElementType="Title">PhD</n:NameElement>

</n:PersonName>

</n:PartyName>

Are CIQ Specifications defined with the aim of achieving interoperability of data?

Absolutely. CIQ TC since its inception has been advocating the importance of data interoperability and data quality. The CIQ TC is of the strong view that data quality plays a significant role in interoperability. The quality of any information management/processing system is only as good as the quality of the data it processes/stores/manages. No matter how efficient your exchange system is, if the quality of data that is interoperated is poor, the business benefit arising out of the information processing system is expected to be poor. Always remember, “Garbage In, Garbage Out”.

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. CIQ specifications have been designed with the above formula in mind.

In addition to representing an address using xAL, what other key attributes can be represented using xAL?

You can represent the following using xAL also:

- History (Valid dates of an address, change of address history)

- Type of address

- How the address is used (e.g. for mailing purposes, for communication purposes, etc)

- Postal ID

- Address Usage

- Unique identifier

- Geospatial information

- Quality of address

- Language used to represent address

- Primary and secondary addresses in the same structure

- Multiple delivery points in the same address such as postal and street delivery points (common in many applications)

Do CIQ V3.0 Specifications support geo-coding?

Yes, they do. xAL (the Address Schema) reference GeoRSS from Open Geospatial Consortium and also provide a base set of elements for location coordinates.

I have already implemented version 2.0 of the CIQ Specifications. Do I need to move to version 3.0 of the specifications?

This really depends on your requirements. If there are no requirements for you to move to version 3.0, then stay with your current implementation. Version 3.0 is a much simplified and compact set of schemas to make the life of a developer easier. However, note that V3.0 is not backward compatible with V2.0 CIQ Specifications. The schema structures are different and the design approach is different. But representation of different types of data in V2.0 can also be represented in V3.0.

CIQ Specifications (Version 3.0) meets my requirements. But how do I start implementing the specifications?

See section 4.0 of “CIQTC-Technical Overview (version 3.0) ” document.

I am concerned with some of the contents of the CIQ version 3.0 specifications (e.g. missing pieces, errors, etc)? What do I need to do?

OASIS CIQ Specifications are developed in a truly “Open” process environment. We are keen to receive any sort of feedback from public and we look into the feedbacks seriously. This helps us to improve the specifications. So, please, use “Send A Comment” feature on CIQ TC home page (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ciq)

Do OASIS CIQ Specifications support data quality?

Yes, Version 3.0 of the CIQ specifications provides support for defining the quality of data (e.g. valid, invalid, valid at source, 90% confident, etc) and the date of validity of the quality.

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

By implementing CIQ Specifications, can I achieve interoperability of Party data between applications/business systems?

Yes you can, provided the exchange is managed properly. No data exchange for interoperability can be automated without some sort of information exchange agreement is in place at application design time. CIQ specifications are powerful in terms of providing the users the flexibility to customize it to meet their specific requirements. Flexibility is indirectly proportional to interoperability. The more flexible the specification is, less the chances are that interoperability will be achieved, because users will tend to implement the specifications in their own ways. This is where information exchange agreements are helpful in managing implementation of the specifications by more than one party involved in the data exchange. With an information exchange agreement in place, CIQ specifications will enable 100% interoperability of party related data between applications/systems

Are there any restrictions in using the OASIS CIQ Specifications?

No, there are no restrictions in using the OASIS CIQ Specifications (any version). These specifications are free for public to download and use them. There are no Intellectual Property Rights, Licenses, royalties, patents or any “strings” attached to the specifications that limit the use of the specifications.

CIQ Specifications are truly an “international open standard” developed in an “open process” environment. Users of the specifications are advised to read the OASIS Copyright notice.

OASIS CIQ Specifications are developed by the public for the public.

Can I contribute to developing OASIS CIQ Specifications?

Definitely. OASIS CIQ TC is constantly looking for participants. There is no restriction to who can and cannot contribute as OASIS process is truly open. OASIS CIQ Specifications are by the public for the public.

Who has used CIQ Specifications?

CIQ TC specifications have been widely adopted by different groups, organisations and end users around the world since its inception in 2000, 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

· Insurance

· Banking

· Retail

What are the applications that have implemented CIQ specifications?

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

Where can I find more information about CIQ?

The CIQ web site is the best choice (http://www.oasis-open.org/committees/ciq). Several materials exist in this site about CIQ work.

Who can I contact regarding CIQ Specifications?

You can contact the Chair of the CIQ TC and the email address of the chair is on the CIQ TC web site.

A. Acknowledgements

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

Participants:

John Glaubitz	Vertex, Inc	Member, CIQ TC
Max Voskob	Individual	Former Member, CIQ TC
Hidajet Hasimbegovic	Individual	Member, CIQ TC
Robert James	Individual	Member, CIQ TC
Joe Lubenow	Individual	Member, CIQ TC
Mark Meadows	Microsoft Corporation	Former Member, CIQ TC
John Putman	Individual	Former Member, CIQ TC
Michael Roytman	Vertex, Inc	Member, CIQ TC
Colin Wallis	New Zealand Government	Member, CIQ TC
David Webber	Individual	Member, CIQ TC
Graham Lobsey	Individual	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 (http://www.xbrl.org) 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 – http://www.opengeospatial.org) 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 (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=codelist) 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 examples^{1 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.

¹xAL-Australia.XML

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

²xAL-International.xml

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

xLink-2003-12-31.xsd

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

C. Revision History

Revision	Date	Editor	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