7. Implementation: Outline Guidance
You are viewing an ARCHIVED version of this document. Please see the latest version here.
7.1 Tools and applications to implement this Standard
Where possible, this Standard uses XML-based open standards and industry specifications such as XLink, XMI, and XSLT. More information on these standards and tools is available from the World Wide Web Consortium (W3C): www.w3c.com.
A range of technical skills is necessary to create valid XML files. These skills include an understanding of the XML file creation, validation and interpretation processes (and likely sources of error or failure), and an understanding of the logic and semantic meaning of the data elements to be included in validated exchange files.
The particular tools and applications required to use this Standard
are:
- the data dictionary for the local database, available from the database administrator
- XML parser software, either open source or provided by the commercial vendor
- OASIS CIQ v3.0 Specifications documentation, available from www.oasis-open.org
- the CIQ v3.0 Specifications files, available from
www.oasis-open.org:
- xNL.xsd Name Elements
- xNL-types.xsd Name Elements Enumeration Lists
- xAL.xsd Address Elements
- xAL-types.xsd Address Elements Enumeration Lists
- xPIL.xsd Party Elements
- xPIL-types.xsd Party Elements Enumeration Lists
- xPRL.xsd Types of relationship container elements
- xNAL.xsd Name and Address Elements (Record)
- xLink.xsd Types of linkage connectors.
7.2 Implementation considerations
A range of considerations and decisions needs to be made when preparing validated exchange files to represent the identity-related data elements in this Standard. 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 this Standard's identity-related data elements to the fields that are stored and managed in agency databases. Database administrators should be able to assist with this mapping. The question to answer is: "Which fields in our agency database correspond to the identity-related data elements in the Standard?"
Secondly, it is important to remember that different sets of identity-related data elements may be required for different services. The question to answer is: "What data elements do I need for my services?"
Finally, the implementation "rules" laid out in this Standard will need to be interpreted to 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 CIQ v3.0 Specifications.
7.3 Basic steps to implementing the Standard
7.3.1 Principles
The following principles should be followed in implementing this
Standard:
- Exchanging parties should engage, agree and confirm:
- their interpretation of this Standard and implementation considerations
- reference to the latest CIQ v3.0 Specifications available (in order to avoid the generation of a separate schema requiring future maintenance and synchronisation with CIQ v3.0)
- any additional exchange rules specific to the exchange (a draft data exchange checklist is available from e-GIF operations, State Services Commission (contact details on page 9))
- any adjustment in the parties' file exchange implementation as and when necessary.
- Inclusion of all these identity-related data elements in the exchange file is not mandatory. For example, place of birth may not be available and so would be left blank in the exchange file.
7.3.2 Approach
Regardless of the extent to which implementation of this Standard is
automated by agencies, an appropriate data-sharing agreement and
adequate software programming logic will be required. There are three
phases to implementing the Standard:
- Creating a valid XML file for transmission to another agency by building an application that follows the rules of CIQ v3.0 Specifications
- Checking the XML file for validity against the latest CIQ v3.0 Specifications using a fit-for-purpose XML editing and parsing tool. Processing logic applications should be programmed to ignore empty elements
- Interpreting an XML file that came from an outside agency by using XPath to navigate the structure of the validated exchange file.
7.3.3 Parsing and validating
The parsing process helps ensure that the structure of the XML file
is well-formed and validated (i.e. that any elements required by the
IVS to be present are, in fact, present and in the correct order) and
that the file conforms to the agreed (ideally latest) parent CIQ v3.0
Specification and XPath statements. The current applicable XPath
statements at the time of writing are shown in Appendix D. Therefore,
the following principle applies:
- Before exchange, XML files MUST be parsed by the sending party without error using a parser agreed by the receiving party.
7.4 Sample files and navigation or interpretation tools
The sample validated exchange file in Appendix E illustrates appropriate places to accommodate the identity-related data elements defined in this Standard. The CIQ v3.0 Specifications (current at the time of writing) were used to create the sample validated exchange file. For the first stage of creating a valid XML file, a fit-for-purpose editing and parsing tool is used to edit and validate the contents. For the CIQ v3.0 particulars, including the valid metadata tag names and the order of the elements, the CIQ v3.0 Specifications serve as the filter to create a structurally valid XML file.
From the experience in creating the sample validated exchange file, it is possible to create the following summary of rules regarding hierarchy and order of elements, from the CIQ v3.0 Specifications:
<Party> is a container element and the outermost
element
<PartyName> is the first element container;
<PersonName> is a member of
<PartyName>
<PersonInfo> is the second element container
<BirthInfo> is a member of
<PersonInfo>
<BirthInfoElement> is a member of
<BirthInfo>
<BirthPlace> is a member of
<BirthInfoElement>
</Party> is the closing element for the file and
matches the outermost element.
Appendix E contains a sample validated exchange file. Appendix D sets out sample programmatic navigation paths for the sample validated exchange file in Appendix E.