Australian Standard 4590

vetinnocentΛογισμικό & κατασκευή λογ/κού

7 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

91 εμφανίσεις






National Standards

Framework


Australian Standard 4590

Client Information Exchange






AS4590
XML Model
V2.0

Implementation Guidelines


Version: 1.0

Status: Final













September
2011













AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
2

of
31

7/11/2013


National Standards Framework

Table of Contents

1
.

1

PROJECT BACKGROUND

................................
................................
................................
......................

4

1.1

P
RE
-
R
EQUISITES

................................
................................
................................
................................
....

4

1.2

I
N
S
COPE

................................
................................
................................
................................
................

4

1.3

O
UT OF
S
COPE

................................
................................
................................
................................
.......

5

1.4

A
PPROACH

................................
................................
................................
................................
.............

5

1.5

P
ARTICIPANTS

................................
................................
................................
................................
........

6

2

WHO SHOULD USE THIS
GUIDE?

................................
................................
................................
........

6

3

DATA EXCHANGE BETWEE
N PARTIES USING AS45
90 STANDARD V2.0


NO
GOVERNANCE, NO INTER
OPERABILITY OF DATA

................................
................................
...............

6

3.1

D
ATA
E
XCHANGE AND
I
NTEROPERABILITY

................................
................................
...........................

6

3.2

I
NFORMATION
E
XCHANGE
A
GREEMENT


G
UIDELINES

................................
................................
.........

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

Principles

................................
................................
................................
................................
.................

9

3.2.5.2

Approach

................................
................................
................................
................................
..................

9

3.2.5.3

Parsing and Validation

................................
................................
................................
...........................

10

3.2.5.4

Sample XML file for testing

................................
................................
................................
..................

10

4

GUIDELINES TO EXTEND

AS4590 STANDARD V2.0

TO
ADDRESS SPECIFIC
REQUIREMENTS

................................
................................
................................
................................
.............

10

4.1

D
EFINE BUSINESS RULES

AT THE RECEIVING APP
LICATION END

................................
...........................

10

4.2

U
SE DOUBLE PASS VALID
ATION TO CONTROL THE

XML

SCHEMA STANDARD FOR
SPECIFIC
REQUIREMENTS

................................
................................
................................
................................
.................

11

4.3

E
XTEND THE
XML

S
CHEMA USING THE LANG
UAGE 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 Extensi
on


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

E
XTENDING THE
XML

S
CHEMA


C
ONCLUSION

................................
................................
..................

25

5

GENERAL GUIDELINES F
OR ANY PROJECT THAT
IMPLEMENTS AS4590 ST
ANDARD V2.0

26

5.1

B
USINESS
P
ROCESS
C
ONSIDERATIONS

................................
................................
................................
.

26

5.1.1

Business Process Diagrams

................................
................................
................................
............

26

5.1.2

XML Transactions

................................
................................
................................
..........................

26

5.1.3

Data Quality

................................
................................
................................
................................
...

26












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
3

of
31

7/11/2013


National Standards Framework

5.1.4

Data Currency and Re
-
validation

................................
................................
................................
...

27

5.2

D
ATA
C
ONSIDERATIONS

................................
................................
................................
......................

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

Data Cleansing

................................
................................
................................
................................
.......

27

5.2.4.2

Run
-
time Conversion

................................
................................
................................
.............................

28

5.3

E
NTERPRISE
A
RCHITECTURE
C
ONSIDERATIONS

................................
................................
...................

28

5.3.1

Interfaces between Applications

................................
................................
................................
.....

28

5.3.2

Commercial Off
-
the
-
Shelf (COTS) Applications

................................
................................
.............

28

5.4

A
PPLICATION
A
RCHITECTURE
C
ONSIDERATIONS

................................
................................
.................

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

30

6.1

A
DMINISTRATIVE

................................
................................
................................
................................
.

30

6.2

D
EFINE
P
ROJECT
R
EQUIREMENTS

................................
................................
................................
........

30

6.3

D
EFINE
T
ECHNICAL
R
EQUIREMENTS
................................
................................
................................
....

30

6.4

D
EFINE
B
USINESS
P
ROCESS
R
EQUIREMENTS

................................
................................
.......................

31

6.5

XML

T
RANSACTION
C
HECKLIST

................................
................................
................................
.........

31

6.6

D
ATA
C
OMMUNICATION CHECKLI
ST

................................
................................
................................
....

31

6.7

A
PPLICATION
C
HECKLIST

................................
................................
................................
....................

31

6.8

O
PERATIONS
C
HECKLIST

................................
................................
................................
.....................

31





















AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
4

of
31

7/11/2013


National Standards Framework

1

Project Background

The
Cross Jurisdictional Chief Information Officer Co
mmittee
(CJCIOC) and the Commonwealth’s
Chief Information Officer C
ommittee
(CIOC) endorsed the technical review of the
AS 4590
S
tandard

V1.0

under the auspices of the National Standards Framework (NSF).

Go
vernment 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 pr
oject 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 stand
ard under the
NSF
. At this meeting the CIOC

also agreed to re
-
convene a
T
echnical Review Group

to assist with the development of an implementation road map.

This phase of the project
included the

development of
:



an

I
mplementation
G
uide for the AS4590
Standard V2.0
;



a
G
overnance
F
ramework for managing the AS4590 Standard V2.0
; and



a

namespace r
egime

This document
’s

focu
s

is

the
I
mplementation
G
uide


1.1

Pre
-
Requisite
s


It is expected that the readers of this document have a good understanding of the follow
ing:



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

T
he 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











AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
5

of
31

7/11/2013


National Standards Framework

model sh
ould be implemented and instead

provides a set of guidelines
,

to

assist agencies
and
jurisdictions to interoperate client information data between them
selves
.

1.3

Out of Scope

The following are outside the scope of this
s
tandard:



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



M
andatory 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 AS
4590 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 th
ese 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 a
n online

c
ollaborative
w
orkspace will reduce the need for a large number of face to face

meetings.

Following are the steps adopted to support this process:



Establishment of

a
n online
c
ollaborative
w
orkspace for the project, including an on line
discussion forum.



A c
all
for
participants from jurisdictions a
nd C
ommonwealth agencies to particip
ate.



Invit
ation to

participants to provide input
in
to the implementation guidelines
.



Creat
ion

of
an implementation guidelines template and publish on the site
.



Holding
face to face meetings
with participants
to discuss the guidelines and
gather

input
.




Produc
tion of

a draft implementation guidelines document
.












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
6

of
31

7/11/2013


National Standards Framework



Publi
cation
of
the draft implementation guidelines document for review by the participants
.



Prepar
ation

and circulat
ion of

a final draft document incorporating input from t
he participants



Manage
men
t 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 pe
r 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 wi
th
external agencies or jurisdictions. The guidelines could be used in any of the following scenarios:



A
ny project within an agency that requires the implementation/reuse of
AS4590 Standard V2.0
including
to exchange client data with other agencies
.



A
ny 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
B
etween
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”












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
7

of
31

7/11/2013


National Standards Framework

It is the view of the CIQ TC that to
enable interoperability of data
be
twee
n 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 interop
erability 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 inform
ation 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
b
e used

as a consistent
baseline for creating exchange documents and transactions within Australian Government
o
rganisations. 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 c
ustom 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/specificati
on should outline in detail the customisation of the AS4590 Standard V2.0.

3.2.1

Conformance Rules

This section summari
s
e
s

the conformance rules that users should implement when using the AS4590
Standard V2.0. These rules are as follows:



Instances

must validat
e 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.












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
8

of
31

7/11/2013


National Standards Framework

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
automat
ed
interoperability of information/data at applicat
ion/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

l
ist of all elements of AS4590 Standard V2.0 XM
L 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 assembl
ing 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 super
set 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 involve
d in the
exchange
.

4.

A
ny

extensions to the default XML schemas
. These

should be clearly defined and agreed.
It
should be determined w
hether 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.

D
etails 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 s
tructured ‘
vs.

unstructured data.
There should be a discussion of whether
the
data to be exchanged is structured or un
structured 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
cod
e.

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 s
uch 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 st
akeholders 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 co
nforming
to the
AS4590
Standard V2.0
. These skills include an understanding of XML file creation, validation and
interpretation processes (a
s well as

likely sources of error or failure)
;

and an understanding of the
logic and semantic meaning of the data el
ements 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
.












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
9

of
31

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 to
represent the data
elements in th
e

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 th
at 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
?’

Second
ly
, it i
s 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

Basic steps to implementing the Sta
ndard

3.2.5.1

Principles

The following principles
should
be followed in implementing this
s
tandard:

Exchanging parties
should
agree, and confirm:



an
interpretation of
the
AS4590 Standard V2.0
and implementation considerations
;



to use

the latest specification avail
able (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



a
ny

adjustment
to

the

AS4590 Standard V2.0
f
ile exchange implementation as and when
necessary.

3.2.5.2

Approach

Regardless of the extent to which implementation of this
s
tandard is automated by agencies, an
appropriate data
-
sharing agreement and adequate software programming logic will be required. There
a
re 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
.












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
10

of
31

7/11/2013


National Standards Framework



Interpreting an XML file that came from an outside agency by using XPath to navigate the
structure of th
e 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
:
b
efore exchange, XML files should be parsed by the sending party
,
without error
,

using a parser agreed by the receiving party
. H
owever, 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
t
esting

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 Standar
d 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

implement
ing

their own standard or customis
ing

the

existing
standard
.

One of the key reasons for
the
lack of uptake of
the
AS4590 Standard V
1
.0
is
that the standard did not

meet the requirements of agencies.
The design of the
standard

addresses this issue.

T
he 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 t
he 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
b
usiness
r
ules at the receiving applic
ation 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 applic
ation 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
veri
fication of data, etc. This may require coding of the business rules in a programming language that
is compl
ia
nt with the environment.
In
this way, the exchanged payload is compliant with the standard.












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
11

of
31

7/11/2013


National Standards Framework

4.2

Use double pass validation to control the XML schema s
tandard for
specific requirements

Schem
as

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 constraint
s

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

is
the

second pass of a two
-
pass validation strategy
.

T
he “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
.

T
he

second pass”
can be

accomplished with a transformation
language such as a W3C XSLT 1.0 stylesheet or a Python prog
ram

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 expres
s 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
S
chematron, one can place constraints on the XML schemas without being non
-
compliant.

A good
case study on using
S
chematron 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












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
12

of
31

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 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 informa
tion
.
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/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. 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, th
ereb
y 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
"/>












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
13

of
31

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.


<?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 a
dd 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
">












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
14

of
31

7/11/2013


National Standards Framework


<
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 fi
gure 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"?>












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
15

of
31

7/11/2013


National Standards Framework

<
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 w
as

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


I
mport”
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
optimi
s
ing 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 erro
rs 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
exten
sion of

existing type definitions to add additional sub
-
elements, to the data model's structure.
E
xtensions
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
















AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
16

of
31

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 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
PersonName
Type

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
PersonName
Type

(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
<DateOfBir
th
>

is added

to the
PersonName
Type

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












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
17

of
31

7/11/2013


National Standards Framework

T
he
<Party
>

element defined in Listing 8
uses the
PersonNamePlusDOB
, which has been
defined to include all the sub
-
elements from its base type
PersonName
Type

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 sc
hema that defines a
Complex
Type

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


















AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
18

of
31

7/11/2013


National Standards Framework

Listing 10 is shown in the figure below:


The
PersonName
Type

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 an
d redefines it with the code in Listing 14.

<?xml version="1.0"?>

<
xsd:schema

xmlns:xsd
="
http://www.w3.org/2001/XMLSchema
"

elementFormDefault
="
qualifi
ed
"

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
PersonName
Type

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
.


















AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
19

of
31

7/11/2013


National Standards Framework

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 elem
ents
. The ex
ample in Listing 15
shows
an element named
<PersonName
>

that has a wild
card where subordinate element
would be
de
clared

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
-
forme
d 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
"/>












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
20

of
31

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 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 o
f 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 par
t 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















AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
21

of
31

7/11/2013


National Standards Framework

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 a
lternative 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 non
-
deterministic conditions. The sim
plest use of wildcards with
processContents="skip"

will
allow you to avoid most of this complexity.

4.3.7

XML Schema Extension


Derive by Extension
M
echanism for Attributes

Similar to what we saw in section
4.3.4
,
W3C XML Schema lets you extend existing type definition
s
to add additional attributes

to the data model's structure. You can apply extens
ions to the types of
attributes.
Let us
use
the XML Schema in Listing 18
to demonstrate this. Listing 19 extends Listing 1.
























AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
22

of
31

7/11/2013


National Standards Framework

<?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:






























AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
23

of
31

7/11/2013


National Standards Framework

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























AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
24

of
31

7/11/2013


National Standards Framework

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 ex
tension 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
="
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 this
document

includes
an attribute called “Category”
which
is from a different namespace
and is ignored during validation.














AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
25

of
31

7/11/2013


National Standards Framework

4.3.8

XML Schema Extension


Controlling Code Lists outside of the X
ML 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 le
xically 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 list
s.

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 co
de 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, “
G
eneri
code
”, 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) again
st 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 l
ist 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.oasis
-
open.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 sc
hemas 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 w
ildcards
and other constructs that might affect the examples shown here.












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
26

of
31

7/11/2013


National Standards Framework


5

General Guidelines for any
p
roject that implements
AS4590 Standard V2.0

The Australian Government has developed a comprehensive Architecture Framework
1

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
F
ramework
describes reference models that form the basis of a

common language between agencies and structure
a repository of architectural art
e
facts (including standards, guidelines, designs and solutions)
. The
models may

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

The
F
r
amework 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. T
he following
points
cover business process, data,
e
nterprise architecture and application archi
tecture 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 process
es

that the data exchange
parties
will

use to perform the business function

when exchanging AS4590 data
.

5.1.2

XML Transactions

T
he 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 da
ta element the data exchange partie
s n
eed to identify:



t
he
data format of the data element;



i
f the data element is mandatory, optional, or forbidden
;




p
ossible default values for the data element if absent
; and




r
elationships 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












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
27

of
31

7/11/2013


National Standards Framework

1.
d
ata 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 cust
omer
contact is a common practice in customer contact business process
es
. This ensures ongoing address
data currency as well as validity, without incurring additional cost.

5.1.4

Data Currency and Re
-
v
alidation

Once acquired and recorded d
ata in an IT system can

become out of date due to:



t
he data no longer being valid

(e
g.
a

person or organisation has moved to another address
); or



i
nfrequent changes to data (e.g. occasional changes to street numbers, names and/or suburb
boundaries).

The effort required for mai
ntaining 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 fac
tored 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 w
hen 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 with
AS4590 Standard V2.0
, it may be necessary to
conduct address data cleansing, most notably when:



t
he data model (format, semantics and validity) of existing client data deviates substantially from
AS4590 Standard V2.0
;

and/or



t
he existing client data has not been validated (e.g. against a reference address file, say PAF)

Costs for utili
s
ing client dat
a (and in particular address data) that require cleansing should be included
in the business case of the application which uses the data.












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
28

of
31

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 to
AS4590 Stan
dard
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:



p
rovides maximum semantic compatibility between interfacing systems
;



e
liminates effort required in sema
ntic mapping, and



i
ncludes 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 follow
ing principles shou
ld

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 Austral
ian 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 vali
dation (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
AS459
0 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 appli
cation.

5.4

Application Architecture Considerations

5.4.1

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.
T
hese 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 address
es

map to and compl
y

with the
AS4590 Standard V2.0












AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
29

of
31

7/11/2013


National Standards Framework

5.4.2

Reference User Interface Implementation

A re
-
usable user inter
face 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 dat
a
-
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 m
ade 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 lo
gical 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 D
iverse 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 develo
ped due to
semantic mismatch
; or


2.
F
ormat 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 cer
tain
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 transformati
on 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
o
f a web services provides the opportunity for loose coupling
.

















AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
30

of
31

7/11/2013


National Standards Framework

6

Implementation Checklist

Please use

the following implementation checklist
as a guideline
when planning and implementing the
use of
AS4590 Standard V2.0
s
chemas

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

6.2

Define Project Requirements



Define business process and transaction requirements
.




Define error
-
processing requirements
.




Define problem resolution requirements
.




Define security requirements
.



Confident
iality
.




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













AS4590
XML Model
V2.0: Implementation Guidelines


Version:1.0

Status: Final



Page
31

of
31

7/11/2013


National Standards Framework

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 addre
sses/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, unpackagi
ng 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
.