.@BookNet_Canada shares @EDItEUR_org's lists of common ONIX issues data providers & data recipients face.
CLICK TO TWEET

In April 2020, Graham Bell, Executive Director of EDItEUR, posted a list of the top 12 ONIX issues that cause the most problems for data recipients (PDF). In December 2021, he created a second list focused on the 12 issues faced by data senders (PDF). These lists are easy-to-use, well-explained entry points to ONIX Best Practice (which is supported by its own documentation). They’re great for the publishing supply chain to consider while they marshal their metadata resources and needs as they create and consume business information.

Both 12 ONIX issues documents are published as “Application Notes” for the ONIX 3.0 Specification, they include a full and readable explanation, and are available with other Notes on the EDItEUR website.

They were also featured in the ONIX implementation group — a mailing list that includes announcements and discussions on ONIX that you really do want to follow. Join the group.

Here are Graham’s lists, in ascending order

TWELVE
Problem for ONIX recipients: Sender putting data into an inappropriate field
Problem for ONIX senders: Recipient requirements omitting certain data fields

ELEVEN

Problem for ONIX recipients: Sender including invalid characters or using the wrong character encoding
Problem for ONIX senders: Recipient ignoring key data that is provided correctly

TEN

Problem for ONIX recipients: Sender using terms like “N/A” rather than omitting fields
Problem for ONIX senders: Recipient ignoring repeats of common composites

NINE

Problem for ONIX recipients: Sender using CDATA sections (i.e., using <![CDATA[ … ]]> when it isn’t necessary)
Problem for ONIX senders: Recipient reading only one <ProductSupply> (market) or only one <Price>

EIGHT

Problem for ONIX recipients: Sender providing “horrendous” HTML tagging
Problem for ONIX senders: Recipient requiring use of non-standard codes, or worse, non-standard fields… (or to add specific “codewords” into particular fields, often in order to support some business process or sales model)

SEVEN

Problem for ONIX recipients: Sender trying to format text using spaces, tabs, returns
Problem for ONIX senders: Recipient “We support only the following codes” AKA '“data submission guidelines”

SIX

Problem for ONIX recipients: Sender sending the wrong Notification type
Problem for ONIX senders: Recipient not using “statement” fields like contributor statement and “rolling their own” display fields algorithmically

FIVE

Problem for ONIX recipients: Sender using codes exclusive to a different version of ONIX
Problem for ONIX senders: Recipient failing to process updates, or a tendency to stop updates at some point in the lifecycle

FOUR

Problem for ONIX recipients: Sender failing to ensure the <RecordReference> is unique and does not change
Problem for ONIX senders: Recipient creating “author pages” by matching names and not making use of publisher IDs or ISNIs

THREE

Problem for ONIX recipients: Sender sending prices without an associated territory
Problem for ONIX senders: Recipient online retailers failing to display mandatory safety information

TWO

Problem for ONIX recipients: Sender using inappropriate or unrealistic audience age ranges
Problem for ONIX senders: Recipient lacking transparency, consistency, and feedback

And finally the number ONE problem

For ONIX recipients: Sender sending ONIX that doesn’t validate using the XSD schema
For ONIX senders: Recipient still demanding ONIX 2.1*

Learn more

Read the complete documents below

* Yes, BookNet Canada’s data aggregation service BiblioShare and its client services (including CataList) still require 2.1. We need to look no farther than a mirror.