Appendices
Appendix A: Glossary of key terms
|
Term
|
Definition
|
|---|---|
|
Zero-to-infinity or one-to-infinity. This terminology is used in schema representation to indicate that an instance can occur from zero (or one) to an infinite number of times. In schema infosets, minimum or maximum occurrences (commonly termed minOccurs and maxOccurs) are written in schema as: minOccurs="0" maxOccurs="unbounded". |
|
|
Attributes |
A qualifier on an XML tag that provides additional information. |
|
DTD |
Documents that specify the valid tags and the valid structure of a document class. |
|
Element |
A unit of XML data, delimited by tags. An XML element can enclose other elements. |
|
Entity |
A distinct, individual item that can be included in an XML document by referencing it. |
|
Extensibility |
The xNAL schemas are extensible. This means that any number of elements from other namespaces may be added to an xNAL document where any element is allowed; and any number of attributes from other namespaces may be added to any element. These places are illustrated in all diagrams as: This extensibility allows the use of xNAL constructs with data or metadata from other namespaces. This data may be from any proprietary namespace or another open standard. All extensions must be consistent with the xNAL standard itself. Refer to xNAL governance documentation (http://www.oasis-open.org/committees/ciq/ciq.html - 4) to find out more information on extending name and address information. |
|
Infoset |
The combination of namespace, attributes and elements of the schema |
|
Name and address data parsing |
A process of walking through the xNAL data and converting it into an application-specific form or just extracting the necessary values. |
|
Name and address data processing |
Any application-specific use of the data; for example, an application uses name and address data to match customer records and print postal labels |
|
Namespace |
A standard that lets you specify a unique label to the set of element names defined by a DTD. A document using that DTD can be included in any other document without having a conflict between element names. The elements defined in your DTD are then uniquely identified so that, for example, the parser can tell when an element called <name> should be interpreted according to your DTD, rather than using the definition for an element called "name" in a different DTD. |
|
Parse |
To analyse or separate input, for example, into more easily processed components. For Example to split a "block" of data in a single data field containing "MrAndrewCliveGolightly" into separate elements under Title, FirstName, MiddleName, LastName. Note that the term is also used anecdotally to describe the process of using natural language content between the tags to try to add meaning to the content by associating elements with the token (a word or number) in the data. NameLine and AddressLine have appropriate examples. |
|
Parser |
A module that reads in XML data from an input source and breaks it up into chunks so that your program knows when it is working with a tag, an attribute, or element data. See example above. A non-validating parser ensures that the XML data is well formed, but does not verify that it is valid. A validating parser ensures that that XML data is well formed AND valid (i.e. conforms to a schema) |
|
Root element |
The outermost element in an XML document. The element that contains all other elements |
|
Schema |
A database-inspired method for specifying constraints on XML documents using an XML-based language. Schemas address deficiencies in DTDs, such as the inability to put constraints on the kinds of data that can occur in a particular field (for example, all numeric). Since schemas are founded on XML, they are hierarchical, so it is easier to create an unambiguous specification, and possible to determine the scope over which a comment is meant to apply. |
|
Tag |
A piece of text that describes a unit of data, or element, in XML. The tag is distinguishable as mark-up, as opposed to data, because it is surrounded by angle brackets (< and >). |
|
Unparsed |
Data that is in a "block" as shown in the parse example and not split by tags or elements |
|
Valid |
A valid XML document, in addition to being well formed, conforms to all the constraints imposed by a DTD. In other words, it does not contain any tags that are not permitted by the DTD, and the order of the tags conforms to the DTD's specifications. |
|
Well-formed |
A well-formed XML document is syntactically correct. It does not have any angle brackets that are not part of tags. In addition, all tags have an ending tag or are themselves self-ending. In addition, in a well-formed document, all tags are fully nested. Knowing that a document is well formed makes it possible to process it. A well-formed document may not be valid however. To determine that, you need a validating parser and a DTD. |
Appendix B: Glossary of acronyms
|
Acronym
|
Definition
|
|---|---|
|
API |
Application Programming Interface - a set of functions that an application or component exposes to external software. Programmers use an API to create software that accesses the functionality of an application or component. |
|
CIQ |
Customer Information Quality |
|
CVL |
Controlled Value/vocabulary/code List |
|
DTD |
Document Type Definition |
|
e-GIF |
E-government Interoperability Framework |
|
EGU |
New Zealand E-government Unit |
|
GML |
Geography Markup Language; refer http://www.opengis.org/specs/ |
|
GUID |
128-bit Global Unique IDentifier |
|
LINZ |
Land Information New Zealand |
|
NZ Post |
New Zealand Post |
|
NZ xNAL |
NZ E-government eXtensible Name and Address Language |
|
OASIS |
Organisation for the Advancement of Structured Information Standards |
|
OASIS xNAL |
eXtensible Name and Address Language developed by OASIS CIQ TC |
|
SOAP |
Simple Object Access Protocol |
|
TC |
OASIS Technical Committee |
|
XAL |
eXtensible Address Language |
|
XCIL |
eXtensible Customer Information Language |
|
XML |
eXtensible Markup Language |
|
XNAL |
eXtensible Name and Address Language |
|
xNAL WG |
NZ E-government xNAL Working Group |
|
xNL |
eXtensible Naming Language |
|
xNL-basic |
eXtensible Naming Language for basic (as opposed to complex or extended) person or organisation names |
|
XSL |
eXtensible Style Language |
|
XSLT |
EXtensible Stylesheet Language Transformation. It is a sub set of XSL suitable for transforming an XML document in one format to an XML document in another format, such as HTML amongst many others including XML. So the output format could, for example be xNAL. |
Appendix C: New Zealand-wide identifiers - discussion for comment
NOTE
This section is informative. It is provided for further discussions. Please direct your comments to e-gif@ssc.govt.nz in the first instance. Thank you.
It is possible to establish a system with New Zealand-wide address identifiers based on xNAL.
Let's say there was a drive to establish a national address file/service. This service would assign identifiers to every address element at every level.
For example: Country has an ID; Admin Areas have IDs; streets have IDs; and so on. A national address file/service would greatly reduce the amount of data transferred between services, reduce mismatches, and speed up processing.
An example of the solution:

Most systems use relational databases to store address information anyway; therefore it is a sensible approach to use New Zealand-wide identifiers in data exchange, providing there is an agreement regarding the identifiers.
Appendix D: xNL-basic schema
This is a specific purpose document and can only be viewed as a PDF [132 KB].
Appendix E: xNL schema
This is a specific purpose document and can only be viewed as a PDF [128 KB].
Appendix F: xAL schema
This is a specific purpose document and can only be viewed as a PDF [252 KB].
Appendix G: xAL formatting
This is a specific purpose document and can only be viewed as a PDF [60 KB].
Appendix H: xNAL schema
This is a specific purpose document and can only be viewed as a PDF [76 KB].
[ Previous ]


.