Government agencies record and interchange information about Name and Address. A nationalagreement on the syntax that is directly aligned to the agreed Australian Standard will improve theexchange of information about Name and Address. The benefits of anational agreement on thesyntax mayinclude

a reduction in deployment time, a reduction in the number of address errors andreduced costs. The existing version of the technical standard that was used for reviewcan be found at:

AS4590 Standard V2.0 is not a data storage standard for client data. It does not define agencydatabase fields, nor enforce database designs, although it may influence them. Each agencydecides whether it stores its data in the data formats specified in AS4590 Standard V2.0 orwhether it transforms its data when importing to and exporting from its databases. Whereagencies 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 atomicparts.

1.4

Approach

The development of the guidelines followsthe standards development process outlined in theNSF.Use of an online

collaborativeworkspace 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 onlinecollaborativeworkspace for the project, including an on linediscussion forum.



A callforparticipants from jurisdictions and Commonwealth agencies to participate.

Publicationofthe 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 andInter-jurisdictional).



Publication of the Implementation Guidelines

1.5

Participants

Therewere

a large number ofparticipants;

however national voting rightswere

limited to one voteper 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 AS4590Standard V2.0 as part of their project to exchange client data within a department or agency or withexternal agencies or jurisdictions. The guidelines could be used in any of the following scenarios:



Any project within an agency that requires the implementation/reuse ofAS4590 Standard V2.0includingto exchange client data with other agencies.



Any national project that requires the implementation/reuse ofAS4590 Standard V2.0.



Any national project that is building a standard for the Australian Government and requires reuseofAS4590 Standard V2.0to represent client data.

It is the view of the CIQ TC that toenable interoperability of databetween parties, the best practice

isto parse the data elements into its atomic elements thereby preserving the semantics and quality ofdata.Inthis way the parties involved in data exchange will be in the best position to understand thesemantics and quality

of data thereby minimising interoperability issues.However,

the

method inwhich

data will be exchanged between parties, whether in parsed or unparsed structure, must benegotiated between the parties to enable interoperability.

One cannot expect interoperability to occur automatically without some sort of negotiation betweenparties (e.g. Information Exchange Agreement, whether internal or external to an organisation)involved in data exchange. Once information exchange agreements between parties are inplace, thenthe data/information exchange process can be automated. Moreover, the entire information exchangeand interoperability processshouldbe

managed through an effective governance process whichshouldinvolve all the parties involved in the information exchange process. This enables effective andefficient 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 tobe used

as a consistentbaseline for creating exchange documents and transactions within Australian Governmentorganisations. The goal of the AS4590 Standard V2.0 asconformance

is for the sender and receiver ofinformation to share a common, unambiguous understanding of the meaning ofabasic core set ofinformation (the components).

The result is a level of interoperability that would be unachievable withthe proliferation of custom schemas and dictionaries.

To ensure interoperability it is strongly advised that an information exchange agreement/specificationAS4590 Standard V2.0 be in place, with the agreement of the parties involved in the exchange. Thisagreement/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 AS4590Standard V2.0. These rules are as follows:



Instances

must validate against the AS4590 Standard V2.0 reference schema. Schemasconformant to the AS4590 Standard V2.0 must import and reference the AS4590 Standard V2.0Schema namespace or a correct AS4590 Standard V2.0 Schema Subset (which relates tothe same

namespace).



If the appropriate component (type, element, or attribute) required for the application exists in theAS4590 Standard V2.0, use that component (i.e. do not create a duplicate of one that alreadyexists).



Be semantically consistent. UseAS4590 Standard V2.0components in accordance with theirdefinitions. Do not useanAS4590 Standard V2.0

componentto

represent data other than what itsdefinition describes.



Apply XML Schema extension rules correctly and consistently.

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page8

of31

7/11/2013

National Standards Framework

3.2.2

Key factors to include in theExchange Agreement

Following are some of the key factors that should be documented and agreed (if involving more thanone party in data exchange) at application/system design time. This will

enableautomatedinteroperability of information/data at application/system run time. Therationale

of having anexchange agreement is to ensure that the receiving party is well prepared and ready to process the datasent 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, datatypes XML schemas) that should be used in the exchange. This includes details of which elementsare mandatory and which elements are optional during data exchange.

2.

The order of occurrence of elements when assembling core components should be agreed betweenthe parties.Stick to the order of occurrenceorXML 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 subsetof the code list or a superset or the default code list. These code list files should then be sharedandimplemented by all applications/systems involved in data exchange.

Any changes to the codelists should be managed through a governance process

that includes

all parties involved in theexchange.

4.

Any

extensions to the default XML schemas. These

should be clearly defined and agreed.Itshould be determined whether XML schema should be extendedby using new attributes from anon-target namespace and if so, details of the additional

attributes should be agreed.Anyextensions to the XML schema model should follow the same design approach/guidelines

used inthe development of theAS4590 Standard V2.0.

5.

Details ofany

business rules that should be implementedto constrain theAS4590 Standard V2.0schemas. These should be appliedconsistently by all applications/systems involved in dataexchange.

6.

A breakdown of structured ‘vs.

unstructured data.There should be a discussion of whetherthedata to be exchanged is structured or unstructured andwhat level it might be structured to.

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 alsoolder versions that might be used by parties until such timeasthey move to an updated version.

Once the agreement is implemented, it is vital that the agreement shouldhave

a governance process tomanage change effectively and efficiently. All parties involved in the data exchange process should bekey stakeholders of the governance process. Any changes to the implementation guidelines shouldalsooccur

through a governance process.

3.2.3

Tools and applications to implement this Standard

A range of technical skillsarenecessary to create valid XML documents conformingto theAS4590Standard V2.0. These skills include an understanding of XML file creation, validation andinterpretation processes (as well as

likely sources of error or failure);

and an understanding of thelogic and semantic meaning of the data elements to be included in validated exchange files.

The particular tools and applications required to useAS4590 Standard V2.0are:



The data dictionary for the local database, available from the database administrator.

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page9

of31

7/11/2013

National Standards Framework



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 torepresent the dataelements in the

AS4590 Standard V2.0. Once these decisions are made, thedeveloper can proceed to write the code to prepare the validated exchange file in XML format.

The first consideration is how to mapAS4590 Standard V2.0data elements to the fields that arestored and managed in agency databases. Database administrators should be able to assist with thismapping. The question to answer is: ‘Which fields in our agency database correspond to the dataelements in theAS4590 Standard V2.0?’

Secondly, it is important to remember that different sets of data elements may be required for differentservices.

Finally, the implementation ‘rules’ laid out intheAS4590 Standard V2.0will need to be interpretedby 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 withouterror so it conforms to theAS4590 Standard V2.0

specification.

3.2.5

Basic steps to implementing the Standard

3.2.5.1

Principles

The following principlesshouldbe followed in implementing thisstandard:

Regardless of the extent to which implementation of thisstandard is automated by agencies, anappropriate data-sharing agreement and adequate software programming logic will be required. Thereare three phases to implementing the Standard.



Creating a valid XML file for transmission to another agency by building an application thatfollows the rules of AS4590 Standard V2.0 and the exchange agreement.



Checking the XML file for validity against thelatest specification using a fit-for-purpose XMLediting and parsing tool. Processing-logic applications should be programmed to ignore emptyelements.

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page10

of31

7/11/2013

National Standards Framework



Interpreting an XML file that came from an outside agency by using XPath to navigate thestructure 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 (thatis, any elements requiredby

the exchange agreement are present and in the correct order and that thefile conforms to the agreedAS4590 Standard V2.0specifications.To ensure this,

the followingprincipleshould 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 filesshould be parsed by the receiving partyasit is in their best interests to validate the incoming XMLfiles before transferring them to a processing system.

3.2.5.4

Sample XML file fortesting

It is advisable to providesomesample XML files(validated against theAS4590 Standard V2.0)

tothe parties involved in the exchange. This

will enable the

parties

to test them on their endandensurethat they are ready to process the exchange file.

One common problem in using an industry standardis that thestandard is either generic ortoolimitedto meet the specific requirements of an organisation. As a result of this, organisationsoftenend up notimplementing the standard and instead,

either

implementing

their own standard or customising

the

existingstandard.

One of the key reasons forthelack of uptake oftheAS4590 Standard V1.0isthat the standard did not

meet the requirements of agencies.The design of thestandard

addresses this issue.

The physical implementation model

of a standard

(e.g.anXML schema) should be extendable to meetthe requirements. At the same time, it is important that the extended model is compliant with thestandard.This means that the extended model can be a super set of the standard, but not a subset. Anyextensions to a standard need to be governed properly,

particularly when twoormoreparties/applications are involved in exchanging data between each other usingthe documentsgenerated from the extended model. The parties should agree on the extensions to the standard thatwill be used to generate the document.Inthis way, the parties can define business rules that canhandle these extensions. Therefore, a strong

governance model should be implemented to managethis.

This section will briefly describe the different strategies that can be consideredtoimplement theAS4590 Standard V2.0to meet specific business needs.

4.1

Definebusinessrules at the receiving application end

In cases where an XML schema standard is generic, it is strongly advisedthat an organisation/snotcustomise the standard. Instead an organisation/s should

define and implement business rules at theapplication integration layer or at the application end that consumes the payload generated from thestandard and that is exchanged. These business rules can control the payload before hitting thebackend systems/applications in terms of fields that should be optional or mandatory, validation andverification of data, etc. This may require coding of the business rules in a programming language thatis compliant with the environment.Inthis way, the exchanged payload is compliant with the standard.

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page11

of31

7/11/2013

National Standards Framework

4.2

Use double pass validation to control the XML schema standard forspecific requirements

Schemas

describe the structural and lexical constraints on a document. Some information items in adocument are described in the schema lexically as a simple value.

Using XML technologies tovalidate and place constraints

by defining rules on the XML schema standard outside of the standard,

isthe

second pass of a two-pass validation strategy.

The “first pass” confirms the structural andlexical constraints of a document and the “second pass” confirms the value constraintsof a document.

The “first pass” can be accomplished with an XML document schema language such as W3C Schemaor ISO/IEC 19757-2 RELAX NG.

The“second pass”can be

accomplished with a transformationlanguage such as a W3C XSLT 1.0 stylesheet or a Python program

or usingISO/IEC 19757-3Schematron schemas.

ISO Schematron is a powerful yet simple assertion-based schema language used to confirm thesuccess or failure of a set of assertions made about XML document instances. One can use ISOSchematron to express assertions supporting business rules and other limitations of XML informationitems so as to aggregate sets of requirements for the value validation of documents.

UsingSchematron, one can place constraints on the XML schemas without being non-compliant.

A goodcase study on usingSchematron to place constraints on a generic XML industry standard outside of it,

can be foundat:http://www.oasis-open.org/committees/ciq.

4.3

Extend the XML Schema usingthe language capabilities

The W3C XML Schema Definition Language allows several powerful techniques for extendingschemas to include or redefine elements and attributes.

This section describes different strategies toextend and redefine theAS4590 Standard

V2.0

XMLschemas to enable development of robustinformation 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

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page12

of31

7/11/2013

National Standards Framework

Listing 1 is shown in the figure below:

The W3C XML Schema lets you extend existing type definitions to add additionalsub-elements,adding additional elements to the data model's structure. You can apply extensions to the types ofelement or attributes. Given the example type definition

in Listing 1,you can define the contents ofelements that contain person name information.This definition will parse thedocumentinstancebelow(Listing 2)as valid:

<?xml version="1.0" encoding="UTF-8"?>

<Party

xsi:noNamespaceSchemaLocation="OriginalSchema.xsd"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<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. Acode list

is a list of unique code valuesthat have specific meanings, such as product descriptors, frequently used terms, and lists of countriesor cities. These values are often stored in a database row that you can add to over time and use topopulate choices in

an application window.

Listing 3 is an extension to OriginalSchema.xsd (Listing 1) and its last element “Other” that is addedis sometimes called ageneric element

and is designed to allow any value to be inserted in the“PersonName” entity

attribute, thereby allowing you to add new data

to thePersonNamelist asneeded over time. When validated, the<other>

element is allowed, and you keep working with nochanges 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"/>

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page13

of31

7/11/2013

National Standards Framework

<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.

Now, the element “Other” has a metadata description using the attribute “Type”.

4.3.3

XML SchemaExtension using Modular Schema Assembly

This is the approach that was

used to build theAS4590 Standard V2.0to extend the base XMLschema that was constructed as core reusable components. By using the reusable components, one canassemble new XML schemasto meet their specific business requirements using “Import” capabilitiesof XML Schema. If you are assembling schemas from the same namespace, use

the

“Include” featureto 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 ofdynamically assembled modules to create flexible schemas for different environments andapplications is a powerful concept foroptimising development and maintenance effort.The end resultis a

library of predefined, consistent declarations for developers to selectively use throughout theenterprise. Even so, special care

should be taken

to prevent naming collisions and other errors fromoccurring, especially in a single namespace.

4.3.4

XML Schema Extension using Derive by Extension Mechanism for Elements

The W3C XML Schemaallows theextension of

existing type definitions to add additional sub-elements, to the data model's structure.Extensionscan be appliedto the types of element or attributes.Usingthe example type definition in Listing 6,

the contents of elements that contain person nameinformation

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

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page16

of31

7/11/2013

National Standards Framework

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 thePersonNameType

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 calledPersonNameType

using theexample in Listing 8.

In this example, you can see that a newcomplexType

namedPersonNamePlusDOB

shows that the extension is to be applied to the base typePersonNameType

(defined in Listing 6). Once extended, the base type will inherit the properties ofthe new extended type in addition to its own definition. In this case,the

element defined in Listing 8uses thePersonNamePlusDOB, which has beendefined to include all the sub-elements from its base typePersonNameType

as well as theextension element<DateOfBirth>. This would allow the following(Listing 9)instance to validatewith 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 behaviorcan be handy if you inherit a schema but want to modify the definition somewhat to work better inyour environment. Suppose you're given an industry-standard schema that defines aComplexType

for thePersonNameType

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

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page18

of31

7/11/2013

National Standards Framework

Listing 10 is shown in the figure below:

ThePersonNameType

in Listing 10 might not beenough for your local environment. Perhaps inyour environment, you need to have another element calledGenerationIdentifierwhich is mandatory.

Consider a separate schema module that calls the original schema through theschemaLocation=

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 thePersonNameType

has been redefined, it is still referred to using the same name, butwhen applied to the<PersonName>

element, it ensures that thePersonName

will always containthe GenerationIdentifier.

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page19

of31

7/11/2013

National Standards Framework

The figure of Listing 14 is shown below:

4.3.6

XML SchemaExtension–

Using Wildcards for Elements

The W3C XML Schema allows you to declare some elements usingwildcards,

or elements that cancontain just about any other element or attribute—declared or otherwise. The wildcardANY

type is aplaceholder whose content might or might not be validated against a schema. Validation is controlledby setting theprocessContents

attribute to one of the following levels:



Skip:

Do not validate contents.



Lax:

Validate only if you can find acorresponding declaration.



Strict:

Validate against the current schema.

You define wildcards using the<xs:any>

element for elements. The example in Listing 15showsan element named<PersonName>

that has a wildcard where subordinate elementwould bedeclared

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 externalSchema and allow the elements to parse against it, and then set theprocessContent

level tolax

or

skipor

strictdepending 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"/>

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page20

of31

7/11/2013

National Standards Framework

<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 15shows the element declaration to contain a complex type thatcontains a sequence. The sequence contains the<any>

element, which is the wildcard placeholderindicating that any element markup can appear at this location.If

the processing of the contents of thiselement should be skipped, no schema validation is performed on the contents between the start andend tags. Therefore, the entire element can contain any well-formed markup using any element orattribute 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, thatyou

want to use some elements from another schema (Listing 16) in a different namespace 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

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page21

of31

7/11/2013

National Standards Framework

The data instance in Listing 17is 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 inListing 15.

In the example in Listing 17,the element type<PersonName>

is validated normally against theschema

in Listing 15, but the contents of that element,the PersonDemographics elements are checkedonly for presence of corresponding declarationgiven that the process content is set to “lax”. If it wasset to “skip”, even this will be ignored.

Takeparticularcare when you use wildcards if you expect to require validation ortoallow laxvalidationwhen 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, usingwildcards in conjunction with optional or repeatable elements can cause ambiguities and non-deterministic conditions. The simplest use of wildcards withprocessContents="skip"

willallow you to avoid most of this complexity.

4.3.7

XML Schema Extension–

Derive by ExtensionMechanism for Attributes

Similar to what we saw in section4.3.4,W3C XML Schema lets you extend existing type definitionsto add additional attributes

In Listing 19,thePersonName element is extended by adding two additional attributes namely, an‘ID” and “ANY” attribute (wildcard) using extension mechanism. You will also notice that Listing 18is also extended by addinganadditional element called “DateOfBirth” using extension mechanism asexplained in section4.3.4. The “ANY” attribute uses the same concept as described in section4.3.6

for elements. The Process content is set to “lax” for this example. Listing 20 is an instance documentthat validates against the schema in Listing 19.

<?xml version="1.0" encoding="UTF-8"?>

<Party

xmlns:a="http://www.somelocation.com"

xsi:noNamespaceSchemaLocation="OriginalSchema-DeriveByExtension.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 thisdocument

includesan attribute called “Category”whichis from a different namespaceand is ignored during validation.

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page25

of31

7/11/2013

National Standards Framework

4.3.8

XML Schema Extension–

Controlling Code Lists outside of the XML Schema

Acode list

(also calledenumeration) defines a classification scheme and a set of classification valuesto support the scheme. For example, “Administrative Area” for an Address schema is a classificationscheme. 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. Someinformation items in a document are described in the schema lexically as a simple value whereby thevalue is a code representing an agreed-upon semantic concept. The value used is typically chosenfrom a set of unique coded values enumerating related concepts. These sets of coded values aresometimes termedcode lists.

Code Lists are generally embedded in an XML schema and software application code are generatedout of the XML schema, compiled and executed as part of an application. The compiled code includesthe enumeration lists. When changes happen to a code list,the software application code has to berecompiled. This is often an issue for organisations that reuse code lists for many applications, ororganisations that want to add additional value to the standard code list or restrict the values in thestandard code lists. How do we add or restrict the values in the code list without the need to update theXML schema and recompile the software application code that uses the XML schema and thesupporting code lists?

The OASIS Code List Representation format, “Genericode”, is a singleindustrymodel and XMLformat (with a W3C XML Schema) that can encode/standardise

a broad range of code listinformation. The XML format is designed to support interchange or distribution of machine-readablecode 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 Optionuses a “two”pass validation methodology, whereby, the “first” pass validation, allows the XML document instanceto be validated for its structure and well-formedness (ensures that information items are in the correctplaces and are correctly formed) against the entity XML schema, and the “second” pass validationallows the code list values in XML document instance to be validated against the genericode basedcode 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. javaobject must be re-created) based on the entity schema as the entity schema reference the genericodebased code list. A case study involving the use of this approach isathttp://www.oasis-open.org/committees/ciq.

4.4

Extending the XML Schema–

Conclusion

Asshown

bythestrategies discussed above regarding extending XML schemas,the designers of theW3C XML Schema language had extensibility inmind when they created the standard. Take care toobserve 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 youwork with schemas used in distributed and diverse environments.However, the most important aspectis that whatever extensions are done to the base XML Schema, ensure that a governance model is inplace to ensure that parties involved in the data exchange process arekept informed of theseextensions to achieve interoperability of data.

It will be valuable to pay attention to

the emerging XML Schema version 1.1 standard being producedin the W3C XML Schema Working Group.The schema

has some interesting changes to the wildcardsand other constructs that might affect the examples shown here.

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page26

of31

7/11/2013

National Standards Framework

5

General Guidelines for anyproject that implementsAS4590 Standard V2.0

The Australian Government has developed a comprehensive Architecture Framework1

to assist in thedelivery of more consistent and cohesive services to citizens and support cost-effective delivery ofInformation and Communications Technology (ICT) services by government. TheFrameworkdescribes reference models that form the basis of a

common language between agencies and structurea repository of architectural artefacts (including standards, guidelines, designs and solutions). Themodels may

be utilised by agencies to deliver an increasing range of whole-of-government services.

TheFramework contains a set of inter-related ‘reference models’ designed to facilitate cross-agencyanalysis and the identification of duplicate investments, gaps and opportunities for collaborationwithin and across agencies. Collectively, the reference models

comprise a framework for describingimportant elements of the architecture in a common and consistent manner. It is strongly advised thatagencies refer to this work extensively wherever appropriate rather than duplicate or re-invent.

In addition to theabove framework, the following section provides “General” Guidelines for anyproject that intends to implementtheAS4590 Standard V2.0as part of the project. The followingpointscover business process, data,enterprise architecture and application architecture considerationswhile implementing a project involving theAS4590 Standard V2.0

5.1

Business Process Considerations

5.1.1

Business Process Diagrams

Business Process diagramsshould be usedto define the

business processes

that the data exchangepartieswill

use to perform the business function

when exchanging AS4590 data.

5.1.2

XML Transactions

The BusinessProcess diagramscan be used to

define the

XML transactions(e.g. CreatePartyData,SendPartyData, UpdatePartyData) thatwill be exchanged by the

Data exchange partiesneed to identify each data element within each XML transaction that will betransferred. For each data element the data exchange parties need to identify:



thedata 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 correctingdata is an expensive undertaking after it has already been entered into IT systems, and more so afterthe data has propagated to other systems. In orderto improve data quality at the earliest opportunity,ensure that:

1

. Australian Government Architecture Reference Model, V2.0, AGIMO, December 2009

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page27

of31

7/11/2013

National Standards Framework

1.data captured interactively (during online web interactions, a phone conversation, or face to face) isentered into an IT system thatisimmediately validated wherever possible by a setof business rules.For example,

with name and address data, the party can be asked to provide the right data if thevalidation fails during point of data entry.

2.

confirmation ofthe currency and validity of address held on government records at each customercontact is a common practice in customer contact business processes. This ensures ongoing addressdata currency as well as validity, without incurring additional cost.

The effort required for maintaining the currency of data after initial capture needs to be weighedagainst 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 datacollection.

Databases holding client data can be used to store address as perAS4590 Standard

V2.0schema andlogical data model. The physical data model can be mapped to the appropriate database being used.

5.2.3

Physical Forms of the AS4590 V2.0XML Model

Logical Schema

TheAS4590 Standard V2.0logical schema client data is the recommended standard. Its physicalincarnation may take any form, such as an XML document, a COBOL copybook and itscorresponding data file, or a comma-separated data file. However, data model mapping should bespecified when converting to and from another data model.

5.2.4

Current Data Stores

5.2.4.1

Data Cleansing

When upgrading current applications to comply withAS4590 Standard V2.0, it may be necessary toconduct address data cleansing, most notably when:

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 includedin the business case of the application which uses the data.

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page28

of31

7/11/2013

National Standards Framework

5.2.4.2

Run-time Conversion

For non-compliant current data stores, feasibility of using a run-time conversion toAS4590 StandardV2.0

where it suits the transaction processing profile of an interactive application should be evaluatedas 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 inAS4590Standard 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 appropriatefor 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 theAS4590 Standard V2.0during the Request forInformation, Request for Proposal, and Request for Tender processes.

2. Preference should be given to those

offerings

with Australian versions supporting the Australianstandards, specifically the AS4590Semantic

Standard from Standards Australia.

3. The street address data captured by the COTS application must be validated against the designatedstandard for street address data validation (Vicmap Address Dataset or G-NAF).

4. The client data interchange must comply with the requirements stipulated in theAS4590 StandardV2.0.

Where a COTS application does not explicitly support or cannot be easily customised to align withtheAS4590 Standard V2.0, its deployment can result in additional costs (both initial and ongoing) indeveloping appropriate inbound and outbound interfaces. These costs should be included in evaluatingthe package options and the overall business case of the application.

TheAS4590 Standard V2.0consists 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 interfacesinvolving these fields should be designed as per good useability practices.

User interfaces, on-screen and in printed forms, should display thesefields in a pragmatic mannerwith few significant components. Validation and parsing by application logic should ensure thatsupplied addresses

map to and comply

with theAS4590 Standard V2.0

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page29

of31

7/11/2013

National Standards Framework

5.4.2

Reference User Interface Implementation

A re-usable user interface component can be developed that lets the user choose the broad category ofparty 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 aremandatory or not-applicable;

2. Carry out address data validation appropriate for each category; and

3. Return validated client data, compliant withAS4590 Standard V2.0.

Such a component can be made available as a reference implementation for re-use.

It is a common myth that web services provides “loose coupling”. The reason being that certaininterfaces 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 asthis will result in data mapping and transformation process thereby resulting in tight coupling. Toenable 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 partof a web services provides the opportunity for loose coupling.

AS4590XML ModelV2.0: Implementation Guidelines

Version:1.0

Status: Final

Page30

of31

7/11/2013

National Standards Framework

6

Implementation Checklist

Please use

the following implementation checklistas a guidelinewhen planning and implementing theuse ofAS4590 Standard V2.0schemas