This CIQ Profile describes a subset of components and component types from the Customer Information Quality (CIQ) standard, useful for describing persons and organizations, chosen for reuse across the suite of Emergency Data Exchange Language (EDXL) standards. This subset is intended for internal use by the Emergency Management Technical Committee and its subcommittees as they develop specific standards utilizing these types.

Status:

This document was last revised or approved by the OASIS Emergency Management TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency#technical.

TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the Technical Committee’s web page at https://www.oasis-open.org/committees/emergency/.

For information on whether any patents have been disclosed that may be essential to implementing this Work Product, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC's web page (https://www.oasis-open.org/committees/emergency/ipr.php).

Citation format:

When referencing this Work Product the following citation format should be used:

[EDXL-CIQ]

Emergency Data Exchange Language (EDXL) Customer Information Quality (CIQ) Profile Version 1.0. Edited by Werner Joerg and Jeff Waters. 13 January 2015. OASIS Committee Specification Draft 04. http://docs.oasis-open.org/emergency/edxl-ciq/v1.0/csd04/edxl-ciq-v1.0-csd04.html. Latest version: http://docs.oasis-open.org/emergency/edxl-ciq/v1.0/edxl-ciq-v1.0.html.

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 name "OASIS" is a trademark 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 https://www.oasis-open.org/policies-guidelines/trademark for above guidance.

Table of Contents

1 Introduction. 5

1.1 Terminology. 5

1.2 Normative References. 5

1.3 Non-Normative References. 6

2 Design Principles & Concepts (non-normative) 7

2.1 Design Philosophy. 7

2.2 Structural Summary. 7

2.2.1 Organization of Schema files. 7

2.2.2 CIQ Top Level Elements. 7

2.2.3 CIQ Elements. 8

3 CIQ Profile Structure (normative) 9

3.1 Data Dictionary. 9

3.1.1 CIQ Elements. 9

3.1.2 Enumerated Types. 20

4 Conformance. 23

Appendix A Acknowledgements. 24

Appendix B Non-Normative Text 25

Appendix C Revision History. 26

1 Introduction

[All text is normative unless otherwise labeled]

This document describes common components and component types for describing persons and organizations that can be reused across the suite of Emergency Data Exchange Language (EDXL) standards. These particular components are derived from the Customer Information Quality (CIQ) standard. See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ciq#overview for more information about CIQ, including the quick summary provided here:

The objective of the OASIS CIQ Technical Committee (formed in 2000) is to deliver a set of XML Specifications for defining, representing, inter operating and managing "PARTY (Person or Organisation) CENTRIC INFORMATION" that are truly open, vendor neutral, industry and application independent, and importantly "Global" (ability to represent international data formats such as different types of party names and addresses used in 241+ countries).

The CIQ family of specifications are designed to represent party data (e.g. name and address) independent of any culture, geographical location, application or industry at an abstract (simple representation of data - free text format) or detailed (complex representation, i.e. breaking the data into its atomic elements - structured format) level from a data integrity and quality perspective and therefore, is truly a "global" (International) specification for representing party information.

The Emergency Management Technical Committee has the need to represent basic person and organization information across its standards and has chosen to reuse the important work performed by the OASIS CIQ Technical Committee; however, to make this reuse easy and understandable, the EM TC has authorized the development of this “profile” which is a set of schema which utilize only a portion of the entire CIQ schema and which create XML fragments which validate against those schema.

This document is intended for internal use by the Emergency Management Technical Committee and its subcommittees as they develop specific standards utilizing these types.The goal is to enable reuse of components which are commonly used in specifications and which have been designed based on lessons learned from the development of the Common Alert Protocol 1.1, the Distribution Element 1.0, Hospital Availability and Resource Messaging. The first use of this CIQ profile is intended to be in Situation Reports 1.0 and the Distribution Element 2.0. The components will be used and expanded as needed for future EDXL specifications.

1.1 Terminology

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

1.2 Normative References

[RFC2119]

S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt.

[RFC2046]

N. Freed, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, IETF RFC 2046, November 1996. http://www.ietf.org/rfc/rfc2046.txt.

[RFC3066]

H. Alvestrand, Tags for the Identification of Languages, IETF RFC 3066, January 2001. http://www.ietf.org/rfc/rfc3066.txt.

[WGS 84]

National Geospatial Intelligence Agency, Department of Defense, World Geodetic System 1984, NGA Technical Report TR8350.2, January 2000. http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf.

[XML 1.0]

T. Bray, Extensible Markup Language (XML) 1.0 (Third Edition), W3C REC-XML-20040204, (Fifth Edition), 26 November 2008. http://www.w3.org/TR/REC-xml/.

[namespaces]

T. Bray, Namespaces in XML, W3C REC-xml-names-19990114, (Third Edition) W3C Recommendation 8 December 2009. http://www.w3.org/TR/REC-xml-names/.

[dateTime]

N. Freed, XML Schema Part 2: Datatypes (Second Edition), W3C REC-xmlschema-2, October 2004. http://www.w3.org/TR/xmlschema-2/#dateTime.

1.3 Non-Normative References

[EDXL GFR]

EDXL General Functional Requirements, OASIS Emergency Management TC, 4 November 2004 http://www.oasis-open.org/committees/download.php/10031/EDXL%20General%20Functional%20Requirements.doc,

[EDXL-DE IG]

EDXL Distribution Element Implementer's Guide, Edited by Patti Aymond, 19 Aug. 2005. OASIS Working Draft WD01. http://www.oasis-open.org/committees/download.php/14120/EDXL_Implementer%27sGuide.doc

2 Design Principles & Concepts (non-normative)

2.1 Design Philosophy

Below are some of the guiding principles of the EDXL CIQ Profile:

1. Provide a method to capture and reuse xml types and elements for representing persons and organizations which are commonly needed across multiple EDXL standards.

2. Provide flexible mechanisms to update the EDXL CIQ Profile efficiently, without slowing down the EDXL standards development process.

3. Allow for easy updates to capture fixes or improvements.

4. Ease the reuse and understanding of the basic CIQ person and organization elements and types important for emergency management.

5. Speed the development of EDXL Standards through reuse of common components and thereby improve information sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services.

6. Support the integration of data elements from profiles which enables efficient and effective reuse of other important open standards.

2.2 Structural Summary

About multiplicity notation: “[l..h]” designates range from lower bound l to higher bound h, with both l and h Natural numbers, 0 ≤ l ≤ h, plus option “*” (unbounded) for h.

About notation: “(.., ..)” lists attributes.

2.2.1 Organization of Schema files

EDXL-CIQ is based on the 3 schema files (Name (xNL), Address (xAL), and Party (xPIL)) of OASIS CIQ Standard version 3.0 [OASIS CIQ]. The necessary definitions are replicated in the EDXL-CIQ name space as xNL-types.xsd, xAL-types.xsd, xPIL-types.xsd and CommonTypes.xsd files – these files must not be modified unless so required to adapt to a later OASIS-CIQ release. The EDXL-CIQ specific schemas are built as profiles in the files edxl-xNL.xsd, edxl-xAL.xsd and edxl-xPIL.xsd.

2.2.2 CIQ Top Level Elements

Element/Type Schema

party: PartyType edxl-xPIL.xsd

partyName [0..1]: PartyNameType edxl-xNL.xsd

addresses [0..1]: address edxl-xPIL.xsd

contactNumbers [0..1]: contactNumber “

electronicAddressIdentifiers [0..1]: electronicAddressIdentifier “

identifiers [0..1]: identifier “

organisationInfo [0..1] “

personDetails: PersonDetailsType edxl-xPIL.xsd

xnl:PersonName [1..*]: PersonNameType edxl-xNL.xsd

addresses [0..1]: address edxl-xPIL.xsd

contactNumbers [0..1]: contactNumber “

electronicAddressIdentifiers [0..1]: electronicAddressIdentifier “

identifiers [0..1]: identifier “

organisationDetails: OrganisationDetailsType edxl-xPIL.xsd

xnl:organisationName [1..*]: OrgansationNameType edxl-xNL.xsd

oddresses [0..1]: oddress edxl-xPIL.xsd

contactNumbers [0..1]: contactNumber “

electronicAddressIdentifiers [0..1]: electronicAddressIdentifier “

organisationInfo [0..1] + attributes “

2.2.3 CIQ Elements

Element/Type Schema

address [0..*]: AddressType edxl-xAL.xsd

freeTextAddress [0..1] “

addressLine [1..*] “

country [0..1]: CountryType “

nameElement [1..1] “

administrativeArea [0..1] “

nameElement [1..*] “

subAdministrativeArea [0..1] “

nameElement [1..*] “

locality [0..1] “

nameElement [1..*] “

subLocality [0..1] “

nameElement [1..*] “

thoroughfare [0..1]: ThoroughfareType “

nameElement [1..1] + attribute: NameKind “

number [1..1]: IdentifierType

+ attribute: Kind “

postCode [0..1] “

identifier [1..*]: IdentifierType “

contactNumber [1..*] edxl-xPIL.xsd

contactNumberElement [0..*] + attribute: Kind

+ attributes: CommunicationMediaKind, Usage, ContactHours “

electronicAddressIdentifier [1..*] + attributes: Kind, Usage “

identifier [1..*] “

identifierElement [0..*] + attribute: Kind “

issuerName [0..1]: xnl:OrganisationNameType “

OrganisationNameType edxl-xNL.xsd

nameElement [0..*]

subDivisionName [0..*] “

+ attributes: OrganisationID, OrganisationIDKind “

OrganisationInfo + attributes: edxl-xPIL.xsd

Kind, CategoryKind, Status, Nature, IndustryKind,

IndustryCode, IndustryCodeKind, NumberOfEmployees,

OperatingHourStartTime, OperatingHourEndTime

3 CIQ Profile Structure (normative)

3.1 Data Dictionary

3.1.1 CIQ Elements

Namespaces and prefixes used below include:

xs="http://www.w3.org/2001/XMLSchema"

ct="urn:oasis:names:tc:emergency:edxl:ciq:1.0:ct"

xpil="urn:oasis:names:tc:emergency:edxl:ciq:1.0:xpil"

<no prefix>=”urn:oasis:names:tc:emergency:edxl:ciq:1.0:xpil”

xal="urn:oasis:names:tc:emergency:edxl:ciq:1.0:xal"

xnl="urn:oasis:names:tc:emergency:edxl:ciq:1.0:xnl"

Element	party
BaseType	xnl:PartyType
Usage	OPTIONAL [0..1]
Schema	edxl-xPIL.xsd
Definition	A container for defining the unique characteristics of a party, which can be a person or an organization.
Comments
Sub-elements	· partyName [0..1] · addresses [0..1] · contactNumbers [0..1] · electronicAddressIdentifiers [0..1] · identifiers [0..1] · organisationInfo [0..1]
Used In	Top level element
Example

Element	personDetails
BaseType	PersonDetailsType
Usage	OPTIONAL [0..1]
Schema	edxl-xPIL.xsd
Definition	A container for defining the unique characteristics of a person only.
Comments
Sub-elements	· xnl:personName [1..*] · addresses [0..1] · contactNumbers [0..1] · electronicAddressIdentifiers [0..1] · identifiers [0..1]
Used In	Top level element
Example	<personDetails> <xnl:personName> <xnl:nameElement>Mary Smith</xnl:nameElement> </xnl:personName> </personDetails>

Element	organisationDetails
BaseType	OrganisationDetailsType
Usage	OPTIONAL [0..1]
Schema	edxl-xPIL.xsd
Definition	A container for defining the unique characteristics of an organisation only.
Comments	Note the English spelling of “Organisation”
Sub-elements	· xnl:organisationName [1..*] · addresses [0..1] · contactNumbers [0..1] · electronicAddressIdentifiers [0..1] · organisationInfo [0..1]
Used In	Top level element
Example	<organisationDetails> <xnl:organisationName> <xnl:nameElement>Mary Smith</xnl:nameElement> </xnl:organisationName> </organisationDetails>

Element	addresses
BaseType	complexType
Usage	OPTIONAL [0..1]
Schema	edxl-xPIL.xsd
Definition	A container for one or more Address elements
Comments
Sub-elements	address [0..*]
Used In	· organisationDetails · party · personDetails
Examples

Element	address
BaseType	xal:AddressType
Usage	OPTIONAL [0..*]
Definition	A container for an address.
Comments
Sub-elements	· freeTextAddress [0..1] · country [0..1] · administrativeArea [0..1] · locality [0..1] · thoroughfare [0..1] · postCode [0..1]
Used In	addresses
Examples	<ct:valueListURI>http://example.com/mylist</ct:valueListURI> <ct:valueListURI> urn:oasis:names:tc:emergency:EDXL:DE:2.0:Defaults:DistributionType </ct:valueListURI>

Element	[address.]freeTextAddress
BaseType	complexType
Usage	OPTIONAL [0..1]
Definition	A container for free text address elements where address elements are not parsed.
Comments
Sub-elements	addressLine [1..*] of type ct:String
Used In	address
Examples

Element	[address.]country
BaseType	CountryType
Usage	OPTIONAL [0..1]
Definition	Country details.
Comments
Sub-elements	nameElement [1..1] of type ct:String
Used In	address
Examples

Element	[address.Country.]nameElement
BaseType	ct:String
Usage	REQUIRED [1..1]
Definition	Data associated with the name of the country in whatever form available, e.g. full, abbreviation, common use, code of the country, etc.
Comments
Sub-elements	None
Used In	address.country
Examples

Element	[address.]administrativeArea
BaseType	complexType
Usage	OPTIONAL [0..1]
Definition	Details of the top-level area division in the country, such as state, district, province, island, region, etc. Note that some countries do not have this.
Comments
Sub-elements	· nameElement [1..*] · subAdministrativeArea [0..1]
Used In	address
Examples

Element	[address.administrativeArea.]nameElement
BaseType	ct:String
Usage	REQUIRED [1..1]
Definition	Data associated with the Administrative Area. e.g. Full name of administrative area or part of it. eg. MI in USA, NSW in Australia, reference location to the administrative area.
Comments
Sub-elements	None
Used In	address.administrativeArea
Examples

Element	[address.administrativeArea.]subAdministrativeArea
BaseType	complexType
Usage	OPTIONAL [0..1]
Definition	The next level down division of the area. E.g. state / county, province / reservation. Note that not all countries have a sub-administrative area
Comments
Sub-elements	nameElement [1..*]
Used In	address.administrativeArea
Examples

Element	[address.administrativeArea.subAdministrativeArea.]nameElement
BaseType	ct:String
Usage	REQUIRED [1..*]
Definition	Data associated with the subAdministrativeArea. e.g. Full name of sub-administrative area or part of it.
Comments
Sub-elements	None
Used In	address.administrativeArea.subAdministrativeArea
Examples

Element	[address.]locality
BaseType	complexType
Usage	OPTIONAL [0..1]
Definition	Details of Locality which is a named densely populated area (a place) such as town, village, suburb, etc. A locality composes of many individual addresses. Many localities exist in an administrative area or a sub administrative area. A locality can also have sub localities. For example, a municipality locality can have many villages associated with it which are sub localities. Example: Tamil Nadu State, Erode District, Bhavani Taluk, Paruvachi Village is a valid address in India. Tamil Nadu is the Administrative Area, Erode is the sub admin area, Bhavani is the locality, and Paruvachi is the sub locality
Comments
Sub-elements	· nameElement [1..*] of type ct:String · subLocality [0..1]
Used In	address
Examples

Element	[address.locality.]nameElement
BaseType	ct:String
Usage	REQUIRED [1..*]
Definition	Data associated with the locality. e.g. full name of the locality or part of it, reference location to the locality
Comments
Sub-elements	None
Used In	address.locality
Examples

Element	[adress.locality.]subLocality
BaseType	complexType
Usage	OPTIONAL [0..1]
Definition	A locality that is smaller and is contained within the boundaries of its parent locality. Note that not all localities have sub-locality. For example, many areas within a locality where each area is a sub-locality
Comments
Sub-elements	nameElement [1..*]
Used In	address.locality
Examples

Element	[address.locality.subLocality.]nameElement
BaseType	ct:String
Usage	REQUIRED [1..*]
Definition	Data associated with the sub-locality. e.g. Full name of the locality or part of it, reference location to the locality.
Comments
Sub-elements	None
Used In	address.locality.subLocality
Examples

Element	[address.]thoroughfare
BaseType	ThoroughfareType
Usage	OPTIONAL [0..1]
Definition	Details of the Access route along which buildings/lot/land are located, such as street, road, channel, crescent, avenue, etc. This also includes canals/banks on which houses/boat houses are located where people live
Comments	The Type attribute represents the type of thoroughfare. e.g. primary road, secondary road, road branch (e.g. Lane 14), road sub branch (e.g. Alley 21), adjourning street, cross street, closest street, etc
Attributes	Type: ThoroughfareTypeList (see xAL-types.xsd)
Sub-elements	Choice [1..*] between · nameElement [1..1] OR · number [1..1]
Used In	address
Examples

Element	[address.thoroughfare.]nameElement
BaseType	ct:String
Usage	REQUIRED [1..1]
Definition	Data associated with the thoroughfare details. e.g. Full thoroughfare name or part of it, type of thoroughfare, old name, new name, reference data in support of the thoroughfare
Comments
Attributes	· ct:grAbbreviation:Abbreviation – xs:boolean (see CommonTypes.xsd) · NameKind: ThoroughfareNameTypeList (see xAL-types.xsd)
Sub-elements	None
Used In	address.thoroughfare
Examples

Element	[address.thoroughfare.]number
BaseType	IdentifierType extends ct:String
Usage	REQUIRED [1..1]
Definition	Data associated with the number of the thoroughfare. E.g. 39 in 39 Baker Street, street range, street suffix
Comments	The Type attribute indicates which part of number or identifier this element contains. Some "numbers" are as simple as 42 and some "numbers" are more like complex aplhanumeric identifiers as Postcodes in UK or Canada, e.g. M2H 2S5. It may be necessary to separate the "number" into sub-elements and indicate what type of information each of them contains.
Attributes	· Kind: IdentifierElementTypeList (see xAL-types.xsd) · ct:grAbbreviation:Abbreviation – xs: boolean (see CommonTypes.xsd)
Sub-elements	None
Used In	address.thoroughfare
Examples

Element	[address.]postCode
BaseType	complexType
Usage	OPTIONAL [0..1]
Definition	A container for a single free text or structured postcode. Note that not all countries have post codes
Comments	The postcode is formatted according to country-specific rules. Example: SW3 0A8-1A, 600074, 2067. This element can also be used to define the semantics of what each code in the post code means
Sub-elements	identifier [1..*]

Used In	address
Examples

Element	[address.postCode.]identifier
BaseType	IdentifierType extends ct:String
Usage	REQUIRED [1..*]
Definition	The postcode is formatted according to country-specific rules. Example: SW3 0A8-1A, 600074, 2067. This element can also be used to define the semantics of what each code in the post code means
Comments	The Type attribute indicates which part of number or identifier this element contains. Some "numbers" are as simple as 42 and some "numbers" are more like complex aplhanumberic identifiers as Postcodes in UK or Canada, e.g. M2H 2S5. It may be necessary to separate the "number" into sub-elements and indicate what type of information each of them contains.
Attributes	· Type: IdentifierElementTypeList (see xAL-types.xsd) · ct:grAbbreviation:Abbreviation – xs: boolean (see CommonTypes.xsd)
Sub-elements	None
Used In	address.postCode
Examples

Element	contactNumbers
BaseType	complexType
Usage	OPTIONAL [0..1]
Schema	edxl-xPIL.xsd
Definition	A container for all kinds of telecommunication lines of party used for contact purposes. e.g. phone, fax, mobile, pager, etc.
Comments
Sub-elements	contactNumber [1..*]
Used In	· party · personDetails · organisationDetails
Examples

Element	contactNumber
BaseType	complexType
Usage	REQUIRED [1..*]
Definition	Universal telecommunication number structure
Comments
Attributes	· CommunicationMediaKind: CommunicationMediaTypeList (xPIl-types.xsd) · Usage: ContactNumberUsageList (see xPIl-types.xsd) · ContactHours: ct:String
Sub-elements	contactNumberElement [0..*]
Used In	contactNumbers
Examples

Element	[contactNumber.]contactNumberElement
BaseType	ct:String
Usage	OPTIONAL [0..*]
Definition	Full contact number or part of it
Comments
Attributes	Kind: ContactNumberElementList (see xPIL-types.xsd)
Sub-elements	None
Used In	contactNumber
Examples

Element	electronicAddressIdentifiers
BaseType	complexType
Usage	OPTIONAL [0..1]
Schema	edxl-xPIL.xsd
Definition	A container of different types of electronic addresses of party (e.g. email, chat, skype, etc)
Comments
Sub-elements	electronicAddressIdentifier [1..*]
Used In	· party · personDetails · organisationDetails
Examples

Element	electronicAddressIdentifier
BaseType	ct:String
Usage	REQUIRED [1..*]
Definition	Universal telecommunication number structure
Comments
Attributes	· Kinde: ElectronicAddressIdentiferTypeList (see xPIL-types.xsd) · Usage: ElectronicAddressIdentifierUsageList (see xPIL-types.xsd)
Sub-elements	None
Used In	electronicAddressIdentifiers
Examples

Element	identifiers
BaseType	complexType
Usage	OPTIONAL [0..1]
Schema	edxl-xPIL.xsd
Definition	A container for a list of Identifiers to recognise the party such as customer identifer, social security number, tax number, etc
Comments
Sub-elements	identifier [1..*]
Used In	· party · personDetails
Examples

Element	identifier
BaseType	complexType
Usage	REQUIRED [1..*]
Definition	Identifier to recognise the party such as customer identifer, social security number, National ID Card, tax number, buiness number, company number, company registration, etc
Comments
Attributes	Kind: PartyIdentifierTypeList (see xPIL-types.xsd)
Sub-elements	· identifierElement [0..*] · issuerName [0..1]
Used In	identifiers
Examples

Element	[identifier.]identifierElement
BaseType	ct:String
Usage	OPTIONAL [0..*]
Definition	Information about the identifier
Comments
Attributes	Kind: PartyIdentifierElementList (see xPIL-types.xsd)
Sub-elements
Used In	identifier
Examples

Element	[identifier.]issuerName
BaseType	xnl:OrganisationNameType
Usage	OPTIONAL [0..1]
Definition	Reference to a Party element that describes the issuing organisation
Comments
Attributes	· OrganisationID: ct:String · OrganisationIDKind: OrganisationIDTypeList (see xNL-types.xsd)
Sub-elements	· nameElement [0..]: ct:String · subDivisionName [0..]: ct:String
Used In	identifier
Examples

Element	organisationInfo
BaseType	complexType
Usage
Definition	Container for organisation specific details that are not covered in this schema that is common to a party
Comments
Attributes	· Kind: OrganisationInfoTypeList (see xPIL-types.xsd) · CategoryKind: OrganisationCategoryTypeList (see xPIL-types.xsd) · Status: ct:StatusList (see CommonTypes.xsd) · Nature: OrganisationInfoNatureList (see xPIL-types.xsd) · IndustryKind: IndustryTypeList (see xPIL-types.xsd) · IndustryCode: IndustryCodeList (see xPIL-types.xsd) · IndustryCodeKind: ct:String · NumberOfEmployees: ct:String · OperatingHourStartTime: xs:time · OperatingHourEndTime: xs:time · anyAttribute from namespace=”##other” · AttributeGroups: ct:grDataQuality (see CommonTypes.xsd) ◦ DataQualityType: DataQualityTypeList (see CommonTypes.xsd) ◦ ValidFrom: xs:dateTime ◦ ValidTo: xs:dateTime
Sub-elements	None
Used In	· party · organisationDetails
Examples

3.1.2 Enumerated Types

Attribute	CategoryKind
BaseType	OrganisationCategoryTypeList
Usage
Definition	List of category the organisation belongs to
Comments	The OrganisationCategoryTypeList is found in xPIL-types.xsd.
Values	Vendor, GovernmentAgency, University, College, School, Club, Association, Consortium, Company
Used In	organisationInfo
Examples

Attribute	DataQualityType
BaseType	ct:DataQualityTypeList
Usage
Definition	A list of values to indicate the level of reliability of the data
Comments	The DataQualityTypeList is found in CommonTypes.xsd.
Values	Valid, Invalid
Used In	organisationInfo
Examples

Attribute	[identifierElement.]Kind
BaseType	PartyIdentifierElementList
Usage
Definition	List of information types used for describing party identifiers
Comments	The PartyIdentiferElementList is found in xPIL-types.xsd.
Values	Identifier, IssuingCountryName
Used In	identifierElement
Examples

Attribute	[identifier.]Kind
BaseType	PartyIdentifierTypeList
Usage
Definition	List of identifier types
Comments	The PartyIdentiferTypeList is found in xPIL-types.xsd.
Values	TaxID, CompanyID, NationalID, RegistrationID
Used In	identifier
Examples

Attribute	[electronicAddressIdentifier.]Kind
BaseType	ElectronicAddressIdentifierTypeList
Usage
Definition	List of electronic address identifiers
Comments	The ElectronicAddressIdentifierTypeList is found in xPIL-types.xsd.
Values	AIM, EMAIL, GOOGLE, GIZMO, ICQ, JABBER, MSN, SIP, SKYPE, URL, XRI, YAHOO
Used In	electronicAddressIdentifier
Examples

Attribute	[contactNumberElement.]Kind
BaseType	ContactNumberElementList
Usage
Definition	List of information types used for phone number details
Comments	The ContactNumberElementList is found in xPIL-types.xsd.
Values	CountryCode, AreaCode, LocalNumber, Extension, Pin, Separator, NationalNumber, InternationalNumber
Used In	contactNumberElement
Examples

Attribute	communicationMediaKind
BaseType	CommunicationMediaTypeList
Usage
Definition	List of communication media types used for contact purposes
Comments	The CommunicationMediaTypeList is found in xPIL-types.xsd.
Values	Cellphone, Fax, Pager, Telephone, VOIP
Used In	contactNumber
Examples

4 Conformance

The last numbered section in the specification must be the Conformance section. Conformance Statements/Clauses go here.

TBD

Appendix A Acknowledgements

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

Participants

Don McGarry, MITRE Corp., Member

Jeff Waters, DoD, Member

Werner Joerg, Individual, Member

Appendix B Non-Normative Text

Appendix C Revision History

Revision	Date	Editor	Changes Made
WD01	03/02/2011	Jeff Waters	Initial setup
WD02	04/21/2011	Werner Joerg	Completion, clean up, ready for TC review
	05/10/2011	Werner Joerg	Fixed link for [WGS 84] reference
WD03	07/28/2011	Werner Joerg	Fixed xPIL namespace
WD04	12/19/2011	Werner Joerg	Adapted to naming convention: replaced underscores “_” (in edxl_xAL, edxl_xNL and edxl_xPIL) with “-”
WD05	07/14/2014 07/23/2014	Werner Joerg	Update for compliance with EDXL Naming and Capitalization Guidelines (EM-TC 12/18/2012)
WD06	12/31/14	Werner Joerg	Updated formatting of references