Specification URIs:

 

This Version:

http://docs.oasis-open.org/ciq/v3.0/prd02/supp/ciq-release-v3-prd2.html

http://docs.oasis-open.org/ciq/v3.0/prd02/supp/ciq-release-v3-prd2.doc

http://docs.oasis-open.org/ciq/v3.0/prd02/supp/ciq-release-v3-prd2.pdf

 

Previous Version:

N/A

 

Latest Version:

http://docs.oasis-open.org/ciq/v3.0/supp/ciq-release-v3.html

http://docs.oasis-open.org/ciq/v3.0/supp/ciq-release-v3.doc

http://docs.oasis-open.org/ciq/v3.0/supp/ciq-release-v3.pdf

 

Technical Committee:

OASIS Customer Information Quality TC

 

Chair(s):

Ram Kumar (kumar.sydney@gmail.com)

 

Editor(s):

Ram Kumar (kumar.sydney@gmail.com)

 

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

 

 

Abstract:

This document provides an overview of the differences between version 2.0 and version 3.0 of the CIQ TC Specifications

 

Status:

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 www.oasis-open.org/committees/ciq.

 

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 (www.oasis-open.org/committees/ciq/ipr.php.

 

The non-normative errata page for this specification is located at www.oasis-open.org/committees/ciq.

 

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.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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 http://www.oasis-open.org/who/trademark.php for above guidance.

 

 

1     Introduction.. 5

2     Differences between Version 2.0 and 3.0. 6

2.1 New Design Approach.. 6

2.2 DTD Support.. 6

2.3 Backward Compatibility.. 6

2.4 Names for Specifications. 6

2.5 UML Model. 7

2.6 Schema Structure. 7

2.6.1 Example. 7

2.7 Data Types. 8

2.8 Namespace. 8

2.9 Elements and Attributes. 9

2.10 Preservation of the Original Order.. 9

2.10.1 Example – normal order. 9

2.11 xLink to define Relationships. 9

2.12 Code List/Enumerations Support to customize CIQ Schemas to support application specific requirements. 9

2.12.1 Example. 10

2.13 Customization of CIQ Schemas to meet application specific requirements. 10

2.14 Data Quality Metrics. 10

2.14.1 Example – Data Quality. 11

2.15 Geo-coordinates. 11

2.16 Examples. 11

A.       Acknowledgements.. 12

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

C.       Revision History.. 14

 

 

The purpose of this document also is to give readers a quick snapshot of the differences between the two versions of the CIQ TC specifications and help plan them to migrate from version 2.0 to version 3.0.

·         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

 

In this section, we summarize the key differences between version 2.0 and version 3.0 of the CIQ TC specifications. The following documents should be read in conjunction with this document to get a detailed understanding of the differences:

·         CIQ TC – Technical Overview V3.0

·         CIQ TC – Name, Address and Party Specifications V3.0

·         CIQ TC – Party Relationships Specification V3.0 – release date not set yet

·         W3C xLink Recommendation (http://www.w3.org/1999/xlink)

2.1 New Design Approach

Version 3.0 has taken a new design approach to modeling CIQ Specifications. Please study the Technical Overview document or the CIQ XML Schemas for more information. The new approach is summarized as follows (See section 2.1 of Technical Overview document for further information):

·         Flat data structure design as opposed to the deeply nested hierarchical data structure in V2.0

·         Generic element and attributes reused throughout the schema, but at the same time maintaining the semantic integrity of the data

·         Importance of semantics by enabling users to define the semantics of data for a particular context (e.g. cultural requirements) rather than forcing a single/common definition on the users

·         Enumerations to support extensibility of the schema and to support customization of the schema to meet application requirements without impacting the structure of the schema

·         Strong focus on namespace support for extensibility in a controlled manner

·         Flexibility to meet cultural specific data semantic requirements

·         Design approach based on implementation requirements and to ease implementation by programmers/developers

·         Data Modeling approach

·         Practical Requirements based approach.

·         Provides a platform parties exchanging data to agree on interoperability with minimum complexity as the specifications are less ambiguous

2.2 DTD Support

Version 3.0 does not support any DTDs.

2.3 Backward Compatibility

Version 3.0 is NOT backward compatible with Version 2.0. However, version 3 can represent any party related information that version 2 can, but in a simpler and more elegant way easing the implementation tasks.

2.4 Names for Specifications

Term “PARTY” has a broader definition than term “CUSTOMER”. Customer is a subset of party. Therefore, the name “extensible Customer Information Language (xCIL)” is now replaced with the name “extensible Party Information Language (xPIL)” in version 3.0 and “extensible Customer Relationships Language (xCRL)” is now replaced with the name “extensible Party Relationships Language (xPRL)” in version 3.0.

 

2.5 UML Model

Version 3.0 provides high level UML models of the specifications that reflect the XML schemas that support the specifications.

2.6 Schema Structure

There are different ways to model data, including hierarchical, relational and object-oriented. Address data for example, is hierarchical in nature (Example: a country has cities, a city has streets and streets have premises, premises have sub premises etc). So a hierarchical model was used to design the data model in Version 2.0.

However, due to the deep nested structure of the schemas, building object models from the schemas have been proven to be complex to implement and expensive. Therefore, version 3.0 design uses a relational approach by defining a flat schema structure. An example that differentiates the two approaches is shown below. Let us consider the following address example:

2.6.1 Example

Egis Building, Level 12, 67 Albert Avenue,

Chatswood, NSW 2067, Australia

 

Representation in xAL Version 2.0

 

Representation in xAL Version 3.0

 

 

2.7 Data Types

Version 2.0 did not specify strong data types for text nodes and attribute values and hence, was ambiguous for implementers. This resulted in interoperability problems and additional data transformation work. All elements and attributes in version 3.0 are strongly data typed.

2.8 Namespace

Version 3 allows for attributes from other namespaces to reside under any element, but disallows elements from other namespaces as in the following example.

All elements in the CIQ Specifications are extensible allowing for any number of attributes from a non-target namespace to be added.

All elements share the same declaration:

This specification mandates that an application should not fail if it encounters an attribute from a non-target namespace. The application may choose to ignore or remove the attribute.

 

2.9 Elements and Attributes

With version 2.0, there was always ambiguity in placing elements and attributes because of the ability to use same elements and attributes in various places of the schema structure and xAL is a classical example of this. For example, “ThoroughfareName”, could be used under “Country”, “AdministrativeArea”, “SubAdministrativeArea”, “Locality”, “SubLocality”, “Thoroughfare”, or “SubThoroughfare” structures in the schema due to the hierarchical nature of address structures.

This ambiguity has been avoided in version 3.0 by flattening the structure.

Locally declared elements and attributes in version 3.0 do not have parent’s name as part of its own name as it was the case it version 2.0. 

2.10 Preservation of the Original Order

Order of name or address elements occurring in the original data should be preserved for correct presentation.

If an application needs to present the name to a user it may not always be aware about the correct order of the elements if the semantics of the name elements are not available.  Version 3.0 supports the order of presentation in xNL and xAL.

2.10.1 Example – normal order

could be presented as follows in version 3.0

and restored back to Mr Jeremy Apatuta Johnson PhD during data formatting exercise.

Any other order of NameElement tags in the XML fragment could lead to an incorrect presentation of the name.

2.11 xLink to define Relationships

xLink provides a set of attributes that can be reused within other namespaces. The meaning and usage of those attributes are well defined in the xLink specification from W3C. Version 3.0 of CIQ TC specifications uses xLink to define relationships between two parties. By incorporating xLink, the CIQ TC specifications have been significantly simplified for defining relationships between entities (e.g. more than one party)

However, support for relationships through key references is also available as an option.

2.12 Code List/Enumerations Support to customize CIQ Schemas to support application specific requirements

Version 3.0 supports for extensive use of code lists enumerations for flexibility in the way the schemas can be used. This enables adopters of the schemas to adjust the schemas for their specific needs without affecting the actual structure. Let us consider the following example:

 

 

2.12.1 Example

The above name is of Indian origin. This name in Anglo Saxon culture is represented as follows:

Version 3.0 provides the ability for the implementers to define the type of names as enumerations and in the above example, the enumeration values for NameElement are: PrecedingTitle, Title, GivenName, MiddleName and FamilyName. These values are provided with the schema.

If the above name had to be represented in its native Indian culture (applicable to southern part of India only), it would be represented as per the following example:

The implementers can add the enumeration list (in this case, PositionTitle, EducationTitle, NativePlaceName, FatherName, ActualName, and Degree) without impacting the structure of the schema.

However, it is important that the code lists/enumeration list has to be agreed by the parties involved to achieve interoperability. Moreover, these lists have to be managed / governed else, any change to the list without the knowledge of the other parties involved in the exchange will break interoperability.

Two ways of customizing code lists/enumerations is provided. One approach is representing the code lists as XML schema and including them as part of the CIQ Specification entity schemas namely, Name, Party, and Address. The other approach is representing the code lists in genericode format defined by OASIS Codelist technical committee.

2.13 Customization of CIQ Schemas to meet application specific requirements

Version 3.0 supports customisation of CIQ entity schemas (Party, Name and Address) without having to modify the base schemas. Customization can be achieved using enumeration list approach (two options provided, see section above) or by using the UMCLVV (Option 2 of Code List) to customize the CIQ base entity schemas using Schematron language without touching or modifying the base schemas. Schematron is an ISO based powerful and yet simple assertion based rule language that can be used to apply constraint rules on XML schemas.

2.14 Data Quality Metrics

One of the key aims of the CIQ (Customer Information Quality) TC is to enable representation and exchange of quality party information. 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 the interoperability of data 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.

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.

For the first time since the CIQ TC’s inception in 2000, version 3.0 of the CIQ TC specifications have concentrated on introducing simple data quality metrics to the data it represents. The specifications allows for data quality information to be provided as part of the entity using attribute DataQuality that can be set to either “Valid” or “Invalid”, if such status is known. If DataQuality attribute is omitted it is presumed that the validity of the data is unknown.

DataQuality attribute refers to the content of a container, e.g. PersonName, asserting that all the values are known to be true and correct. This specification has no provision for partial data quality where some parts of the content are correct and some are not or unknown.

2.14.1 Example – Data Quality

In this example John Anthony Jackson is known to be the true and correct value asserted by the sender of this data.

This feature allows the recipient of data to get an understanding of the quality of data they are receiving and assists them to take appropriate measures to handle the data according to its quality.

2.15 Address/Location Coordinates

Address specification provides options to use coordinates to map the location of the address. This is done by either using GeoRSS industry standard from Open Geospatial Consortium. Option is also provided to use some basic coordinates information.

2.16 Examples

Version 3.0 provides many more international address examples (covering most of the countries) than version 2.0 in “xal-international.xml” file.

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.

 

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.

 

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