Skip to content.
|Networking government in New Zealand.

7 Relational models (referencing)

It is not always efficient to transfer the entire name and address information, particularly in cases where some parts of the addresses are being repeated. An example would be a batch of data about a block of flats. Normally, the information source would repeat city and street information for every flat. The only difference would be the premise number. xNAL offers a simple solution to this issue.

7.1 xAL referencing through the AddressDetailsKey attribute

The AddressDetails element has an AddressDetailsKey attribute of type GUID (128-bit Global Unique Identifier) that serves as a unique key to a particular AddressDetails element. Some other elements under AddressDetails have an AddressDetailsKeyRef attribute that is also of type GUID, but serves as a pointer to a particular AddressDetails element.

As an example for a block of flats (as mentioned in the introduction to this section), the solution would be as follows.

First we specify the repeatable part and assign a key to it.

The example above utilises the AddressDetailsKeyRef attribute that points to a particular AddressDetails element. The processing rule dictates that the referencing element should be replaced with the matching element, which is a child of the referenced AddressDetails element.

For example,

should be replaced with

during the processing.

There is no reinforcement of referential integrity in the schema that allows referencing elements that reside outside of the document. It is up to the processing application to locate the referenced elements.

7.2 xAL Referencing through the ComplementWith attribute

Another example utilises the ComplementWith attribute of the AddressDetails element. This attribute also references other AddressDetails elements, but the mechanism is somewhat different from the previous example:

This example illustrates the use of the ComplementWith attribute.

The attribute points to another AddressDetails element with the following processing rules:

  • All direct child elements of the referenced AddressDetails elements, which are not present in the referencing element, are being inserted into their respective places as children of the referencing AddressDetails element.
  • No child element of the referencing AddressDetails element is being replaced or modified if already present.
  • Attribute nodes of the referencing AddressDetails element remain unaffected—nothing is either inserted, or replaced, and no values are modified. The insertion affects only child element nodes.

An example of the address after parsing follows:

The elements in blue were inserted into the referencing AddressDetails element.

7.3 xNL Referencing

xNL has a similar referencing mechanism to xAL.

The NameDetails element has an attribute NameDetailsKey which serves as a primary key and can be referenced from other elements. Some other elements have the attribute NameDetailsKeyRef that actually references a NameDetails element. The NameDetailsKey and NameDetailsKeyRef attributes are of type GUID, similar to AddressDetailsKey and AddressDetailsKeyRef. Also, NameDetailsKey can be seen as a primary key and NameDetailsKeyRef as a foreign key.

An example of using referencing in xNL may be a situation when names are stored in a relational database as individual records and need to be assembled into xNL structures to describe complex names, as per the following example:

In this example the code in blue is a person name that is assembled from other NameDetails elements via referencing.

7.4 Referencing rules

There are a number of referencing rules that should be followed by processing applications:

  • The referenced structure must be of the same type as the referencing structure. For example, if the referencing structure is of type PersonName the referenced structure should be of the PersonName type too.
  • If an element references another NameDetails element, the referencing element should contain no other nodes except the NameDetailsKeyRef attribute.
  • If the referenced NameDetails element contains other child structures that cannot be part of the referencing structure, then those child structures should be ignored. For example, the NameDetails/PersonName/FormerName element references another NameDetails element that contains PersonName with FormerName elements. In this case the referencing FormerName element takes its contents from PersonName children that would be valid children of the FormerName element. FormerName elements that are children of the referenced PersonName element are being ignored.
    See the decision table below for a more detailed explanation.

7.4.1 Combining referencing elements

The following table provides all possible combinations for referencing and merging Name, FormerName, and OtherName structures.

Referencing element
Contents of the referenced NameDetails element

N'

FN'

ON'

N'+FN'

N'+ON'

N'+FN'+ON'

N

N:=N'

N:=FN'

N:=ON'

N:=N'+FN'

N:=N'+ON'

N:=N'+FN'+ON'

FN

FN:=N'

FN:=FN'

FN:=ON'

FN:=N'

FN:=N'

FN:=N'

ON

ON:=N'

ON:=FN'

ON:=ON'

ON:=N'

ON:=N'

ON:=N'

In this table,

  • N = PersonName or OrganisationName
  • FN = FormerName
  • ON = OtherName.

The SubdivisionName element may only exist as a direct child of OrganisationName element and should be ignored when the OrganisationName element is referenced from FormerName or OtherName elements.

The greyed-out cell is an example where a Name element (N) with no descendant FormerName or OtherName elements references another Name element with a descendant FormerName element (N'+FN')—the resulting element will be the referenced Name element with a descendant FormerName element (N'+FN'). This is signified with N:=N'+FN' notation.

7.5 Cross-referencing

NOTE

This section is open for discussion and may change during future work to be planned on an NZ xNAL API.

It is a valid scenario when one element references another element that references a third element and so on. It may lead to a loop of cross-referencing that cannot be resolved or be too complex to handle with some acceptable certainty.

Referencing must be resolved only down to one level, so that the reference to the third element does not need to be resolved. This rule applies to an open exchange of name or address data between parties. However, it is up to the implementers to apply this rule within their system boundaries.

7.6 Direct element referencing versus ComplementWith

This section discusses possible applications of the referencing options; it is completely informative. It is up to the implementers of this standard to reach agreement on how to apply the referencing in every particular situation.

Scenario 1: referencing individual address elements

Three databases:

1. address elements such as administrative areas, cities, suburbs and streets

2. names

3. names linked with addresses, by providing the full address for the name, but referencing the address elements to avoid redundancy.

The third database is likely to use AddressDetailsKeyRef and reference individual address elements in the first database, as described in the first example in 7.1, xAL referencing through the AddressDetailsKey attribute.

Scenario 2: referencing individual addresses

Three databases:

1. complete addresses

2. names

3. names linked to addresses in database #1.

The third database is likely to use AddressDetailsKeyRef and reference individual addresses in the first database, as described in 7.1, xAL referencing through the AddressDetailsKey attribute.

Scenario 3: referencing individual incomplete addresses for merger

Three databases:

1. some incomplete addresses, such as a combination of city and suburb names

2. names

3. names linked to addresses, through providing a street name and number with the flat number and referencing an incomplete address in database #1.

The third database is likely to use ComplementWith and reference individual incomplete addresses in database #1 for merger, as described in the second example in 7.2, xAL Referencing through the ComplementWith attribute.

Scenario 4: referencing in xNAL

The following xAL infoset is an example of an address with an identifier:

In the following example, the xAL infoset from above is being referenced from three different Record xNAL elements, to demonstrate that the address remains the same, but its use and type changes.

First, the address was occupied by Mr Nic Peterson from 04/02/2001 to 07/01/2003 as residential. Then Mr James Bond took it over from 07/01/2003 and also began to use it as an address for his Bond Inc business from 15/05/2003.

There is no actual repetition of the address—only a reference. The address remains the same and resides separately from the names of its occupants.


[ Previous | Next ]