1

2Name, Address and Party

3Information
4
5Customer Information Quality Technical Committee
6Name, Address and Party Information Technical Specification
7Version 3.0 (draft)
8Date Created: 15 August 2004
9Last Updated: 5 November 2020
10
11Editors
12Max Voskob, Individual Member, OASIS CIQ TC (max.voskob@paradise.net.nz)
13Ram Kumar, Individual Member and Chair, OASIS CIQ TC (kumar.sydney@gmail.com)
14
15Contributors
John Glaubitz Vertex Member, CIQ TC
Hido Hasimbegovic Individual Member, CIQT TC
Robert James Individual Member, CIQ TC
Joe Lubenow Individual Member, CIQ TC
Mark Meadows Microsoft Corporation Member, CIQ TC
John Putman Individual Prospective Member, CIQ TC
Michael Roytman Vertex Member, CIQ TC
New Zealand
Colin Wallis Member, CIQ TC
Government
David Webber Individual Member, CIQ TC
16
17Abstract
18This Technical Specification defines the name (xNL), address (xAL), name and address
19(xNAL) and Party Information (xPIL) specifications version 3.0.
20
21
22
23Intellectual Property Rights, Patents and Royalties
24This specification (includes this document, schemas and sample files) is free of any
25Intellectual Property Rights, Patents or Royalties. Public is free to download, use and apply
26the specification free of charge. Please, read OASIS Copyright Notice in APPENDIX A.

1
27xAL-Australia.XML
28 Address examples come from the Standard AS /NZ 4819:2003
29xAL-international.xml
30 Address examples come from a variety of sources including Universal Postal Union
31 website

2Name, Address and Party Information -2- 1999 – 2005 © OASIS

3
4
32

33 TABLE OF CONTENTS
34
351 SCHEMA DESIGN APPROACH IN VERSION 3.0...................................................................5
36 1.1 VERSION 3.0 SCHEMA FILES............................................................................................................5
37 1.2 FORMAL DESIGN REQUIREMENTS FOR VERSION 3.0.........................................................................5
38 1.3 MAJOR ENTITIES...............................................................................................................................6
39 1.4 COMMON APPROACHES....................................................................................................................6
40 1.5 NAMESPACES....................................................................................................................................6
41 1.6 OTHER SPECIFICATIONS....................................................................................................................6
422 ENTITY “NAME”...........................................................................................................................7
43 2.1 SEMANTICS OF “NAME”...................................................................................................................7
44 2.2 DATA TYPES.....................................................................................................................................9
45 2.3 ENUMERATIONS................................................................................................................................9
46 2.4 ORDER OF ELEMENTS AND PRESENTATION.......................................................................................9
47 2.5 DATA MAPPING..............................................................................................................................10
48 2.6 DATA QUALITY..............................................................................................................................11
49 2.6.1 Data Quality Verification and trust........................................................................................12
50 2.6.2 Data Validation......................................................................................................................12
51 2.7 EXTENSIBILITY...............................................................................................................................12
52 2.7.1 Practical Applications............................................................................................................12
53 2.8 LINKING AND REFERENCING..........................................................................................................13
54 2.9 SCHEMA CUSTOMIZATION GUIDELINES..........................................................................................13
55 2.9.1 Namespace..............................................................................................................................13
56 2.9.2 Reducing the structure............................................................................................................13
57 2.9.3 Customizing the enumerations................................................................................................14
58 2.9.4 Implications............................................................................................................................15
593 ENTITY “ADDRESS”...................................................................................................................16
60 3.1 SEMANTICS OF “ADDRESS”............................................................................................................16
61 3.2 GEO-COORDINATES........................................................................................................................17
62 3.3 DATA TYPES...................................................................................................................................18
63 3.4 ENUMERATIONS..............................................................................................................................18
64 3.5 ORDER OF ELEMENTS AND PRESENTATION.....................................................................................18
65 3.6 DATA MAPPING..............................................................................................................................18
66 3.7 DATA QUALITY...............................................................................................................................19
67 3.8 EXTENSIBILITY...............................................................................................................................19
68 3.9 LINKING AND REFERENCING...........................................................................................................19
69 3.10 SCHEMA CUSTOMIZATION............................................................................................................19
704 COMBINATION OF “NAME” AND “ADDRESS”..................................................................20
71 4.1 USE OF ELEMENT XNAL:RECORD...................................................................................................20
72 4.2 USE OF ELEMENT XNAL:POSTALLABEL..........................................................................................20
735 ENTITY “PARTY”.......................................................................................................................22
74 5.1 DATA TYPES...................................................................................................................................24
75 5.2 ENUMERATIONS..............................................................................................................................25
76 5.3 ORDER OF ELEMENTS AND PRESENTATION.....................................................................................25
77 5.4 DATA MAPPING..............................................................................................................................25
78 5.5 DATA QUALITY...............................................................................................................................25
79 5.6 EXTENSIBILITY...............................................................................................................................25
80 5.7 LINKING AND REFERENCING...........................................................................................................25
81 5.8 SCHEMA CUSTOMIZATION..............................................................................................................25

5Name, Address and Party Information -3- 1999 – 2005 © OASIS

6
7
826 MISCELLANEOUS......................................................................................................................26
83 6.1 DOCUMENTATION...........................................................................................................................26
84 6.2 EXAMPLES......................................................................................................................................26
85 6.3 CONTRIBUTIONS FROM PUBLIC......................................................................................................26
86Appendix A. Notices................................................................................................................................27
87

8Name, Address and Party Information -4- 1999 – 2005 © OASIS

9
10
 881 Schema Design Approach in Version 3.0
89Name, Address and Party schemas of version 3.0 share the same design concepts. The
90commonality should simplify understanding and adoption of the schemas. xNAL schema
91stands out as it is only a simple container for associating names and addresses.
92Name, and Address and Party schemas were designed to bring interoperability in the way the
93most common entities used across all spectrum of business and government.

941.1 Version 3.0 Schema Files

95Following are the different schemas produced for version 3.0:
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 Defines a set of enumerations that suit this
particular application
xAL.xsd Entity Address Defines a set of reusable types and elements
for an address, location name or description
xAL-types.xsd Entity Address Defines a set of enumerations that suit this
particular application
xNAL.xsd Name and Address Defines two constructs to bind names and
binding addresses for data exchange or postal
purposes
xPIL.xsd (formerly Entity Party Defines a set of reusable types and elements
xCIL.xsd) (organisation or for a detailed description of an organisation or
individual) individual
xPL-types.xsd Entity Party Defines a set of enumerations that suit this
(organisation or particular application
individual)
xLink.xsd xLink attributes Defines a subset of xLink attributes as XML
schema
xPRL.xsd (formerly Party relationships Defines a simple reusable type for party
xCRL.xsd) relationships (not currently utilised)
96

971.2 Formal design requirements for version 3.0

98Following are the formal design requirements taken into consideration for version 3.0
99schemas:
100  Data structures should be described using XML Schema language
101  Data structures should be separated into multiple namespaces for reuse of the main
102 fundamental entities
103  Data structures should be able to accommodate all information types used for data
104 exchanges at present
105  Data structures should be extensible to provide enough flexibility for point-to-point
106 solutions and application-specific scenarios
107  Data structures should allow organisation-specific information to be attached to entities

11
108  Implementation complexity should be proportional the complexity of the subset of data
109 structures used by the implementer

1101.3 Major entities

111The entire party information space is divided into a number of complex information types that
112are viewed as basic entities. This enables re-use of the basic entities as required. Following
113are the entities:
114  Name (see xNL.xsd, xNL-types.xsd)
115  Address (see xAL.xsd, xAL-types.xsd)
116  Personal details and specifics (see xPIL.xsd, xPIL-types.xsd)
117  Organisation details and specifics (see xPIL.xsd, xPIL-types.xsd)
118  Party Relationships (see xPRL.xsd and xLink.xsd)

1191.4 Common approaches

120The design concepts of name, address and party schemas are very similar in terms of the
121way semantic information is represented. All the common concepts are explained in section 2
122(Entity “Name”). It is recommended to study that section first and then proceed to other
123entities.

1241.5 Namespaces

Entity Namespace Recommended prefix 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 urn:oasis:names:tc:ciq:xnal:3 xnal xNAL.xsd
address
Party urn:oasis:names:tc:ciq:xpil:3 xpil or p xPIL.xsd
xPIL-types.xsd
Party urn:oasis:names:tc:ciq:xprl:3 xprl or r xPRL.xsd
relationships
xLink http://www.w3.org/1999/xlink xlink xLink.xsd

1251.6 Other specifications

126This document contains references to XML Linking Language (XLink) Version 1.0, W3C
127Recommendation 27 June 2001 available at http://www.w3.org/TR/xlink/

12Name, Address and Party Information -6- 1999 – 2005 © OASIS

13
14
1282 Entity “Name”
129Entity “Name” was taken out of any context and modelled as a standalone class to reflect
130some common understanding of concepts “Person Name” and “Organisation Name”.

1312.1 Semantics of “Name”

132Name schema is separated into a structural part (xNL.xsd) as shown in the XML schema
133diagram below and an “include” that contains enumeration (xNL-types.xsd). The structural
134part is expected to remain unchanged over the course of time when the “include” with
135enumerations may be easily changed to meet particular needs.
136

137
138
139The structure allows for different semantic levels based on the following paradigm:
140  A simple data structure with minimum semantics should fit into the schema with
141 minimal effort
142  A complex data structure should fit into the schema without loss of any semantic
143 information
144Example 1 – no semantics
145An imaginary database does not differentiate between person and organisation name with
146one field allocated for storing name information. This database can be mapped to xNL as
147follows:
148 <n:PartyName>

15Name, Address and Party Information -7- 1999 – 2005 © OASIS

16
17
149 <n:NameLine>Mr Jeremy Apatuta Johnson</n:NameLine>
150 </n:PartyName>

151In this example, information related to party name, resides in NameLine elements. It has no
152semantic information that may indicate what kind of name it is and what the individual name
153elements are (i.e., the data has not been parsed to identify the different components of the
154name). All is known is that it is a name of some party, be it a person or an organisation.
155
156Example 2 – minimal semantics
157The next complexity level is when a database differentiates between person and organisation
158name. In this case, names can be placed in their respective places inside the structure.
159Person name:
160 <n:PartyName>
161 <n:PersonName>
162 <n:NameLine>Mr Jeremy Apatuta Johnson</n:NameLine>
163 </n:PersonName>
164 </n:PartyName>

165This example shows that name information belongs to an individual, but the semantics of
166name elements (e.g. What is “Mr”, “Jeremy”, etc.) are unknown.
167
168Organisation name:
169 <n:PartyName>
170 <n:OrganisationName>
171 <n:NameElement>Khandallah Laundering Ltd.</n:NameElement>
172 </n:OrganisationName>
173 </n:PartyName>

174This example is similar to the previous one, except that the name belongs to an organisation.
175
176Example 3 – full semantics
177The next complexity level is when a database differentiates between person and organisation
178name and also differentiates between different name elements.
179 <n:PartyName>
180 <n:PersonName>
181 <n:NameElement Abbreviation="true" ElementType="Title">Mr</n:NameElement>
182 <n:NameElement ElementType="FirstName">Jeremy</n:NameElement>
183 <n:NameElement ElementType="MiddleName">Apatuta</n:NameElement>
184 <n:NameElement ElementType="LastName">Johnson</n:NameElement>
185 <n:NameElement ElementType="GenerationIdentifier">III</n:NameElement>
186 <n:NameElement ElementType="GenerationIdentifier">Junior</n:NameElement>
187 <n:NameElement ElementType="Title">PhD</n:NameElement>
188 </n:PersonName>
189 </n:PartyName>

190This example introduces ElementType attribute that indicates the exact meaning of the name
191element. This is an additional level of semantics that is supported through enumerated
192values. Technically, the enumerations sit in a separate schema “include” (xNL-types.xsd).
193An example of such enumeration is a list of name element types for a person name.
194 <xs:simpleType name="PersonNameElementsEnumeration">
195 <xs:restriction base="xs:string">
196 <xs:enumeration value="PrecedingTitle"/>
197 <xs:enumeration value="Title"/>
198 <xs:enumeration value="FirstName"/>
199 <xs:enumeration value="MiddleName"/>
200 <xs:enumeration value="LastName"/>
201 <xs:enumeration value="OtherName"/>

18Name, Address and Party Information -8- 1999 – 2005 © OASIS

19
20
202 <xs:enumeration value="Alias"/>
203 <xs:enumeration value="GenerationIdentifier"/>
204 </xs:restriction>
205 </xs:simpleType>

206This and other enumerations are built on the common sense and a culture-specific view of the
207subject area (in this case Anglo-American), rather than adopted from a specific application.

2082.2 Data Types

209All elements and attributes in xNL schema have strong data types.
210All free-text values of elements (text nodes) and attributes are constraint by simple type
211“string” defined in xNL-types.xsd. This type has a limit on the number of characters it may
212contain.
213Other XML Schema defined data types are also used throughout the schema.

2142.3 Enumerations
215The Name, Address and Party schemas come with enumerations designed to satisfy some
216common usage scenario, but there is always a possibility that a specific application requires
217some other enumerated values. It is acceptable for specific applications to provide their own
218enumerated values, but all participants need to be aware of what they are and that they are
219different from the ones provided by this specification.
220Example – point-to-point
221 Assume that participants of some data exchange agreed that for their purpose only a
222 very simple name structure is required. One of the options for them is to modify
223 PersonNameElementsEnumeration simple type in xNL-types.xsd file with the following
224 values:

225 <xs:simpleType name="PersonNameElementsEnumeration">

226 <xs:restriction base="xs:string">
227 <xs:enumeration value="Title"/>
228 <xs:enumeration value="FirstName"/>
229 <xs:enumeration value="MiddleName"/>
230 <xs:enumeration value="LastName"/>
231 </xs:restriction>
232 </xs:simpleType>

233Example – locale specific

234 In Russia, it would be more appropriate to use the following enumeration:

235 <xs:simpleType name="PersonNameElementsEnumeration">

236 <xs:restriction base="xs:string">
237 <xs:enumeration value="Title"/>
238 <xs:enumeration value="Name"/>
239 <xs:enumeration value="FathersName"/>
240 <xs:enumeration value="FamilyName"/>
241 </xs:restriction>
242 </xs:simpleType>

243 Again, it is up to the implementers to modify PersonNameElementsEnumeration simple

244 type in xNL-types.xsd file.

2452.4 Order of elements and presentation

246Order of name elements should be preserved for correct presentation.
247If an application needs to present the name to a user it may not always be aware about the
248correct order of the elements if the semantics of the name elements are not available.
249Example – normal order
250

21Name, Address and Party Information -9- 1999 – 2005 © OASIS

22
23
251 Mr Jeremy Apatuta Johnson PhD

252 could be presented as follows

253 <n:PartyName>
254 <n:PersonName>
255 <n:NameElement>Mr</n:NameElement>
256 <n:NameElement>Jeremy</n:NameElement>
257 <n:NameElement>Apatuta</n:NameElement>
258 <n:NameElement>Johnson</n:NameElement>
259 <n:NameElement>PhD</n:NameElement>
260 </n:PersonName>
261 </n:PartyName>

262 and restored back to Mr Jeremy Apatuta Johnson PhD during data formatting exercise.
263 Any other order of NameElement tags in the XML fragment could lead to an incorrect
264 presentation of the name.

2652.5 Data Mapping

266Mapping data between the xNL schema and a target database is not expected to be an issue
267as xNL provides enough flexibility for virtually any level of data decomposition. However, the
268main issue lies in the area of mapping a data provider with a data consumer through xNL.
269This may be a challenging task that requires additional name parsing software.
270For example, consider a data provider that has a person name all in one line and a data
271consumer that has a highly decomposed data structure for a person’s name that requires first
272name, family name and title to reside in their respective fields. There is no way of putting the
273provided data in the target data structure without parsing it. Such parsing is expected to be
274the responsibility of the data consumer.
275
276Example – complex-to-simple mapping
277The source database easily maps to the xNL NameElement qualified with ElementType
278attribute set to values as in the diagram
279

280
281
282Source database

NAME MIDDLENAME SURNAME

John Anthony Jackson
283
284xNL

285 <n:PersonName>
286 <n:NameElement n:ElementType="FirstName">John</n:NameElement>
287 <n:NameElement n:ElementType="MiddleName">Anthony</n:NameElement>
288 <n:NameElement n:ElementType="LastName">Jackson</n:NameElement>
289 </n:PersonName>

24Name, Address and Party Information - 10 - 1999 – 2005 © OASIS

25
26
290
291Target database

FULLNAME
John Anthony Jackson
292
293This type of mapping does not present a major challenge as it is a direct mapping from source
294to xNL and then a concatenation of values at the end.
295
296
297Example – simple-to-complex mapping
298The source database has the name in a simple unparsed form which can be easily mapped to
299xNL, but cannot be directly mapped to the target database as in the following diagram:
300

301
302
303
304Source database

FULLNAME
John Anthony Jackson
305
306xNL

307 <n:PersonName>
308 <n:NameElement>John Anthony Jackson</n:NameElement>
309 </n:PersonName>

310
311At this point, the name resolution software splits John Anthony Jackson into a form
312acceptable by the target database.
313
314Target database

315
NAME MIDDLENAME SURNAME
John Anthony Jackson
316

3172.6 Data Quality

318xNL schema allows for data quality information to be provided as part of the entity using
319attribute DataQuality that can be set to either “Valid” or “Invalid”, if such status is known. If
320DataQuality attribute is omitted it is presumed that the validity of the data is unknown.

27Name, Address and Party Information - 11 - 1999 – 2005 © OASIS

28
29
321DataQuality attribute refers to the content of a container, e.g. PersonName, asserting that all
322the values are known to be true and correct. This specification has no provision for partial
323data quality where some parts of the content are correct and some are not or unknown.
324Example – data quality
325 <n:PersonName n:DataQuality="Valid">
326 <n:NameElement>John Anthony Jackson</n:NameElement>
327 </n:PersonName>

328 In this example John Anthony Jackson is known to be the true and correct value
329 asserted by the sender of this data.
330
331This feature allows the recipient of data to get an understanding of the quality of data they are
332receiving and assists them to take appropriate measures to handle the data according to its
333quality.

3342.6.1 Data Quality Verification and trust

335This specification does not mandate any data verification rules or requirements. It is entirely
336up to the data exchange participants to establish them.
337Also, the participants need to establish if the data quality information can be trusted.

3382.6.2 Data Validation

339This specification does not mandate any data validation rules or requirements. It is entirely up
340to the data exchange participants to establish such rules and requirements.

3412.7 Extensibility
342All elements in Name, Address and Party namespaces are extensible allowing for any
343number of attributes from a non-target namespace to be added.
344All elements share the same declaration:
345 <xs:anyAttribute namespace="##other" processContents="lax"/>

346Although this specification provides an extensibility mechanism, it is up to the participants of

347the data exchange process to agree on the use of any extensions to the target namespace.
348This specification mandates that an application should not fail if it encounters an attribute from
349a non-target namespace. The application may choose to ignore or remove the attribute.

3502.7.1 Practical Applications

351System-specific identifiers
352 Participants in some data exchange may wish to add their system specific identifiers
353 for easy matching of known data, e.g. if system A sends a message containing a name
354 of a person to system B as in the example
355 <n:PartyName xmlns:b="urn:acme.org:corporate:IDs" b:PartyID="123445">
356 <n:PersonName>
357 <n:NameElement>John Johnson</n:NameElement>
358 </n:PersonName>
359 </n:PartyName>

360 Attribute b:PartyID="123445" is not in xNL namespace and acts as an identifier for
361 system A. When system B returns a response or sends another message and needs to
362 include information about the same party, it may use the same identifier as in the
363 following example:
364

30Name, Address and Party Information - 12 - 1999 – 2005 © OASIS

31
32
365 <n:PartyName xmlns:b="urn:acme.org:corporate:IDs" b:PartyID="123445" />

366 The response could include the original payload with the name details.
367Additional metadata
368 Sometime it is required to include some additional metadata that is specific to a
369 particular system or application. Consider these examples:

370 <n:PartyName xmlns:x="urn:acme.org:corporate" x:OperatorID="buba7">

371 .............

372
373 <n:PartyName xmlns:b="urn:acme.org:corporate ">
374 <n:PersonName>
375 <n:NameElement b:Corrected="true">John Johnson</n:NameElement>
376 </n:PersonName>
377 </n:PartyName>

378

3792.8 Linking and Referencing

380Names can be referenced internally (i.e. within some XML infoset that contains both
381referencing and referenced elements) through xlink:href pointing at an element with xml:id
382with a matching value.
383External entities can also be referenced if they are accessible by the recipient via
384HTTP(s)/GET.
385The following example illustrates PartyName elements that reference other PartyName
386elements that reside elsewhere, in this case outside of the document.
387
388 <a:Contacts
389 xmlns:a="urn:acme.org:corporate:contacts"
390 xmlns:n="urn:oasis:names:tc:ciq:xsdschema:xNL:3.0/20050427"
391 xmlns:xlink="http://www.w3.org/1999/xlink">
392 <n:PartyName xlink:href="http://example.org/party?id=123445" xlink:type="locator"/>
393 <n:PartyName xlink:href="http://example.org/party?id=83453485" xlink:type="locator"/>
394 </a:Contacts>

395This example presumes that the recipient of this XML fragment has access to resource
396http://example.org/party and that the resource returns PartyName element as an XML
397fragment of text/xml MIME type.
398Usage of xLink attributes may slightly differ from the original xLink specification. See CIQ TC
399Party Relationships Specification for more information on using xLink with xNL. The
400specification is available at http://www.w3.org/TR/xlink/.
401Element PartyName can be either of type locator or resource in relation to xLink.

4022.9 Schema customization guidelines

403The broad nature and cultural diversity of entity “Name” makes it very difficult to produce one
404schema that would satisfy all applications and all cultures while keeping the size and
405complexity under control. This specification allows some changes to the schema by adopters
406of the schema to fit their specific requirements and constraints.

4072.9.1 Namespace
408The namespace identifier should be changed if it is possible for an XML fragment valid under
409the altered schema to be invalid under the original schema.

33Name, Address and Party Information - 13 - 1999 – 2005 © OASIS

34
35
4102.9.2 Reducing the structure
411It is recommended to retain the minimum structure as in the following diagram:
412

413
414This structure, although somewhat limited, still allows for most names to be represented, with
415exception for
416  additional names (KnownAs), e.g. maiden name as part of PartyName
417  organisation subdivision hierarchy (SubdivisionName), e.g. faculty / school /
418 department
419Any further reduction in structure may lead to loss of flexibility and expressive power of the
420schema.
421It is not recommended to remove any attributes from the schema as they can be easily
422ignored during the processing.

4232.9.3 Customizing the enumerations

424Enumerations clarifying the meaning for generic elements (e.g. NameElement) were
425intentionally taken out of the main schema file into an include (xNL-types.xsd) to make
426customisation easier.
427The values of the enumerations can be changed or new ones added as required.
428Proprietary enumeration example
429
Original xNL values for AliasTypeEnumeration Possible proprietary values
MaidenName MaidenName
NameChange CommonUse
CommonUse CivilName
NickName
PublishingName
430
431The code for the new proprietary enumeration would look like this:
432 <xs:simpleType name="AliasTypeEnumeration">

36Name, Address and Party Information - 14 - 1999 – 2005 © OASIS

37
38
 433 <xs:restriction base="xs:string">
434 <xs:enumeration value="MaidenName"/>
435 <xs:enumeration value="CommonUse"/>
436 <xs:enumeration value="CivilName"/>
437 <xs:enumeration value="NickName"/>
438 <xs:enumeration value="PublishingName"/>
439 </xs:restriction>
440 </xs:simpleType>

441This level of flexibility allows some customization of the schema through changing the
442enumerations only without changing its basic structure. It is important to ensure that all
443schema users use the same enumerations.

4442.9.4 Implications
445Any changes to the schemas are likely to break the compatibility one way or another.
446It may be possible that an XML fragment created for the original schema is invalid for the
447altered schema or vice versa. This issue needs to be considered before making any changes
448to the schema and breaking the compatibility.

39Name, Address and Party Information - 15 - 1999 – 2005 © OASIS

40
41
4493 Entity “Address”
450Entity “Address” was taken out of any context and modelled as a standalone class to reflect
451some common understanding of concepts “Location” and “Delivery Point”.
452The design concepts for “Address” are similar to “Name”. Refer to section 1.4 Common
453approaches for more information.

4543.1 Semantics of “Address”

455The high level schema elements of xAL schema are illustrated in the following diagram:

456
457An address can be structured according to the complexity level of its source.
458Example – free text
459 Suppose that the source database does not differentiate between different address
460 elements and treats them as Address Line 1, Address Line 2, Address Line “N”, then
461 the address information can be placed inside the free text container.

462 <a:Address>
463 <a:FreeTextAddress>
464 <a:AddressLine>Substation C</a:AddressLine>
465 <a:AddressLine >17 James Street</a:AddressLine >
466 <a:AddressLine>SPRINGVALE VIC 3171</a:AddressLine>
467 </a:FreeTextAddress>
468 </a:Address>

469 It is up to the receiving application to parse this address and map to the target data
470 structure. It is possibly that some sort of parsing software or human involvement will
471 be required to accomplish the task.

42Name, Address and Party Information - 16 - 1999 – 2005 © OASIS

43
44
472
473Example – semi structured address
474 Assume that the address was captured in some semi-structured form such as State,
475 Suburb and Street.

476 <a:Address>
477 <a:AdministrativeArea>
478 <a:Name>WA</a:Name>
479 </a:AdministrativeArea>
480 <a:Locality>
481 <a:Name>OCEAN REEF</a:Name>
482 </a:Locality>
483 <a:Thoroughfare>
484 <a:NameElement>16 Patterson Street</a:NameElement>
485 </a:Thoroughfare>
486 </a:Address>

487 In this example, the free text information resides in containers that provide some
488 semantic information on the content. E.g. State -> AdministrativeArea, Suburb ->
489 Locality, Street -> Thoroughfare. At the same time, the Thoroughfare element
490 contains street name and number in one line as free text, which may not be detailed
491 enough for data structures where street name and number are separate fields.
492
493Example – fully structured address
494 The following example illustrates an address structure that was decomposed into its
495 atomic elements:

496 <a:Address>
497 <a:AdministrativeArea>
498 <a:Name a:Abbreviation="true" a:NameType="state">VIC</a:Name>
499 </a:AdministrativeArea>
500 <a:Locality>
501 <a:Name>CLAYTON</a:Name>
502 <a:SubLocality>
503 <a:Name>Technology Park</a:Name>
504 </a:SubLocality>
505 </a:Locality>
506 <a:Thoroughfare>
507 <a:NameElement>Dandenong Road</a:NameElement>
508 <a:Number a:EnumeratedType="RangeFrom">200</a:Number>
509 <a:Number a:EnumeratedType="Separator">-</a:Number>
510 <a:Number a:EnumeratedType="RangeTo">350</a:Number>
511 <a:SubThoroughfare>
512 <a:NameElement>Fifth Avenue</a:NameElement>
513 </a:SubThoroughfare>
514 </a:Thoroughfare>
515 <a:Premise>
516 <a:NameElement>Toshiba Building</a:NameElement>
517 </a:Premise>
518 <a:PostalCode>
519 <a:Number>3168</a:Number>
520 </a:PostalCode>
521 </a:Address>

5223.2 Geo-coordinates
523Geo-coordinates can be provided by using Geography Markup Language (GML), an industry
524standard (http://www.opengis.net).
525The reason for using some complex constructs from GML is due to the ambiguity of different
526coordinate systems, units and measurements. Also, GML incorporates a huge body of
527knowledge and expertise in geographical systems interoperability that can be reused for our
528purpose rather than re-inventing what has already been developed.
529The content of a:GML must comply with the following requirements:

45Name, Address and Party Information - 17 - 1999 – 2005 © OASIS

46
47
530  Be from the GML namespace
531  Refer to finest level of address details available in the address structure a:GML belongs
532 to
533  Be used unambiguously so that there is no confusion whether the coordinates belong
534 to the postal delivery point (e.g. Post Box) or a physical address (e.g. flat) as it is
535 possible to have both in the same address structure.
536There is no restriction on the shape of the area a:GML can describe be it a point, polygon or
537some other object.

5383.3 Data types

539All elements and attributes in xAL schema have strong data types.
540All free-text values of elements (text nodes) and attributes are constraint by simple type
541“string” defined in xAL-types.xsd. This type has a limit on the number of characters it may
542contain.
543Other XML Schema defined data types are also used throughout xAL namespace.

5443.4 Enumerations
545Use of enumerations is identical to use of enumerations for entity “Name”. Refer to section
5462.3 Enumerations for more information.
547Enumerations used in xAL reside in an “include” file xAL-types.xsd.

5483.5 Order of elements and presentation

549Order of address elements should be preserved for correct presentation in a fashion similar to
550what is described in section 2.4 Order of elements and presentation.
551Child elements of a:Address can appear in any order as members of xs:all grouping as in the
552example below:
553Example – order of second level elements in xAL
554
555 23 Archer Street : Thoroughfare
556 Chatswood, NSW 2067 : Suburb, State, Post Code
557 Australia : Country

558 could be preserved and presented in XML as:

559 <a:Address>
560 </a:Thoroughfare>
561 </a:Locality>
562 </a:AdministrativeArea>
563 </a:PostalCode>
564 </a:Country>
565 </a:Address>

566Some other elements can also appear in any order to preserve the original order.

5673.6 Data Mapping

568Mapping data between xAL schema and a database is similar to that of entity “Name” as
569described in section 2.5 Data Mapping.
570
571
572

48Name, Address and Party Information - 18 - 1999 – 2005 © OASIS

49
50
573
574
575Example – normal order
576
577 23 Archer Street
578 Chatswood, NSW 2067
579 Australia

580 could be presented as follows

581 <a:Address>
582 <a:FreeTextAddress>
583 <a:AddressLine>23 Archer Street</a:AddressLine>
584 <a:AddressLine>Chatswood, NSW 2067</a:AddressLine>
585 <a:AddressLine>Australia</a:AddressLine>
586 </a:FreeTextAddress>
587 </a:Address>

588 and restored back to

589 23 Archer Street
590 Chatswood, NSW 2067
591 Australia

592 during data formatting exercise.

593 Any other order of AddressLine tags in the XML fragment could lead to an incorrect
594 presentation of the address.

5953.7 Data quality

596xAL schema allows for data quality information to be provided as part of the entity using
597attribute DataQuality as for entity “Name”. Refer to section 2.6 Data Quality for more
598information.

5993.8 Extensibility
600All element in Address namespace are extensible as described in section 2.7 Extensibility.

6013.9 Linking and referencing

602All linking and referencing rules described in section 2.8 Linking and Referencing apply to
603entity “Address”.

6043.10 Schema customization

605Schema customisation rules and concepts described in section 2.9 Schema customization
606are fully applicable to entity “Address”.

51Name, Address and Party Information - 19 - 1999 – 2005 © OASIS

52
53
6074 Combination of “Name” and “Address”
608xNAL (Name and Address) schema is a container for combining related name and addresses.
609This specification recognises two ways of achieving so:
610  Binding multiple names to multiple addresses (element xnal:Record)
611  Binding multiple names to a single address for postal purposes (element
612 xnal:PostalLabel)

6134.1 Use of element xnal:Record

614Element xnal:Record is a binding container that shows that some names relate to some
615addresses as in the following diagram:

616
617The relationship type is application specific, but in general it is assumed that the people
618named in the xNL part somehow reside at the addresses specified in the xAL part. Use
619attributes from other namespace to specify the type of relationships and roles of names and
620addresses.
621Example
622 Mr H G Guy, 9 Uxbridge Street, Redwood, Christchurch 8005

623 <xnal:Record>
624 <n:PartyName>
625 <n:NameLine>Mr H G Guy</n:NameLine>
626 </n:PartyName>
627 <a:Address>
628 <a:Locality>
629 <a:Name>Christchurch</a:Name>
630 <a:SubLocality>
631 <a:Name>Redwood</a:Name>
632 </a:SubLocality>
633 </a:Locality>
634 <a:Thoroughfare>
635 <a:Number>9</a:Number>
636 <a:NameElement>Uxbridge Street</a:NameElement>
637 </a:Thoroughfare>
638 <a:PostCode>
639 <a:Identifier>8005</a:Identifier>
640 </a:PostCode>
641 </a:Address>
642 </xnal:Record>

6434.2 Use of element xnal:PostalLabel

644Element xnal:PostalLebel is a binding container that provides elements and attributes for
645information often used for postal / delivery purposes, as in the following diagram:

54Name, Address and Party Information - 20 - 1999 – 2005 © OASIS

55
56
646
647This structure allows for any number of recipient to be linked to a single address with some
648delivery specific elements such as Designation and DependencyName.
649
650Example
651
652 Attention: Mr S Mart
653 Name Plate Engravers
654 The Emporium
655 855 Atawhai Drive
656 Atawhai
657 Nelson 7001

658 Translates into the following xNAL fragment:

659 <xnal:PostalLabel>
660 <xnal:Addressee>
661 <xnal:Designation>Attention: Mr S Mart</xnal:Designation>
662 <n:PartyName>
663 <n:NameLine>Name Plate Engravers</n:NameLine>
664 </n:PartyName>
665 </xnal:Addressee>
666 <a:Address>
667 <a:Locality>
668 <a:Name>Nelson</a:Name>
669 <a:SubLocality>
670 <a:Name>Atawhai</a:Name>
671 </a:SubLocality>
672 </a:Locality>
673 <a:Thoroughfare>
674 <a:NameElement>Atawhai Drive</a:NameElement>
675 <a:Number>855</a:Number>
676 </a:Thoroughfare>
677 <a:PostCode>
678 <a:Identifier>4001</a:Identifier>
679 </a:PostCode>
680 </a:Address>
681 </xnal:PostalLabel>

682
683

57Name, Address and Party Information - 21 - 1999 – 2005 © OASIS

58
59
6845 Entity “Party”
685Entity “Party” encapsulates some most commonly used characteristics of Person or
686Organisation, such as name, address, personal details, contact details, body features, etc.
687The diagram below shows the high level structure of Party. The full schema can be found in
688xPIL,xsd file with enumerations in xPIL-types.xsd file. See the sample XML files for examples.

689
690
691The schema is separated in 3 parts: shared elements (all children of Party before
692OrganisationInfo and PersonInfo elements), OrganisationInfo and PersonInfo.
693The shared elements apply to organisation as well as person.
694Name of the party reuses PartyNameType construct from xNL namespace as illustrated in the
695following diagram:

60Name, Address and Party Information - 22 - 1999 – 2005 © OASIS

61
62
696
697
698Address of the party reuses AddressType construct from xAL namespace as illustrated in the
699following diagram:

700
701
702The design paradigm for this schema is similar to those of Name and Address entities.
703Likewise, it is possible to combine information at different detail and semantic levels.
704The following example illustrates use of some of party constructs
705

63Name, Address and Party Information - 23 - 1999 – 2005 © OASIS

64
65
706
707
708Example – qualification details
709 <p:Qualifications>
710 <p:Qualification>
711 <p:QualificationElement
712 p:ElementType="QualificationName">BComp.Sc.</p:QualificationElement>
713 <p:QualificationElement
714 p:ElementType="MajorSubject">Mathematics</p:QualificationElement>
715 <p:QualificationElement
716 p:ElementType="MinorSubject">Statistics</p:QualificationElement>
717 <p:QualificationElement p:ElementType="Award">Honours</p:QualificationElement>
718 <p:InstitutionName>
719 <n:NameLine>University of Technology Sydney</n:NameLine>
720 </p:InstitutionName>
721 </p:Qualification>
722 </p:Qualifications>

723
724Example – birth details
725 <p:BirthInfo p:BirthDateTime="1977-01-22T00:00:00"/>

726
727Example – driver license
728 <p:Document p:ValidTo="2004-04-22T00:00:00">
729 <p:IssuePlace>
730 <a:Country>
731 <a:Name>Australia</a:Name>
732 </a:Country>
733 <a:AdministrativeArea>
734 <a:Name>NSW</a:Name>
735 </a:AdministrativeArea>
736 </p:IssuePlace>
737 <p:DocumentElement p:ElementType="DocumentID">74183768C</p:DocumentElement>
738 <p:DocumentElement p:ElementType="DocumentType">Driver License</p:DocumentElement>
739 <p:DocumentElement p:ElementType="Priveledge">Silver</p:DocumentElement>
740 <p:DocumentElement p:ElementType="Restriction">Car</p:DocumentElement>
741 </p:Document>

742
743Example – contact phone number
744 <p:ContactNumber p:MediaType="Telephone" p:ContactNature="Business Line"
745 p:ContactHours="9:00AM - 5:00PM">
746 <p:ContactNumberElement p:ElementType="CountryCode">61</p:ContactNumberElement>
747 <p:ContactNumberElement p:ElementType="AreaCode">2</p:ContactNumberElement>
748 <p:ContactNumberElement p:ElementType="LocalNumber">94338765</p:ContactNumberElement>
749 </p:ContactNumber>

750

7515.1 Data types

752All elements and attributes in xPIL schema have strong data types.
753All free-text values of elements (text nodes) and attributes are constraint by simple type
754“string” defined in xPIL-types.xsd. This type has a limit on the number of characters it may
755contain.
756Other XML Schema defined data types are also used throughout the schema.
757
758

66Name, Address and Party Information - 24 - 1999 – 2005 © OASIS

67
68
7595.2 Enumerations
760Use of enumerations is identical to use of enumerations for entity “Name”. Refer to section
7612.3 Enumerations for more information.
762Enumerations used in xPIL reside in an “include” xPIL-types.xsd.

7635.3 Order of elements and presentation

764Order of unqualified address elements should be preserved for correct presentation in a
765fashion similar to what is described in section 2.4 Order of elements and presentation.

7665.4 Data Mapping

767Mapping data between xPIL schema and a database is similar to that of entity “Name” as
768described in section 2.5 Data Mapping.

7695.5 Data quality

770xPIL schema allows for data quality information to be provided as part of the entity using
771attribute DataQuality as for entity “Name”. Refer to section 2.6 Data Quality for more
772information.

7735.6 Extensibility
774All element in Party namespaces are extensible as described in section 2.7 Extensibility.

7755.7 Linking and referencing

776All linking and referencing rules described in section 2.8 Linking and Referencing apply to
777entity “Party”.
778The following example illustrates PartyName elements that reference other PartyName
779element that resides elsewhere, in this case outside of the document.
780 <a:Contacts xmlns:a="urn:acme.org:corporate:contacts">
781 <xnl:PartyName xlink:href="http://example.org/party?id=123445"/>
782 <xnl:PartyName xlink:href="http://example.org/party?id=83453485"/>
783 </a:Contacts>

784This example presumes that the recipient of this XML fragment has access to resource
785“http://example.org/party” (possibly over HTTP/GET) and that the resource returns as
786PartyName element as an XML fragment of text/xml MIME type.

7875.8 Schema customization

788Schema customisation rules and concepts described in section 2.9 Schema customization
789are fully applicable to entity “Party”.

69Name, Address and Party Information - 25 - 1999 – 2005 © OASIS

70
71
7906 Miscellaneous
7916.1 Documentation
792Although, all schema files are fully documented using XML Schema annotations it is not
793always convenient to browse the schema itself. This specification is accompanied by a set of
794HTML files auto generated by XML Spy. Note that not all information captured in the schema
795annotation tags is in the HTML documentation.

7966.2 Examples
797Several examples of instance XML documents for name, address and party schemas are
798provided as XML files. The examples are informative and demonstrate the application of this
799Technical Specification.
800The example files and their content are being constantly improved and updated on no
801particular schedule.

8026.3 Contributions from Public

803OASIS CIQ TC is open in the way it conducts its business. We welcome contributions from
804public in any form. Please, use “Send A Comment” feature on CIQ TC home page
805(http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ciq) to tell us about:
806  errors, omissions, misspellings in this specification, schemas or examples
807  your opinion in the form of criticisms, suggestions, comments, etc
808  willingness to contribute to the work of CIQ TC by becoming a member of the TC
809  willingness to contribute indirectly to the work of CIQ TC
810  provision of sample data that can be used to test the specifications
811  implementation experience
812  etc.
813

72Name, Address and Party Information - 26 - 1999 – 2005 © OASIS

73
74
814Appendix A. Notices
815OASIS takes no position regarding the validity or scope of any intellectual property or other
816rights that might be claimed to pertain to the implementation or use of the technology
817described in this document or the extent to which any license under such rights might or might
818not be available; neither does it represent that it has made any effort to identify any such
819rights. Information on OASIS's procedures with respect to rights in OASIS specifications can
820be found at the OASIS website. Copies of claims of rights made available for publication and
821any assurances of licenses to be made available, or the result of an attempt made to obtain a
822general license or permission for the use of such proprietary rights by implementors or users
823of this specification, can be obtained from the OASIS Executive Director.
824OASIS invites any interested party to bring to its attention any copyrights, patents or patent
825applications, or other proprietary rights which may cover technology that may be required to
826implement this specification. Please address the information to the OASIS Executive Director.
827Copyright © OASIS Open 2002. All Rights Reserved.
828This document and translations of it may be copied and furnished to others, and derivative
829works that comment on or otherwise explain it or assist in its implementation may be
830prepared, copied, published and distributed, in whole or in part, without restriction of any kind,
831provided that the above copyright notice and this paragraph are included on all such copies
832and derivative works. However, this document itself does not be modified in any way, such as
833by removing the copyright notice or references to OASIS, except as needed for the purpose of
834developing OASIS specifications, in which case the procedures for copyrights defined in the
835OASIS Intellectual Property Rights document must be followed, or as required to translate it
836into languages other than English.
837The limited permissions granted above are perpetual and will not be revoked by OASIS or its
838successors or assigns.
839This document and the information contained herein is provided on an “AS IS” basis and
840OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
841LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
842NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
843OR FITNESS FOR A PARTICULAR PURPOSE
844
845

75Name, Address and Party Information - 27 - 1999 – 2005 © OASIS

76
77