National Standards Framework
Australian Standard 4590
Client Information Exchange
AS4590 XML Model V2.0
Implementation Guidelines
Version: 1.0
Status: Final
September 2011
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
Table of Contents
1. 1 PROJECT BACKGROUND ...................................................................................................................... 4
1.1
1.2
1.3
1.4
1.5
2
PRE-REQUISITES .................................................................................................................................... 4
IN SCOPE ................................................................................................................................................ 4
OUT OF SCOPE ....................................................................................................................................... 5
APPROACH ............................................................................................................................................. 5
PARTICIPANTS ........................................................................................................................................ 6
WHO SHOULD USE THIS GUIDE? ........................................................................................................ 6
3
DATA EXCHANGE BETWEEN PARTIES USING AS4590 STANDARD V2.0 – NO
GOVERNANCE, NO INTEROPERABILITY OF DATA ............................................................................... 6
3.1
DATA EXCHANGE AND INTEROPERABILITY ........................................................................................... 6
3.2
INFORMATION EXCHANGE AGREEMENT – GUIDELINES ......................................................................... 7
3.2.1 Conformance Rules ........................................................................................................................... 7
3.2.2 Key factors to include in the Exchange Agreement .......................................................................... 8
3.2.3 Tools and applications to implement this Standard .......................................................................... 8
3.2.4 Implementation Considerations ........................................................................................................ 9
3.2.5 Basic steps to implementing the Standard ........................................................................................ 9
3.2.5.1
3.2.5.2
3.2.5.3
3.2.5.4
Principles ................................................................................................................................................. 9
Approach.................................................................................................................................................. 9
Parsing and Validation ........................................................................................................................... 10
Sample XML file for testing .................................................................................................................. 10
4
GUIDELINES TO EXTEND AS4590 STANDARD V2.0 TO ADDRESS SPECIFIC
REQUIREMENTS ............................................................................................................................................. 10
4.1
4.2
DEFINE BUSINESS RULES AT THE RECEIVING APPLICATION END ........................................................... 10
USE DOUBLE PASS VALIDATION TO CONTROL THE XML SCHEMA STANDARD FOR SPECIFIC
REQUIREMENTS ................................................................................................................................................. 11
4.3
EXTEND THE XML SCHEMA USING THE LANGUAGE CAPABILITIES ...................................................... 11
4.3.1 XML Schema Extension by Generic Element .................................................................................. 11
4.3.2 XML Schema Extension by Generic Element supported by Controllable Code List....................... 13
4.3.3 XML Schema Extension using Modular Schema Assembly ............................................................ 15
4.3.4 XML Schema Extension using Derive by Extension Mechanism for Elements ............................... 15
4.3.5 XML Schema Extension – Using Redefine Mechanism ................................................................... 17
4.3.6 XML Schema Extension – Using Wildcards for Elements .............................................................. 19
4.3.7 XML Schema Extension – Derive by Extension Mechanism for Attributes..................................... 21
4.3.8 XML Schema Extension – Controlling Code Lists outside of the XML Schema ............................. 25
4.4
EXTENDING THE XML SCHEMA – CONCLUSION .................................................................................. 25
5
GENERAL GUIDELINES FOR ANY PROJECT THAT IMPLEMENTS AS4590 STANDARD V2.0
26
5.1
BUSINESS PROCESS CONSIDERATIONS ................................................................................................. 26
5.1.1 Business Process Diagrams ............................................................................................................ 26
5.1.2 XML Transactions .......................................................................................................................... 26
5.1.3 Data Quality ................................................................................................................................... 26
Version:1.0
Status: Final
31/07/2017
Page 2 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
5.1.4 Data Currency and Re-validation ................................................................................................... 27
5.2
DATA CONSIDERATIONS ...................................................................................................................... 27
5.2.1 Schema Guidelines.......................................................................................................................... 27
5.2.2 Database Schemas .......................................................................................................................... 27
5.2.3 Physical Forms of the AS4590 V2.0 XML Model Logical Schema ................................................. 27
5.2.4 Current Data Stores ........................................................................................................................ 27
5.2.4.1
5.2.4.2
Data Cleansing ....................................................................................................................................... 27
Run-time Conversion ............................................................................................................................. 28
5.3
ENTERPRISE ARCHITECTURE CONSIDERATIONS ................................................................................... 28
5.3.1 Interfaces between Applications ..................................................................................................... 28
5.3.2 Commercial Off-the-Shelf (COTS) Applications ............................................................................. 28
5.4
APPLICATION ARCHITECTURE CONSIDERATIONS ................................................................................. 28
5.4.1 Practical User Interface Design for Display and Capture of Client Data...................................... 28
5.4.2 Reference User Interface Implementation ...................................................................................... 29
5.4.3 Compliant Physical Format ............................................................................................................ 29
5.4.4 Mapping Across Diverse Data Models ........................................................................................... 29
5.4.5 Payload for Web Services ............................................................................................................... 29
6
IMPLEMENTATION CHECKLIST....................................................................................................... 30
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
ADMINISTRATIVE ................................................................................................................................. 30
DEFINE PROJECT REQUIREMENTS ........................................................................................................ 30
DEFINE TECHNICAL REQUIREMENTS.................................................................................................... 30
DEFINE BUSINESS PROCESS REQUIREMENTS ....................................................................................... 31
XML TRANSACTION CHECKLIST ......................................................................................................... 31
DATA COMMUNICATION CHECKLIST .................................................................................................... 31
APPLICATION CHECKLIST .................................................................................................................... 31
OPERATIONS CHECKLIST ..................................................................................................................... 31
Version:1.0
Status: Final
31/07/2017
Page 3 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
1 Project Background
The Cross Jurisdictional Chief Information Officer Committee (CJCIOC) and the Commonwealth’s
Chief Information Officer Committee (CIOC) endorsed the technical review of the AS 4590 Standard
V1.0 under the auspices of the National Standards Framework (NSF).
Government agencies record and interchange information about Name and Address. A national
agreement on the syntax that is directly aligned to the agreed Australian Standard will improve the
exchange of information about Name and Address. The benefits of a national agreement on the
syntax may include a reduction in deployment time, a reduction in the number of address errors and
reduced costs. The existing version of the technical standard that was used for review can be found at:
https://www.GovDex.gov.au/confluence/display/STANDARDS/Name+and+Address
An environment for this review process was created under Govshare for the review committee
members to contribute. This project was executed between April 2010 and July 2010 resulting in a
revised AS 4590 Technical Standard (XML) V2.0 (AS4590 Standard V2.0.) that was formally voted
on and adopted by the review committee members. Details of the voted model can be found at:
https://www.GovDex.gov.au/confluence/display/RAS4590/Home
On 12 August 2010 the CIOC agreed to, and provisionally endorsed the revised technical standard
AS4590 Standard V2.0 as a standard under the NSF. At this meeting the CIOC also agreed to reconvene a Technical Review Group to assist with the development of an implementation road map.
This phase of the project included the development of:

an Implementation Guide for the AS4590 Standard V2.0;

a Governance Framework for managing the AS4590 Standard V2.0; and

a namespace regime
This document’s focus is the Implementation Guide
1.1
Pre-Requisites
It is expected that the readers of this document have a good understanding of the following:

AS4590-2006 Standard from Standards Australia;

AS4590 Standard V2.0 from https://www.GovDex.gov.au/confluence/display/RAS4590/Home;

W3C XML Schema V1.0; and

Unified Modelling Language
The document is technical in nature, providing specific details on the data structures and formats of
XML. It is assumed that users of this document have, or can access a certain level of technical
knowledge.
1.2
In Scope
The scope of this document is restricted to provide a set of implementation guidelines to assist
stakeholders who are planning to implement the AS4590 Standard V2.0. It does not mandate how the
Version:1.0
Status: Final
31/07/2017
Page 4 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
model should be implemented and instead provides a set of guidelines, to assist agencies and
jurisdictions to interoperate client information data between themselves.
1.3
Out of Scope
The following are outside the scope of this standard:

Specification of business rules for interpretation, manipulation or use of the AS4590 Standard
V2.0 elements.

Internet security and transport standards, message structure and protocols, policies and protocols
associated with the storage and transport of the client interchange data.

Verification of the elements.

Information sharing, data matching and electronic data exchange policies and processes.

Data modelling, database design, and data mapping tools such as eXtensible Stylesheet Language
(XSL).

Data models other than AS4590 Standard V2.0.

Mandatory and optional elements and attributes.

AS4590 Standard V2.0 is not a data storage standard for client data. It does not define agency
database fields, nor enforce database designs, although it may influence them. Each agency
decides whether it stores its data in the data formats specified in AS4590 Standard V2.0 or
whether it transforms its data when importing to and exporting from its databases. Where
agencies store data elements as simple strings rather than as atomic or granular components,
transformation will require splitting and mapping these simple strings into their correct atomic
parts.
1.4
Approach
The development of the guidelines follows the standards development process outlined in the NSF.
Use of an online collaborative workspace will reduce the need for a large number of face to face
meetings. Following are the steps adopted to support this process:

Establishment of an online collaborative workspace for the project, including an on line
discussion forum.

A call for participants from jurisdictions and Commonwealth agencies to participate.

Invitation to participants to provide input into the implementation guidelines.

Creation of an implementation guidelines template and publish on the site.

Holding face to face meetings with participants to discuss the guidelines and gather input.

Production of a draft implementation guidelines document.
Version:1.0
Status: Final
31/07/2017
Page 5 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines

Publication of the draft implementation guidelines document for review by the participants.

Preparation and circulation of a final draft document incorporating input from the participants

Management of the voting processes (Commonwealth and Inter-jurisdictional).

Publication of the Implementation Guidelines
1.5
Participants
There were a large number of participants; however national voting rights were limited to one vote
per jurisdiction and one vote per agency in the Commonwealth.
2 Who Should Use This Guide?
This Implementation Guide is to be used by agencies and jurisdictions who intend to use AS4590
Standard V2.0 as part of their project to exchange client data within a department or agency or with
external agencies or jurisdictions. The guidelines could be used in any of the following scenarios:

Any project within an agency that requires the implementation/reuse of AS4590 Standard V2.0
including to exchange client data with other agencies.

Any national project that requires the implementation/reuse of AS4590 Standard V2.0.

Any national project that is building a standard for the Australian Government and requires reuse
of AS4590 Standard V2.0 to represent client data.
3 Data Exchange Between Parties Using AS4590 Standard
V2.0 – No Governance, No Interoperability of Data
3.1
Data Exchange and Interoperability
OASIS Customer Information Quality (CIQ) Technical Committee (TC) defines data interoperability
as follows:
“Get the right data to the right place at the right time in the right format with the right quality
with the right security in the right context and with the right governance to applications,
processes, or users”
Version:1.0
Status: Final
31/07/2017
Page 6 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
It is the view of the CIQ TC that to enable interoperability of data between parties, the best practice is
to parse the data elements into its atomic elements thereby preserving the semantics and quality of
data. In this way the parties involved in data exchange will be in the best position to understand the
semantics and quality of data thereby minimising interoperability issues. However, the method in
which data will be exchanged between parties, whether in parsed or unparsed structure, must be
negotiated between the parties to enable interoperability.
One cannot expect interoperability to occur automatically without some sort of negotiation between
parties (e.g. Information Exchange Agreement, whether internal or external to an organisation)
involved in data exchange. Once information exchange agreements between parties are in place, then
the data/information exchange process can be automated. Moreover, the entire information exchange
and interoperability process should be managed through an effective governance process which
should involve all the parties involved in the information exchange process. This enables effective and
efficient management of any change to the information exchange process in the future.
3.2
Information Exchange Agreement – Guidelines
The AS4590 Standard V2.0 was designed as a core set of building blocks to be used as a consistent
baseline for creating exchange documents and transactions within Australian Government
organisations. The goal of the AS4590 Standard V2.0 as conformance is for the sender and receiver of
information to share a common, unambiguous understanding of the meaning of a basic core set of
information (the components). The result is a level of interoperability that would be unachievable with
the proliferation of custom schemas and dictionaries.
To ensure interoperability it is strongly advised that an information exchange agreement/specification
AS4590 Standard V2.0 be in place, with the agreement of the parties involved in the exchange. This
agreement/specification should outline in detail the customisation of the AS4590 Standard V2.0.
3.2.1 Conformance Rules
This section summarises the conformance rules that users should implement when using the AS4590
Standard V2.0. These rules are as follows:

Instances must validate against the AS4590 Standard V2.0 reference schema. Schemas
conformant to the AS4590 Standard V2.0 must import and reference the AS4590 Standard V2.0
Schema namespace or a correct AS4590 Standard V2.0 Schema Subset (which relates to the same
namespace).

If the appropriate component (type, element, or attribute) required for the application exists in the
AS4590 Standard V2.0, use that component (i.e. do not create a duplicate of one that already
exists).

Be semantically consistent. Use AS4590 Standard V2.0 components in accordance with their
definitions. Do not use an AS4590 Standard V2.0 component to represent data other than what its
definition describes.

Apply XML Schema extension rules correctly and consistently.
Version:1.0
Status: Final
31/07/2017
Page 7 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
3.2.2
Key factors to include in the Exchange Agreement
Following are some of the key factors that should be documented and agreed (if involving more than
one party in data exchange) at application/system design time. This will enable automated
interoperability of information/data at application/system run time. The rationale of having an
exchange agreement is to ensure that the receiving party is well prepared and ready to process the data
sent to it without any surprises. The key factors are:
1. A list of all elements of AS4590 Standard V2.0 XML Schemas (core, assembled, code list, data
types XML schemas) that should be used in the exchange. This includes details of which elements
are mandatory and which elements are optional during data exchange.
2. The order of occurrence of elements when assembling core components should be agreed between
the parties. Stick to the order of occurrence or XML schema validation will fail.
3. The code list values should be used for each of the code lists, as parties may decide to use a subset
of the code list or a superset or the default code list. These code list files should then be shared
and implemented by all applications/systems involved in data exchange. Any changes to the code
lists should be managed through a governance process that includes all parties involved in the
exchange.
4. Any extensions to the default XML schemas. These should be clearly defined and agreed. It
should be determined whether XML schema should be extended by using new attributes from a
non-target namespace and if so, details of the additional attributes should be agreed. Any
extensions to the XML schema model should follow the same design approach/guidelines used in
the development of the AS4590 Standard V2.0.
5. Details of any business rules that should be implemented to constrain the AS4590 Standard V2.0
schemas. These should be applied consistently by all applications/systems involved in data
exchange.
6. A breakdown of structured ‘vs. unstructured data. There should be a discussion of whether the
data to be exchanged is structured or unstructured and what level it might be structured to. For
example, address might be semi-structured to street details, suburb and state + post code. A fully
structured address will contain street name, street type, street number, suburb, state, and post
code.
It is also important to ensure that the run-time environment that holds the XML artefacts (schemas,
code lists, etc) is up to date. For example the environment should support recent versions and also
older versions that might be used by parties until such time as they move to an updated version.
Once the agreement is implemented, it is vital that the agreement should have a governance process to
manage change effectively and efficiently. All parties involved in the data exchange process should be
key stakeholders of the governance process. Any changes to the implementation guidelines should
also occur through a governance process.
3.2.3
Tools and applications to implement this Standard
A range of technical skills are necessary to create valid XML documents conforming to the AS4590
Standard V2.0. These skills include an understanding of XML file creation, validation and
interpretation processes (as well as likely sources of error or failure); and an understanding of the
logic and semantic meaning of the data elements to be included in validated exchange files.
The particular tools and applications required to use AS4590 Standard V2.0 are:

The data dictionary for the local database, available from the database administrator.
Version:1.0
Status: Final
31/07/2017
Page 8 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines

Mapping tools to map between database schema and the XML schema.

XML parser software, either open source or provided by the commercial vendor.
3.2.4
Implementation Considerations
A range of considerations and decisions need to be made when preparing validated exchange files to
represent the data elements in the AS4590 Standard V2.0. Once these decisions are made, the
developer can proceed to write the code to prepare the validated exchange file in XML format.
The first consideration is how to map AS4590 Standard V2.0 data elements to the fields that are
stored and managed in agency databases. Database administrators should be able to assist with this
mapping. The question to answer is: ‘Which fields in our agency database correspond to the data
elements in the AS4590 Standard V2.0?’
Secondly, it is important to remember that different sets of data elements may be required for different
services.
Finally, the implementation ‘rules’ laid out in the AS4590 Standard V2.0 will need to be interpreted
by the developer to ensure that the data elements are constructed correctly and put in the correct order.
Additionally, it is the developer’s responsibility to ensure the resulting XML file is parsed without
error so it conforms to the AS4590 Standard V2.0 specification.
3.2.5
3.2.5.1
Basic steps to implementing the Standard
Principles
The following principles should be followed in implementing this standard:
Exchanging parties should agree, and confirm:

an interpretation of the AS4590 Standard V2.0 and implementation considerations;

to use the latest specification available (in order to avoid the generation of a separate schema
requiring future maintenance and synchronisation with the latest specification);

any additional exchange rules specific to the exchange; and

any adjustment to the AS4590 Standard V2.0 file exchange implementation as and when
necessary.
3.2.5.2
Approach
Regardless of the extent to which implementation of this standard is automated by agencies, an
appropriate data-sharing agreement and adequate software programming logic will be required. There
are three phases to implementing the Standard.

Creating a valid XML file for transmission to another agency by building an application that
follows the rules of AS4590 Standard V2.0 and the exchange agreement.

Checking the XML file for validity against the latest specification using a fit-for-purpose XML
editing and parsing tool. Processing-logic applications should be programmed to ignore empty
elements.
Version:1.0
Status: Final
31/07/2017
Page 9 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines

Interpreting an XML file that came from an outside agency by using XPath to navigate the
structure of the validated exchange file.
3.2.5.3
Parsing and Validation
The parsing process helps ensure that the structure of the XML file is well-formed and validated (that
is, any elements required by the exchange agreement are present and in the correct order and that the
file conforms to the agreed AS4590 Standard V2.0 specifications. To ensure this, the following
principle should be applied: before exchange, XML files should be parsed by the sending party,
without error, using a parser agreed by the receiving party. However, on each exchange the XML files
should be parsed by the receiving party as it is in their best interests to validate the incoming XML
files before transferring them to a processing system.
3.2.5.4
Sample XML file for testing
It is advisable to provide some sample XML files (validated against the AS4590 Standard V2.0) to
the parties involved in the exchange. This will enable the parties to test them on their end and ensure
that they are ready to process the exchange file.
4 Guidelines to extend AS4590 Standard V2.0 to address
specific requirements
One common problem in using an industry standard is that the standard is either generic or too limited
to meet the specific requirements of an organisation. As a result of this, organisations often end up not
implementing the standard and instead, either implementing their own standard or customising the
existing standard.
One of the key reasons for the lack of uptake of the AS4590 Standard V1.0 is that the standard did not
meet the requirements of agencies. The design of the standard addresses this issue.
The physical implementation model of a standard (e.g. an XML schema) should be extendable to meet
the requirements. At the same time, it is important that the extended model is compliant with the
standard. This means that the extended model can be a super set of the standard, but not a subset. Any
extensions to a standard need to be governed properly, particularly when two or more
parties/applications are involved in exchanging data between each other using the documents
generated from the extended model. The parties should agree on the extensions to the standard that
will be used to generate the document. In this way, the parties can define business rules that can
handle these extensions. Therefore, a strong governance model should be implemented to manage
this.
This section will briefly describe the different strategies that can be considered to implement the
AS4590 Standard V2.0 to meet specific business needs.
4.1
Define business rules at the receiving application end
In cases where an XML schema standard is generic, it is strongly advised that an organisation/s not
customise the standard. Instead an organisation/s should define and implement business rules at the
application integration layer or at the application end that consumes the payload generated from the
standard and that is exchanged. These business rules can control the payload before hitting the
backend systems/applications in terms of fields that should be optional or mandatory, validation and
verification of data, etc. This may require coding of the business rules in a programming language that
is compliant with the environment. In this way, the exchanged payload is compliant with the standard.
Version:1.0
Status: Final
31/07/2017
Page 10 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
4.2
Use double pass validation to control the XML schema standard for
specific requirements
Schemas describe the structural and lexical constraints on a document. Some information items in a
document are described in the schema lexically as a simple value. Using XML technologies to
validate and place constraints by defining rules on the XML schema standard outside of the standard,
is the second pass of a two-pass validation strategy. The “first pass” confirms the structural and
lexical constraints of a document and the “second pass” confirms the value constraints of a document.
The “first pass” can be accomplished with an XML document schema language such as W3C Schema
or ISO/IEC 19757-2 RELAX NG. The “second pass” can be accomplished with a transformation
language such as a W3C XSLT 1.0 stylesheet or a Python program or using ISO/IEC 19757-3
Schematron schemas.
ISO Schematron is a powerful yet simple assertion-based schema language used to confirm the
success or failure of a set of assertions made about XML document instances. One can use ISO
Schematron to express assertions supporting business rules and other limitations of XML information
items so as to aggregate sets of requirements for the value validation of documents. Using
Schematron, one can place constraints on the XML schemas without being non-compliant. A good
case study on using Schematron to place constraints on a generic XML industry standard outside of it,
can be found at: http://www.oasis-open.org/committees/ciq.
4.3
Extend the XML Schema using the language capabilities
The W3C XML Schema Definition Language allows several powerful techniques for extending
schemas to include or redefine elements and attributes. This section describes different strategies to
extend and redefine the AS4590 Standard V2.0 XML schemas to enable development of robust
information architectures that can accommodate enterprise information needs.
4.3.1
XML Schema Extension by Generic Element
Let us take the following XML Schema (OriginalSchema.xsd) as an example.
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:element name="Party">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="PersonName" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="NameTitle" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="FullName" type="xsd:string" minOccurs="0"/>
<xsd:element name="GivenName" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="FamilyName" type="xsd:string"/>
<xsd:element name="NameSuffix" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Listing 1: OriginalSchema.xsd
Version:1.0
Status: Final
31/07/2017
Page 11 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
Listing 1 is shown in the figure below:
The W3C XML Schema lets you extend existing type definitions to add additional sub-elements,
adding additional elements to the data model's structure. You can apply extensions to the types of
element or attributes. Given the example type definition in Listing 1, you can define the contents of
elements that contain person name information. This definition will parse the document instance
below (Listing 2) as valid:
<?xml version="1.0" encoding="UTF-8"?>
<Party xsi:noNamespaceSchemaLocation="OriginalSchema.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance">
<PersonName>
<NameTitle>Mr</NameTitle>
<GivenName>Steven</GivenName>
<FamilyName>Smith</FamilyName>
</PersonName>
</Party>
Listing 2. OriginalSchema.xml
A good example of data that changes over time is code lists. A code list is a list of unique code values
that have specific meanings, such as product descriptors, frequently used terms, and lists of countries
or cities. These values are often stored in a database row that you can add to over time and use to
populate choices in an application window.
Listing 3 is an extension to OriginalSchema.xsd (Listing 1) and its last element “Other” that is added
is sometimes called a generic element and is designed to allow any value to be inserted in the
“PersonName” entity attribute, thereby allowing you to add new data to the PersonName list as
needed over time. When validated, the <other> element is allowed, and you keep working with no
changes to the schema required.
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:element name="Party">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="PersonName" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="NameTitle" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="FullName" type="xsd:string" minOccurs="0"/>
Version:1.0
Status: Final
31/07/2017
Page 12 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
<xsd:element name="GivenName" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="FamilyName" type="xsd:string"/>
<xsd:element name="NameSuffix" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="Other" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Listing 3: OriginalSchema-ExtendedByGenericElement.xsd
Listing 3 is shown in the figure below:
Listing 4 is the document instance that is validated against Listing 3 schema.
<?xml version="1.0" encoding="UTF-8"?>
<Party xsi:noNamespaceSchemaLocation="OriginalSchema-ExtendByGenericElement.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<PersonName>
<NameTitle>Mr</NameTitle>
<GivenName>Steven</GivenName>
<FamilyName>Smith</FamilyName>
<Other>PhD</Other>
<Other>Junior II</Other>
</PersonName>
</Party>
Listing 4. OriginalSchema-ExtensionByGenericElement.xml
4.3.2
XML Schema Extension by Generic Element supported by Controllable Code
List
One shortcoming of Listing 3 is that any data can be added to the “Other” element without any
definition of metadata for the data. It would be useful if metadata is defined that will add context to
the data. Listing 5 is an extension to OriginalSchema.xsd and provides a strategy to do this.
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
attributeFormDefault="unqualified">
Version:1.0
Status: Final
31/07/2017
Page 13 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
<xsd:simpleType name="OtherType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="FatherName"/>
<xsd:enumeration value="MaidenName"/>
<xsd:enumeration value="Alias"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:element name="Party">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="PersonName" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="NameTitle" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="FullName" type="xsd:string" minOccurs="0"/>
<xsd:element name="GivenName" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="FamilyName" type="xsd:string"/>
<xsd:element name="NameSuffix" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="Other" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="Type" type="OtherType"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Listing 5. OriginalSchema-ExtendedByGenericElementAndCodeList.xsd
Listing 5 is shown in the figure below:
Users can now define the metadata for the element “Other” using the “Type” enumeration list.
A valid XML document instance for Listing 5 is shown below:
<?xml version="1.0" encoding="UTF-8"?>
Version:1.0
Status: Final
31/07/2017
Page 14 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
<Party xsi:noNamespaceSchemaLocation="OriginalSchema-ExtendByGenericElementAndCodeList.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<PersonName>
<NameTitle>Mr</NameTitle>
<GivenName>Steven</GivenName>
<FamilyName>Smith</FamilyName>
<Other Type="FatherName">Gary Smith</Other>
<Other Type="Alias">Bumbly</Other>
</PersonName>
</Party>
Listing 5. OriginalSchema-ExtendByGenericElementAndCodeList.xml
Now, the element “Other” has a metadata description using the attribute “Type”.
4.3.3
XML Schema Extension using Modular Schema Assembly
This is the approach that was used to build the AS4590 Standard V2.0 to extend the base XML
schema that was constructed as core reusable components. By using the reusable components, one can
assemble new XML schemas to meet their specific business requirements using “Import” capabilities
of XML Schema. If you are assembling schemas from the same namespace, use the “Include” feature
to assemble them. If the schemas to be assembled are from different namespaces, use the “Import”
feature to assemble them.
Although adding modules is a form of extending a schema, the potential for building a set of
dynamically assembled modules to create flexible schemas for different environments and
applications is a powerful concept for optimising development and maintenance effort. The end result
is a library of predefined, consistent declarations for developers to selectively use throughout the
enterprise. Even so, special care should be taken to prevent naming collisions and other errors from
occurring, especially in a single namespace.
4.3.4
XML Schema Extension using Derive by Extension Mechanism for Elements
The W3C XML Schema allows the extension of existing type definitions to add additional subelements, to the data model's structure. Extensions can be applied to the types of element or attributes.
Using the example type definition in Listing 6, the contents of elements that contain person name
information can be defined.
<xsd:complexType name="PersonNameType">
<xsd:sequence>
<xsd:element name="NameTitle" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="FullName" type="xsd:string" minOccurs="0"/>
<xsd:element name="GivenName" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="FamilyName" type="xsd:string"/>
<xsd:element name="NameSuffix" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
Listing 6. PersonName Complex Type
Version:1.0
Status: Final
31/07/2017
Page 15 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
Listing 6 is shown in the figure below:
This definition will parse the instance below (Listing 7) as valid (assuming that the element <name>
is defined using the PersonNameType type):
<PersonName>
<NameTitle>Mr</NameTitle>
<GivenName>Steven</GivenName>
<FamilyName>Smith</FamilyName>
</PersonName>
Listing 7. Instance Document of Listing 6 schema
You can supply additional sub-elements to the complex type called PersonNameType using the
example in Listing 8. In this example, you can see that a new complexType named
PersonNamePlusDOB shows that the extension is to be applied to the base type
PersonNameType (defined in Listing 6). Once extended, the base type will inherit the properties of
the new extended type in addition to its own definition. In this case, the sub-element
<DateOfBirth> is added to the PersonNameType element defined above, which already has as
sub-elements the <NameTitle>, <GivenName> and <FamilyName> elements.
<xsd:complexType name="PersonNamePlusDOB">
<xsd:complexContent>
<xsd:extension base="PersonNameType">
<xsd:sequence>
<xsd:element name="DateOfBirth"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="Party">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="PersonName" type="PersonNamePlusDOB" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Listing 8. Extension to Listing 6 Schema
Version:1.0
Status: Final
31/07/2017
Page 16 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
The <Party> element defined in Listing 8 uses the PersonNamePlusDOB, which has been
defined to include all the sub-elements from its base type PersonNameType as well as the
extension element <DateOfBirth>. This would allow the following (Listing 9) instance to validate
with no errors:
<Party xsi:noNamespaceSchemaLocation="OriginalSchema-DeriveByExtension.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<PersonName>
<NameTitle>Mr</NameTitle>
<GivenName>Steven</GivenName>
<FamilyName>Smith</FamilyName>
<DateOfBirth>01 January 1982</DateOfBirth>
</PersonName>
</Party>
Listing 9. Document instance for Listing 8
4.3.5
XML Schema Extension – Using Redefine Mechanism
Types defined in one schema can be reused and redefined in another schema module. This behavior
can be handy if you inherit a schema but want to modify the definition somewhat to work better in
your environment. Suppose you're given an industry-standard schema that defines a ComplexType
for the PersonNameType as in Listing 10.
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:complexType name="PersonNameType">
<xsd:sequence>
<xsd:element name="NameTitle" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="FullName" type="xsd:string" minOccurs="0"/>
<xsd:element name="GivenName" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="FamilyName" type="xsd:string"/>
<xsd:element name="NameSuffix" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="Party">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="PersonName" type="PersonNameType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Listing 10. OriginalSchemaToBeRedefined.xsd
Version:1.0
Status: Final
31/07/2017
Page 17 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
Listing 10 is shown in the figure below:
The PersonNameType in Listing 10 might not be enough for your local environment. Perhaps in
your environment, you need to have another element called GenerationIdentifier which is mandatory.
Consider a separate schema module that calls the original schema through the schemaLocation=
attribute and redefines it with the code in Listing 14.
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:redefine schemaLocation="OriginalSchemaToBeRedefined.xsd">
<xsd:complexType name="PersonNameType">
<xsd:complexContent>
<xsd:extension base="PersonNameType">
<xsd:sequence>
<xsd:element name="GenerationIdentifier"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:redefine>
<xsd:element name="Person">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="PersonName" type="PersonNameType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Listing 14. OriginalSchemaRedefined.xsd
Because the PersonNameType has been redefined, it is still referred to using the same name, but
when applied to the <PersonName> element, it ensures that the PersonName will always contain
the GenerationIdentifier.
Version:1.0
Status: Final
31/07/2017
Page 18 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
The figure of Listing 14 is shown below:
4.3.6
XML Schema Extension – Using Wildcards for Elements
The W3C XML Schema allows you to declare some elements using wildcards, or elements that can
contain just about any other element or attribute—declared or otherwise. The wildcard ANY type is a
placeholder whose content might or might not be validated against a schema. Validation is controlled
by setting the processContents attribute to one of the following levels:

Skip: Do not validate contents.

Lax: Validate only if you can find a corresponding declaration.

Strict: Validate against the current schema.
You define wildcards using the <xs:any> element for elements . The example in Listing 15 shows
an element named <PersonName> that has a wildcard where subordinate element would be
declared as <xsd:any namespace="##other" processContents="lax" minOccurs="0"/>. In other words, the
<PersonName> element can contain any other elements as long as they have well-formed markup.
You can add an external Schema and allow the elements to parse against it, and then set the
processContent level to lax or skip or strict depending upon the level of validity.
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:element name="Party">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="PersonName" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="NameTitle" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="FullName" type="xsd:string" minOccurs="0"/>
<xsd:element name="GivenName" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="FamilyName" type="xsd:string"/>
<xsd:element name="NameSuffix" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
Version:1.0
Status: Final
31/07/2017
Page 19 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
<xsd:any namespace="##other" processContents="lax" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Listing 15. XML Schema with an element “ANY”
Listing 15 is shown in figure below.
Specifically, the example in Listing 15 shows the element declaration to contain a complex type that
contains a sequence. The sequence contains the <any> element, which is the wildcard placeholder
indicating that any element markup can appear at this location. If the processing of the contents of this
element should be skipped, no schema validation is performed on the contents between the start and
end tags. Therefore, the entire element can contain any well-formed markup using any element or
attribute names. In this way, you can add content from other document models inside this element,
thus extending the types of elements allowed overall in the document—albeit in a specific location.
Let us say, that you want to use some elements from another schema (Listing 16) in a different name
space as part of the schema in Listing 15.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns="http://www.somelocation.com" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.somelocation.com" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:element name="PersonDemographics">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Age"/>
<xsd:element name="Sex"/>
<xsd:element name="LicenseNumber"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Listing 16. Schema from another Namespace
Version:1.0
Status: Final
31/07/2017
Page 20 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
The data instance in Listing 17 is valid given this example.
<?xml version="1.0" encoding="UTF-8"?>
<Party xmlns:a="http://www.somelocation.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="OriginalSchema-DeriveByANY.xsd">
<PersonName>
<NameTitle>Mr</NameTitle>
<GivenName>Steven</GivenName>
<FamilyName>Smith</FamilyName>
<a:PersonDemographics>
<a:Age>28</a:Age>
<a:Sex>Male</a:Sex>
<a:LicenseNumber>8345678C</a:LicenseNumber>
</a:PersonDemographics>
</PersonName>
</Party>
Listing 17. Document Instance Valid for Schema in Listing 15.
In the example in Listing 17, the element type <PersonName> is validated normally against the
schema in Listing 15, but the contents of that element, the PersonDemographics elements are checked
only for presence of corresponding declaration given that the process content is set to “lax”. If it was
set to “skip”, even this will be ignored.
Take particular care when you use wildcards if you expect to require validation or to allow lax
validation when a schema can be found. Resources, such as alternative schemas to validate against,
must be made available to the processor. Namespaces must be managed correctly. Also, using
wildcards in conjunction with optional or repeatable elements can cause ambiguities and nondeterministic conditions. The simplest use of wildcards with processContents="skip" will
allow you to avoid most of this complexity.
4.3.7
XML Schema Extension – Derive by Extension Mechanism for Attributes
Similar to what we saw in section 4.3.4, W3C XML Schema lets you extend existing type definitions
to add additional attributes to the data model's structure. You can apply extensions to the types of
attributes. Let us use the XML Schema in Listing 18 to demonstrate this. Listing 19 extends Listing 1.
Version:1.0
Status: Final
31/07/2017
Page 21 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:element name="Party">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="PersonName" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="NameTitle" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="FullName" type="xsd:string" minOccurs="0"/>
<xsd:element name="GivenName" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="FamilyName" type="xsd:string"/>
<xsd:element name="NameSuffix" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="Type" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Listing 18. Original Schema
Listing 18 is shown in the figure below:
Version:1.0
Status: Final
31/07/2017
Page 22 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:complexType name="PersonNameType">
<xsd:sequence>
<xsd:element name="NameTitle" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="FullName" type="xsd:string" minOccurs="0"/>
<xsd:element name="GivenName" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="FamilyName" type="xsd:string"/>
<xsd:element name="NameSuffix" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="Type" type="xsd:string"/>
</xsd:complexType>
<xsd:complexType name="PersonNamePlusDOB">
<xsd:complexContent>
<xsd:extension base="PersonNameType">
<xsd:sequence>
<xsd:element name="DateOfBirth"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="Party">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="PersonName" maxOccurs="unbounded">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="PersonNamePlusDOB">
<xsd:attribute name="ID" type="xsd:string"/>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Listing 19. Extending Attributes
Version:1.0
Status: Final
31/07/2017
Page 23 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
Listing 19 is shown in the figure below:
In Listing 19, the PersonName element is extended by adding two additional attributes namely, an
‘ID” and “ANY” attribute (wildcard) using extension mechanism. You will also notice that Listing 18
is also extended by adding an additional element called “DateOfBirth” using extension mechanism as
explained in section 4.3.4. The “ANY” attribute uses the same concept as described in section 4.3.6
for elements. The Process content is set to “lax” for this example. Listing 20 is an instance document
that validates against the schema in Listing 19.
<?xml version="1.0" encoding="UTF-8"?>
<Party xmlns:a="http://www.somelocation.com" xsi:noNamespaceSchemaLocation="OriginalSchemaDeriveByExtension.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<PersonName Type="Male" ID="ID1234" xmlns:a="http://www.somelocation.com" a:Category="Gold Customer">
<NameTitle>Mr</NameTitle>
<GivenName>Steven</GivenName>
<FamilyName>Smith</FamilyName>
<DateOfBirth>01 January 1982</DateOfBirth>
</PersonName>
</Party>
Listing 20. Instance document validated against Schema in Listing 19
Note that this document includes an attribute called “Category” which is from a different namespace
and is ignored during validation.
Version:1.0
Status: Final
31/07/2017
Page 24 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
4.3.8
XML Schema Extension – Controlling Code Lists outside of the XML Schema
A code list (also called enumeration) defines a classification scheme and a set of classification values
to support the scheme. For example, “Administrative Area” for an Address schema is a classification
scheme. A set of classification values for this scheme could be: State, City, Province, Town, Region,
District, etc.
XML Schema describes the structural and lexical constraints on an XML document. Some
information items in a document are described in the schema lexically as a simple value whereby the
value is a code representing an agreed-upon semantic concept. The value used is typically chosen
from a set of unique coded values enumerating related concepts. These sets of coded values are
sometimes termed code lists.
Code Lists are generally embedded in an XML schema and software application code are generated
out of the XML schema, compiled and executed as part of an application. The compiled code includes
the enumeration lists. When changes happen to a code list, the software application code has to be
recompiled. This is often an issue for organisations that reuse code lists for many applications, or
organisations that want to add additional value to the standard code list or restrict the values in the
standard code lists. How do we add or restrict the values in the code list without the need to update the
XML schema and recompile the software application code that uses the XML schema and the
supporting code lists?
The OASIS Code List Representation format, “Genericode”, is a single industry model and XML
format (with a W3C XML Schema) that can encode/standardise a broad range of code list
information. The XML format is designed to support interchange or distribution of machine-readable
code list information between systems. Details about this specification are available at:
http://www.oasis-open.org/committees/codelist.
This approach keeps the enumeration list outside of the base XML schema. This Option uses a “two”
pass validation methodology, whereby, the “first” pass validation, allows the XML document instance
to be validated for its structure and well-formedness (ensures that information items are in the correct
places and are correctly formed) against the entity XML schema, and the “second” pass validation
allows the code list values in XML document instance to be validated against the genericode based
code lists and this does not involve the entity schemas.
Any change to the genericode based code list does not require changes to the software code (e.g. java
object must be re-created) based on the entity schema as the entity schema reference the genericode
based code list. A case study involving the use of this approach is at http://www.oasisopen.org/committees/ciq.
4.4
Extending the XML Schema – Conclusion
As shown by the strategies discussed above regarding extending XML schemas, the designers of the
W3C XML Schema language had extensibility in mind when they created the standard. Take care to
observe the rules for each extension type in order for them to work. These powerful techniques,
although only working in a single namespace, can allow tremendous flexibility—especially when you
work with schemas used in distributed and diverse environments. However, the most important aspect
is that whatever extensions are done to the base XML Schema, ensure that a governance model is in
place to ensure that parties involved in the data exchange process are kept informed of these
extensions to achieve interoperability of data.
It will be valuable to pay attention to the emerging XML Schema version 1.1 standard being produced
in the W3C XML Schema Working Group. The schema has some interesting changes to the wildcards
and other constructs that might affect the examples shown here.
Version:1.0
Status: Final
31/07/2017
Page 25 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
5 General Guidelines for any project that implements
AS4590 Standard V2.0
The Australian Government has developed a comprehensive Architecture Framework1 to assist in the
delivery of more consistent and cohesive services to citizens and support cost-effective delivery of
Information and Communications Technology (ICT) services by government. The Framework
describes reference models that form the basis of a common language between agencies and structure
a repository of architectural artefacts (including standards, guidelines, designs and solutions). The
models may be utilised by agencies to deliver an increasing range of whole-of-government services.
The Framework contains a set of inter-related ‘reference models’ designed to facilitate cross-agency
analysis and the identification of duplicate investments, gaps and opportunities for collaboration
within and across agencies. Collectively, the reference models comprise a framework for describing
important elements of the architecture in a common and consistent manner. It is strongly advised that
agencies refer to this work extensively wherever appropriate rather than duplicate or re-invent.
In addition to the above framework, the following section provides “General” Guidelines for any
project that intends to implement the AS4590 Standard V2.0 as part of the project. The following
points cover business process, data, enterprise architecture and application architecture considerations
while implementing a project involving the AS4590 Standard V2.0
5.1
Business Process Considerations
5.1.1
Business Process Diagrams
Business Process diagrams should be used to define the business processes that the data exchange
parties will use to perform the business function when exchanging AS4590 data.
5.1.2
XML Transactions
The Business Process diagrams can be used to define the XML transactions (e.g. CreatePartyData,
SendPartyData, UpdatePartyData) that will be exchanged by the data exchange parties. Note that the
AS4590 Standard V2.0 does not define any transaction types.
Data exchange parties need to identify each data element within each XML transaction that will be
transferred. For each data element the data exchange parties need to identify:




the data format of the data element;
if the data element is mandatory, optional, or forbidden;
possible default values for the data element if absent; and
relationships between/among multiple data elements
5.1.3
Data Quality
Entering valid data (e.g. name and address data) at the earliest opportunity is vital since correcting
data is an expensive undertaking after it has already been entered into IT systems, and more so after
the data has propagated to other systems. In order to improve data quality at the earliest opportunity,
ensure that:
1 . Australian Government Architecture Reference Model, V2.0, AGIMO, December 2009
Version:1.0
Status: Final
31/07/2017
Page 26 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
1. data captured interactively (during online web interactions, a phone conversation, or face to face) is
entered into an IT system that is immediately validated wherever possible by a set of business rules.
For example, with name and address data, the party can be asked to provide the right data if the
validation fails during point of data entry.
2. confirmation of the currency and validity of address held on government records at each customer
contact is a common practice in customer contact business processes. This ensures ongoing address
data currency as well as validity, without incurring additional cost.
5.1.4
Data Currency and Re-validation
Once acquired and recorded data in an IT system can become out of date due to:

the data no longer being valid (eg. a person or organisation has moved to another address); or

infrequent changes to data (e.g. occasional changes to street numbers, names and/or suburb
boundaries).
The effort required for maintaining the currency of data after initial capture needs to be weighed
against the derived business benefits. Due consideration of business and legislative regulations,
including compliance with privacy legislation and regulations, may also need to be factored into data
collection.
5.2
Data Considerations
5.2.1
Schema Guidelines
The AS4590 Standard V2.0 can assist in designing application data and database schemas.
5.2.2
Database Schemas
Databases holding client data can be used to store address as per AS4590 Standard V2.0 schema and
logical data model. The physical data model can be mapped to the appropriate database being used.
5.2.3
Physical Forms of the AS4590 V2.0 XML Model Logical Schema
The AS4590 Standard V2.0 logical schema client data is the recommended standard. Its physical
incarnation may take any form, such as an XML document, a COBOL copybook and its
corresponding data file, or a comma-separated data file. However, data model mapping should be
specified when converting to and from another data model.
5.2.4
5.2.4.1
Current Data Stores
Data Cleansing
When upgrading current applications to comply with AS4590 Standard V2.0, it may be necessary to
conduct address data cleansing, most notably when:

the data model (format, semantics and validity) of existing client data deviates substantially from
AS4590 Standard V2.0; and/or

the existing client data has not been validated (e.g. against a reference address file, say PAF)
Costs for utilising client data (and in particular address data) that require cleansing should be included
in the business case of the application which uses the data.
Version:1.0
Status: Final
31/07/2017
Page 27 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
5.2.4.2
Run-time Conversion
For non-compliant current data stores, feasibility of using a run-time conversion to AS4590 Standard
V2.0 where it suits the transaction processing profile of an interactive application should be evaluated
as an option (viz. number of updates vs. queries, transaction volumes).
5.3
Enterprise Architecture Considerations
5.3.1
Interfaces between Applications
Client data is to be interchanged between IT systems using the standard described in AS4590
Standard V2.0 This approach should be adopted because it:

provides maximum semantic compatibility between interfacing systems;

eliminates effort required in semantic mapping, and

includes a physical format which can be selected on the basis of technology choices appropriate
for the interfacing systems.
5.3.2
Commercial Off-the-Shelf (COTS) Applications
When purchasing commercial off-the-shelf applications, the following principles should be applied:
1. Vendors should be asked to comply with the AS4590 Standard V2.0 during the Request for
Information, Request for Proposal, and Request for Tender processes.
2. Preference should be given to those offerings with Australian versions supporting the Australian
standards, specifically the AS4590 Semantic Standard from Standards Australia.
3. The street address data captured by the COTS application must be validated against the designated
standard for street address data validation (Vicmap Address Dataset or G-NAF).
4. The client data interchange must comply with the requirements stipulated in the AS4590 Standard
V2.0.
Where a COTS application does not explicitly support or cannot be easily customised to align with
the AS4590 Standard V2.0, its deployment can result in additional costs (both initial and ongoing) in
developing appropriate inbound and outbound interfaces. These costs should be included in evaluating
the package options and the overall business case of the application.
5.4
5.4.1
Application Architecture Considerations
Practical User Interface Design for Display and Capture of Client Data
The AS4590 Standard V2.0 consists of a large number of component fields such as name and address.
These fields should not be displayed as separate fields either on a screen or on a form. User interfaces
involving these fields should be designed as per good useability practices.
User interfaces, on-screen and in printed forms, should display these fields in a pragmatic manner
with few significant components. Validation and parsing by application logic should ensure that
supplied addresses map to and comply with the AS4590 Standard V2.0
Version:1.0
Status: Final
31/07/2017
Page 28 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
5.4.2
Reference User Interface Implementation
A re-usable user interface component can be developed that lets the user choose the broad category of
party name (e.g. person, organisation) or address being entered (e.g. residential, business, or rural).
For each category, these can:
1. Display a user-friendly layout for data-entry, taking into account any specific fields that are
mandatory or not-applicable;
2. Carry out address data validation appropriate for each category; and
3. Return validated client data, compliant with AS4590 Standard V2.0.
Such a component can be made available as a reference implementation for re-use.
Technology specific versions of the user interface implementation may be developed: e.g. a version
for Windows Desktop or for web browsers.
5.4.3
Compliant Physical Format
Client data complying with the logical schema of AS4590 Standard V2.0 can be transformed to and
from various physical formats (e.g. comma-separated values, XML or COBOL copybook) through
simple tools. All such physical formats are considered to comply with this standard.
5.4.4
Mapping Across Diverse Data Models
Please be aware that mapping from one data model to another, such as from AS4590 Standard V2.0 to
a custom format, may involve one of the following:
1. Manual data cleansing where rules for automated data transformation cannot be developed due to
semantic mismatch; or
2. Format conversions and/or table look-ups (for code conversion, street name renaming, or
substitutions).
5.4.5
Payload for Web Services
It is a common myth that web services provides “loose coupling”. The reason being that certain
interfaces are industry standards based i.e. they use WSDL as the interface language written in XML.
However, loose coupling cannot be achieved if the payload of the service is in proprietary format as
this will result in data mapping and transformation process thereby resulting in tight coupling. To
enable loose coupling, it is important to provide loose coupling of the information components
(i.e. the payload). Using AS4590 Standard V2.0 schema as the standard payload for client data as part
of a web services provides the opportunity for loose coupling.
Version:1.0
Status: Final
31/07/2017
Page 29 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
6 Implementation Checklist
Please use the following implementation checklist as a guideline when planning and implementing the
use of AS4590 Standard V2.0 schemas in a project.
6.1
Administrative

Create the required legal agreement between or among data exchange partners.

Establish project objectives, scope.

Establish project contacts: business, technical, operational.

Develop an implementation project plan.

Establish a governance structure with key stakeholders involved.
6.2
Define Project Requirements

Define business process and transaction requirements.

Define error-processing requirements.

Define problem resolution requirements.

Define security requirements.

Confidentiality.

Integrity.

Availability.

Non-repudiation.

Define application interface requirements (proprietary to each data exchange partner).

Define transaction storage and audit requirements.
6.3
Define Technical Requirements

Define each Action and Signal message that will be exchanged.

Define field by field requirements for each Action (business) message.

Define field by field requirements for each Signal message.

Define data communication and network (firewall, router) access requirements.

Define transmission protocol (HTTP(S), SMTP, other) requirements.

Define what will be encrypted.

Define use of digital signatures.

Define use of the message "digest" for non-repudiation.

Define business recovery requirements.

Define hardware requirements.

Define software requirements.
Version:1.0
Status: Final
31/07/2017
Page 30 of 31
National Standards Framework
AS4590 XML Model V2.0: Implementation Guidelines
6.4
Define Business Process Requirements

Define internal business process requirements (proprietary to each data exchange partner) .

Train internal staff (proprietary to each data exchange partner).
6.5
XML Transaction Checklist

Develop, test, and implement the creation of each transaction.

Develop, test, and implement the acceptance and processing of each transaction.
6.6
Data Communication checklist

Install, configure, test, and implement each network component.

Exchange IP addresses/names.

Configure firewalls, routers, and other communications equipment.
6.7
Application Checklist

Define, build/install, test, and implement application interfaces (proprietary to each data exchange
partner).

Define, build/install packaging, unpackaging processes.

Define, build/install, test, and implement error processes.

Implement application support processes.
6.8
Operations Checklist

Install, configure and implement hardware.

Install, configure, and implement software.

Install, configure, and implement network components.

Install, configure, and implement data storage and backup.

Define, test, and implement business recovery processes.

Train operation and network support personnel.
Version:1.0
Status: Final
31/07/2017
Page 31 of 31