This Technical Specification defines the OASIS Customer Information Quality Specifications Version 3.0 namely, Name (xNL), Address (xAL), Name and Address (xNAL) and Party Information (xPIL) specifications. This specification replaces the earlier version of the committee specifications released in November 2007.

This specification also includes changes to OASIS CIQ V3.0 xAL schema (both for default code list and genericode approaches). The changes to xAL V3.0 schema is documented as “OASIS CIQ v3.0 xAL Schema (xAL.xsd) Changes.doc” under “supp” directory of the specification package. This is the only change in this specification compared to the V3.0 committee specifications released in November 2007.

Status:

This document was last revised or approved by the OASIS CIQ Technical Committee (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 http://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 (http://www.oasis-open.org/committees/ciq/ipr.php.

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

Notices

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.

Table of Contents

1 Name, Address, Party and Party Relationship.. 5

1.1 Terminology.. 5

1.2 Definitions. 5

2 CIQ Specifications Version 3.0. 6

2.1 Formal Design Requirements. 6

2.2 Major CIQ Specification Entities. 6

2.3 Version 3.0 XML Schema Files. 7

2.4 Common Design Concepts Used.. 8

2.5 Namespaces Used.. 8

2.6 Other Industry Specifications/Standards Used.. 8

3 Entity “Name” (extensible Name Language) 10

3.1 Semantics of “Name”. 10

3.1.1 Example 1 – No Semantics (Unstructured/Free Text Data) 11

3.1.2 Example 2 – Minimal Semantics (Partially Structured Data) 11

3.1.3 Example 3 – Full Semantics (Fully Structured Data) 12

3.2 Data Types. 12

3.3 Code Lists (Enumerations) 12

3.3.1 What is a Code List?. 12

3.3.2 The importance of Code Lists for CIQ Specifications. 13

3.3.3 Customisable Code Lists. 14

3.3.4 Improving Interoperability using Code Lists. 15

3.4 Using Code Lists in CIQ Specifications – Two Options. 15

3.4.1 Why Two Options. 15

3.4.2 Option 1 – “Include” Code Lists (The Default Approach) 16

3.4.3 Option 2 – Code Lists using Genericode Approach. 18

3.5 Code List Packages – Option 1 and Option 2. 22

3.6 Order of Elements and Presentation.. 22

3.6.1 Example – Normal Order. 22

3.7 Data Mapping.. 22

3.7.1 Example – Complex-to-simple Mapping. 23

3.7.2 Example – Simple-to-complex Mapping. 23

3.8 Data Quality.. 24

3.8.1 Example – Data Quality. 24

3.8.2 Data Quality Verification and Trust 25

3.8.3 Data Validation. 25

3.9 Extensibility.. 25

3.9.1 Extending the Schemas to Meet Application Specific Requirements. 25

3.9.2 Extensibility - Practical Applications. 25

3.10 Linking and Referencing.. 26

3.10.1 Using xLink [OPTIONAL]. 26

3.10.2 Using Key Reference [OPTIONAL]. 27

3.11 ID Attribute.. 27

3.12 Schema Conformance.. 28

3.13 Schema Customisation Guidelines. 28

3.13.1 Namespace. 28

3.13.2 Reducing the Entity Schema Structure. 28

3.13.3 Customising the Code Lists/Enumerations of Name. 29

3.13.4 Using the Methodology to customise Name Schema to meet application specific requirements. 29

4 Entity “Address” (extensible Address Language) 31

4.1 Semantics of “Address”. 31

4.1.1 Example – Minimal Semantics (Unstructured/Free Text Data) 31

4.1.2 Example – Partial Semantics (Partially Structured Data) 31

4.1.3 Example – Full Semantics (Fully Structured Data) 33

4.2 Data Types. 33

4.3 Code Lists (Enumerations) 33

4.4 Order of Elements and Presentation.. 33

4.5 Data Mapping.. 34

4.5.1 Example – Normal Order. 34

4.6 Data Quality.. 34

4.7 Extensibility.. 34

4.8 Linking and Referencing.. 34

4.9 ID Attribute.. 34

4.10 Schema Conformance.. 34

4.11 Address/Location Referenced By GeoRSS and Coordinates. 35

4.11.1 Using GeoRSS in xAL Schema. 35

4.11.2 Defining Location Coordinates in xAL Schema. 38

4.12 Schema Customisation Guidelines. 39

4.12.1 Customising the Code Lists/Enumerations of Address. 39

4.12.2 Using CVA to customise CIQ Address Schema to meet application specific requirements. 40

5 Combination of “Name” and “Address” (extensible Name and Address Language) 42

5.1 Use of element xnal:Record.. 42

5.1.1 Example. 42

5.2 Use of element xnal:PostalLabel.. 43

5.2.1 Example. 43

5.3 Creating your own Name and Address Application Schema.. 44

6 Entity “Party” (extensible Party Information Language) 45

6.1 Reuse of xNL and xAL Structure for Person or Organisation Name and Address. 45

6.2 Party Structures - Examples. 46

6.2.1 Example – Qualification Details. 46

6.2.2 Example – Birth Details. 46

6.2.3 Example – Driver License. 46

6.2.4 Example – Contact Phone Number. 46

6.2.5 Example – Electronic Address Identifiers. 46

6.3 Dealing with Joint Party Names. 47

6.4 Representing Relationships with other Parties. 47

6.4.1 Example – Person Relationship with other Persons of type “Friend”. 49

6.4.2 Example – Organisation Relationship with other Organisations of type “Branch”. 49

6.4.3 Example – Person Relationship with another Person. 49

6.5 Data Types. 50

6.6 Code Lists (Enumerations) 50

6.7 Order of Elements and Presentation.. 50

6.8 Data Mapping.. 50

6.9 Data Quality.. 50

6.10 Extensibility.. 50

6.11 Linking and Referencing.. 50

6.12 Schema Conformance.. 51

6.13 Schema Customisation Guidelines. 51

6.13.1 Customising the Code Lists/Enumerations of Party. 51

6.13.2 Using CVA to customise Party Schema to meet application specific requirements. 52

7 Differences between two types of Entity Schemas for CIQ Specifications. 53

7.1 Files for Option 1 (The Default) 53

7.2 Files for Option 2. 54

7.2.1 XML Schema Files. 54

7.2.2 Genericode Based Code List Files. 54

7.3 Namespace Assignment.. 55

7.4 Differences between CIQ Entity Schemas used in Option 1 and Option 2. 55

7.4.1 Compatibility between XML documents produced using Option 1 and Option 2 CIQ XML Schemas. 58

7.4.2 Which Code List Package to Use? Option 1 or Option 2?. 58

8 Data Exchange and Interoperability.. 59

8.1 Data Interoperability Success Formula.. 59

8.2 Information Exchange Agreement - Guidelines. 59

9 Conformance.. 61

9.1 Conformance Clauses. 61

9.1.1 Specifications Schema Conformance. 61

9.1.2 Specifications Schema Extensibility Conformance. 61

9.1.3 Specifications Code List Schema Customisation Conformance. 61

9.1.4 Interoperability Conformance. 61

10 Miscellaneous. 63

10.1 Documentation.. 63

10.2 Examples. 63

10.3 Contributions from Public.. 63

11 Change Log.. 64

A. Acknowledgements. 65

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

C. Revision History.. 67

1 Name, Address, Party and Party Relationship

1.1 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].

While RFC2119 permits the use of synonyms, to achieve consistency across specifications, “MUST” is used instead of “SHALL” and “REQUIRED”, “MUST NOT” instead of “SHALL NOT”, and “SHOULD” instead of “RECOMMENDED” in this specification. To enable easy identification of the keywords, uppercase is used for keywords.

1.2 Definitions

Following are the core entities and its definitions used by CIQ TC:

Name

Name of a person or an organisation

Address

A physical location or a mail delivery point

Party

A Party could be of two types namely,

· Person

· Organisation

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

Party data consists of many attributes (e.g. Name, Address, email address, telephone, etc) that are unique to a party. However, a person or organisation’s name and address are generally the key identifiers (but not necessarily the unique identifiers) of a “Party”. A “Customer” is of type “Party”.

Party Relationship

Pairwise affiliation or association between two people, between two organisations, or between an organisation and a person.

xPRL supports chains of interlocking pairwise party relationships, linked by common members.

2 CIQ Specifications Version 3.0

2.1 Formal Design Requirements

Following are the formal design requirements taken into consideration for version 3.0 XML Schemas of CIQ Specifications:

· Data structures SHOULD be described using W3C XML Schema language

· Data structures SHOULD be separated into multiple namespaces for reuse of the core Party entities (e.g. Person Name, Organisation Name, Address, Party Centric Information)

· Data structures SHOULD be able to accommodate all information types used for data exchanges based on previous versions of the CIQ Specifications

· Data structures SHOULD be extensible (also, allow reduction in complexity) to provide enough flexibility for point-to-point solutions and application-specific scenarios

· Data structures SHOULD allow application-specific information to be attached to entities without breaking the structures.

· Implementation complexity SHOULD be proportional to the complexity of the subset of data structures used by the implementer

· Data structures SHOULD be customisable to meet different end user requirements without breaking the structures and at the same time, conforming to the core specification.

2.2 Major CIQ Specification Entities

The entire party information space is divided into a number of complex information types that are viewed as core entities. This enables re-use of the core entities as required. We categorise these core entities of CIQ Specifications into four namely,

· Name

· Address

· Party Centric Information, and

· Party Relationships

Following are the basic and core CIQ specification entities defined in XML schemas as re-usable types:

· Name (Person or Organisation - see xNL.xsd schema)

· Address (see xAL.xsd schema)

· Name and Address combined (see xNAL.xsd schema)

· Personal details of a person (person-centric information) (see xPIL.xsd schema)

· Organisation specific details (organisation-centric information) (see xPIL.xsd schema)

· Party Relationships (see xPRL.xsd [not available in this release] and xLink-2003-12-31-revised.xsd schemas)

These core entities are supported by relevant code lists/enumerations to add “semantics/meaning” to the data they represent. This will be discussed in detail in the following sections.

2.3 Version 3.0 XML Schema Files

Following are the different XML schemas produced for version 3.0:

XML Schema File name	Description	Comments
xNL.xsd	Entity Name	Defines a set of reusable types and elements for a name of individual or organisation
xNL-types.xsd	Entity Name Enumerations	Defines a set of enumerations to support Name entity
xAL.xsd	Entity Address	Defines a set of reusable types and elements for an address, location name or description
xAL-types.xsd	Entity Address Enumerations	Defines a set of enumerations to support address entity
xNAL.xsd	Name and Address binding	Defines two constructs to associate/link names and addresses for data exchange or postal purposes
xNAL-types.xsd	Name and Address binding Enumerations	Defines a set of enumerations to support name and address binding
xPIL.xsd (formerly xCIL.xsd)	Entity Party (organisation or individual)	Defines a set of reusable types and elements for a detailed description of an organisation or individual centric information
xPIL-types.xsd	Entity Party (organisation or individual) Enumerations	Defines a set of enumerations to support party centric information entity
CommonTypes.xsd	Common Data Types and Enumerations	Defines a set of commonly used data types and enumerations in the CIQ Schemas
xLink-2003-12-31.xsd	xLink attributes	Implements a subset of W3C xLink specification attributes as XML schema
*.gc files	Entity Party, Name, and Address	Defines a set of enumerations/code lists in genericode format

2.4 Common Design Concepts Used

Name, Address and Party schemas are designed to bring interoperability to the way these most “common” Party related entities are used across all spectrums of business and government.

Name, Address and Party information components of version 3.0 share common design concepts that are implemented as XML Schemas. This commonality should simplify understanding and adoption of the XML Schemas. The xNAL schema design concept varies slightly as it is only a simple container for associating/linking names and addresses.

The design concepts of Name, Address and Party schemas are similar in terms of the way semantic information is represented to add the required “meaning” to the data. For example, for a person’s name data, “Given Name, “Middle Name’ Surname” etc, are the semantic information that add meaning to the data.

All common design concepts used in the CIQ Specifications (e.g. using code lists/enumerations, customising CIQ entity schemas, extending CIQ entity schemas, referencing between entities, defining business rules to constrain CIQ entity schemas) are equally applicable for all key entities of CIQ specifications namely, Name, Address and Party. These common concepts are explained in detail in section 3 (Entity “Name”). Users SHOULD study that section in detail before proceeding to other entities namely, Address and Party, as these concepts are applicable to these entities also.

2.5 Namespaces Used

Following are the namespaces used in the specification:

Entity	Namespace	Suggested Prefix	XML Schema Files
Name	urn:oasis:names:tc:ciq:xnl:3	xnl (or) n	xNL.xsd xNL-types.xsd
Address	urn:oasis:names:tc:ciq:xal:3	xal (or) a	xAL.xsd xAL-types.xsd
Name and Address	urn:oasis:names:tc:ciq:xnal:3	xnal	xNAL.xsd xNAL-types.xsd
Party	urn:oasis:names:tc:ciq:xpil:3	xpil (or) p	xPIL.xsd xPIL-types.xsd