Guidelines for designing new naxps

A naxp and, in particular, its encoded values are likely to end up embedded in lots of places, which means picking a definition is a long-lived decision.

The guidelines on this page are to help you get it right first time.

Pick one encoding

Do not use naxps that produce different encodings for the same thing – this is asking for trouble.

If there is a standard naxp then use it.

If you are contemplating changing a naxp, e.g. to tolerate different but equivalent text, then test whether it preserves previous encodings.

Don’t go overboard on fault tolerance

It can be tempting to build fault tolerance into a naxp, but this is best limited to forms widely regarded as legitimate and therefore likely to be encountered in data transfer. Separators in postcodes and leading zeros fall into this category.

Example: Royal Mail officially mandates a space between the outward and inward parts of a UK postcode, but postcodes are (notoriously) stored in a variety of conflicting text formats, of which simply stripping spaces is the simplest. So it’s reasonable to adjust the standard form \A\A?\9\X? \s \9\A\A to tolerate a missing space, while retaining the version with the space as the canonical form, i.e. \A\A?\9\X? \s!! \9\A\A.

Don’t hard-code restrictions that may later be relaxed

When designing a naxp it is tempting to incorporate all the current restrictions on the text patterns in pursuit of stronger validation. But, when a naxp relates to something that can grow, history shows that complex restrictions have a tendency to be removed over time in order to increase capacity. And in such cases, the codes typically require separate validation against a database and so the supposed strong validation benefit is illusory.

Example: The Netherlands’ original 1977 postcode format strictly excluded the letters FIOQUY – an engineering decision to aid character recognition. But in 2005 that exclusion was dropped and new postcodes started to be issued using the previously banned letters, resulting in a lot of software validation failures.

So, unless you are absolutely sure that the specification is fixed for all time, prefer simpler naxps with fewer restrictions, because they are

• robust to future relaxation of standards, and
• less error prone.

Consider the storage required

Sometimes naxp design choices have a material impact on the storage required for the encoded value. This matters because only a few numerical types are universally available and robust to exchange.

The important thresholds to consider are:

• up to 31 bits means a signed integer can be used, and
• up to 53 bits means a double precision floating point number can be used – this is often the safe upper limit, e.g. in MS Excel, JavaScript and R.

This guidance can be in tension with the above guidance to avoid over-engineered naxps, so judgement can be required.

Example: The ‘unique identifier’ part of an Eircode (Ireland’s postcode) is four alphanumeric characters. Encoding this as \X{4} would mean that an Eircode would require 33 bits, forcing the use of 64‑bit storage. The official specification actually restricts the letters to only fifteen. Incorporating this by instead using [\9AC-FHKNPRTV-Y]{4} reduces the storage so that it fits in a standard 31‑bit signed integer. The legitimate concern that these restrictions may be lifted in the future is mitigated by the built-in massive headroom for expansion – the postcodes in use comprise less than 0.5% of those available.

Including leading zeros may help with sorting

If encoded values are required to sort in the same order as the numbers they contain then include leading zeros in the canonical form.

Example: #[001-999] and #[0!0!1-999] sort numerically, e.g. 001 < 003 < 020. In contrast, #[1-999] and #[0?0?1-999] do not, e.g. 1 < 20 < 3.

Don’t use naxps for pure numbers

If a code relates to a pure numerical mapping then a naxp may add little and there may be better tools already in place. Bear in mind also that naxps reserve 0 for invalid text, which may not be a good fit for your use case.

Examples of pure numerical mappings are decimal numbers, hexadecimal numbers, Base64 and Unicode code points.

Before using a naxp for purely numerical text consider whether a standard parsing approach might be more appropriate.

Use whitespace for clarity

Ordinary whitespace carries no meaning (\s is the only thing that means a space), and a naxp with space between its components is far easier to review than the same expression run together. So use whitespace for clarity.