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.
Sneak a peek at buying and borrowing numbers for Canadian titles to see how that has evolved over the last five years.