You are here: Home » Standards » Interoperability (e-GIF) » Extensible Name and Address Mark-up Language (xNAL) » Frequently Asked Questions

Frequently Asked Questions

This page lists Frequently Asked Questions. It also outlines agencies' experiences and ideas from current implementations of the standard.

If you have any feedback about this page or its contents, email us on e-gif@ssc.govt.nz.

Step A: Download and thoroughly read the NZ XNAL Guidelines:
Step B: Download and read the documentation or xNAL international from OASIS at http://www.oasis-open.org/committees/ciq/Downloads/ciq_pdf_docs.zip.

This will give you the background on the xNL, xAL and xNAL structure, element name definitions and so on.

Material already published at these links above will not be repeated here.

Why xNAL?

Name and address data is a key component of most information exchanged by agencies under the information matching agreement, overseen by the Office of the Privacy Commissioner.

xNAL allows for standardisation of key sets of data like names and addresses. No translation of that data is required. Standardising the structure removes one of the major obstacles to seamless data flow between various agencies.

xNAL will become a key component in future e-services - enabling on-line delivery of government services. Examples might include: services associated with going overseas (passports, visas, travel advice), paying a parking fine, registering your dog, enrolling to study, changing your address.

We need xNAL because some online services, like paying fines and going overseas, need several agencies to work together so that New Zealanders do not have to contact multiple agencies in order to complete one service. These agencies need a common format to transfer name and address information entered online; both internally and externally.

xNAL needs to be taken in context with other related standards. xNAL consists of xNL (eXtensible Name Language) and xAL (eXtensible Address Language), siblings of xCIL (eXtensible Customer Information Language) from the OASIS standards group CIQ (Customer Information Quality)

How do I get started on xNAL?

Read all the documentation shown above. Review your existing databases holding name and address details. Are there duplicates? If so, begin a project to cleanse and de-duplicate entries. No receiving agency will thank you for sending them poor quality data. Check the structure of your data. Many agencies have "name" all in a single free text field including title, first name middle name and last name. To exchange data in xNAL the data needs to be parsed into xNAL as much as possible.

Is there a list of NZ xNAL element names I can check my database against?

Yes. Download the spreadsheet here Excel [111 KB].

Where do I get a parser?

Open source parsers can be found at http://xml.apache.org/.

How do I convert my existing database to xNAL?

Try using Altova MapForce for assisting in moving data from existing databases to xNAL.

Note: Best Practice in New Zealand is that if your XML File has ONLY xNL, XAL, xNAL element names, then download and use the relevant NZ xNL, xAL, xNAL schema to parse the file. If the XML file you are sending includes non xNL, xAL, xNAL element names (e.g includes proprietary data fields from your database) then you should send a schema file along with your XML file to the receiver to show them how you have composed the file.

What is my agency's position if the data we receive from another agency is using the fields NameLine and AddressLine to send unparsed data (name or address data in a single free text line)?

It depends on the structure of your database. If it is also unstructured then you can agree to this. But the Guidelines state that you are under no obligation to do so. It is the responsibility of the sender to parse the data into xNAL. Continual use of the these fields to send unparsed data defeats the object of interoperability and incurs extra resource in mapping the received data into a state that your database and applications can process.

What is the difference between NZ xNAL and xNAL international?

A spreadsheet outlining the differences can be found here Excel [120 KB]

I am planning a project that includes exchanging name and address data. What should I do?

In addition to getting started you should bring together all parties you expect to transfer name and address data with. This group should agree and document (in the form of a working Memorandum of Understanding) the use of optional element names, optional attributes and the agreed parser, amongst other things.

I have both name and address AND proprietary data to exchange. What do I do?

Ensure the receiving party knows this and understands what the proprietary element names are and what data they contain. Then encode the XML file so that the xNAL data is separate from the proprietary data in the record. If elements from varying schema are mixed up, more parsing work will be generated for the receiver of that data.

I have additional customer information, such as gender, phone number, email address and so on which is regularly required to be exchanged. What should I do?

While these can be put into the optional placeholders for elements within xNAL, regular exchange of this data would be better served by using xCIL (eXtensible Customer Information Language). xCIL is not yet in the New Zealand e-GIF but early consideration is underway. Ministry of Social Development, Accident Compensation Commission, Inland Revenue Department and New Zealand Qualifications Authority have all expressed an interest in the xCIL standard. xCIL is the parent of xNAL. Documentation on xCIL can be downloaded from the OASIS website.

I do not have data for all the xNAL element names. What do I do?

Do not include element names that have no data for them in your XML file. Including element names holding no data needlessly increases the size of the file.

I regularly exchange name and address details under an information matching agreement. But the file is very large! What do I do?

It is true that the structured nature of XML files makes them larger than files such as comma separated files. However, because the structure inherent in an XML file increases the ease with which both humans and computers process them, the larger file size is offset by the benefits accruing. However, to reduce large file sizes consider:

Zip or Tar the files before sending.
Break the file into smaller chunks and send over a longer period.
Consider using Web Services to dynamically update the recipient's applications in real time.