As an international standard, one might think that exchanging ONIX with a third party is a simple matter of generating the standard ONIX format for your products, and sending it to them in a big file.

However, in practice there are a number of confounding factors which mean that systems usually need to provide a custom feed for almost every recipient.

ONIX major versions

ONIX comes in two major versions, 2.1 and 3.0/3.1. Version 2.1 was issued in 2003, and version 3.0 was issued in 2009 (3.1 is almost identical to 3.0).

2.1 is entrely inadequate for modern publishing purposes as it lacks a number of critical capabilities. Despite this, 2.1 is still required by some third parties, in particular print distributors, so Consonance supports the generation of both 2.1 and 3.0/3.1 from the same data.

ONIX minor versions

ONIX minor versions, such as 3.0.8, are in theory entirely backwards compatible with earlier versions. An ONIX recipient who can accept 3.0.6 should be able to accept 3.0.8 and ignore any new features that have been added to the standard.

In practice, some recipients systems cannot accept later minor versions, so Consonance allows an ONIX feed to be limited to particular minor versions. This generally removes some metadata from the file.

ONIX codelist versions

A major characteristics of ONIX is its use of standard codes to express particular publishing concepts. For example the product form code BC means paperback book. This removes ambiguity from the standard, so publishers own terminology or language is not an impediment to communication.

As the publishing environment continually changes, new codes are added to express newly important concepts, such as accessibility features for ebooks, or to allow ONIX to carry new types of information, such as deforestation regulation compliance.

These code lists are numbered, with a new edition being assigned a new code, and adoption of new codes often takes some time. It is not unusual for an ONIX recipient to be unable to accept particular new codes immediately, or even after several years.

ONIX short tags and reference names

ONIX messages can be constructed in one of two ways: with human readable reference names, such as A01, or as unreadable but more concise short tags such as A01.

Consonance always generates ONIX initially in reference names format, and can convert complete files to short tags for transmission to recipients who require them.

ONIX character encodings

Character encodings are the way in which the letters, numbers, punctuation, spaces, or graphemes or an electronic message are encoded. An ONIX message is declared to use a particular encoding standard, and commonly UTF-8 (which can represent every Unicode code point, and thus represent almost every written language system) is used.

However it is not uncommon for ONIX to be represented in other character encodings, such as ISO-8859-1. Converting messages between character encodings can be problematic, and lead to ambiguous characters.

ONIX recipient technical limitations

Some ONIX recipients have technical limitations on ONIX files and their contents, and this is a major area in which customisation of file contents is required.

These limitations can include only being able to receive up to a particular number of contributors, or a particular number of related products, or that particular suppliers be included.

Consonance has support for a number of limitations of this sort, and they are generally low-effort to configure or add to the systems capabilities. That doesn’t mean is is not a bit annoying that third parties demand this, of course.

Non-ONIX code version limitations

ONIX includes that capability to send codes that are not defined as part of the ONIX standard, for example BISAC and Thema subject categories, or Creative Commons licenses.

As these code lists evolve, support for the new versions tends to lag by a few months. If you attempt to send newly valid codes to recipients they are likely to reject them.

Consonance generally waits until the major ONIX recipients such as Ingram have announced support for new BISAC codes before allowing their use. Thema codes can usually be added to Consonance before they are adopted by third parties as new codes generally represent additional levels of detail in the subject hierarchy, and if a recipient is known to not accept the new version we will downgrade the Thema categories to an acceptable version before including them in ONIX to that recipient.

ONIX product limitations

Perhaps in an ideal world, a publisher could send a list of all of their products to a third party and the third party could arrange to only read or process those which are of interest.

Third-parties often require that publishers send them only a limited set of products, defined in a variety of ways:

1. By publication date: only products to be published in the next three months or earlier, only products publishing on the date in which the ONIX is sent, etc.
2. By form: only print products, only EPUB ebooks, only PDF ebooks, only MP3-format streamable audiobooks, etc.
3. By imprint.
4. By series.
5. By data quality gates: only when a description, biographical note, and table of contents are present, only when a firm prices is assigned, etc.
6. By license: excluding Open Access., etc
7. By individual product: only these ISBNs.

Some of these constraints are configurable through the interface, but many require intervention on the part of Consonance support, who are able to accomodate almost any restriction that can be logically inferred from the metadata. where the restrictions cannot be inferred from the metadata we can provide a mechanism for you to individually choose the products that are to be sent to a recipient.