Font Size:

ONIX

FAQs

General

Release 3.0

Schemas and validation

Implementation

General

What is ONIX?

ONIX stands for ONline Information eXchange; it is an XML-based family of international standards intended to support computer-to-computer communication between parties involved in creating, distributing, licensing or otherwise making available intellectual property in published form, whether physical or digital.

What is ONIX for Books?

ONIX for Books was the first, and is the most widely-adopted, member of EDItEUR’s ONIX family of standards. The first release of ONIX for Books was published in 2000. The most recent release (Release 3.0) was published in 2009. ONIX for Books is now firmly established around the world as the book trade standard for the communication of “rich product metadata” – the type of metadata that is needed to support the sale of books in the supply chain, not least for online retailing.

Who is responsible for ONIX for Books international standards?

ONIX for Books was originally developed jointly by the Association of American Publishers and EDItEUR, and subsequently in collaboration with the Book Industry Study Group (BISG) in the US, and Book Industry Communication (BIC) in the UK. It is now managed by an International Steering Committee with representatives of user groups in 15 countries: Australia, Belgium, Canada, Finland, France, Germany, Italy, the Netherlands, Norway, Russia, Spain, Sweden and the Republic of Korea, as well as BISG and BIC.

Are ONIX for Books standards only used for “books”?

Although the format is invariably referred to as ONIX for Books, it has always covered other media and other products produced by book publishers and distributed through the book supply chain. In particular, Release 3.0 has improved the capabilities of ONIX with respect to the management of information about “ebooks” and other digital products.

What are the benefits of adopting ONIX for Books standards?

For publishers, experience has shown that ONIX for Books brings two important business benefits. As a communications format, it makes it possible to deliver rich product information into the supply chain in a standard form, to wholesalers and distributors, to larger retailers, to data aggregators, and to affiliate companies. And by providing a template for the content and structure of a product record, ONIX has helped to stimulate the introduction of better internal information systems, capable of bringing together all the “metadata” needed for the description and promotion of new and backlist titles. The same core data can also be used to produce advance information sheets, catalogues and other promotional material.

For “downstream” supply chain partners, ONIX for Books means that they can speed up the loading of up-to-date product information into customer-facing systems, with less need for manual intervention and much lower risk of error.

Release 3.0

What is ONIX for Books 3.0?

It is a major new release of the ONIX for Books product information format for book publishers and other players in the book supply chain. It is the first major release since 2001 (when ONIX for Books 2.0 was released), and is the first release in which digital products have been treated as a “core” element in ONIX coverage. It is the first release for eight years which is not backwards-compatible with previous releases.

Why has EDItEUR decided that the time is right for a new release?

The International Steering Committee took the decision that the time had come to move to a new release for two main reasons. The first was the need to improve the handling of digital products; the second was the recognition that the price of maintaining backwards-compatibility was the increasing number of “deprecated” elements which have had to be retained – and supported by ONIX receivers – even though they are no longer recommended for use. ONIX for Books 3.0 deletes all “deprecated” elements, as well as others that are now redundant as a result of other changes in the new release. It also enables digital products to be handled more comprehensively and more consistently than before. At the same time, the opportunity has been taken to introduce important improvements in other areas, although there are many data element groups where little or no change has been considered necessary.

What is the status of previous releases of ONIX for Books?

With the release of ONIX 3.0, all ONIX for Books 1.n releases have been formally withdrawn, and EDItEUR will no longer support them. ONIX for Books 2.n will continue to be supported until the Steering Committee determines that the implementation of ONIX 3.0 has reached a point where it is appropriate to cease further support. This includes essential updates to code lists used in 2.n. However, all development will now be focused on Release 3.0 and ONIX for Books users are encouraged to adopt the new release as early as is practicable.

When do you anticipate that ONIX for Books 3.0 will be widely implemented?

Implementation is at an early stage, but we currently anticipate that most major metadata aggregators will be able to receive and send ONIX for Books v.3.0 messages in Q1 or Q2 of 2010; and that the major suppliers of publishers’ systems should also be in a position to support the standard at around the same time.

What are the advantages of ONIX for Books 3.0?

Some of the advantages of Release 3.0 over previous ONIX for Books releases are:

• Redundant elements have been eliminated.

• Digital products can be more fully and consistently described, and the groundwork has been laid for further development in this area, as new product formats and content packages evolve.

• The handling of series, sets and multiple-item products – an acknowledged problem in earlier releases – has been greatly improved. As part of this improvement, there is a new extended title composite, which enables title detail to be more accurately expressed.

• Publishers and others are using a much greater variety of “marketing collateral” – typically web resources – to support the promotion and sale of physical and digital products.

• For ONIX users working in international markets, particularly the international English-language market, supply-related elements in ONIX 3.0 have been regrouped to allow the status of a product in different markets to be more clearly and accurately described.

• With the introduction of the ISTC (International Standard Text Code), products can be related to a parent ‘work’, to identify groups of different manifestations of the same text, or of texts derived from a common source.

• ONIX 3.0 Product records are ‘blocked’ in a new way which will permit updates to be sent without complete record replacement, and without the need for a separate “Supply Update” message type (which was necessary for this purpose in ONIX 2.1). Additional guidelines on updates will be published in Q4 of 2009 after further consultation with ONIX for Books national groups.

• The ONIX 3.0 schema definition is available in the ISO RELAX NG schema language, as well as in DTD and W3C XSD schema languages.

What are the significant differences between Release 2.1 and Release 3.0?

As a quick guide to those considering upgrading from Release 2.1 to 3.0, we have prepared a summary table which you will find in the Appendix to the Introduction to ONIX for Books 3.0.

Schemas and validation

What is the “schema”?

The schema is the formal definition of the structure, content and, to some extent the semantics (or meaning) of data in an XML file, ie in this case an ONIX XML message.

What are the “DTD”, “XSD” and “RELAX NG” schemas?

These are three widely-recognised “languages” in which XML schemas can be expressed. EDItEUR provides DTDs and XSD schemas for all current ONIX for Books releases, and for Release 3.0 there is also a RELAX NG schema. Developers can use a variety of widely-available XML tools to validate an ONIX message against the DTD, XSD or RNG schema. With the DTD, only the structure is validated. With the XSD or RNG schema, both the structure and the code values are validated. An ONIX message which fails at either of these levels is invalid, and it is reasonable to expect it to be rejected by a receiver.

How should I validate an ONIX for Books message?

In the first place, whether you are sending or receiving ONIX messages, we strongly recommend that you should use a suitable XML validation tool to check the message structure and, preferably, the code values against one of the schema definitions. Over and above this, there are also ONIX business rules which (for example) specify conditional requirements. These cannot at present be validated by off-the-shelf XML tools. Some national groups and independent developers offer validation tools which check some of these added criteria. And several national groups operate accreditation schemes which involve a more rigorous test process, typically taking into account not just the basic validity of ONIX messages but also their timeliness and the level of content.

Implementation

How can I implement ONIX for Books?

The options for publishers who want to start sending ONIX for Books are of three kinds: develop or commission bespoke software for managing your product metadata, and build in support for ONIX for Books; acquire a third-party system for product data management which supports ONIX for Books; or contract to use a web-based service which supports online data entry and delivery of ONIX for Books output to designated receivers. The availability and practicality of each of these options will vary from country to country: some ONIX national groups may be able to provide contacts with system or service suppliers. (Wherever possible, EDItEUR provides links to national groups from the ONIX for Books pages on this website.)

Will ONIX for Books affect the way I manage my product information?

ONIX for Books is a format specifically developed to support the communication of information from one computer system to another. It is not designed as an internal database format. However, it is obvious that communication can only work if the systems at each end are substantially “ONIX compliant” – for example, supporting data element structures and data encoding which are no less exact than those used in ONIX. It is important to verify at the earliest possible stage that any product data management system you plan to use is “ONIX compliant” in this sense.

Much of the content of a product record is free text which cannot be automatically validated. It is all too easy to deliver something which is correct in format terms but wrong in data content. For example, title fields in some book trade systems are traditionally used to carry added data, such as an edition number, which differentiates one product from another. But in ONIX for Books, title elements should carry only the component parts of the title, and there are separate elements for edition numbers and types. So not only your internal database structures, but also the disciplines followed by your data entry staff, need to be “ONIX compliant”.

Where can I get more information on implementing ONIX for Books?

Implementation questions are routinely discussed on the ONIX_Implement listserv, and notices of ONIX for Books developments are sent out to the listserv as well as to national groups. If you have not signed up to the list, you can do so here.

Do I need to include all elements listed in ONIX for Books?

ONIX for Books aims to cover the widest possible range of needs, and it therefore includes many elements which are specialised to particular forms of publishing or particular markets. Nobody uses all the elements of the format, and only a small number are mandatory. In many countries where ONIX for Books has been adopted, national groups publish their own guidelines for implementation and “good practice”. If you are buying a third-party system or service, you need to check that it complies with the guidelines that are in use in your particular market(s). Some receivers may choose not to use certain elements, or may ask for one option rather than another. However, no receiver should reject a valid message because it includes optional content which they have chosen not to use.

Does the order of elements matter in ONIX for Books?

Elements in an ONIX for Books message must be delivered in the sequence defined by the schema. A message in which elements occur out of sequence will not validate.

What are “reference names” and “short tags”?

Each element in ONIX for Books has a “plain language” reference name (for example, <NotificationType>) and a short tag (for example, <a002>). The schema definitions allow either reference names or short tags to be used to label the elements in an ONIX XML message. They cannot, however, be mixed in the same message. Users can make the choice between readability and conciseness. For ONIX releases up to 2.1, a tagname converter, which translates reference names to short tags, and vice versa, can be downloaded here.

In the very earliest ONIX for Books releases, the initial letters of the short tags indicated an attempted logical grouping of elements. As the format developed, this grouping quickly became impractical, so that there is now no significance to be drawn from the initial letters. (The numeric part of the tag has always been unique by itself.) In ONIX 3.0, all new elements have been assigned short tags of the form <xnnn>, so that they can be immediately recognised as new.

What should I do if I have no information to go in an ONIX data element?

If for a particular product there is no information available for an optional data element, the data element should be omitted. If the element is mandatory, however, you must not send an ONIX record without providing valid data for the element. In neither case is it permissible to send an “empty element”.

[In XML it is possible to deliver an empty element in either of two forms: <Tag></Tag> or <Tag/>. Neither of these two forms should ever occur in an ONIX for Books message, except in a few instances where an element (eg the <MainSubject/> flag in Group P.12 in Release 3.0) is specifically defined as always empty, in which case we strongly recommend that the second form <Tag/> should be used. If there is no data for an element that is not defined as empty, the element should be omitted completely. “Illegal” empty elements are detected by validation against the XSD or RNG schemas, but not by validation against the DTD. Consequently there is a risk with the DTD that a message could pass validation even though it includes mandatory elements for which there is no data. This is another reason for using the XSD or RNG schema for validation wherever possible.]

 

 

top of page

Browse

ONIX

E-Commerce

Identifiers

Contact Details

  • EDItEUR
  • 39-41 North Road,
  • London, N7 9DP,
  • U.K.

  • info@editeur.org
  • tel: +44 (0)20 7503 6418
  • fax: +44 (0)20 7503 6418

Terms & Conditions  |  Privacy Policy