Introduction

This ONIX for Books Implementation and Best Practice Guide (‘the Guide’) is intended to be read in conjunction with the ONIX for Books Product Information Format Specification (‘the Specification’), and section numbering is compatible between the two documents.

This guide documents ‘best practice’, not ‘common practices’, and its aim is to improve the quality of communication using ONIX, industry-wide, by ensuring ONIX users implement the standard in a consistent and effective fashion.

It is intended as a global guide: as such, there may be some specific national best practices that differ in a few aspects. But in general, the principles and global best practices apply in all markets. ONIX National Groups are encouraged to view the global guide as a base to which to add any purely national variations, rather than developing potentially conflicting local guidelines from scratch.

‘Best practice’ is dynamic: as data providers and recipients improve their capabilities, as business models develop, and as market conditions change, the nature and extent of these best practice guidelines is liable to evolve. And the guidance in this document is not entirely limited to the data content of individual ONIX elements, but includes some comments on reasonable expectations for how that data should be treated by both data suppliers and recipients.

Within this Implementation and Best Practice Guide, the ONIX for Books message Header and each Block or Group of a Product record is considered in turn. Each of these sections begins with a boxed summary of the best practice, and is followed by one or more extended and annotated examples, and more detailed discussion of each composite or data element.

Throughout this guide, Reference names are used in text descriptions, diagrams and discussions of best practice. In all cases, equivalent Short tags are equally good practice, and examples given show both alternatives.

It is recognized that this Implementation and Best Practice Guide may be – for some ONIX users – somewhat beyond the current capabilities of their internal IT systems, and initial implementations of ONIX 3.0 may not meet all aspects of this best practice. However, implementors are encouraged to plan to comply with all aspects of best practice as a minimum, even if this plan involves a multi-phase implementation.

This guide does not set out to define a ‘minimum’ set of data elements for valid ONIX – technically, that minimum set is inherent in the ONIX schema, and is all but useless. In reality, the minimum set of elements is the set that meets your business requirements – and real business requirements will inevitably require use of a larger set of data elements than any purely technical minimum. These best practices go well beyond any technical minimum, and outline a set of data elements that are likely to be the most commercially relevant in a broad range of circumstances.

Omission of any data element from this Implementation and Best Practice Guide does not imply that all data providers should simply omit the data element from their ONIX messages or their internal systems – the uses to which ONIX data is put by data recipients vary widely, and the range of potentially useful data content that might be carried in ONIX messages should be discussed between providers and recipients. For certain types of product and particular trading arrangements, individual data elements may be of great importance, yet may not be covered in this guide. For example, it may be highly advantageous for the publisher to supply details of the product classification using the UNSPSC (UN Standard Product and Service Classification), WCO (World Customs Organization) Harmonized Commodity Coding or another commodity coding scheme to overseas distributors as an indication of the customs or tax status of the product. Equally, this best practice guide does not cover use of the <ReligiousText> composite, which of course would be critical to a publisher or reseller specializing in religious publications. However, this document provides guidance on those data elements that will be found most commonly useful to the broad range of supply chain partners – the ‘core content’ of an ONIX message.

Although ONIX 2.1 is considered a legacy format, this Guide can provide useful help for 2.1 in areas where there are no differences, or only modest changes, between 2.1 and 3.0. An appendix lists these changes. Many codelists are shared between ONIX 2.1 and 3.0, though the latest update of the codelists that can be used with 2.1 is Issue 36 – new codes added to shared lists after Issue 36 are not valid in ONIX 2.1.

Introduction to Release 3.0 revision 1 (3.0.1)

This revision of the Implementation and Best Practice Guide includes a number of updates taking into account additions made in Release 3.0 revision 1 (3.0.1) of the ONIX for Books Product Information Format Specification. Many of these changes are intended primarily for use with East Asian writing systems, or with multilingual metadata, but other additions are of more general use. The earliest release of the codelists suitable for use with version 3.0.1 is Issue 16.

Introduction to Release 3.0 revision 2 (3.0.2)

This revision of the Guide includes a number of updates taking into account additions made in Release 3.0 revision 2 (3.0.2) of the ONIX for Books Product Information Format Specification. Some data elements introduced in version 3.0.2 require use of Codelists Issue 24 or later.

Introduction to Release 3.0 revision 3 (3.0.3)

This revision of the Guide includes a number of updates related to additions made to ONIX for Books in Release 3.0 revision 3 (3.0.3). Some key additions introduced in version 3.0.3 of the ONIX for Books Product Information Format Specification require the use of Issue 33 or later of the Codelists.

Introduction to Release 3.0 revision 4 (3.0.4)

This revision of the Guide includes a number of updates related to additions made to ONIX for Books in Release 3.0 revision 4 (3.0.4). Some key additions introduced in version 3.0.4 of the ONIX for Books Product Information Format Specification require the use of Codelists Issue 39 or later. Note that Issue 39 codelists are not usable with ONIX 2.1, and for applications supporting both, a copy of Issue 36 is also required.

Introduction to Release 3.0 revision 5 (3.0.5)

This revision of the Guide includes updates covering additions made to ONIX for Books in Release 3.0 revision 5 (3.0.5). One key addition introduced in version 3.0.5 of the ONIX for Books Product Information Format Specification – the <AVItem> composite – requires the use of Codelists Issue 43 or later.

Introduction to Release 3.0 revision 6 (3.0.6)

This revision of the Guide includes two very minor updates made in Release 3.0 revision 6 (3.0.6).

Document history

14 April 2011
Working draft.
30 June 2011
Initial release.
26 July 2011
Added appendix listing key changes between ONIX 2.1 and ONIX 3.0.
Added stronger recommendation to use UTF‑8 encoding, and a note on omission of BOM with UTF‑16 encodings.
Added advice against including a DOCTYPE declaration or any reference to local schema files in transmitted messages.
Added note on use of the textformat attribute, and either CDATA or escaping of < characters in HTML.
Added guidance on preferred format for <SentDateTime> and datestamp.
Added note on sequence numbering for <UnnamedPersons> element.
Minor updates to take into account additional codes in Codelists Issue 14.
Minor changes for clarity and style.
22 Aug 2011
Added note about use cases.
Added appendix checklist for new data feeds.
Added ‘At a glance’ diagrams.
Fixed section P.19.14.
Minor changes for clarity and style.
13 Sept 2011
Added appendix on codelists and internationalization.
Added notes about delivery of collateral resources.
Correction to <Header> At a glance diagram.
Correction to <Tax> composite example.
Minor changes for clarity and style.
4 Oct 2011
Added diagram illustrating semantics of List 64.
Minor changes for clarity and style.
21 Oct 2011
Added example illustrating use of <ProductFormFeature> for describing accessibility features of an e‑book.
Minor updates to take into account other additional codes in Codelists Issue 15.
Added example showing use of publisher and publishing group.
Update of XML namespace used by ONIX messages.
Added notes on governance.
Minor updates to take into account additional codes in Codelists Issue 15.
Minor changes for clarity and style.
13 Dec 2011
Corrections to Collection and Sender ‘At a glance’ diagrams.
Added appendix on development and support lifecycle.
Minor changes for clarity and style.
27 Jan 2012
Revised release, to accompany Release 3.0 revision 1 of ONIX for Books.
Added notes and examples related to provision of textual metadata in multiple ‘parallel’ languages, provision of transliterated names, inclusion of glosses in Chinese and Japanese, and provision of phonetic information for sorting names and titles in non-alphabetic writing systems.
Added notes relating to the <CollectionSequence> composite, the <SequenceNumber> within the <TitleElement> composite and the <ProductContact> composite.
Modified ‘At a glance’ diagrams to include new data elements introduced in ONIX 3.0.1.
Added examples showing wholesale and temporary ‘special offer’ pricing, and provision of multiple publishing dates for an e‑book.
Minor updates to take into account additional codes in Codelists Issue 16.
Minor changes for clarity and style.
10 Feb 2012
Added notes to some ‘At a glance’ diagrams.
Change to appendix to reflect the ONIX International Steering Committee decision and EDItEUR’s announcement that ONIX 2.1 support will be reduced at the end of 2014.
Minor changes for clarity and style.
18 Apr 2012
Added example showing versioned e-publication file format.
Updated best practice for ISBN-A.
Minor changes for clarity and style.
25 Apr 2012
Additions in P.7 to recommend use of the newly-published ISNI.
Minor updates to take into account additional codes in Codelists Issue 17.
14 Aug 2012
Added paragraphs in Section 2 on the ‘metadata supply chain’, on the use of EDItX or EDI P&A update messages, and on user interfaces.
Added typical schema references and DOCTYPE declarations for validation.
Clarifications in use of the <TitleElement> composite and <ImprintIdentifier>.
Corrected minor errors in examples showing use of <Language> and <NameIDType>.
Added notes on use of rolling and instantaneous datetimes.
Minor updates to align with Codelists Issue 18.
Other minor changes for clarity and style.
Added notes on CI/RI/CX/RX combinations in <Territory>.
Added example showing multiple, qualified prices.
Updated diagrams to reflect recent tightening of schema requirements.
19 Oct 2012
Added further clarification on naming of imprints and publishers.
Documented subset of List 65 likely to be applicable to digital products.
Added further clarification of best practices for tax-inclusive and tax-exclusive pricing.
Strengthened advice on use of narrow audience age ranges.
Extended example showing usage constraints in P.3.
Added example of review quote in P.14.
Added Sales outlet ID to example in P.21.
Added note on 2-series GTIN-13s.
Added note on RTL scripts.
Minor updates for clarity and style, and to align with Codelists Issue 19.
Fixed SVG to work around a problem with Firefox 17 (and later).
25 Jan 2013
Added sections on <Barcode> and <ContributorPlace> for North America.
Added section on specifying rental prices using <PriceCondition>.
Added examples of <RelatedWork> for an omnibus edition, and of use of et al.
Added diagrams for common packaging.
CSS improvements for printing.
Other minor changes for clarity and style, and updates to align with Codelists Issue 20.
26 Apr 2013
Added note on overseas territories and dependencies.
Added tables showing associations between <ProductFormDetail> and <ProductFormFeature>, and <ProductForm>.
Expanded notes on best practice with hierarchical subject categorization.
Added note on sort order.
Added example differentiating perpetual licenses and rentals of e‑books.
Other minor changes for clarity and style, and updates to align with Codelists Issue 21.
19 July 2013
Added notes on encoding of versions, version history, extended XHTML recommended subset to include <dl>.
Added note on relative URIs in <ResourceLink>.
Added note on avoiding special characters in <RecordReference>.
Other minor changes for clarity and style, and updates to align with Codelists Issue 22.
Fixed error in labelling of ‘At a glance’ diagram in P.14.
18 Oct 2013
Added example of use of track count for extent of an audiobook.
Added example of retailer exclusion.
Added section on use of <ProductClassification>.
Other minor updates to align with Codelists Issue 23.
24 Jan 2014
Revised release, to accompany Release 3.0 revision 2 of ONIX for Books.
Added further notes on message sequence numbers, added para and example on <NoProduct/> and modified ‘At a glance’ diagram.
Added section on <EpubLicense>.
Added para on <NoPrefix/>, modified ‘At a glance’ diagram and updated examples.
Added note to <ContributorPlace>, modified ‘At a glance’ diagram and updated examples.
Added para on <PrizeStatement>, modified ‘At a glance’ diagram and updated example.
Modified section on <SalesRestriction>, modified ‘At a glance’ diagram and updated examples.
Added section on <CopyrightStatement>, added ‘At a glance’ diagram and added example.
Added section on <PriceIdentifier>, modified ‘At a glance’ diagram and updated examples.
Added para and example on linked prices in <PriceCondition>.
Added note on contrast between 3.0 handling of sales rights, markets, suppliers and prices, and equivalent in 2.1.
Added appendix sections on character sets and encodings, and on XHTML tagging.
Other minor updates to align with Codelists Issue 24.
29 Mar 2014
Corrected diagrammed cardinality of <AgentRole> in P.25 (it is mandatory).
Corrected second example in P.26.
Added definition of market publication date.
Added para on gaming the keywords.
Added note on conventions for decimal places in <PriceAmount>.
Minor updates to align with Codelists Issue 25.
11 July 2014
Added example to illustrate US ‘Common Core’ curriculum alignment in <Subject>.
Added example to illustrate use of <SupplierOwnCoding>.
Added example illustrating rental extensions and upgrades.
Modified ‘At a glance’ diagrams to highlight deprecated elements with pink tint.
Added section on <Stock> composite.
Added examples and diagrams to illustrate use of contributor dates and professional affiliations.
Corrections to ‘At a glance’ diagram showing structure of <ProductClassification> and of Block 6.
Extended notes on whitespace normalization, CDATA and escaping HTML in <BiographicalNote>.
Extended notes on <ProductRelationCode> relationships.
Other minor changes for clarity, and updates to align with Codelists Issue 26.
17 Oct 2014
Added aside on manifestations and works.
Other minor changes and updates to align with Codelists Issue 27.
24 Jan 2015
Added ‘DOI per chapter’ example in <ContentDetail>.
Added notes on digital exclusivity.
Elaborated example showing change of publisher of a product.
Noted that there is no longer a need to remove the xmlns attribute from <ONIXMessage> prior to DTD validation.
Added references to new ONIX Acknowledgement Message.
Other minor changes and updates to align with Codelists Issue 28 and the sunset date for ONIX 2.1.
26 Mar 2015
Added example of windowing around subscription services in P.24.
Added some text on Complexity measures.
Added appendix section on integer and real number data elements.
Other minor changes and updates to align with Codelists Issue 29.
29 July 2015
Added example of back cover copy as separately-downloadable supporting resource.
Extended CCSS example in <Subject> to include BISG Educational Taxonomy.
Added example of POD information, including order time.
Added example of revenue-share market using Unpriced item type.
Other minor changes and updates to align with Codelists Issue 30.
29 Oct 2015
Clarifications on the use of the datestamp attribute and ‘last updated’ dates, particularly with respect to descriptions and supporting resources.
Clarification on textual data length limits, which are specified in characters, not bytes.
Other minor changes for clarity and updates to align with Codelists Issue 31.
26 Jan 2016
Added <cite> to recommended subset of HTML/XHTML markup.
Clarifications on the use of 00:00 or 24:00 for midnight.
Clarifications on the use of exclusive and non-exclusive sales rights.
Other minor changes and updates to align with Codelists Issue 32.
25 Apr 2016
Revised release, to accompany Release 3.0 revision 3 of ONIX for Books.
Added ‘Common issues’ boxouts.
Revised various ‘At a glance’ diagrams and data examples to incorporate new elements (eg <Gender>) and new composites (eg <ReviewRating>) added in revision 3.
Added section on use of <Gender> in P.7.
Added sections on <Territory> and <ReviewRating> in both P.14 and P.15.
Added section on <PriceConstraint> in P.26, and modified rental examples using <PriceCondition>.
Added section clarifying the meaning of exclusive and non-exclusive sales rights.
Added note on the effect on filesize of using short tags and zip compression.
Other minor changes and updates to align with Codelists Issue 33.
25 July 2016
Added summary for embedding HTML.
Other minor changes and updates to align with Codelists Issue 34.
25 Oct 2016
Added section on <UnpricedItemType> in <Price>.
Other minor changes and updates to align with Codelists Issue 35.
20 Jan 2017
Added German tax example with product identifier in <Tax> composite.
Added JSON‑LD example in <TextContent>.
Other minor changes and updates to align with Codelists Issue 36.
3 Apr 2017
Added example of table of contents with nesting, using type and start attributes on <ol>.
Added example of ‘FOC for one day’ price promotion.
Minor changes and updates to align with Codelists Issue 37.
14 July 2017
Added examples for official examination board endorsements and use of <ContentAudience>.
Added example of 3-for-2-style support using <PriceCondition>.
Added example specifying traditional or simplified script in Chinese language.
Minor changes for clarity and style, and updates to align with Codelists Issue 38.
26 Oct 2017
Revised release, to accompany Release 3.0 revision 4 of ONIX for Books.
Revised various ‘At a glance’ diagrams and data examples to incorporate new elements (eg <Reserved>) and new composites (eg <SupplyContact>) added in revision 4.
Added further usage examples for extended <CollectionSequenceNumber>.
Added example showing use of <NameAsSubject> for fiction.
Added example showing <SupplyContact> for return authorization.
Added example showing <PricePartDescription> for French éco-participation.
Added example showing Phonogram rightsholder.
Added example showing progressive discount.
Minor updates to align with Codelists Issue 39.
23 Jan 2018
Minor correction in ‘At a glance’ diagram around <AudienceCode> (it is repeatable).
Added note on XSD 1.1 validation.
Minor updates to align with Codelists Issue 40.
26 Apr 2018
Minor updates to align with Codelists Issue 41.
9 July 2018
Added note on use of stock quantities.
Added note on format of BIC discount code.
Minor updates to align with Codelists Issue 42.
26 Oct 2018
Revised release, to accompany Release 3.0 revision 5 of ONIX for Books.
Revised ‘At a glance’ diagrams and data examples to incorporate new <PalletQuantity>, <TaxExempt/> elements and the new <AVItem> composite added in revision 5.
Added appendix listing allowed empty elements.
Added appendix listing XPaths for each element.
Minor updates to align with Codelists Issue 43.
21 Jan 2019
Added color swatches.
Minor updates to align with Codelists Issue 44.
26 Apr 2019
Slightly revised release, to accompany Release 3.0 revision 6 of ONIX for Books.
Modified ‘At a glance’ diagrams to add <Measure> within <ProductPart> and make <WebsiteLink> repeatable.
Added example providing battery information and safety warning.
Other minor updates to align with Codelists Issue 45.
10 July 2019
Addition to 26 Hints section.
Correction to example ‘deletion’ message.
Minor updates to align with Codelists Issue 46.

The ONIX for Books framework

ONIX for Books provides a standardized framework for transfer of rich bibliographic and product information between computer systems within the book and e‑book supply chains.

The framework consists of an XML-based message specification – the ONIX for Books Product Information Format Specification (‘the Specification’), a message acknowledgement specification (‘the Acknowledgement Specification’), and the accompanying XML schemas – plus a set of regularly-updated controlled vocabularies (the ‘Codelists’) used in conjunction with the specifications, and various guidelines for implementation and best practice including this document (‘the Guide’). In addition, some national book trade bodies provide further guidance or certification schemes to denote compliance with the framework and with the wider needs of the supply chain.

The ONIX for Books documentation and various XML software tools are downloadable from the EDItEUR website:

Some aspects of the ONIX framework are also used in other EDItEUR standards – in particular the EDItX message framework. Some EDItX message formats, for example the Sales Report and Inventory Report, maintain both semantic and limited syntactic compatibility with ONIX, they share some codelists, and they can be used to report on the products that ONIX ‘advertises’.

Ongoing development and maintenance of the ONIX framework is managed by EDItEUR, in response to business requirements identified by its stakeholders. Although EDItEUR is a membership-based organization, ‘stakeholders’ encompasses all participants in the global book and e‑book supply chains.

EDItEUR has established a governance model for ONIX that ensures a balance between responsiveness to changing business requirements and stability of the standards. ONIX for Books standards are developed and maintained in consultation with a network of ONIX National Groups – essentially committees of ONIX users and other stakeholders such as trade associations – that have been set up in many countries. National Groups are each represented on the ONIX International Steering Committee (ISC), which meets twice per year at the London and Frankfurt International Book Fairs. The ISC provides overall direction for development of the framework. Terms of reference for National Groups and for the ISC can be found on the EDItEUR website.

Change requests or proposals for new developments can be submitted by any stakeholder, either via a National Group or direct to EDItEUR. Most such requests can be met through supplementing the ONIX codelists. More rarely, a change to the Specification and associated XML schemas is required. In either case, requests are reviewed by EDItEUR and the National Groups, and major developments must be approved by the ISC. After approval, major developments are carried through in line with the ONIX development and support lifecycle.

Codelists are revised and extended on a regular basis (three or four times per year), and from time to time, minor corrections and revisions are incorporated into documentation and schemas. Such updates are announced via the EDItEUR website and the ONIX_implement e‑mail listserver.

ONIX is founded partly on principles developed within the <indecs> project and upon the EPICS data dictionary, but is firmly rooted in real-world use cases and the practices of book supply chains in many countries. Typical use cases for ONIX messages include:

Although all of these supply chain partners are likely to maintain databases of product information, ONIX is primarily a message format, and is not in itself a specification for a database. ONIX specifies a range of key data elements or fields that might be stored in such a database. But the data structures defined by the ONIX specification are designed for communication of data. They are not necessarily a good match for either storage or management of product data. Databases optimized for management of bibliographic data would ideally have a more normalized (relational) or hierarchical structure to reduce the duplication of data (and thus the duplication of data management effort). Nonetheless, the ONIX specification is often used to inform the design of a database schema. And while ONIX codelists are often used as controlled vocabularies or lists of options in a database-backed application, the way ONIX encodes options (usually as numbers drawn from the codelists) is not ideal for presentation.

Implicit in the design of ONIX is the idea of a ‘metadata supply chain’. Product information is created alongside the product itself (though not necessarily by the same staff) and flows to the eventual retailer, possibly via one or more intermediary organizations – much as the products themselves do. But the metadata may take a different route, and may be managed and enhanced along the chain: no one department at the publisher, and no single organization in the chain, controls all the metadata elements. For example, within a publisher, product information may be drawn from editorial, production, advertising and promotion, the contracts or rights departments, and from sales. The distributor or wholesaler may contribute further information, and the eventual distribution of the data is sometimes accomplished by a data aggregator or other intermediary. Complete, accurate and timely metadata is the result of good business process and clear ‘ownership’ of each data element, and collating the metadata efficiently from the disparate sources may depend on a high level of business process and application integration within an organization.

The metadata supply chain may be complex: publishers may need to provide data direct to retailers, indirectly to retailers via intermediaries such as data aggregators, distributors and wholesalers, and to other service providers such as e‑book conversion vendors and online marketing organizations.

And because ONIX is about communication – unambiguous and consistent computer-to-computer communication suitable to support automation of business processes – precise semantics are important. Each party in the metadata supply chain must agree and understand the meaning of the data supplied. A price is not simply ‘the price’: buyers and sellers must know whether that price includes or excludes relevant taxes, whether it is a fixed price or may be reduced by the retailer, and whether it applies to all classes of customer or is a special price for one specific class (such as for schools). The extent of a book (the number of pages) can be measured and expressed in many different ways. The publication date must be communicated in a particular way, in a specific ONIX data element, and sender, recipient and intermediaries must agree to interpret the date in the same way – the phrase ‘publication date’ is used loosely to mean startlingly different things within different organizations, but communicating with ONIX (or any other standard) requires agreed definitions of such terms. And no data element should be misused to carry data that truly belongs in a different field. While seemingly onerous, this precision is designed to allow a single ONIX data feed to meet the needs of multiple recipients – if one party wants the extent of a book expressed as ‘the number of physical pages including unnumbered pages and blanks’ and another demands the extent as ‘the highest page number’, then both can be included in the ONIX message. And of course, to maintain this semantic precision, senders should never put data into a field simply because they want it displayed in a particular way by a specific recipient (for example putting a publisher name into a series or collection title field, or promotional text into a subtitle, so that the recipient displays it more prominently).

In principle, a single ONIX message that meets the best practices described here should be suitable for any recipient able to accept ONIX 3.0. In practice, of course, business sensitivities may mean that one recipient should not receive details of a particular product that is exclusive to a competitor (or at least, not prior to its publication), or e‑book retailers may wish not to receive details of physical products they cannot retail – which means that the content of messages can become recipient- or channel-specific. However, this specificity is limited to the selection of Product records included in the message, and the exact content of each Product record should not need to be varied.

High-level message structure and conformance

ONIX for Books is an XML-based standard, and it is obviously an overriding requirement that ONIX messages are well-formed according to the XML syntax rules and valid according to the ONIX schema, and that they conform to the ONIX for Books Message Format Specification (including conforming to any ‘business rules’ described in the specification but not expressed in the DTD, XSD or RNG schemas – some of these rules may be enforced by future versions of the schemas). However, within that, there is huge scope for variation in what is considered valid ONIX for Books data. This document is intended to guide implementors, with the intention of narrowing the range of variation between implementations (particularly between different countries) and making it simpler for data senders and recipients to exchange ONIX data – adherence to agreed guidelines and best practice means less need for testing when establishing new data relationships, less tailoring of messages for individual recipients, and fewer ‘special cases’ built into recipient’s systems – all of which lower costs.

Consistent use of the ONIX data elements – putting the right data in the right boxes – is clearly paramount. And consistent use of codes drawn from the ONIX codelists is vital in this regard.

All ONIX for Books release 3.0 messages must begin with a standard XML declaration and message start tag. The <ONIXMessage> start tag must of course be balanced by an </ONIXMessage> tag at the end of the message. Between the two, there must be a <Header> and either one or more <Product> records or a single <NoProduct/> empty tag. The message header contains information about the message itself – which organization sent it, when and to whom – and each ‘Product record’ contains information describing a single product.

ONIXMessage Start of ONIXMessage Header – Click to jump to diagram showing internal structure of <Header> Header Product – Click to jump to diagram showing internal structure of <Product> Product NoProduct NoProduct End of ONIXMessage start circle represents <ONIXMessage> represents a <Product> composite, also known as a ‘Product record’. The arrows show the composite is repeatable represents a <NoProduct> element. The arrows show the <Product> composite and <NoProduct> element are mutually exclusive end circle represents </ONIXMessage>

This diagram shows the highest-level composites and data elements within an ONIX message – other similar diagrams show lower-level composites and elements within specific parts of the message. Composites have a darker blue background, individual data elements have a pale blue background, and most are clickable – they link either to a diagram showing the internal structure of the composite, or to detailed notes about the composite or data element. Elements or composites that are not included in EDItEUR’s ‘best practice’ guidelines (though they may still be needed to meet specific business requirements – for example the need to send supplier-specific codes using <SupplierOwnCode> or ‘empty update’ delta messages using the <NoProduct/> empty element), are grey rather than blue. The small number of deprecated elements such as <DateFormat> are tinted pink.

The arrows indicate the required sequence of data elements and composites within the message, and whether a particular element is optional (the arrow bypasses the element) or repeatable (the arrow loops back). Note that the diagram shows more information than the simple cardinality statement in the Specification – the cardinality of <Product> is nominally 0…n, but the diagram clearly indicates that if <Product> is omitted then <NoProduct/> must be included, and that they may not both occur in the same message.

The standard XML declaration and <ONIXMessage> start tag at the beginning of each ONIX message file may carry other information, about the character encoding of the file and the XML namespace used.

message start, including optional (but recommended) encoding and namespace declarations
using Reference names
<?xml version="1.0" encoding="UTF-8"?>
<ONIXMessage release="3.0" xmlns="http://ns.editeur.org/​onix/​3.0/​reference">upper case M
using Short tags
<?xml version="1.0" encoding="UTF-8"?>
<ONIXmessage release="3.0" xmlns="http://ns.editeur.org/​onix/​3.0/​short">lower case m
The choice between <ONIXMessage> (upper case M) and <ONIXmessage> (lower case m) in the message start dictates the use of either Reference names or Short tags throughout the remainder of the message.
The addresses ns.editeur.org/​onix/​3.0/​reference and /short do not represent real files on the internet – there is nothing at those addresses. They act merely as names that can be used to ensure uniqueness for the names of ONIX data elements and attributes, and they have a role in linking the ONIX data file to the ONIX schema for validation purposes.
message end
using Reference names
</ONIXMessage>
using Short tags
</ONIXmessage>

The encoding declaration is technically optional, but is effectively mandatory if your message does not use UTF‑8 or -16, and it is best practice to include it even if it does. UTF‑8 is the recommended encoding for ONIX data, although recipients should also accept other encodings in common use in particular markets, for example ISO 8859‑15 (ISO Latin‑9) or Windows‑1252 (Windows codepage 1252). If a message uses UTF‑16 or UTF‑32, the encoding should be declared explicitly as (for example) UTF‑16BE or UTF‑16LE, and a byte order mark should ideally not be included at the beginning of the data file. However, certain software insists on a byte order mark, so data recipients should not rely on its absence. Data recipients should also not rely on supplied Unicode using a particular normalization form, although NFC is recommended for data senders.

The XML namespace declaration is also optional, but may be included as an xmlns attribute of the <ONIXMessage> element. The namespace declaration is usually required for validation of the ONIX message using the XSD or RNG schemas. It is not required for validation using the DTD, but if present it may remain in place. (Versions of the DTD dated before 2015‑01‑24 required any xmlns attribute be removed, but this is no longer necessary.)

ONIX 3.0 messages as transmitted may include the namespace declaration (the xmlns attribute), but should not include any reference to a schema file location (the xsi:schemaLocation attribute), since these are likely to be inaccessible to the recipient of the ONIX data. In particular – and unlike earlier versions of ONIX – transmitted messages should not include a DOCTYPE declaration. Of course such references may need to be added when files are validated and processed internally. (For validation with the DTD, any xmlns namespace declaration would need to be removed and a DOCTYPE declaration may need to be added. For validation with an XSD schema, the xmlns attribute must be present, and for some validation tools, the xmlns:xsi and xsi:schemaLocation attributes also need to be added to the <ONIXMessage> element, giving the local network location of the schema file.)

message start with namespace declaration and reference to location of the XSD schema file, for validation purposes only
using Reference names
<?xml version="1.0" encoding="UTF-8"?>
<ONIXMessage release="3.0" xmlns="http://ns.editeur.org/​onix/​3.0/​reference" xmlns:xsi="http://www.w3.org/​2001/​XMLSchema-instance" xsi:schemaLocation="http://ns.editeur.org/​onix/​3.0/​reference http://intranet/​onix/​ONIX_BookProduct_3.0_reference.xsd">
using Short tags
<?xml version="1.0" encoding="UTF-8"?>
<ONIXmessage release="3.0" xmlns="http://ns.editeur.org/​onix/​3.0/​short" xmlns:xsi="http://www.w3.org/​2001/​XMLSchema-instance" xsi:schemaLocation="http://ns.editeur.org/​onix/​3.0/​short http://intranet/onix/​ONIX_BookProduct_3.0_short.xsd">
The actual location of the XSD schema file, which is the second part of the value of the xsi:schemaLocation attribute – a location on the local intranet in the example – needs to be adjusted depending on local circumstance. The reference style required for the RNG schema is different. The xmlns:xsi and xsi:schemaLocation attributes should be removed before transmission of the message, since the location of the schema file will be different for any recipient.
message start with DOCTYPE reference and location of the DTD file, for validation purposes only
using Reference names
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ONIXMessage SYSTEM "http://intranet/​onix/​ONIX_BookProduct_3.0_reference.dtd">
<ONIXMessage release="3.0">
using Short tags
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ONIXmessage SYSTEM "http://intranet/​onix/​ONIX_BookProduct_3.0_short.dtd">
<ONIXmessage release="3.0">
The actual location of the DTD file – on the local intranet in the example – needs to be adjusted depending on local circumstances. The entire DOCTYPE line should be removed before transmission.
For more on validating XML – the technical process of checking ONIX messages meet the syntactic requirements of the standard – see DIY Schema Validation for Workmanlike ONIX, a comprehensive set of instructions for validation beginners by Tom Richardson of BookNet Canada. While it’s focused on ONIX 2.1, the same principles apply to ONIX 3.0.

Given a correct encoding declaration (or – because UTF-8 or UTF-16 are the XML defaults – without one) an ONIX message file can include metadata in many languages and scripts. Note that in all cases, whatever the language and script of the textual metadata, the ONIX tags and attributes, codes drawn from the codelists, numerical metadata and most dates remain the same.

Title and collection title of a novel in Chinese
using Reference names
<!-- Group P.5 -->
<Collection>
    <CollectionType>10</CollectionType>
    <TitleDetail>
        <TitleType>01</TitleType>
        <TitleElement>
            <TitleElementLevel>02</TitleElementLevel>
            <NoPrefix/>
            <TitleWithoutPrefix>地球往事</TitleWithoutPrefix>
        </TitleElement>
    </TitleDetail>
</Collection>
<!-- Group P.6 -->
<TitleDetail>
    <TitleType>01</TitleType>
    <TitleElement>
        <TitleElementLevel>01</TitleElementLevel>
        <NoPrefix/>
        <TitleWithoutPrefix>三体</TitleWithoutPrefix>
    </TitleElement>
</TitleDetail>
using Short tags, with title of a Hebrew translation
<!-- Group P.5 -->
<collection>
    <x329>10</x329>
    <titledetail>
        <b202>01</b202>
        <titleelement>
            <x409>02</x409>
            <x501/>
            <b031>זכרו את עבר כדור הארץ</b031>Remembrance of Earth’s Past
        </titleelement>
    </titledetail>
</collection>
<!-- Group P.6 -->
<titledetail>
    <b202>01</b202>
    <titleelement>
        <x409>01</x409>
        <x501/>
        <b031>בעיית שלושת הגופים</b031>The Three-Body Problem
    </titleelement>
</titledetail>
26 ONIX XML hints and tips

Organization of data delivery

ONIX data files are sent from a ‘sender’ to a ‘recipient’ – for example from a publisher to a retailer. One data file, or ‘message’, may contain information about many products, and may form part of a sequence or ‘feed’ of ONIX messages.

There is a separate – and entirely optional – Acknowledgement message which may be returned from recipient to sender, to confirm receipt and processing of the data. Use of the Acknowledgement message should be agreed between parties involved in a message exchange.

A single ONIX data file or ‘message’ includes a snapshot of the sender’s data about a range of products at the moment the message was created – and that snapshot can be transferred into the recipient’s system. But within the sender’s in-house systems, that data is subject to change. For example, as a forthcoming product approaches publication, more comprehensive bibliographic data becomes available, and previously collected data is corrected or refined. Thus exchanges of ONIX data are better thought of as ‘data feeds’ consisting of an ongoing sequence of messages – either a series of complete snapshots of the entire set of data, or (more likely) a series of changes between one snapshot and the next.

For a published product, aside from fixing any genuine errors, some elements of an ONIX Product record are effectively ‘frozen’ – the title or author cannot really change post-publication. However, other parts of the record – particularly collateral, price and availability elements that are mostly in Block 2 and Block 6 – remain subject to change throughout the life of the product. A subsequent message would include any new or updated data.

It is best practice to begin to deliver data about a planned product to supply chain partners several months in advance of actual availability. However, an initial Product record, produced eight or six months prior to publication, is not expected to be complete or final in all respects: at that point in the product’s lifecycle, many parts of the Product record would be subject to change – or missing altogether. Data suppliers should continue to update the Product record as information is confirmed or becomes available, and it is best practice for senders to ensure that all key information is available to recipients at least four months prior to publication. ONIX National Groups may operate compliance or certification schemes that specify more detailed (and perhaps earlier) targets for the delivery of comprehensive metadata prior to publication.

Certain information may only become available or be confirmed after manufacture of a physical product – an exact weight, for example. Data senders should continue to send updates and incorporate the latest available data in their data feed. And of course, although much of the bibliographic data in a Product record is in effect ‘frozen’ as the product is published, price and availability, collateral material such as reviews, relations to other works and products and other data elements should continue to be updated post-publication and throughout the product lifecycle.

Any exchange of ONIX data must be based (at least implicitly) on an agreed set of criteria for selecting a range of Product records from the data supplier’s in-house system – an agreed ‘catalog’ of products. These criteria may vary – how far in advance of publication should products be included, and should out of print products be included? Should the catalog include all markets and all types of product, or be tailored to include only those markets and products suitable for a specific class of recipient (or even a single recipient)? Each distinct set of selection criteria and catalog creates a distinct ‘data feed’, a sequence of messages, and in some circumstances, a particular set of selection criteria may be unique to a single ONIX data recipient.

Data senders should be particularly careful about products that initially fall within the selection criteria, where a subsequent change such as postponement of publication date means they fall outside the criteria – such products should continue to be included in the feed. It is a common error to omit them from the subsequent feed, thus leaving the old (and incorrect) data relict in the recipient’s system.

ONIX for Books envisions three different ‘modes’ for a data feed:

  • Full update – supply of the complete set of Product records that fall within the feed’s selection criteria;
    • any ongoing exchange of ONIX data would at least have to begin with a full data feed;
    • each Product record carries all available information about that product, even if the entire Product record is unchanged from a previous message;
    • implementing a data feed which is simply a series of full updates is simple as there is no need to track when updates are made in the sender’s system, and no need for the recipient to ensure that all messages are received and processed in order. Missed messages and messages processed out of order are ‘self-correcting’ when the next message is dealt with;
    • recipients should first match each received record with existing records on the basis of the <RecordReference>, then replace any and all existing data previously associated with each product with the new data in the latest message (this means that any data previously held for a matched product, but not included in the new full update, should be deleted);
    • unmatched records in the message are new and should be added;
    • depending on the feed’s selection criteria, recipients’ existing records that are not matched might appear to require deletion. However, this is not the case: data suppliers should use a change of Publishing status (eg publication abandoned or publication out of print) rather than omitting records entirely;
    • full update files can be large, and the repeated supply of unchanged Product records places an unnecessary processing burden on recipients;
  • Delta update – supply of the set of Product records that fall within the feed’s selection criteria and where there has been a change to some data element within the record since a previous full feed or delta update. The message itself has the same structure as a full feed, and the method of processing is identical to a full feed;
    • each Product record carries all available information about that product;
    • but the message size is significantly reduced because unchanged Product records are omitted entirely, which greatly decreases the processing burden for recipients;
    • the sender must maintain a modification date or a full journal of changes for each Product record so unchanged records can be suppressed from each outgoing message, and must also manage a <MessageNumber> for each distinct data feed to ensure recipients can process received messages in the correct order. Messages processed out of order or missed are not ‘self-correcting’;
    • each recipient must ensure every message is parsed and processed in the order they were sent;
    • recipients should first match each received record with existing records on the basis of the <RecordReference>, then replace any and all existing data previously associated with each product with the new data in the latest message (this means that any data previously held for a matched product, but not included in the new delta update, should be deleted);
    • unmatched records in the message are new and should be added;
    • recipients’ existing records that are not matched should be left unchanged;
    • except that any datestamps attached to those unmatched records in the recipient’s system should be updated, because omission of a previously-supplied record from a delta update carries the implication that the previously-supplied data is still correct;
  • Block update – a refined type of delta update, new in ONIX 3.0. The body of a Product record consists of six more or less independent groups of data elements, or ‘blocks’. There are blocks dedicated to describing the nature of product itself, to marketing collateral, to publishing details and territorial rights, etc. These Blocks 1–6 are preceded by data elements in Groups P.1 and P.2 containing information about the record itself and the identifiers (often ISBNs) for the product it describes. This preamble is sometimes informally termed ‘block zero’. A Block update message contains only those Product records where data has changed, and for those records, includes only Groups P.1 and P.2 (‘block zero’) plus whichever of Blocks 1–6 contain data that has changed:
    • this minimizes the message size because unchanged Blocks are omitted;
    • but note that updates cannot be more granular than ‘whole block’ – you cannot send an update that consists of just the data element that has changed;
    • block updates are more complex to implement for both sender and recipient – for example, journalling of changes must be more granular than for ordinary delta updates;
    • many recipients forget that a block update of one or more blocks also signifies no change in all other blocks, which means that the <SentDateTime> of the block update in fact applies to the modified record as a whole. Omission of a block carries the implication that previously-supplied data is still correct, and so any datestamps attached to the old blocks in the recipient’s system should be updated. (In contrast, omission of previously-supplied data elements within a block does imply that data should be deleted);
    • note that Block 6 consists of the repeatable <ProductSupply> composite, ie there is a single and non-repeatable Block 6, within which there may be multiple <ProductSupply> composites representing multiple markets for the product. Any block update including Block 6 should include replacements for all the <ProductSupply> composites previously sent. Omission of a previously-sent <ProductSupply> composite will result in deletion of market information – it does not imply that the omitted market’s details should remain unchanged;
      • if a product is no longer distributed into a market, this should be treated as a change of product status or availability within that market, not as a market that requires deliberate deletion;
    • note that block updates and ‘full record’ updates can be freely mixed within the same delta update message, as they are differentiated at record level (see <NotificationType> within Group P.1);
    • it is likely that some initial ONIX 3.0 implementations will not support block updates, so senders and recipients should discuss their capabilities prior to using block updates, to ensure that the integrity of the data can be maintained;
    • previous versions of ONIX for Books specified a compact Supply Update message format, which was intended to make delivery of price and availability updates more efficient. For ONIX 3.0, a simple price and availability update is not a distinct message type, but a normal block update message consisting only of Groups P.1 and P.2 (‘block zero’) plus Block 6;
      • Block 6 is designed to carry all the metadata that would be required for a price and availability update, including discount and returns information, market rights, etc. A data supplier may routinely send many Block 6 block updates – perhaps even daily – as prices and particularly availabilities fluctuate;
      • Block 6 may also be customized easily to a particular data recipient. While for the most part Blocks 1–5 are ‘universal’, different versions of Block 6 may be sent to different recipients. A data sender could send a generic data feed containing the universal blocks, and a stream of customized Block 6 block updates containing prices tailored to individual wholesalers or retailers.

An important caveat: where recipients are receiving ONIX data (about the same products) from more than one source, then ‘replacement’ of old data with new should be conditional on both the message source and the relative age of the data, as indicated by the sourcetype, sourcename and datestamp attributes (where they are supplied), or by both the <Sender> identity and <SentDateTime>, as it is not always the case that the most reliable data is the latest to arrive. Recipients should generally maintain a ‘hierarchy of trust’ that guides whether data from a particular source should overwrite earlier data from a different and possibly more trusted source – and this hierarchy may differ from data element to element.

And special requirements may apply to Block 6: a recipient may receive price and availability information from multiple sources in separate ONIX feeds, and may wish to maintain them in parallel. For example a retailer may wish to track stock availability from multiple wholesalers.

When dealing with large numbers of products, full update ONIX files can be large. The comprehensive sample message included in the ONIX Specification is a little over 16.5 kilobytes for a single Product record: comprehensive Product records in languages other than English and non-Latin based scripts may be larger. And ONIX messages containing tens of thousands of Product records are not unknown. However, use of delta updates greatly diminishes the typical size and complexity of files: most products are simply omitted from most messages, because they have not been updated (the frequency of updates to a single product is much less than the frequency of update messages). Block updates reduce the amount of data per record and per message even more. ‘Size’ here is a rough proxy for ‘effort required to parse and ingest the data into the recipient’s database’, or the number of insert and update operations that need to be performed on the recipient’s database.

If the concern is filesize itself and the time taken to transfer files across the network (rather than the burden of parsing and ingestion), then using Short tags also helps a little – it usually reduces the message size by around 20–25%, and the sample message with short tags is reduced from 16.7 kilobytes to 12.5 kilobytes – but zipping files before transfer to the recipient is considerably more effective. Zipping can reduce the size by a factor of three or more (much more for larger ONIX files). A zipped version of the sample message – with either long or short tags – is a little under 5 kilobytes. Ratios are a little different in languages other than English and for non-Latin based scripts, and of course neither short tags nor zipping significantly affect the difficulty of the parsing and ingestion process – in general, it does not take significantly longer to process a file using reference names rather than short tags.

The effect of using short tags and ZIP compression on typical ONIX file size
Product recordsreference names
(kB)
short tags
(kB)
reference names
zipped (kB)
short tags
zipped (kB)
1 (sample file)171355
100 (production file)14051117175170

ZIP compression reduces the file size of typical large (English language) ONIX production files by up to 80%. Note that zipped reference name files are not significantly larger than zipped short tag files.

Reference names are more commonly used than Short tags, but both are fully supported in ONIX 3.0.
There is a Tagname Converter available, a short XSLT script to translate an ONIX message between Reference names and Short tags (or vice versa). Many XML software tools are available to process the XSLT. The Converter is available from www.editeur.org/93/Release-3.0-Downloads/#Tools.

ONIX messages are normally exchanged via FTP, with the data sender depositing files on a server maintained by the recipient (‘push’), or by the sender maintaining a file on a server that one or multiple recipients download. The latter ‘pull’ approach is considerably more difficult to combine with delta and block updates, as the sender has no control over the frequency that fresh data is downloaded by the recipient – though it might be possible by providing a full file at the beginning of each month, then retaining that file plus all subsequent delta or block updates on the server until the end of the month, and only deleting all the updates and adding a replacement full update file at the beginning of the next month.

As an alternative to FTP, transferring messages as e‑mail attachments may be suitable for messages with small numbers of Product records (fewer than about 100 records).

The Media type (‘MIME type’) for such e‑mail attachments should typically be ‘application/xml’, or ‘application/xml+zip’ if the file is zipped before sending.

The naming of ONIX files transferred from sender to recipient is not defined by the standard. Clearly, naming schemes have to be agreed in advance between sender and recipient, but a practical naming scheme would probably combine a name for the sender (since the recipient may be receiving files from many senders), plus an element that indicates the order in which multiple files must be parsed, such as:

  • the Message sequence and Repeat numbers (the <MessageNumber> and <MessageRepeat> data elements included in the message header);
  • the Message creation date and time (the <SentDateTime> data element from the message header).
  • a year and ordinal day number (a number from 1 to 365 or 366). This cannot be used if intra-day updates might be required;

The first of these options is likely to be the simplest in cases where <MessageNumber> is used, and is preferred. Where <MessageNumber> is not used, other options are acceptable so long as the order of messages implied by the file naming matches the actual order recorded in <SentDateTime>.

ONIX file names commonly include the ‘.xml’, ‘.onix’ or ‘.onx’ suffix (the first two are preferred).

Templar_286_2.onix (second repeat of message number 286 from Templar Publishing)
LBBG20101211.xml (file from Little Brown Book Group sent on 11th December 2010)
RHGUK2010345.xml (a file sent by Random House UK, on 11th Dec [day 345] of 2010)

In addition to transferring the ONIX message data from sender and recipient, supply chain partners need to exchange supporting resources such as cover images (see Group P.16). The ideal method here is the ‘pull’ model, in which the recipient downloads the collateral resource from a URL provided within the ONIX Product record (and the download would be triggered based on the ‘last updated’ date attached to the resource metadata in the ONIX). In practice, it is more common for recipients to push collateral resources to an FTP server maintained by the recipient – in effect a separate feed, perhaps with the filename provided in the ONIX metadata.

Sender and recipient may also need to agree a method for exchange of post-publication price and availability information. While this can be carried very effectively within a continuing series of ONIX messages – and clearly ONIX implementors are encouraged to use this mechanism – it is also common for post-publication price and availability updates to use other message standards. EDItEUR maintains a family of XML-based message formats under the EDItX banner, and a family of older EDIFACT EDI formats. Other EDI formats such as ANSI X.12 or Tradacoms might also be used. Great care is needed to ensure that if EDItX or an EDI method is used for price and availability updates, there is no conflict with information in a post-publication ONIX message sent to update information other than price or availability – in many cases, because the risk of conflict cannot be eliminated, when EDItX or EDI is in use for post-publication price and availability, Block 6 should not be sent in ONIX records sent post-publication.

Implied license to use ONIX data

Certain data included within, cited by or linked from an ONIX message – for example, excerpts from the product, tables of contents, long descriptive text, cover or contributor images and other resources – is likely to be subject to copyright. The data in an ONIX message may also be the subject of other property rights, for example a sui generis database right.

ONIX data sent to a recipient is sometimes accompanied by an explicit and formal license covering use of that data. However – even in the absence of an explicit license – when a data supplier provides an ONIX message to a data recipient, there is a clear invitation extended to the recipient with an ‘implied license’ to use the product data supplied for the purposes of cataloging, trading in, merchandising, promoting and selling the products described, both internally within the recipient organization and in customer-facing applications. ONIX data recipients should treat the implied license as limited, non-exclusive, non-transferable, non-sublicensable, and should not substantively modify, redistribute or provide access to the data in bulk to third parties either commercially or non-commercially without express permission. ONIX recipients should also treat compliance with Embargo, Valid From/Until and Announcement dates, Audience limitations, display of required credits and the like as a duty of the implied license, and should ensure reasonable efforts are made to process data updates from the supplier in a timely way (including requests to remove the data from public view in the case of legal or other issues). A typical retailer might not require anything beyond this implied license.

For the avoidance of doubt, it is strongly recommended that recipients wishing to make substantive modifications to any data (as opposed to using the data as supplied) and/or intending to redistribute the data in bulk to a third party in any manner should secure an explicit license from the data supplier rather than relying solely on the implied license.

Formal agreements such as would be required for commercial or non-commercial redistribution of data supplied in an ONIX message (eg by a data aggregator) or for provision of third-party bulk access to the data (eg via an API) should be concluded separately between data supplier and recipient. These agreements might cover both permitted use of the supplied data and the duties and service level expectations placed upon data supplier and recipient.

Checking your messages meet best practice

If you are an experienced XML developer, then you will have a range of software tools to validate the structure of any ONIX file against one or other of the ONIX schemas (these are available in XSD, RNG and DTD format, though the XSD and RNG are strongly recommended in preference to the DTD). EDItEUR uses the cross-platform oXygen XML editor but other, similar software tools are equally suitable, for example Altova‘s XML Spy or various software (including command line tools) based on libxml. Validation is an essential discipline.

But even the ONIX XSD and RNG schemas check only the structure of the ONIX file and the content of those data elements which use controlled vocabularies from the codelists – they do not validate the content of free text data elements or the check digits of identifiers, nor can such schemas check for potential internal inconsistencies in the Product record. Validation with a conventional schema is not – in itself – enough.

EDItEUR has developed an extended ‘strict’ schema (using XSD 1.1) that does check identifier check digits, a range of ‘business rules’ and internal consistency requirements (‘co-occurrence constraints’). A version of the XSD 1.1 is available from the EDItEUR website. Note however that XSD 1.1 is not supported by all XML validation frameworks. For more details, see Appendix A.10.
Many product data management applications which support ONIX output incorporate applcation-level checking of business rules to improve the consistency of data output, and a ‘scorecard‘ approach to ensure data is comprehensive and aligns with best practice.

If you are not experienced with XML, then it can be difficult to judge whether your ONIX data is structured correctly and contains data in line with these best practices. However, XML is only a text file: in principle, it can be read and edited by plain text editors such as Notepad++ (on Windows), or BBEdit (on Mac OS), and it can be viewed (but not edited) in a web browser. Even the simple built-in Notepad (Windows) or TextExit (Mac OS) applications can be used – but do not be tempted to use a word processor. If you do aim to check your ONIX data this way, it is best to stick to a very small ONIX file – no more than a couple of dozen Product records.

Opening a small ONIX file in a modern web browser (Firefox 4+, Chrome 9+, Safari 5.1+, Edge 20+, IE9+) or text editor (Notepad++, TextWrangler) produces a display like this:

 <Product>
       <RecordReference>com.globalbookinfo.onix.01734529</RecordReference>
       <NotificationType>03</NotificationType>
       <RecordSourceType>04</RecordSourceType>
     <RecordSourceIdentifier>
           <RecordSourceIDType>06</RecordSourceIDType>
           <IDValue>0614141800001</IDValue>
       </RecordSourceIdentifier>
       <RecordSourceName>Global Bookinfo</RecordSourceName>
     <ProductIdentifier>
           <ProductIDType>03</ProductIDType>
           <IDValue>9780007232833</IDValue>
       </ProductIdentifier>
     <ProductIdentifier>
           <ProductIDType>15</ProductIDType>
           <IDValue>9780007232833</IDValue>
       </ProductIdentifier>
     <DescriptiveDetail>
           <ProductComposition>00</ProductComposition>
           <ProductForm>BC</ProductForm>
           <ProductFormDetail>B105</ProductFormDetail>
         <Measure> … </Measure>
         <Measure>
               <MeasureType>02</MeasureType>
               <Measurement>130</Measurement>
               <MeasureUnitCode>mm</MeasureUnitCode>
           </Measure>

This highlights the markup (colored), the data (black) and the nesting structure (via indenting). Clicking on the triangles ( or ) hides or reveals the contents of the composite elements – the first of the two <Measure> composites has been collapsed in the example above.

Web browsers add the indentation automatically, and often appear to show extra new lines within data elements containing text with XHTML markup:
   <BiographicalNote textformat="05">
       <p>
            <strong>Maj Sjöwall</strong>
            was born in Stockholm…
These extra new lines are not present in the ONIX data, and are only added for display purposes. The original data most likely reads:
    <BiographicalNote textformat="05"><p><strong>Maj Sjöwall</strong> was born in Stockholm…

Note also that web browsers will often modify &lt; and &amp;, and display them as < and & – so if you’re checking textual data with HTML markup, a plain text editor is recommended, at least until you are sure the syntax of your ONIX is correct.

Text editors like Notepad++ and TextWrangler do similar syntax coloring and collapsing of composites (sometimes called ‘code folding’), and they also helpfully number each line of the XML. They do not (usually) add automatic indentation to highlight the XML structure or add misleading line breaks within text elements using XHTML. The basic built-in Notepad and TextEdit applications do not do coloring, folding, line numbering or automatic indentation.

This very basic technique makes it straightforward – though laborious – to check your ONIX file against the examples given in this guide, or to discover how data elements in a publisher’s internal application are expressed in the ONIX messages that the application sends.

It’s often simple to associate database fields in an internal application with XML data elements in an ONIX message. If the application’s user interface for a contributor contains several data fields like those shown below, the mapping from user interface field to ONIX data element is quite clear: Title goes into <TitlesBeforeName>, Given name goes into <NamesBeforeKey>, Family name is used to populate <KeyNames> and the Role field is used to work out the code carried in the ONIX <ContributorRole>. The application might also calculate the <PersonName> and <PersonNameInverted> data elements by combining the parts of the name in the correct order.

Title Given name Prefix Family name Suffix Role Add Prof. Steve Jones (author) +

An application with this user interface could generate the following ONIX XML:

<Contributor>
    <SequenceNumber>1</SequenceNumber>
    <ContributorRole>A01</ContributorRole>
    <PersonName>Prof. Steve Jones</PersonName>
    <PersonNameInverted>Jones, Prof. Steve</PersonNameInverted>
    <TitlesBeforeNames>Prof.</TitlesBeforeNames>
    <NamesBeforeKey>Steve</NamesBeforeKey>
    <KeyNames>Jones</KeyNames>
</Contributor>

However this simple user interface also suggests that the application might not properly support Hungarian or east Asian names, since there is no apparent way to populate the relevant <NamesAfterKey> ONIX data element. The application may not be able to differentiate corporate from personal names. And the application may impose a limitation of one role per contributor that prevents the ONIX from complying with best practice when, for example, a single contributor is both author and illustrator.

What can complicate such seemingly-straightforward mappings between parts of an application’s interface and the ONIX messages that the application might send or receive is that many applications use a relational or hierarchical structure to make managing metadata more efficient. Changing a single data field in the user interface (say the Family name) may affect many ONIX Product records, not just a single record. And since ONIX messages may contain data owned or managed by several different departments within a sender organization, the ONIX may be assembled from data taken from several different applications.

Mapping between data elements in an ONIX Product record and database columns in an internal application applies to ONIX recipients too: each distributor, data aggregator or retailer has to parse the ONIX data it receives, and insert the data from its suppliers into the internal database (product catalog). The structure of a retailer’s internal product catalog is likely to be very different from the structure of the database the publisher used to create the ONIX data: since there is usually much less need to manage the data actively, a retailer is less likely to use a highly normalized database structure and may opt for judicious denormalization to gain some performance improvements.

It’s important to understand that creating usable ONIX for Books data is not simply a matter of creating a file that conforms to the structural requirements of ONIX. Ensuring the right data is embedded in each data element, ensuring the data is accurate and that there are no internal inconsistencies, and ensuring that each Product record contains all the data that ONIX recipients require – and that it’s delivered in a timely fashion – are all vital. The business process and workflow challenge inherent in introducing ONIX to an organization is usually much greater than the technical challenge.

ONIX for Books Message header

Header composite

Header Sender Addressee MessageNumber MessageRepeat SentDateTime MessageNote DefaultLanguageOfText DefaultLanguageOfText DefaultPriceType DefaultCurrencyCode DefaultCurrencyCode
sending a <Header>
using Reference names
<Header>
    <Sender>
        <SenderIdentifier>
            <SenderIDType>06</SenderIDType>GLN
            <IDValue>5030670137992</IDValue>
        </SenderIdentifier>
        <SenderIdentifier>
            <SenderIDType>07</SenderIDType>SAN
            <IDValue>0137995</IDValue>
        </SenderIdentifier>
        <SenderName>HarperCollins UK</SenderName>
        <ContactName>Jane King</ContactName>
        <EmailAddress>jbk@hcp.co.uk</EmailAddress>
    </Sender>
    <Addressee>
        <AddresseeIdentifier>
            <AddresseeIDType>06</AddresseeIDType>GLN
            <IDValue>5030670090754</IDValue>
        </AddresseeIdentifier>
        <AddresseeIdentifier>
            <AddresseeIDType>07</AddresseeIDType>SAN
            <IDValue>0090751</IDValue>
        </AddresseeIdentifier>
        <AddresseeName>Gardners Books</AddresseeName>
    </Addressee>
    <MessageNumber>262</MessageNumber>
    <SentDateTime>20100510</SentDateTime>
</Header>
using Short tags
<header>
    <sender>
        <senderidentifier>
            <m379>06</m379>
            <b244>5030670137992</b244>
        </senderidentifier>
        <senderidentifier>
            <m379>07</m379>
            <b244>0137995</b244>
        </senderidentifier>
        <x298>HarperCollins UK</x298>
        <x299>Jane King</x299>
        <j272>jbk@hcp.co.uk</j272>
    </sender>
    <addressee>
        <addresseeidentifier>
            <m380>06</m380>
            <b244>5030670090754</b244>
        </addresseeidentifier>
        <addresseeidentifier>
            <m380>07</m380>
            <b244>0090751</b244>
        </addresseeidentifier>
        <x300>Gardners Books</x300>
    </addressee>
    <m180>262</m180>
    <x307>20100510</x307>
</header>
Sender composite

The <Sender> composite is mandatory, and identifies the sender of the ONIX message file.

Sender SenderIdentifier SenderName ContactName EmailAddress SenderIdentifier SenderIDType IDTypeName IDValue must not omit both must include if ID is proprietary, otherwise omit

It is best practice to include:

  • any applicable identifiers for the sender organization in one or more repeats of the <SenderIdentifier> composite;
  • the business name of the sender organization in the <SenderName> element;
    • in many cases, the same identifier and name are repeated in <RecordSourceIdentifier> and <RecordSourceName>, where the message as a whole is created by the organization that is also responsible for the data within each Product record;
  • the name and e‑mail address of a contact person who is responsible for the technical and operational aspects of the ONIX message, in the <ContactName> and <EmailAddress> elements.

The preferred identifier for international use is the GLN (Global Location Number), although in many countries, there are also local and industry-specific identifiers that are widely used, and these should also be supplied – for example, in many Anglophone countries, the SAN (Standard Address Number) is well established and in other countries, company or tax registration numbers are commonly used. The GLN is a global, cross-industry scheme administered by GS1 for identifying physical addresses. The SAN is an earlier, publishing-specific identifier for physical addresses maintained by Bowker, and is likely to be superseded by the GLN over the next few years. However, SANs are built into many widely-used electronic trading systems – particularly in the English-language book trade – and it is best practice to provide both wherever possible. Note with both SAN and GLN, the referent is an address rather than an organization. The organization is identified only by implication or proxy, as operating at that address. A single organization may have several address identifiers, each identifying a different physical location (for example the publishing office and a distribution warehouse), and care should be taken to ensure the correct identifiers are used. In Germany, the Verkehrsnummer administered by the Börsenverein is similar.

There is a central database of GLNs that you can use to look up details of the identified locations – GS1’s GEPIR service. Note there are caveats, and the data it returns is imperfect and occasionally misleading. SANs can be looked up via the assigning agencies Nielsen and Bowker.
SANs and GLNs are – to some degree – interoperable. Some SANs may be prefixed with a six-digit ‘magic number’, then the check digit recalculated to create a valid GLN. If you have a SAN but no GLN, contact your SAN Agency to discuss conversion.

The business name of the sender organization should not include suffixes such as ‘Inc’, ‘SA’ or ‘Ltd’, unless they are required to distinguish similarly-named organizations. However, where a single organization has several business units that send ONIX messages independently, a suffix should be added to indicate which business unit is responsible for the message.

Providing a contact name and e‑mail address is important as this may be used for automated notification of receipt of the message, or when a recipient has a query about the content of the message.

Addressee composite

The <Addressee> composite is optional. However, it is best practice to include it when ONIX messages are prepared for specific recipients – for example where the message contains details of retailer-specific products – and it can be repeated if the message is intended for a specific set of recipients (eg for several bibliographic data aggregators, or for multiple wholesalers). The composite should be omitted if a single message file is made generally available, for example if it is placed on an FTP site for downloading by any supply chain partner.

Addressee AddresseeIdentifier AddresseeIdentifier AddresseeName ContactName EmailAddress AddresseeIdentifier AddresseeIDType IDTypeName IDValue must not omit both must include if ID is proprietary, otherwise omit

If one or more <Addressee> composites are included, then each should include:

  • any applicable identifiers for the recipient organization in one or more repeats of the <AddresseeIdentifier> composite;
  • the business name of the recipient organization in the <AddresseeName> element.

These data elements mirror those in the <Sender> composite, and similar recommendations apply.

H.13 Message sequence number

A message sequence number is optional. However, for practical purposes, it must be included in any data exchange where delta files or block updates are used – that is, where ONIX messages contain only those Product records where some change has occurred since the previous message – and its inclusion is strongly encouraged even when full (not delta) data files are used. It is vital that the recipient processes received messages in the correct order, and is able to identify whenever a message has been missed.

The message sequence number is a simple integer that increments by 1 for each new message in a particular data feed. Note that where an organization is generating multiple messages tailored for specific recipients or sets of recipients, the message sequence number for each recipient or set of recipients must be managed independently, and the <Addressee> composite used consistently to identify individual data feeds. Thus a publisher may send out a sequence of generic messages without any <Addressee> composites, plus a sequence of tailored messages with an <Addressee> composite identifying retailer X, using the following message sequence numbers:

  • message 123 sent to all recipients
  • message 261 sent to X
  • message 124 to all
  • message 125 to all
  • message 262 to X
  • message 126 to all
  • message 263 to X

In this way, any recipient can identify whenever a message is missing or duplicated. While this is complex, using a simpler scheme based on, say, the day number lacks clarity when events like public holidays intervene – was there meant to be a message on day 125 (Cinco de Mayo)? – or when messages are sent irregularly. A sequence number makes it clear that if message 126 arrives while the recipient is expecting 125, then a message has been missed. And if 125 arrives when 126 is expected, it’s a duplicate message. Similarly, if updates are sent to a regular schedule but the sender deliberately skips a message (perhaps because no records need updating), upon receipt of the ‘next’ regular update, the sequence numbers make it clear that the recipient did not miss a message.

If there is any reason to ensure a regular schedule of messages is maintained, even when no Product records require updating, it is possible to send an ‘empty update’ – a delta file containing no Product records. In addition to the normal <Header> elements, this uses the <NoProduct/> element to provide a positive indication that the message is solely intended as a placeholder. The message sequence number should be incremented as normal, and the only net effects of the empty update upon the recipient system should be to confirm that all previously-received data remains correct, and to increment the expected value of the next message number in the sequence of messages.

Senders sometimes maintain a data feed consisting of a sequence of delta files interspersed with occasional full feed files, perhaps daily deltas and a full file once per four weeks. This ensures that if anything goes amiss with the processing of the deltas, it is automatically corrected at the next full feed. In this case, the sequence numbers of the delta files should increment as normal. If the full feed at the end of the month takes the place of one of the deltas (ie there are 27 deltas and one full feed in a 28 day period, and the full feed must be processed because it may contain updates that are not included in any delta) then it should be given the next sequential number. If the full feed serves only to confirm (ie there are 28 daily deltas plus one full feed in a 28 day period, and the full feed does not contain any updates that are not included in the deltas), the full feed should be given the same sequence number as the last delta. This emphasizes that the end result should be the same whether the recipient processes the full file, or processes all deltas including the last.

H.15 Message creation date/time

The <SentDateTime> element is mandatory.

Where a sender sends out no more than one message per day (in any particular data feed), and the recipient receives data exclusively from the sender, then the format YYYYMMDD is usually adequate. Where a sender may send multiple messages per day, or the recipient needs to aggregate data from multiple sources, then a more precise time should be included. Either of the formats:

  • YYYYMMDDThhmmZ (exact time expressed as UTC)
  • YYYYMMDDThhmm±hhmm (exact time, with a timezone offset)

are recommended. Similar formats with second precision (YYYYMMDDThhmmss±hhmm or YYYYMMDDThhmmssZ) are available, but times to the nearest second are unlikely to be needed. Formats including a time but without timezone information (such as YYYYMMDDThhmm) can be ambiguous and are not recommended. These considerations also apply to the datestamp attribute that acts as a datestamp on individual data elements (a datestamp should be included when the ‘age and reliability’ of a particular data element is significantly different from that of the overall message, such as when data from disparate sources is compiled into an aggregated data feed).

sent on 14th August at 3:10pm in a time zone four hours behind UTC, for example Toronto on Eastern Daylight Time (Eastern Standard Time, with Daylight Saving in operation)
using Reference names
<SentDateTime>20120814T1510-0400</SentDateTime>
using Short tags
<x307>20120814T1910Z</x307>
The two times here are the same – 3:10pm EDT is 19:10 UTC. Use of UTC times is preferred.

No dateformat attribute is required or allowed with the <SentDateTime> element or with a datestamp attribute, and the possible date and time formats are a small subset of those that may be used in other parts of an ONIX message (see List 55). Dates within <SentDateTime> and datestamp (ie the YYYYMMDD part) must always use the Gregorian calendar, even if other dates within the message use other calendars. Times within <SentDateTime> and datestamp (ie the hhmm or hhmmss part) can be specified in any timezone (the ±hhmm part), but using UTC is strongly preferred (the time is suffixed with Z).

Note that in the absence of datestamp information attached to individual data elements or composites, the <SentDateTime> element may be used to indicate when the data in the message was correct (according to the sender), and it is assumed there is no significant delay between generation of the message and its availability to the recipient. In general, in any data feed, the order of messages indicated by <SentDateTime> will be the same as the order indicated by <MessageNumber>. However, in a scenario where delta files are used, <SentDateTime> cannot be used by a recipient to identify when a message has been missed, so <MessageNumber> should be used for ensuring messages are processed in the correct sequence.

H.17 to H.19 Message defaults

It is best practice to omit any <DefaultLanguageOfText>, <DefaultPriceType> and <DefaultCurrencyCode> elements from the header, and to ensure the equivalent information is included within each Product record instead.

ONIX for Books Product record

Product composite

Every ONIX for Books message must contain at least one repeat of the <Product> composite. Each <Product> composite – a ‘Product record’ – contains a mandatory preamble comprising data element Groups P.1 and P.2 that together identify the record itself and the product to which it refers (the preamble is sometimes informally called ‘block zero’). This is followed by some or all of Blocks 1–6 (each Block is optional).

Product RecordReference RecordReference NotificationType DeletionText RecordSourceType RecordSourceType RecordSourceIdentifier RecordSourceIdentifier RecordSourceName RecordSourceName ProductIdentifier Barcode DescriptiveDetail CollateralDetail ContentDetail PublishingDetail RelatedMaterial ProductSupply Preamble (‘block zero’) Block 1 Block 2 Block 3 Block 4 Block 5 Block 6 consists of the combination of all <ProductSupply> composites Must include at least one of Blocks 1–6 (unless <NotificationType> = 05)

There are two typical types of Product record, distinguished by their <NotificationType> element. The first and (currently) most common type, contains all applicable information for the product: thus it contains Groups P.1 and P.2 plus most or all of the Blocks 1–6. This type of Product record may be supplied in the context of a ‘full’ data feed where the ONIX message contains Product records for all the supplier’s products, or it may be supplied in the context of a ‘delta’ feed where a message contains only Product records which contain data that has been updated since a previous message was sent. In either case, all previously-supplied data for the product should be entirely replaced by the new data in the message. Data from any previously-supplied records relating to products not included in a delta message should continue to be used unchanged.

Note that, for recipients, the treatment of the records in the message is the same, whether the message is a full-feed or a delta – the difference between the two is simply in the selection of records included in the message.

The second type, as yet not in widespread use, is a ‘block-level partial update’ (or simply, ‘block update’) record that contains Groups P.1 and P.2 (which are sometimes informally referred to as ‘block zero’) plus only those of Blocks 1–6 which contain data that has changed since a previous Product record was supplied. If a particular Product record contains only Groups P.1, P.2 and Block 4, it means that recipients should update information based on the Groups and Blocks supplied, and any previously-supplied data from Blocks 1–3, 5 and 6 should continue to be used unchanged. This type of Product record may be supplied only in the context of a ‘delta’ feed, and must also be distinguished with <NotificationType> code 04.

Note that for a block-level partial update, if any of the data in a block has changed, the whole block must be supplied. Granularity of updates does not extend below block level.

This update strategy means that if a previously-supplied data element is not supplied in any update (full or partial), then the previously-supplied data should be deleted from the recipient’s systems. For example, if a previous message included three contributors, and the update contains only two, the third contributor should be deleted (and in fact, it’s more correct to say that all three previous contributors should be deleted, then the newly-supplied two should be re-inserted).

Block 6 consists of the repeatable <ProductSupply> composite: for the purposes of sending block-level partial updates, a record containing several repeats of <ProductSupply> has only one Block 6. If one particular repeat must be updated, all repeats must be included in the block update. But for recipients, Block 6 is exceptional: a recipient may receive supply detail information from several sources (eg a retailer may receive data from a distributor and from several wholesalers). For Blocks 1–5, one particular source of data is likely to be definitive or more trusted. But for Block 6, the recipient should probably treat each feed separately – the wholesaler’s Block 6 may need to be retained in parallel with the Block 6 received from the distributor.

P.1 Record reference, type and source

identifying a Product record (using a meaningless internal ID)
using Reference names
<!-- record 71 of 246 -->
<Product>
    <RecordReference>com.xyzpublishers.onix.32032</RecordReference>
    <NotificationType>02</NotificationType>
    <RecordSourceType>01</RecordSourceType>
    <RecordSourceName>XYZ Publishers</RecordSourceName>
    . . . 
</Product>
using Short tags
<!-- record 71 of 246 -->XML comment
<product>
    <a001>com.xyzpublishers.onix.32032</a001>Row ID from internal database
    <a002>02</a002>Advance notification
    <a194>01</a194>From publisher
    <a197>XYZ Publishers</a197>
    . . . 
</product>
identifying a Product record (using a UUID)
using Reference names
<!-- record 31 of 46 -->
<Product>
    <RecordReference>f3a85abd-f29e-4e0b-92cc-2fa6a0833022</RecordReference>
    <NotificationType>04</NotificationType>
    <RecordSourceType>01</RecordSourceType>
    <RecordSourceName>XYZ Publishers</RecordSourceName>
    . . . 
<Product>
using Short tags
<!-- record 31 of 46 -->
<product>
    <a001>f3a85abd-f29e-4e0b-92cc-​2fa6a0833022​</a001>Type 4 UUID
    <a002>04</a002>Block-level partial update
    <a194>01</a194>From publisher
    <a197>XYZ Publishers</a197>
    . . . 
</product>
identifying a Product record sent for testing purposes
using Reference names
<!-- record 1 of 1 (test) -->
<Product>
    <RecordReference>com.xyzpublishers.onix.9932032</RecordReference>
    <NotificationType>89</NotificationType>
    <RecordSourceType>01</RecordSourceType>
    <RecordSourceName>XYZ Publishers</RecordSourceName>
    . . . 
</Product>
using Short tags
<!-- record 1 of 1 (test) -->
<product>
    <a001>com.xyzpublishers.onix.9932032</a001>Test ID should not match any previously-sent live ID
    <a002>89</a002>Test record
    <a194>01</a194>From publisher
    <a197>XYZ Publishers</a197>
    . . . 
</product>
deleting a Product record that was issued in error
using Reference names
<Product>
    <RecordReference>com.a2b.wms.01234567</RecordReference>
    <NotificationType>05</NotificationType>
    <DeletionText>Record issued in error – use record com.​a2b.​wms.​01234574 instead​</DeletionText>
    <RecordSourceType>03</RecordSourceType>
    <RecordSourceName>A2B Logistics</RecordSourceName>
    <ProductIdentifier>
        <ProductIDType>15</ProductIDType>
        <IDValue>9780001234567</IDValue>
    </ProductIdentifier>
</Product>
using Short tags
<product>
    <a001>com.a2b.wms.01234567</a001>
    <a002>05</a002>Deletion
    <a199>Record issued in error – use record com.​a2b.​wms.​01234574 instead​</a199>
    <a194>03</a194>From wholesaler
    <a197>A2B Logistics</a197>
    <productidentifier>
        <b221>15</b221>
        <b244>9780001234567</b244>ISBN for confirmation
    </productidentifier>
</product>
P.1.1 Record reference

The <RecordReference> element is mandatory in every Product record. It serves to identify the Product record itself, so it must obviously be unique within a particular ONIX message file, and must not change if the Product record (with either identical or modified data) is resupplied in a subsequent message. Note the record reference does not identify the product, but rather the collection of metadata that describes the product. For this reason, the record reference should not be (or look like) a product identifier such as an ISBN. However, the record reference may include a product identifier within some longer string of characters, where for example the publisher’s internal product management system relies on the ISBN as a key field.

Reliance on an external public identifier as a key field in an internal database is generally considered bad practice. Database keys should be unique and persistent of course, but ideally also meaningless (ie have low affordance). In an internal database design, ISBNs are best treated as attributes of each record, and arbitrary row IDs or UUIDs generated by the database, or purely internal product identifiers, would be ideal key fields – this maximizes the flexibility of the database design, and of course ensures that records can be added to the database prior to ISBN assignment.

Data recipients may receive Product records relating to a single product from multiple sources – for example, a retailer may receive different records for the same product from several wholesalers. In order to ensure these records can be distinguished and – if necessary – managed separately, record references should as far as possible be globally unique: to ensure uniqueness, it is a good practice to use a record reference that includes a reversed Internet domain name (for example, ‘com.xyzpublisher’). Ideally this should be suffixed with an internal product identifier, or with a product identifier such as the ISBN. An arbitrary internal identifier (such as a record ID in an internal database) is somewhat better than an ISBN, as it will remain unchanged in the rare case where an ISBN may need to be corrected. Alternatively, a UUID (Universally Unique Identifier) constructed in accordance with RFC 4122 would make a good Record reference (types 1 or 4 are best).

When creating unique record references in this way, avoid the characters /, \, $, *, %, ? plus the space and colon characters. Why? Because the record reference can be used to construct filenames for supporting resources (see Group P.16) and these characters often have special meanings or are not allowed in filenames.

Where a single organization has more than one IT system that generates ONIX messages, the record reference should also include an indication of which system the record was generated by.

See P.1.4 Record source type code for details of how data aggregators/redistributors should handle record references.

P.1.2 Notification or update type code

The mandatory <NotificationType> element specifies the ‘type’ of Product record – whether the Product record contains pre-publication data that is subject to significant change, or whether it contains data confirmed upon or subsequent to publication.

The notification type changes in Product records issued at different times in the product’s lifecycle. Later Product records may be matched with their predecessors by matching the <RecordReference> element. An initial ONIX record may be issued a few months in advance of expected publication, with <NotificationType> 01 or 02 (values are taken from List 1). This may be followed by successive updated records with the matching <RecordReference> and with <NotificationType> 02 or 04 (the former for a full update of the whole record, the latter for a block-level partial update containing P.1, P.2 plus only those of Blocks 1–6 that have been updated). It is best practice to issue a full update with type 03 to confirm publication, even when block updates are used otherwise, and even when nothing other than the <PublishingStatus> in Block 4 and the <ProductAvailability> in Block 6 have changed. Any post-publication updates – for example price and availability updates – would be types 03 or 04.

Note that List 1 contains other notification type codes for various special purposes: code 05 should be used to indicate a record (as identified by its <RecordReference>) should be deleted (but also see <DeletionText> in P.1.3), and codes 08 and 09 should be used to provide notice of sale and acquisition of products (as identified by a product identifier in P.2, not the <RecordReference>, since it is unlikely the two publishers concerned will use the same Record reference). Code 08, a notice of sale that is sent by the former publisher, should if possible be dealt with as a block update by senders and recipients, since best practice for this record type is to include P.1, P.2 and Block 4 only. Code 09, a notice of acquisition, should be treated as a full update, and should be sent by the acquiring publisher. Records containing notification type codes 88 and 89 should always be ignored if they appear in a live data feed – they are intended for use in test messages only, and it is highly inadvisable to mix test and live records in the same ONIX message.

The diagram shows the <NotificationType> codes of two possible sequences of matching product records within a series of ONIX messages, the left timeline starting with an initial message sent more than six months in advance of expected publication and using only ‘full update’ Product records, and the right timeline starting with an initial message sent fewer than six months in advance of publication and using block-level ‘partial update’ Product records.

About six months prior to publication date Publication date Out of print date Type 01 Type 02 Type 02 Type 03 Type 03 Type 03 Type 02 Type 04 Type 03 Type 04 Type 04 Time

When using a potentially very long series of block updates, it is still a useful practice to provide a full update (type 03) at the time of publication for confirmation purposes. This ensures that the record is corrected around publication time, even if earlier updates were applied wrongly for any reason.

Note that the very first inclusion of a particular product in a data feed does not necessarily use <NotificationType> 01 – the notification type indicates the ‘age’ relative to the publication date, and thus provides some measure of confidence in the data. Data in records with <NotificationType> 01 should be treated as highly provisional, and some recipients may choose not to use type 01 records in consumer-facing contexts. If the first notification is later than six months prior to publication, confidence in the data should be higher, and type 02 should be used immediately even if this is the first time the record has been included in a feed. Type 03 should indicate a very high degree of confidence in the data – though this still does not preclude future post-publication correction of genuine errors, updates of data elements such as price and availability, or enhancement of the data by addition of extra information.

In principle, Product records with differing <NotificationType> codes can be freely mixed within a single ONIX for Books message. However, senders should check with recipients before introducing any block-level partial updates, since not all recipients can cope with records of this type.

For recipients, the treatment of Product records with notification types 01, 02 and 03 is identical. First check whether a Product record with a matching Record reference has been received earlier. If so, it is a record update, and all data in the existing record should be replaced by the newly-received information (this might be through deleting the old record and creating a new one). Otherwise, a new record should be created using the newly-received information. For a record with notification type 04, only certain parts of the existing record should be updated, according to which Blocks are newly-received.

Recipients receiving a record with <NotificationType> 05 should attempt to delete the record altogether. This may not always be possible, particularly if the notification is sent close to or after publication, as for example there may be records of orders, deliveries, shipments or sales attached to the product in the recipient’s system. However, recipients should delete as much of the data as possible. It is good practice to send <DeletionText> with any notification of this type, to highlight why the data should be deleted. It is a common error to send <NotificationType> 05 when products are abandoned, postponed indefinitely or put out of print. While the intention of the sender may be to remove the product from the recipient’s online store, for example, these should be treated as changes of publishing status, never as deletions. Use of code 05 should be very rare, and used only for true deletions – for example where the record was issued in error, or where data must be deleted for legal reasons.

P.1.3 Reason for deletion

When the <NotificationType> code is 05, the reason for deletion should be included. Deletion refers to deletion of a metadata record, not to ‘deletion’ of a product – for example, deletion might be used to resolve a problem where two records have inadvertently been issued for the same product. Abandonment or cancellation of a planned and announced product, or declaring an existing product out of print are not reasons for deletion of a Product record from recipient systems (they should be treated as changes of <PublishingStatus> in Group P.20 or <MarketPublishingStatus> in Group P.25).

Deletions should be extremely rare, and are likely to be processed manually by data recipients.

<DeletionText> is one of a number of textual data elements that are repeatable in order that parallel text may be provided in multiple languages. See the notes with <BiographicalNote> for a fuller explanation.

P.1.4 Record source type code

<RecordSourceType>, <RecordSourceName> and – if possible – <RecordSourceIdentifier> should be set, particularly when they indicate that the record source is different from the <Sender> organization. This happens when data from multiple sources is aggregated and redistributed, for example by a distributor, wholesaler or bibliographic data supplier.

Where an organization aggregates and redistributes product data, the Product records within the redistributed data might retain the same <RecordReference> as the data supplied to the aggregator, or the aggregator may attach new a <RecordReference> to each record. The choice here should be guided by whether the aggregator simply resends exactly what is received, or whether the data is actively managed before redistribution. In the former case, where aggregation is a purely technical exercise, the original record reference should be retained, and the original source of each record should be indicated in <RecordSourceType>, <RecordSourceName> and possibly <RecordSourceIdentifier> data elements. The aggregator should use the <Sender> information, or the <RecordSourceType>, <RecordSourceName> and <RecordSourceIdentifier> elements, from the received records to populate these data elements. In addition, the <SentDateTime> from the received records may be reused as a datestamp attribute attached to the <Product> element in the sent data to indicate the age of the data.

Conversely, if the aggregator actively manages the data prior to redistribution, the aggregator assumes effective responsibility for the data. As a result, it should use a new <RecordReference> and record source information on each record. This clearly indicates that the aggregator is responsible for the redistributed data. This way, the combination of <Sender> information in the <Header> of a message containing redistributed data and the Record source information within each Product record indicate where responsibility for the data content lies.

RecordSourceIdentifier RecordSourceIDType RecordSourceIDType IDTypeName IDValue must include if ID is proprietary, otherwise omit
The preferred <RecordSourceIDType> for international use is the GLN (code 06 from List 44).

P.2 Product identifiers

identifying a product with an ISBN and proprietary SKU
using Reference names
<ProductIdentifier>
    <ProductIDType>03</ProductIDType>GTIN-13
    <IDValue>9780001234567</IDValue>
</ProductIdentifier>
<ProductIdentifier>
    <ProductIDType>15</ProductIDType>ISBN
    <IDValue>9780001234567</IDValue>
</ProductIdentifier>
<ProductIdentifier>
    <ProductIDType>01</ProductIDType>Proprietary
    <IDTypeName>BookPoint Wholesale SKU</IDTypeName>
    <IDValue>BP0054321</IDValue>
</ProductIdentifier>
using Short tags, with additional ISBN-A
<productidentifier>
    <b221>03</b221>GTIN-13
    <b244>9780001234567</b244>
</productidentifier>
<productidentifier>
    <b221>15</b221>ISBN
    <b244>9780001234567</b244>
</productidentifier>
<productidentifier>
    <b221>01</b221>Proprietary
    <b233>BookPoint Wholesale SKU</b233>
    <b244>BP0054321</b244>
</productidentifier>
<productidentifier>
    <b221>06</b221>DOI
    <b244>10.978.000/1234567</b244>
</productidentifier>
<productidentifier>
    <b221>26</b221>ISBN-A
    <b244>10.978.000/1234567</b244>
</productidentifier>
Product identifier composite

At least one repeat of the <ProductIdentifier> composite is mandatory. Typically this will carry a standard identifier such as the ISBN that can be used for orders or sales reports within a trading relationship, but the whole composite is repeatable and other standard identifiers, and proprietary identifiers or SKUs may be sent in addition.

ProductIdentifier ProductIDType IDTypeName IDValue must include if ID is proprietary, otherwise omit
Do not bypass <IDTypeName> if <ProductIDType> is proprietary (code 01). Conversely, omit <IDTypeName> for non-proprietary identifier types. This applies to proprietary identifiers in similar composites throughout ONIX 3.0.

For any item that carries an ISBN, it is best practice to include the identifier twice, in separate repeats of the <ProductIdentifier> composite with <ProductIDType> codes 03 and 15. Why? Because some recipients are looking specifically for an ISBN, others for any GTIN-13. The same applies to a product carrying an ISMN (use codes 03 and 25). If instead the product carries a GTIN-13 that is not an ISBN or ISMN, this should be carried in a composite with <ProductIDType> code 03. ISBNs, ISMNs and GTIN-13s should not include hyphens or spaces.

Very occasionally, a product has both an ISBN and a separate GTIN-13 that is not an ISBN. While the assignment of a separate GTIN to an item with an ISBN is entirely unnecessary (the ISBN is by definition also a valid GTIN-13), it sometimes happens that a stationery item which has a GTIN-13 enters the books supply chain where some organization requires an ISBN. If this is unavoidable, the ISBN should be carried with <ProductIDType> code 15 and the ‘other’ GTIN-13 should be carried with code 03.

If the product’s ISBN is also registered as an ISBN-A (‘Actionable ISBN’), this should be carried in two further composites with type code 06 (ie as a DOI) and code 26 (ie specifically as an ISBN-A) – just as with ISBN and GTIN-13. And note that for a DOI or ISBN-A, the period and slash ( / ) characters plus any hyphens and other punctuation characters are an essential part of the identifier. A <ProductIdentifier> composite carrying an ISBN-A should always be accompanied by a composite carrying the matching ISBN – thus it is best practice to include three <ProductIdentifier> composites alongside a composite carrying an ISBN-A (the ISBN-A itself, plus the generic DOI, the ISBN and the generic GTIN-13). All, of course, carry essentially the same number.

In some trading relationships, the GTIN-14 identifier is useful. Broadly, the GTIN-14 identifies trade items, whereas the GTIN-13 identifies retail items. So where an ONIX record describes multiple retail items in a trade-only pack, the pack may be identified with a GTIN-14. The GTIN-14 may be specified in the metadata record (for the pack) using <ProductIDType> code 14 (and within this record, the GTIN-13 of the items in the pack should be carried inside <ProductPart>). There may also be a separate metadata record for the individual retail items in the pack, and that record should not include the GTIN-14. Note that although any GTIN-13 may be expressed as a GTIN-14 simply by prefixing it with a zero, an ONIX record should not carry a GTIN-14 constructed ‘artificially’ in this way, unless the product actually carries a GTIN-14 barcode (which uses a different barcode ‘symbology’ from the GTIN-13).

ISBN-10 has been obsolete since January 2007, and the use of UPCs in the book trade has been deprecated since 2005. The continued use of obsolete identifiers such as the ISBN-10 or UPC is strongly discouraged, but they may still be needed by certain recipients within the context of a specific trading relationship. If provided, they should be carried alongside an ISBN or GTIN-13.

Use of non-product specific ‘identifiers’ such as price-point GTIN-12s (formerly called UPCs or UCC-12s) as the only identifier is not sufficient as these do not identify specific tradeable items. However, item-specific GTIN-12s or UPCs do identify tradeable items, and should be included in the metadata when (and only when) the product carries a UPC number or barcode, and should use <ProductIDType> code 04. Although any GTIN-12 may be expressed as a GTIN-13 by prefixing the GTIN-12 with a zero, an ONIX record should not carry a GTIN-13 constructed in this way (as for example it would imply the use of a different barcode symbology).

If a proprietary identifier such as a publisher’s internal product identifier, a catalog number or a wholesaler’s SKU is used (<ProductIDType> code 01), then a ‘namespace’ – a consistent name for that identifier scheme – should always be included in the <IDTypeName> element. This applies to all uses of proprietary identifiers or proprietary coding schemes within ONIX for Books – a name for the scheme or identifier should always be included. When minting such names, the data provider should try to promote uniqueness by (for example) including an appropriate organization or domain name, and some indication of what is being identified. ‘PubID’ and ‘SKU’ are not a good names – too likely to be used by others and thus likely not to be unique – whereas ‘Olive Press SKU’ or ‘com.duckhouse.product.id’ are much better. The <IDTypeName> data element has a suggested maximum length of 50 characters.

Including an Amazon ASIN
using Reference names
<ProductIdentifier>
    <ProductIDType>16</ProductIDType>
    <IDValue>9780001234567</IDValue>
</ProductIdentifier>
<ProductIdentifier>
    <ProductIDType>01</ProductIDType>
    <IDTypeName>Amazon ASIN</IDTypeName>
    <IDValue>0001234560</IDValue>
</ProductIdentifier>
using Short tags
<productidentifier>
    <b221>15</b221>ISBN
    <b244>9780001234567</b244>
</productidentifier>
<productidentifier>
    <b221>01</b221>Proprietary
    <b233>Amazon ASIN</b233>Namespace – name of identifier scheme
    <b244>0001234560</b244>
</productidentifier>
Note that for books with an ISBN beginning 978, Amazon states that the ASIN is the same as the obsolete ISBN-10. This cannot be true for ISBNs starting 979, since these ISBNs do not have an ISBN-10 equivalent, and any ASIN created using the same method could duplicate an existing ASIN.

Many supply chain organizations (correctly) allocate so-called ‘2-series’ GTIN-13s as proprietary identifiers. These numbers (thirteen digits beginning with 2, 02 or 04 and ending with the usual GTIN calculated check digit) come from a range of GTINs designated ‘for internal use only’ or for restricted circulation. Such proprietary identifiers should not usually be included in ONIX records, since they are not intended for communication between organizations. If they are included, in the context of an agreed one-to-one exchange of ONIX data between parties, they must be treated as proprietary IDs, with <ProductIDType> 01 and a suitable, likely-to-be-unique name in <IDTypeName>, and not as GTIN-13s with <ProductIDType> 03.

The <ProductIdentifier> composite is also used to deliver various identifiers that are not used for supply chain transactions, but are important to particular groups of data users – for example library identifiers such as Library of Congress control numbers, OCLC identifiers and national legal deposit numbers. Where these are included in the Product record, they should be accompanied by one or more standard commercial product identifiers.

Barcode composite

This composite specifies whether the product carries a printed barcode, and if so, its symbology and optionally its position. Although in most countries the use of GTIN-13 barcodes on physical products is ubiquitous and need not be stated, in North America the continued use of GTIN-12s (formerly termed UPCs) means that the symbology information is valuable to retailers. It should be repeated where a product carries more than one barcode.

Importantly, the composite should also be used to provide a positive indication that a physical product does not carry a barcode, even when it might be expected (perhaps because the product is of unusually small size).

Barcode BarcodeType PositionOnProduct PositionOnProduct omit if <BarcodeType> indicates not barcoded
standard ISBN (GTIN-13) barcode on back cover
using Reference names
<Barcode>
    <BarcodeType>02</BarcodeType>
    <PositionOnProduct>01</PositionOnProduct>
</Barcode>
using Short tags
<barcode>
    <x312>02</x312>GTIN-13 symbology (no extension)
    <x313>01</x313>on Cover 4 (outside back cover)
</barcode>
no barcode
using Reference names
<Barcode>
    <BarcodeType>00</BarcodeType>
</Barcode>
using Short tags
<barcode>
    <x312>00</x312>No barcode on product
</barcode>

Block 1: Product description

Descriptive detail composite

Block 1 of the Product record is intended to carry the core information about the physical or digital nature of the product, its title and authorship, content and subject matter, and it’s target audience.

DescriptiveDetail (P.3 and P.4) ProductComposition ProductComposition ProductForm ProductFormDetail ProductFormDetail ProductFormFeature ProductFormFeature ProductPackaging ProductPackaging ProductFormDescription ProductFormDescription TradeCategory PrimaryContentType PrimaryContentType ProductContentType ProductContentType Measure CountryOfManufacture CountryOfManufacture EpubTechnicalProtection EpubTechnicalProtection EpubUsageConstraint EpubUsageConstraint EpubLicense MapScale ProductClassification ProductClassification ProductPart Continued in Group P.5

P.3 Product form

Additional guidance on the description of digital products in ONIX 3.0 will be found in a separate document ONIX for Books Product Information Message: How to Describe Digital Products in ONIX 3.

describing the form of a simple paperback book product
using Reference names, with measurements provided in both Imperial and metric units for broad international use including North America
<ProductComposition>00</ProductComposition>
<ProductForm>BC</ProductForm>
<ProductFormDetail>B101</ProductFormDetail>Rack-size paperback
<Measure>6⅞ × 4¼ in, ⅝ in spine
    <MeasureType>01</MeasureType>
    <Measurement>6.875</Measurement>
    <MeasureUnitCode>in</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>02</MeasureType>
    <Measurement>4.25</Measurement>
    <MeasureUnitCode>in</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>03</MeasureType>
    <Measurement>0.625</Measurement>
    <MeasureUnitCode>in</MeasureUnitCode>
</Measure>
<Measure>Weight 7⅛ oz
    <MeasureType>08</MeasureType>
    <Measurement>7.125</Measurement>
    <MeasureUnitCode>oz</MeasureUnitCode>
</Measure>
<Measure>Same measurements
    <MeasureType>01</MeasureType>using mm and gr
    <Measurement>175</Measurement>
    <MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>02</MeasureType>
    <Measurement>108</Measurement>
    <MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>03</MeasureType>
    <Measurement>16</Measurement>
    <MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>08</MeasureType>
    <Measurement>202</Measurement>
    <MeasureUnitCode>gr</MeasureUnitCode>
</Measure>
<CountryOfManufacture>US​</CountryOfManufacture>Manufactured in USA
using Short tags, with measurements provided in metric units only, for international use excluding North America
<x314>00</x314>Single-component product
<b012>BC</b012>Paperback
<b333>B106</b333>Trade paperback (UK usage)
<measure>Traditional ‘Demy’ size
    <x315>01</x315>216 × 138 mm, 19 mm spine
    <c094>216</c094>
    <c095>mm</c095>
</measure>
<measure>
    <x315>02</x315>
    <c094>138</c094>
    <c095>mm</c095>
</measure>
<measure>
    <x315>03</x315>
    <c094>19</c094>
    <c095>mm</c095>
</measure>
<measure>Weight 345 gr
    <x315>08</x315>
    <c094>345</c094>
    <c095>gr</c095>
</measure>
<x316>GB</x316>Made in UK
US usage of ‘trade paperback’ is close to UK usage of ‘B-format’. UK usage of ‘trade paperback’ indicates a paperback produced in a larger size (typically a Demy or Royal size).
describing a packaged multi-component product (small book and audio CD in a blister pack)
using Reference names
<ProductComposition>10</ProductComposition>
<ProductForm>SA</ProductForm>
<ProductPackaging>22</ProductPackaging>
<Measure>
    <MeasureType>01</MeasureType>
    <Measurement>145</Measurement>
    <MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>02</MeasureType>
    <Measurement>195</Measurement>
    <MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>03</MeasureType>
    <Measurement>11</Measurement>
    <MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>08</MeasureType>
    <Measurement>195</Measurement>
    <MeasureUnitCode>gr</MeasureUnitCode>
</Measure>
<!-- P.4 Product parts must be included, with -->
<!-- separate Country of Manufacture per item -->
using Short tags
<x314>10</x314>Multi-component product
<b012>SA</b012>Packaging unspecified
<b225>22</b225>Blister pack
<measure>
    <x315>01</x315>Pack is 145 × 195 mm,
    <c094>145</c094>11 mm thick
    <c095>mm</c095>
</measure>
<measure>Note shape is ‘landscape’
    <x315>02</x315>
    <c094>195</c094>
    <c095>mm</c095>
</measure>
<measure>
    <x315>03</x315>
    <c094>11</c094>
    <c095>mm</c095>
</measure>
<measure>Weight 195 gr
    <x315>08</x315>
    <c094>195</c094>
    <c095>gr</c095>
</measure>
<!-- P.4 Product parts must be included, -->
<!-- with separate x316 per item -->
providing e‑book details for an enhanced EPUB format product, with usage constraints such as ‘printing is disallowed’ enforced by technical protection measures (‘DRM’), and a link to the end user license agreement
using Reference names
<ProductComposition>00</ProductComposition>
<ProductForm>ED</ProductForm>
<ProductFormDetail>E101</ProductFormDetail>
<ProductFormDetail>E201</ProductFormDetail>
<ProductFormDetail>E202</ProductFormDetail>
<ProductFormFeature>
    <ProductFormFeatureType>15</ProductFormFeatureType>
    <ProductFormFeatureValue>101B</ProductFormFeatureValue>
</ProductFormFeature>
<PrimaryContentType>10</PrimaryContentType>
<ProductContentType>06</ProductContentType>
<ProductContentType>13</ProductContentType>
<EpubTechnicalProtection>03</EpubTechnicalProtection>
<EpubUsageConstraint>
    <EpubUsageType>05</EpubUsageType>
    <EpubUsageStatus>01</EpubUsageStatus>
</EpubUsageConstraint>
<EpubUsageConstraint>
    <EpubUsageType>03</EpubUsageType>
    <EpubUsageStatus>02</EpubUsageStatus>
    <EpubUsageLimit>
        <Quantity>10</Quantity>
        <EpubUsageUnit>05</EpubUsageUnit>
    </EpubUsageLimit>
</EpubUsageConstraint>
<EpubUsageConstraint>
    <EpubUsageType>06</EpubUsageType>
    <EpubUsageStatus>02</EpubUsageStatus>
    <EpubUsageLimit>
        <Quantity>1</Quantity>
        <EpubUsageUnit>10</EpubUsageUnit>
    </EpubUsageLimit>
    <EpubUsageLimit>
        <Quantity>14</Quantity>
        <EpubUsageUnit>09</EpubUsageUnit>
    </EpubUsageLimit>
</EpubUsageConstraint>
<EpubUsageConstraint>
    <EpubUsageType>02</EpubUsageType>
    <EpubUsageStatus>03</EpubUsageStatus>
</EpubUsageConstraint>
<EpubLicense>
    <EpubLicenseName>New Street Publishers EULA v2</EpubLicenseName>
    <EpubLicenseExpression>
        <EpubLicenseExpressionType>01​</EpubLicenseExpressionType>
        <EpubLicenseExpressionLink>http://www.NewStreetPublishers.com/​licenses/EULA_v2<EpubLicenseExpressionLink>
    </EpubLicenseExpression>
</EpubLicense>
using Short tags (additionally, printing is allowed but restricted)
<x314>00</x314>Single-component product
<b012>ED</b012>Digital download
<b333>E101</b333>EPUB format
<b333>E201</b333>Fixed format
<b333>E202</b333>Does not require network connection (the video and audio resources are packaged within the EPUB itself)
<productformfeature>
    <b334>15</b334>File format version code
    <b335>101B</b335>EPUB 3.0
</productformfeature>
<x416>10</x416>Eye-readable text
<b385>06</b385>Enhanced with video
<b385>13</b385>and audio content
<x317>03</x317>ACS4 DRM
<epubusageconstraint>
    <x318>05</x318>Text to speech
    <x319>01</x319>Is unrestricted
</epubusageconstraint>
<epubusageconstraint>
    <x318>03</x318>Copy/paste
    <x319>02</x319>Is limited
    <epubusagelimit>
        <x320>10</x320>Ten
        <x321>05</x321>Percent
    </epubusagelimit>
</epubusageconstraint>
<epubusageconstraint>
    <x318>06</x318>Lending
    <x319>02</x319>Is limited
    <epubusagelimit>
        <x320>1</x320>Only one
        <x321>10</x321>Occasion
    </epubusagelimit>
    <epubusagelimit>
        <x320>14</x320>For fourteen
        <x321>09</x321>Days
    </epubusagelimit>
</epubusageconstraint>
<epubusageconstraint>
    <x318>02</x318>Printing
    <x319>02</x319>Is limited
    <epubusagelimit>
        <x320>64</x320>Max of 64 pages
        <x321>04</x321>
    </epubusagelimit>
    <epubusagelimit>
        <x320>72</x320>Max of 72dpi
        <x321>21</x321>
    </epubusagelimit>
</epubusageconstraint>
<epublicense>
    <x511>New Street Publishers EULA v2</x511>
    <epublicenseexpression>
        <x508>01</x508>Intended for the lay reader
        <x510>http://www.​NewStreetPublishers.​com/​licenses/​EULA_v2<x510>
    </epublicenseexpression>
</epublicense>
providing both folded and flat dimensions, plus scales, for a road map with larger-scale inset city map panels
using Reference names
<ProductComposition>00</ProductComposition>
<ProductForm>CB</ProductForm>
<Measure>
    <MeasureType>01</MeasureType>
    <Measurement>245</Measurement>
    <MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>02</MeasureType>
    <Measurement>140</Measurement>
    <MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>10</MeasureType>
    <Measurement>980</Measurement>
    <MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>11</MeasureType>
    <Measurement>1120</Measurement>
    <MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>08</MeasureType>
    <Measurement>125</Measurement>
    <MeasureUnitCode>gr</MeasureUnitCode>
</Measure>
<CountryOfManufacture>ES</CountryOfManufacture>
<MapScale>500000</MapScale>
<MapScale>25000</MapScale>
using Short tags
<x314>00</x314>Single-component product
<b012>CB</b012>Sheet map, folded
<measure>Folded size
    <x315>01</x315>245 × 140 mm
    <c094>245</c094>
    <c095>mm</c095>
</measure>
<measure>
    <x315>02</x315>
    <c094>140</c094>
    <c095>mm</c095>
</measure>
<measure>
    <x315>10</x315>980 × 1120 mm flat
    <c094>980</c094>
    <c095>mm</c095>
</measure>
<measure>
    <x315>11</x315>
    <c094>1120</c094>
    <c095>mm</c095>
</measure>
<measure>
    <x315>08</x315>Weight 125 gr
    <c094>125</c094>
    <c095>gr</c095>
</measure>
<x316>ES</x316>Manufactured in Spain
<b063>500000</b063>Scale 1cm to 5km
<b063>25000</b063>Insets at 4cm to 1km
trade pack containing multiple books
using Reference names
<ProductIdentifier>
    <ProductIDType>03</ProductIDType>
    <IDValue>9780001234550</IDValue>
</ProductIdentifier>
<ProductIdentifier>
    <ProductIDType>15</ProductIDType>
    <IDValue>9780001234550</IDValue>
</ProductIdentifier>
. . . 
<ProductComposition>30</ProductComposition>
<ProductForm>XL</ProductForm>
<Measure>
    <MeasureType>01</MeasureType>
    <Measurement>395</Measurement>
    <MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>02</MeasureType>
    <Measurement>260</Measurement>
    <MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>03</MeasureType>
    <Measurement>216</Measurement>
    <MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>08</MeasureType>
    <Measurement>1950</Measurement>
    <MeasureUnitCode>gr</MeasureUnitCode>
</Measure>
<ProductPart>
    <ProductIdentifier>
        <ProductIDType>03</ProductIDType>
        <IDValue>9780001234567</IDValue>
    </ProductIdentifier>
    <ProductIdentifier>
        <ProductIDType>15</ProductIDType>
        <IDValue>9780001234567</IDValue>
    </ProductIdentifier>
    <ProductForm>BC<ProductForm>
    <ProductFormDetail>B105</ProductFormDetail>
    <NumberOfCopies>48</NumberOfCopies>
    <CountryOfManufacture>GB</CountryOfManufacture>
</ProductPart>
using Short tags
<productidentifier>
    <b221>03</b221>GTIN-13 and…
    <b244>9780001234550</b244>
</productidentifier>
<productidentifier>
    <b221>15</b221>ISBN of the pack
    <b244>9780001234550</b244>
</productidentifier>
. . . 
<x314>30</x314>Multi-item trade-only pack
<b012>XL</b012>Shrink-wrapped pack
<measure>
    <x315>01</x315>197 × 130mm, 18mm spine,
    <c094>394</c094>packed 2 × 2 × 12
    <c095>mm</c095>(48 copies total)
</measure>
<measure>
    <x315>02</x315>
    <c094>260</c094>
    <c095>mm</c095>
</measure>
<measure>
    <x315>03</x315>
    <c094>216</c094>
    <c095>mm</c095>
</measure>
<measure>
    <x315>08</x315>
    <c094>1950</c094>
    <c095>gr</c095>
</measure>
<productpart>
    <productidentifier>
        <b221>03</b221>GTIN-13 and…
        <b244>9780001234567</b244>
    </productidentifier>
    <productidentifier>
        <b221>15</b221>ISBN of the book(s) in the pack
        <b244>9780001234567</b244>(the ISBNs and GTIN-13s of the book and the pack must be different)
    </productidentifier>
    <b012>BC<b012>B-format paperback
    <b333>B105</b333>
    <x323>48</x323>48 copies
    <x316>GB</x316>
</productpart>
Book (only available as part of the above trade pack)
using Reference names
<ProductIdentifier>
    <ProductIDType>03</ProductIDType>
    <IDValue>9780001234567</IDValue>
</ProductIdentifier>
<ProductIdentifier>
    <ProductIDType>15</ProductIDType>
    <IDValue>9780001234567</IDValue>
</ProductIdentifier>
. . . 
<ProductComposition>00</ProductComposition>
<ProductForm>BC</ProductForm>
<Measure>
    <MeasureType>01</MeasureType>
    <Measurement>197</Measurement>
    <MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>02</MeasureType>
    <Measurement>130</Measurement>
    <MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>03</MeasureType>
    <Measurement>18</Measurement>
    <MeasureUnitCode>mm</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>08</MeasureType>
    <Measurement>40</Measurement>
    <MeasureUnitCode>gr</MeasureUnitCode>
</Measure>
. . . 
<PublishingStatus>13</PublishingStatus>
. . . 
<RelatedProduct>
    <ProductRelationCode>02</ProductRelationCode>
    <ProductIdentifier>
        <ProductIDType>03</ProductIDType>
        <IDValue>9780001234550</IDValue>
    </ProductIdentifier>
    <ProductIdentifier>
        <ProductIDType>15</ProductIDType>
        <IDValue>9780001234550</IDValue>
    </ProductIdentifier>
</RelatedProduct>
. . . 
<ProductAvailability>45</ProductAvailability>
using Short tags
<productidentifier>
    <b221>03</b221>GTIN-13 and…
    <b244>9780001234567</b244>
</productidentifier>
<productidentifier>
    <b221>15</b221>ISBN of the book
    <b244>9780001234567</b244>
</productidentifier>
. . . 
<x314>00</x314>Single-component product
<b012>BC</b012>Paperback
<measure>
    <x315>01</x315>197 × 130mm, 18mm spine
    <c094>197</c094>
    <c095>mm</c095>
</measure>
<measure>
    <x315>02</x315>
    <c094>130</c094>
    <c095>mm</c095>
</measure>
<measure>
    <x315>03</x315>
    <c094>18</c094>
    <c095>mm</c095>
</measure>
<measure>
    <x315>08</x315>
    <c094>40</c094>
    <c095>gr</c095>
</measure>
. . . 
<b394>13</b394>Active, but not sold separately
. . . 
<relatedproduct>
    <x455>02</x455>
    <productidentifier>
        <b221>03</b221>GTIN-13 and…
        <b244>9780001234550</b244>
    </productidentifier>
    <productidentifier>
        <b221>15</b221>ISBN of the pack containing
        <b244>9780001234550</b244>multiple copies of the book
    </productidentifier>
</relatedproduct>
. . . 
<j396>45</j396>Not sold separately
For the above two examples, note how the pack refers to the book as a Product part, and the book refers to the pack using <RelatedProduct> with Product relation code 02.
book-as-toy with safety warnings (EU Toy Safety Directive)
using Reference names
<ProductComposition>00</ProductComposition>
<ProductForm>BK</ProductForm>
<ProductFormDetail>B213</ProductFormDetail>
<ProductFormDetail>B215</ProductFormDetail>
<ProductFormFeature>
    <ProductFormFeatureType>13</ProductFormFeatureType>
    <ProductFormFeatureValue>01</ProductFormFeatureValue>
</ProductFormFeature>
<ProductFormFeature>
    <ProductFormFeatureType>13</ProductFormFeatureType>
    <ProductFormFeatureValue>07</ProductFormFeatureValue>
    <ProductFormFeatureDescription>http://www.livrescoccinelle.fr/​4123/​CEdéclaration.pdf​</ProductFormFeatureDescription>
</ProductFormFeature>
<ProductFormFeature>
    <ProductFormFeatureType>13</ProductFormFeatureType>
    <ProductFormFeatureValue>03</ProductFormFeatureValue>
    <ProductFormFeatureDescription>Not suitable for children under 36 months, due to small parts​</ProductFormFeatureDescription>
</ProductFormFeature>
<ProductFormFeature>
    <ProductFormFeatureType>13</ProductFormFeatureType>
    <ProductFormFeatureValue>05</ProductFormFeatureValue>
    <ProductFormFeatureDescription>Not tested on animals​</ProductFormFeatureDescription>
</ProductFormFeature>
<!-- <Measure> omitted for brevity -->
<CountryOfManufacture>CN</CountryOfManufacture>
using Short tags, with safety warning text provided in two parallel languages (English and French)
<x314>00</x314>Single item product
<b012>BK</b012>Novelty book
<b333>B213</b333>Book-as-toy
<b333>B215</b333>Fuzzy felt book
<productformfeature>
    <b334>13</b334>EU Toy Safety
    <b335>01</b335>Carries ‘CE’ logo
</productformfeature>
<productformfeature>
    <b334>13</b334>EU Toy Safety
    <b335>07</b335>‘CE’ Declaration of Conformity
    <b336>http://www.livrescoccinelle.fr/​4123/​CEdéclaration.pdf​</b336>URL of full document
</productformfeature>
<productformfeature>
    <b334>13</b334>EU Toy Safety hazard warning
    <b335>03</b335>Carries ‘0–3’ logo and warning
    <b336 language="eng">Not suitable for children under 36 months, due to small parts​</b336>Publisher’s exact wording of warning
    <b336 language="fre">Ne convient pas aux enfants de moins de 3 ans, contient de petites pièces susceptibles d’être ingérées​</b336>
</productformfeature>
<productformfeature>
    <b334>13</b334>EU Toy Safety
    <b335>05</b335>Associated non-warning text
    <b336 language="eng">Not tested on animals​</b336>Publisher’s exact wording of associated text
    <b336 language="fre">Non testé sur les animaux​</b336>
</productformfeature>
<!-- <measure> omitted for brevity -->
<x316>CN</x316>Made in China
Where textual data is provided in parallel languages, the language attribute must be included for each language. Where only a single language is provided, the attribute is optional.
P.3.1 Product composition

The <DescriptiveDetail> composite must begin with a mandatory <ProductComposition> element, to specify whether the product:

  • is a solus item (codes 00 or 20 from List 2);
  • contains multiple items (for example, several volumes in a set retailed as one product, or a ‘classroom pack’ of textbooks, with code 10);
  • contains multiple items that are expected to be retailed individually (code 30);
  • Code 11 is an exception in that it describes a collection that is not itself a product.

If the record is not a solus item (ie <ProductComposition> codes 10, 11,30 or 31) then P.4 Product part information should always be included in the Product record, and the Product form and Product parts should also indicate a multi-component product or multi-item pack.

Note that products such as an audiobook that consists of multiple CDs are often not treated as a multi-component retail product (ie it is common to use <ProductComposition> code 00, and the number of discs may only be specified in <ProductFormDescription>). This is somewhat inconsistent, as a multi-volume collection available as a single item – for example, a boxed set of books – is generally treated as a multiple-component retail product (ie use <ProductComposition> code 10). However, individual discs are almost never available separately: they have essentially no value without the remainder of the discs, nor do they have individual product identifiers, so treating a multi-disc audiobook as a multi-component product and enumerating the discs using a single repetition of <ProductPart> may sometimes be viewed as unnecessary:

describing a multi-disc audiobook as a multiple-component retail product
using Reference names
<ProductComposition>10</ProductComposition>
<ProductForm>SA</ProductForm>
<ProductPackaging>05</ProductPackaging>
<ProductFormDescription>5 discs</ProductFormDescription>
<!-- <Measure> omitted for brevity -->
<CountryOfManufacture>AT</CountryOfManufacture>
<ProductPart>
    <!-- discs not individually identified -->
    <ProductForm>AC</ProductForm>
    <ProductFormDetail>A101</ProductFormDetail>
    <NumberOfItemsOfThisForm>5</NumberOfItemsOfThisForm>
</ProductPart>
using Short tags
<x314>10</x314>Multi-component product
<b012>SA</b012>Packaging unspecified
<b225>05</b225>In jewel case
<b014>5 discs</b014>
<!-- <measure> omitted -->
<x316>AT</x316>Pressed in Austria
<productpart>
    <!-- discs not individually identified -->
    <b012>AC</b012>CD-Audio
    <b333>A101</b333>‘Red book’
    <x322>5</x322>5 discs
</productpart>
describing a multi-disc audiobook as a single-component product
using Reference names
<ProductComposition>00</ProductComposition>
<ProductForm>AC</ProductForm>
<ProductFormDetail>A101</ProductFormDetail>
<ProductPackaging>05</ProductPackaging>
<ProductFormDescription>5 discs</ProductFormDescription>
<!-- <Measure> omitted for brevity -->
<CountryOfManufacture>AT</CountryOfManufacture>
<!-- no ProductPart composite required -->
using Short tags
<x314>00</x314>Single-component product
<b012>AC</b012>CD-Audio
<b333>A101</b333>‘Red book’
<b225>05</b225>In jewel case
<b014>5 discs</b014>
<!-- <measure> omitted -->
<x316>AT</x316>Pressed in Austria
<!-- no productpart composite -->

These two examples have exactly equivalent meanings, but the former, more explicit version which treats the product as having multiple components is strongly preferred, particularly if the multiple discs are (or could plausibly become) available separately or there is some other reason to describe the discs individually. If despite this, the single-component method is used, is also possible to specify the number of discs in <Extent> – but <ProductFormDescription> or both are preferred to <Extent> only.

P.3.2 Product form code

This element is mandatory within the <DescriptiveDetail> composite, and for single-component products specifies the physical or digital nature of the product.

It is generally not good practice to use any of the generic ‘detail unspecified’ codes from List 150, for example code BA for ‘Book – detail unspecified’ or code PA for ‘Miscellaneous print – detail unspecified’, unless the product is being described many months before publication and the detail is genuinely undecided. In this case, the generic Product form code must be updated in a later ONIX message. Occasionally, an unusual product might need both a <ProductForm> code and a full description of the product in <ProductFormDescription>.

For multi-component products with <ProductComposition> code 10, codes SB–SF from List 150 describe the way that the items are packaged together for retail sale (eg slipcased, shrinkwrapped or with smaller items physically enclosed within the largest item). However, the <ProductPackaging> data element is more flexible, and may be used with <ProductForm> code SA. This implies there are two acceptable ways to describe multi-component products, for example the product form and packaging of several related volumes in a slipcase (commonly termed a ‘boxed set’):

describing a boxed set without using <ProductPackaging>
using Reference names
<ProductComposition>10</ProductComposition>
<ProductForm>SC</ProductForm>
using Short tags
<x314>10</x314>Multi-component product
<b012>SC</b012>In slip-case
using <ProductPackaging> to describe a boxed set
using Reference names
<ProductComposition>10</ProductComposition>
<ProductForm>SA</ProductForm>
<!-- intervening elements not shown -->
<ProductPackaging>11</ProductPackaging>
using Short tags
<x314>10</x314>Multi-component product
<b012>SA</b012>Packaging unspecified
<!-- intervening elements not shown -->
<b225>11</b225>Slip-cased set

These two examples have exactly equivalent meanings, but the former method is preferred. However, the latter method may be used whenever codes SB–SF do not adequately describe the packaging method.

For multi-item trade packs with <ProductComposition> codes 30 or 31, codes XC, XE and XL from List 150 should be used whenever possible, rather than using code XA plus <ProductPackaging>. If <ProductPackaging> is included, this should refer to the packaging of the trade pack itself, not to the packaging of each item within the trade pack. If codes XC, XE or XL do not adequately describe the outer packaging of the trade-only pack, use code XA plus descriptive text in <ProductFormDescription>.

P.3.3 Product form detail

Although this is an optional data element, for certain values of <ProductForm> it provides vital extra detail.

And where such detail is provided, <ProductFormDetail> is also repeatable – there may be several properties of the product that are important. For this and other repeatable simple data elements (eg <MapScale>), it is obviously an error to repeat the same information, and although validation via the DTD or schema will not reject such repetition, extended schema validation may do so.

For audio products:

  • use <ProductForm> code AC only for CD-Audio (in the sense of ‘Red Book’ CD-Audio or SACD discs) products, which are eligible to carry the relevant standards compliance logos;
    • then use <ProductFormDetail> codes A101 and A102 to differentiate CD-Audio and SACD products
  • use <ProductForm> code AE for ‘Yellow Book’ data discs which contain audio data in other data formats. Two good examples are ‘MP3 CDs’, which should not carry the Compact Disc Digital Audio logo but which are playable in some CD or DVD player devices, and DAISY books distributed on CD media;
    • then use other <ProductFormDetail> codes to specify the format of the audio data on the disc (WAV, MP3, AAC etc);
    • reserve <ProductForm> code DB for other types of CD-Rom that contain non-audio data;
  • use <ProductForm> code ED in preference to code AJ for downloadable digital audio products:
    • then use other <ProductFormDetail> codes to specify the data format – for example code A109 for proprietary Audible.com format, A103 for a generic MP3 format or A107 for an AAC file;
    • in addition, as with e‑books, you may include <EpubTechnicalProtection> and <EpubUsageConstraint> information to describe any limitations on usage of the downloaded data, and any DRM or other technical protection measures.

For printed book products:

  • where <ProductForm> is BB or BC, <ProductFormDetail> B1xx codes may be used to indicate common named categories of product which indicate a certain combination of product form, physical size and sometimes also target market and terms of trade. Physical sizes may be approximate: in contrast, exact measurements should be given in the <Measure> composite;
  • note the different meaning of ‘Trade paperback’ in the US and UK, and the very similar ‘Paperback (DE)’ in the German book trade;
  • other <ProductFormDetail> codes should be included to specify any other important feature of the product – for example a feature of a children’s book such as die-cutting or pop-up engineering, or features of fine binding such as the use of acid-free paper, real leather or half-binding.

For e-publications such as e‑books, mobile apps including book text, <ProductFormDetail> is used to specify either:

  • a non-proprietary file format such as EPUB (a standard maintained by the W3C and formerly by the IDPF), where any usage constraints and any technical protection measures (DRM) that enforce those usage constraints should be specified separately using the <EpubTechnicalProtection> element and <EpubUsageConstraint> composite;
  • a proprietary file format, which may include platform-specific technical protection. Any usage constraints and technical protection should be specified using <EpubTechnicalProtection> and the <EpubUsageConstraint> composite;
  • further repeats of <ProductFormDetail> can be used to specify whether the text within the e‑book reflows or is ‘fixed-format’, what shape of screen a fixed-format e‑book is optimized for, whether there are any network-based resources that form a part of the e‑book, or whether content present in an equivalent printed publication has been omitted from the e‑book (a common occurrence with trade non-fiction books subsequently converted to e‑book, where illustration rights cannot be obtained).
Owing to the rapid evolution of e-publication types, this distinction in the treatment of proprietary and non-proprietary file formats is not a strict rule. Additional guidance on the description of digital products in ONIX 3.0 will be found in a separate document ONIX for Books Product Information Message: How to Describe Digital Products in ONIX 3.

There are common-sense affinities between values of <ProductForm> and values of <ProductFormDetail>. As illustration, these values for <ProductFormDetail> are intended for use only in combination with listed values for <ProductForm>.

Description ProductForm ProductFormDetail
CD-AudioACA101–A102
Digital audio filesAA, AE, AJ–L, AZ, D*, E*A103–A112
A201–A212
All audioA*, D*, E*A301–A304
Paperback booksBCB101–B107
B113–B114, B116–B118
B504
Hardback booksBBB115
B306–B307, B315
B401–B402
Loose leafBDB301–B303
Spiral-boundBEB311–B314
Fine bindingBGB308–B309
B403–B406
All printed booksB*B108–B112, B119–B130
B201–B215
B304–B305, B310
B409–B415
B501–B503, B505–B510
B601–B602
B701–B707
Digital video filesD*, E*, VA, VZD101–D105
Digital on carrierD*D201–D207
D301–D316
e‑books and ‘apps’D*, E*E1xx
E2xx
CalendarsPCP101–P113
Calendars or organizersPC, PSP114
StationeryPA, PB, PF, PL, PR, PS, PZP201–P204
Analogue videoVA, VI–K, VZV201–V203

The associations listed in the table are not enforced by the XSD or RNG schemas, but may be enforced by an extended schema. Other combinations might superficially ‘work’, but do not make sense: for example the combination of Product form AG (Sony’s proprietary MiniDisc) might not be entirely incompatible with Product form detail A103 or A107 (MP3 or AAC format audio) – in that MiniDiscs can be used to store arbitrary data files – but in practice, any commercial MiniDisc products used Sony’s own ATRAC recording format.

Spiral and slide binding types:

Types of spiral, comb, slide bindings comb-bound (B311) Wire-O (B312) coiled wire (B314) slide (<ProductForm> BL)
Product form feature composite

It is best practice to use the <ProductFormFeature> composite wherever necessary to convey other product attributes that may be significant to the eventual purchaser. To illustrate this, <ProductFormFeature> should be used to specify:

  • any hazard warnings associated with the product (eg CPSIA or EU Toy Safety Directive hazard warnings), as there may be a legal requirement for the warning to be displayed in an online store catalog;
  • the binding material used in a fine binding, or the cover color of a hymnal or other religious text (a congregation may wish to purchase matching colors), or where similar products are available in contrasting colorways (eg boy and girl versions);
  • the text typeface and size used in a large print product, where the exact details may determine suitability of a physical book for a particular print-impaired reader;
  • any required operating system or other technical requirements, for example for an educational software product or mobile ‘app’;
  • where an e-publication file format is versioned (eg EPUB 2 and EPUB 3);
  • ‘accessibility’ features provided by an e-publication, such as provision of alternative textual descriptions attached to images within the e‑book, or inclusion of mathematical content using MathML rather than embedding equations as images, that may determine the suitability of the product for a print-impaired reader.

In contrast, <ProductFormFeature> is not expected to be used to specify the cover color or typeface name and size of – for example – a typical fiction hardback, where these details are largely immaterial to the purchaser.

Publishers or printers may use <ProductFormFeature> to state the product complies with FSC or PEFC scheme requirements related to the use of paper and board made in an environmentally-responsible way. But they should exercise particular care in claiming FSC or PEFC compliance, where the provenance of raw materials for future manufacturing batches might be uncertain. If a particular impression is for any reason manufactured with non-compliant material, the scheme logo must of course be omitted from those copies. However, all metadata records must also be updated to remove the compliance statement in a timely way. This applies both to metadata held by the publisher or printer, but also metadata held by supply chain partners and third parties. Statements that are not (or cannot) be updated and removed when necessary (which might be on an impression-by-impression basis) may affect future auditing and re-certification of the organization.

Within the <ProductFormFeature> composite, <ProductFormFeatureDescription> is repeatable in order that parallel text may be provided in multiple languages. See the notes with <BiographicalNote> for a fuller explanation, and the example above showing EU Toy Safety Directive warnings.

ProductFormFeature ProductFormFeatureType ProductFormFeatureType ProductFormFeatureValue ProductFormFeatureValue ProductFormFeatureDescription ProductFormFeatureDescription repeatable, to describe a feature in multiple languages

<ProductFormFeatureDescription> is mandatory with some values of <ProductFormFeatureType> (eg codes 03, 07), and <ProductFormFeatureValue> is omitted. Other Product form feature type codes need no additional description, and <ProductFormFeatureDescription> should be omitted unless it provides greater detail beyond that encoded in <ProductFormFeatureValue>

Description ProductForm ProductFormFeature…
Type Value ¹ Descr ¹
All printed books B* 01, 02, 04
03, 08
1
0
0…n
1…n
Regionalized video VI, VO 05 1 0
Electronic products A* (except AB, AC, AF), D*, E* 06
07
1
0
0…n
1…n
e‑books and ‘apps’ D*, E* 09, 10, 15 1 0…n
Hazardous products any 12, 13, 14 1 0…n
Paper products B*, C*, P* 30
31–37
40
0
1
0
0
0…n
0…n

¹ 0 = must be omitted, 1 = mandatory, 0…n = optional and repeatable, 1…n = mandatory and repeatable

specifying color of cover binding material
using Reference names – single color
<ProductFormFeature>
    <ProductFormFeatureType>01</ProductFormFeatureType>
    <ProductFormFeatureValue>TEA</ProductFormFeatureValue>
</ProductFormFeature>
using Short tags – multiple color
<productformfeature>
    <b334>01</b334>Color of cover
    <b335>MUL</b335>Multicolored
    <b336>Pale blue with green panel</b336>
</productformfeature>

Cover color is most often used for the cover of Holy books (for example, Bibles), and the same list of colors is used for specifying decorative page edges. The colors in ONIX codelist 98 are (deliberately) quite loosely specified so as to encompass a range of shades – they should not be treated as exact color specifications. The swatches below give only an indication of the expected color.

Color codes from List 98
WHI SLV GRY BLK
GRN TEA SKY BLU PUR
CEL GLD CRE PNK TAN
YEL ORG RED BUR BRN

There are also codes for multi-color covers and page edges, and for ‘four-color’ and ‘four-color plus spot’ for illustrated covers. Silver and gold may be metallic.

specifying the typeface of a large print product
using Reference names
<ProductFormFeature>
    <ProductFormFeatureType>03</ProductFormFeatureType>
    <ProductFormFeatureDescription>Tiresias LP, 18pt​</ProductFormFeatureDescription>
</ProductFormFeature>
. . . .
<EditionType>LTE</EditionType>
using Short tags
<productformfeature>
    <b334>03</b334>Text font
    <b336>Tiresias LP, 18pt</b336>
</productformfeature>
. . . .
<x419>LTE</x419>Large print edition
book manufactured with certified environmentally-responsible paper
using Reference names
<ProductFormFeature>
    <ProductFormFeatureType>32</ProductFormFeatureType>
    <ProductFormFeatureValue>SGS-COC-002061</ProductFormFeatureValue>
</ProductFormFeature>
<ProductFormFeature>
    <ProductFormFeatureType>36</ProductFormFeatureType>
    <ProductFormFeatureValue>35</ProductFormFeatureValue>
</ProductFormFeature>
using Short tags
<productformfeature>
    <b334>32</b334>FSC-certified, mixed sources
    <b335>SGS-COC-002061</b335>Chain of Custody reference (Clays Ltd)
</productformfeature>
<productformfeature>
    <b334>36</b334>FSC-certified pre- and post-consumer waste
    <b335>35</b335>Percentage
</productformfeature>
specifying the accessibility features of a fixed-format e‑book
using Reference names
<ProductFormDetail>E101</ProductFormDetail>
<ProductFormDetail>E201</ProductFormDetail>
<ProductFormDetail>E210</ProductFormDetail>
<ProductFormDetail>E222</ProductFormDetail>
<ProductFormFeature>
    <ProductFormFeatureType>15</ProductFormFeatureType>
    <ProductFormFeatureValue>101A</ProductFormFeatureValue>
</ProductFormFeature>
<ProductFormFeature>
    <ProductFormFeatureType>09</ProductFormFeatureType>
    <ProductFormFeatureValue>10</ProductFormFeatureValue>
</ProductFormFeature>
<ProductFormFeature>
    <ProductFormFeatureType>09</ProductFormFeatureType>
    <ProductFormFeatureValue>11</ProductFormFeatureValue>
</ProductFormFeature>
<ProductFormFeature>
    <ProductFormFeatureType>09</ProductFormFeatureType>
    <ProductFormFeatureValue>13</ProductFormFeatureValue>
</ProductFormFeature>
<ProductFormFeature>
    <ProductFormFeatureType>09</ProductFormFeatureType>
    <ProductFormFeatureValue>15</ProductFormFeatureValue>
</ProductFormFeature>
<ProductFormFeature>
    <ProductFormFeatureType>09</ProductFormFeatureType>
    <ProductFormFeatureValue>97</ProductFormFeatureValue>
    <ProductFormFeatureDescription>Tested with Adobe Digital Editions 1.8 and JAWS screen reader on Windows, and with VoiceOver on Mac​</ProductFormFeatureDescription>
</ProductFormFeature>
using Short tags
<b333>E101</b333>EPUB
<b333>E201</b333>Fixed format
<b333>E210</b333>optimized for landscape
<b333>E222</b333>4:3 aspect ratio
<productformfeature>
    <b334>15</b334>e-publication version code
    <b335>101A</b335>EPUB 2.0.1
</productformfeature>
<productformfeature>
    <b334>09</b334>e-publication accessibility detail
    <b335>10</b335>No reading system options disabled
</productformfeature>
<productformfeature>
    <b334>09</b334>
    <b335>11</b335>Navigation via table of contents
</productformfeature>
<productformfeature>
    <b334>09</b334>
    <b335>13</b335>Single logical reading order
</productformfeature>
<productformfeature>
    <b334>09</b334>
    <b335>15</b335>Full alternative text descriptions
</productformfeature>
<productformfeature>
    <b334>09</b334>
    <b335>97</b335>Compatibility testing
    <b336>Tested with Adobe Digital Editions 1.8 and JAWS screen reader on Windows, and with VoiceOver on Mac</b336>
</productformfeature>
Instead of listing a range of accessibility attributes one at a time, it’s also possible to specify a particular Standardised level of accessibility. In effect, a standard like the EPUB Accessibility Specification or PDF/UA can be thought of as a ready-made ‘bundle’ of attributes, which might otherwise be listed separately. This may be accompanied by information about the conformance checker used.
specifying conformance to a standard accessibility specification
using Reference names
<ProductFormFeature>
    <ProductFormFeatureType>15</ProductFormFeatureType>
    <ProductFormFeatureValue>101E</ProductFormFeatureValue>
</ProductFormFeature>
<ProductFormFeature>
    <ProductFormFeatureType>16</ProductFormFeatureType>
    <ProductFormFeatureValue>4.2.2</ProductFormFeatureValue>
    <ProductFormFeatureDescription>EPUBCheck</ProductFormFeatureDescription>
</ProductFormFeature>
<ProductFormFeature>
    <ProductFormFeatureType>09</ProductFormFeatureType>
    <ProductFormFeatureValue>03</ProductFormFeatureValue>
</ProductFormFeature>
<ProductFormFeature>
    <ProductFormFeatureType>16</ProductFormFeatureType>
    <ProductFormFeatureValue>1.1.1</ProductFormFeatureValue>
    <ProductFormFeatureDescription>Ace by DAISY</ProductFormFeatureDescription>
</ProductFormFeature>
using Short tags
<productformfeature>EPUB v3.2
    <b334>15</b334>
    <b335>101E</b335>
</productformfeature>
<productformfeature>Checked with EPUBCheck
    <b334>16</b334>
    <b335>4.2.2</b335>
    <b336>EPUBCheck</b336>
</productformfeature>
<productformfeature>EPUB accessibility specification 1.0
    <b334>09</b334>
    <b335>03</b335>WCAG Level AA
</productformfeature>
<productformfeature>Checked using ACE by Daisy
    <b334>16</b334>
    <b335>1.1.1</b335>
    <b336>Ace by DAISY</b336>
</productformfeature>
specifying operating system and other technical requirements
using Reference names
<ProductForm>DI</ProductForm>
<!-- <ProductFormDetail>D202</ProductFormDetail> -->
<ProductFormFeature>
    <ProductFormFeatureType>06</ProductFormFeatureType>
    <ProductFormFeatureValue>10</ProductFormFeatureValue>
    <ProductFormFeatureDescription>Vista or Windows 7​</ProductFormFeatureDescription>
</ProductFormFeature>
<ProductFormFeature>
    <ProductFormFeatureType>07</ProductFormFeatureType>
    <ProductFormFeatureDescription>Requires at least 2GB of memory, DirectX 9-compatible graphics​</ProductFormFeatureDescription>
</ProductFormFeature>
using Short tags
<b012>DI</b012>DVD-Rom
<!-- <b333>D202</b333> -->MS Windows
<productformfeature>
    <b334>06</b334>Operating system
    <b335>10</b335>MS Windows
    <b336>Vista or Windows 7</b336>
</productformfeature>
<productformfeature>
    <b334>07</b334>Other system requirements
    <b336>Requires at least 2GB of memory, DirectX 9-compatible graphics​</b336>
</productformfeature>
Some operating systems can be specified in either <ProductFormFeature> or <ProductFormDetail> (as shown in the commented line above). <ProductFormFeature> is preferred wherever possible, as more specific version requirements may be included.
Battery information
Using Reference names
<ProductFormFeature>
    <ProductFormFeatureType>19</ProductFormFeatureType>
    <ProductFormFeatureValue>02</ProductFormFeatureValue>
    <ProductFormFeatureDescription>1 x 2.9V CR2032</ProductFormFeatureDescription>
</ProductFormFeature>
<ProductFormFeature>
    <ProductFormFeatureType>20</ProductFormFeatureType>
    <ProductFormFeatureValue>0.6</ProductFormFeatureValue>
</ProductFormFeature>
<ProductFormFeature>
    <ProductFormFeatureType>19</ProductFormFeatureType>
    <ProductFormFeatureValue>21</ProductFormFeatureValue>
</ProductFormFeature>
<ProductFormFeature>
    <ProductFormFeatureType>19</ProductFormFeatureType>
    <ProductFormFeatureValue>09</ProductFormFeatureValue>
</ProductFormFeature>
. . .
<Measure>
    <MeasureType>17</MeasureType>
    <Measurement>3.5</Measurement>
    <MeasureUnitCode>gr</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>18</MeasureType>
    <Measurement>0.2</Measurement>
    <MeasureUnitCode>gr</MeasureUnitCode>
</Measure>
using Short tags
<productformfeature>
    <b334>19</b334>
    <b335>02</b335>Pre-installed, not user repleaceable
    <b336>1 x 2.9V CR2032</b336>
</productformfeature>
<productformfeature>
    <b334>20</b334>
    <b335>0.66</b335>Capacity in Watt-hours
</productformfeature>
<productformfeature>
    <b334>19</b334>
    <b335>21</b335>Lithium-Manganese dioxide chemistry
</productformfeature>
<productformfeature>
    <b334>19</b334>
    <b335>09</b335>Non-rechargeable
</productformfeature>
. . .
<measure>
    <x315>17</x315>Weight of battery
    <c094>3.5</c094>
    <c095>gr</c095>
</measure>
<measure>
    <x315>18</x315>Mass of elemental Lithium in battery
    <c094>0.2</c094>
    <c095>gr</c095>
</measure>
CPSIA choking hazard warning on boxed book plus toy
using Reference names
<ProductForm>SB</ProductForm>
<ProductFormFeature>
    <ProductFormFeatureType>12</ProductFormFeatureType>
    <ProductFormFeatureValue>01</ProductFormFeatureValue>
</ProductFormFeature>
using Short tags, with additional magnet hazard statement and positive indication that no Proposition 65 Warning is necessary on sales in California
<b012>SB</b012>Boxed multiple-item retail product
<productformfeature>
    <b334>12</b334>CPSIA choke hazard warning
    <b335>01</b335>Small parts, not for children under 3
</productformfeature>
<productformfeature>
    <b334>12</b334>CPSIA or other US hazard warning
    <b335>12</b335>No magnet hazard warning necessary
</productformfeature>
<productformfeature>
    <b334>12</b334>CPSIA or other US hazard warning
    <b335>22</b335>No Proposition 65 warning necessary
</productformfeature>
If the warning text in List 143 is not suitable, the exact text of a warning can be carried in <ProductFormFeatureDescription> (though <ProductFormFeatureValue> must not be omitted).
P.3.7 Product packaging type code

This should be used with any packaged product to specify the nature of any packaging – for example to describe whether a CD is packaged in a card sleeve, a jewel case, a Digipak, an Amaray-style keep case or some other form of packaging, or to describe a book or a collection of books in a slipcase, or a book plus an audio CD in a blister pack. The data element may be omitted if the product is not contained within any separate packaging.

Common packaging types, and the codes used from List 80:

Types of packging keep case (03) jewel case (05) slip-cased set (11) slip-cased (10) clamshell (02) blister pack (22) box (09) slip-sleeve (01) digipak (06)

If a product has multiple levels of packaging – for example a slip-cased book that is also shrinkwrapped, use <ProductPackaging> to describe the primary packaging (in this case, it would be the slip-case), and add text in <ProductFormDescription> to describe any secondary packaging.

Note that the height, width and thickness (spine width) dimensions and weights in the <Measure> composite should include any packaging.

See P.3.2 Product form code for notes relating to the packaging of multi-component and multi-item products and trade packs.

P.3.9 Trade category code

Although not necessarily a recommended best practice, the Trade category is important in some particular circumstances, as it is used, inter alia, to clarify the legal status of particular publications, which may affect their tax status.

specifying a livre scolaire
using Reference names
<TradeCategory>08</TradeCategory>
using Short tags
<b384>08</b384>French livre scolaire, within the context of Decree 2004–922
P.3.10, P.3.11 Primary and Product content type codes

These elements are primarily intended to describe the type of content included within e-publications including e‑books, mobile ‘apps’ and other downloadable or online products. For example, a simple e‑book may contain just eye-readable text, and this would be specified using <PrimaryContentType> code 10.

‘Enhanced’ e‑books or mobile apps that contain both book text and additional content not included in a related ‘unenhanced’ product should be described the same way, but the nature of the enhancements may be specified using a combination of the <PrimaryContentType> and <ProductContentType> elements – <ProductContentType> is repeatable for products that contain several types of additional content or enhancements. ‘Enhanced’ products may also carry the ENH code in <EditionType>. Note that an enhanced edition requires the existence of an ‘unenhanced’ edition – without the latter, the enhanced edition is simply the normal product and should not carry the <EditionType> code ENH. However, the use of additional repeats of <ProductContentType> does not depend on the existence of an ‘unenhanced’ version.

However, the use of these data elements is not limited to e-publications. They may also be used to differentiate between, say, audiobooks containing a single voice reading of a book, and multi-voice ‘dramatized’ audio. It may also be used with multi-component products, where for example product may contain both a book (with eye-readable text) and an audio version of the text, or with ‘multimedia’ educational software products. In general, if omitted from the Product record, the contents of the product should be assumed to be primarily textual.

Measure composite

The <Measure> composite should be included for all physical products.

The whole composite is repeatable, and at minimum, the overall height and width (across the front cover) dimensions should be provided for all physical products. This may be based on specifications provided in advance to the manufacturer (the printer and binder), or measured from the finished book-in-hand. Note that while publishers use the trimmed page size (trimmed leaf size) when specifying the size of a product to the printer – and this may be carried in the ONIX using codes 04 and 05 from List 48 – it is the overall dimensions, codes 01 to 03, that are vital to other parties in the supply chain.

For hardbacks and many other product forms, the overall height and width are not the same as the trimmed page size, because the cover boards overhang the book block. (This difference applies to some other binding types too.) Trimmed page size and overall dimensions may both be provided, in separate repeats of the <Measure> composite. If only the TPS measurements are provided, ONIX recipients should ensure they are not confused with the overall dimensions. The few millimeters difference can be critical, and can for example lead to costly errors for retailers who are forced to plan shelving or estimate mail-order carriage costs based on misleading data.

Of course, the overall height and width can be calculated reasonably accurately from the TPS and the binding type, allowing 3–4mm, or ⅛ to ⅙in or so, on each side, for the cover boards to project beyond the book block for a hardback, for example. Thickness (spine width) may not be known until production details such as the page extent and paper caliper are finalized, or until finished copies are available, and it may subsequently vary slightly between different impressions of the same product due to variations in the density and water content of the paper used. In a similar way, the weight (technically, the mass) may not be known accurately until physical manufacture, and is subject to equivalent variations. However, carefully calculated estimates of weight and spine width made prior to manufacture may still be useful to recipients and should be provided whenever possible: if weight and spine width measurements are provided greater than two months prior to publication, recipients should treat them as estimates, and senders should send updated data as soon as accurate measurements are available.

Never provide zero or dummy measurements: if a measurement is unknown, omit it.

Measure MeasureType Measurement MeasureUnitCode MeasureUnitCode

The primary linear dimensions, and the <MeasureType> codes used from List 48:

Types of dimension Spine width (02) height (01) trimmed page height (04) is smaller for hardback books (also applies to trimmed page width (05)) thickness (03) diameter (12) height (01)

Overall product height, width, thickness (spine width) and weight measurements should include any retail packaging – for a retailer, if a book is sold in a slipcase or box, then it is the dimensions of the slipcase or box that determine whether or not it can be conveniently shelved or shipped. This is doubly important for multi-component products, where the overall package size may be quite different from the size of any particular component within. (Packaging expected to be discarded before retail should not be included.)

For broad international use outside USA, metric units should be used for linear dimensions (millimeters) and weight (grams). For products sold only in USA, Imperial units (inches, ounces) should be used instead. If a product is sold in both USA and elsewhere (for example, globally, or simply in both USA and Canada), inclusion of the same dimensions in both metric and Imperial is clearly the best option, but if only one set of dimensions can be provided, metric is preferred over Imperial. Note that if a book is manufactured to a particular nominal size, there is a certain commercially-acceptable tolerance and the exact size of the finished copies may vary a little: typically, linear measurements should not be specified more precisely than the nearest 1mm or 116in. Recipients should treat linear measurements as having an expected accuracy within ±2mm or ±⅛in, and weights with an accuracy of ±5gr or ±¼oz. Similarly, whenever unit conversions are necessary, the results should be rounded sensitively to avoid misleadingly precise measurements (eg conversion of 197mm to Imperial units indicates a size of 7.756in, but round to 7¾ (ie to 7.75) inches).

For products such as maps or posters, both folded (or rolled) and flat measurements should be included whenever possible, but if only one set of dimensions can be included, the folded (or rolled) sizes used at retail and for shipping are preferred.

For multi-component products – both those that are retailed as such (<ProductComposition> code 10 and <ProductForm> codes SA–SF), and those that are split before retail (<ProductComposition> code 30 and <ProductForm> codes XA, XC, XE, XL) – measurements should relate to the full multi-component or multi-item product. For those products that are split before retail, the measurements of a single retail item must be obtained from the Product record for the individual product.

For products containing batteries, it is important to specify the types of battery, as these are heavily regulated for transportation. The <ProductFormFeature> composite is used to specify most of the battery details – type, number, chemistry and so on. The <Measure> composite is used to specify the total combined weight of all batteries built-in, pre-installed or supplied with the product, and for any batteries containing Lithium or Lithium compounds, also the total weight or equivalent weight of elemental Lithium.

Battery weight information
Using reference names
<Measure>
    <MeasureType>17</MeasureType>
    <Measurement>225</Measurement>
    <MeasureUnitCode>gr</MeasureUnitCode>
</Measure>
<Measure>
    <MeasureType>18</MeasureType>
    <Measurement>12</Measurement>
    <MeasureUnitCode>gr</MeasureUnitCode>
</Measure>
Using short tags
<measure>
    <x315>17</x315>
    <c094>225</c094>225g total weight of battery(ies)
    <c095>gr</c095>
</measure>
<measure>
    <x315>18</x315>
    <c094>12</c094>…containing 12g of Lithium
    <c095>gr</c095>
</measure>
P.3.15 Country of manufacture

This information is required in some countries to meet legal requirements, so it is best practice to include it for all physical products available internationally. For a physical book, the country of manufacture is the country where it is printed and bound, not the country in which the publisher is based (though of course they may be the same).

If the product is a multi-item or multi-component product, the country of manufacture should instead be specified individually for each of the items or physical components in the product, in Group P.4 Product parts, especially if different components of the product are manufactured in different countries or if the items in a multi-item trade pack are intended to be retailed individually. For a multi-component product or multi-item pack, a product- or pack-level country of manufacture could be interpreted as the country in which the items were assembled or packaged together, rather than where they were each manufactured.

P.3.16 Digital product technical protection

This element should be used to specify any technical protection measures applied to the product, and should be used for all downloadable and (where appropriate) other digital products – including the case when no technical protection is applied.

<EpubTechnicalProtection> is not relevant solely to e‑books in EPUB format. The ‘Epub’ is simply a contraction of ‘e-publication’, and elements so named are relevant to all types of e-publication.

Some types of e-publication are defined by their unique combination of file format (eg .epub or .xps, specified in <ProductFormDetail>) and type of technical protection (eg Apple or Adobe DRM). For these products, specification of the technical protection type is clearly vital.

Note that technical protection need not necessarily be used for enforcement. Customer-specific ‘watermarking’ (which normally identifies the purchase transaction, rather than the actual person) or other ‘social DRM’ may be applied to digital files at the moment of sale, so that individual digital copies of a product may be linked with a purchaser, without this being associated with any enforcement measures embodied in the product itself.

It is common with e-publications to question whether the <EpubTechnicalProtection> element and the <UsageConstraint> composite describe the file the publisher supplies to the retailer (or retail platform), or the file the retailer sends to the end customer. It is the latter. So in a common case where the publisher-supplied file does not have DRM, and the retail platform adds the DRM wrapper before delivery to the end customer, the ONIX Product record should indicate the product is DRM-protected.
Usage constraint composite

The <EpubUsageConstraint> composite should be used to specify the license terms which apply to a digital product, whether or not these terms are enforced by any technical protection measures. Multiple repeats of the composite should be included to give a clear picture of what a purchaser may and may not do (legitimately) with the content of the product.

EpubUsageConstraint EpubUsageType EpubUsageStatus EpubUsageStatus EpubUsageLimit EpubUsageLimit Quantity EpubUsageUnit

Note that there are no default usage rights or constraints: if no usage constraints are specified in the Product record, it means only that there is no information, and does not imply an unconstrained usage right. Data providers should aim to specify at least those usages and constraints that vary between products on the ‘retail platform’ the product will be sold through.

One unusual feature of many e-publications is that the range of possible uses or potential constraints may change post-publication, as the technical capabilities of the reading platform may be modified through software upgrades. For example, the addition of text-to-speech or temporary lending to a platform may affect prior purchases on that platform. But there needs to be a clear understanding of whether any capability or constraint is associated with the reading platform or the product. Where these new capabilities are ‘optional’, and controllable at a per-product level, they should be specified in an ONIX (update) message, whether the publisher of the product chooses to opt in or opt out of enabling the new feature. Where these capabilities are added to all products on that platform, without any ‘opt-out’ or per-product control, then no change to ONIX metadata is required: the new capability is a reading platform feature, rather than an attribute of the product.

Similarly, capabilities and constraints may in some cases be somewhat platform-specific, even for a single product usable with multiple reading platforms. Where the same product is usable on multiple reading platforms, a constraint that is wholly related to the platforms should not be listed. For example, for a single product that is usable with two e‑book reading platforms, where text-to-speech is enabled for all products without exception on one platform, but is completely unavailable on the other – perhaps because that platform lacks audio output of any kind – text-to-speech should not be included in the list of constraints.

Library-lendable e‑book
using Reference names: the book can be loaned out up to 52 times, only one borrower can be loaned the book at any one time, for a maximum of a fortnight. Printing is prohibited, text-to-speech is allowed, and these constraints are protected by DRM
<EpubTechnicalProtection>01</EpubTechnicalProtection>
<EpubUsageConstraint>
    <EpubUsageType>02</EpubUsageType>
    <EpubUsageStatus>03</EpubUsageStatus>
</EpubUsageConstraint>
<EpubUsageConstraint>
    <EpubUsageType>05</EpubUsageType>
    <EpubUsageStatus>01</EpubUsageStatus>
</EpubUsageConstraint>
<EpubUsageConstraint>
    <EpubUsageType>06</EpubUsageType>
    <EpubUsageStatus>02</EpubUsageStatus>
    <EpubUsageLimit>
        <Quantity>52</Quantity>
        <EpubUsageUnit>10</EpubUsageUnit>
    </EpubUsageLimit>
    <EpubUsageLimit>
        <Quantity>14</Quantity>
        <EpubUsageUnit>09</EpubUsageUnit>
    </EpubUsageLimit>
    <EpubUsageLimit>
        <Quantity>1</Quantity>
        <EpubUsageUnit>07</EpubUsageUnit>
    </EpubUsageLimit>
</EpubUsageConstraint>
using Short tags: the book can be loaned out up to 52 times, but with unlimited concurrency (ie 52 sequential loans stretching over two years or more, or 52 ‘parallel’ loans over two weeks). Printing is prohibited, text-to-speech is allowed, and DRM enforces these limitations
<x317>01</x317>DRM-protected
<epubusageconstraint>
    <x318>02</x318>Printing
    <x319>03</x319>Is prohibited
</epubusageconstraint>
<epubusageconstraint>
    <x318>05</x318>Text-to-speech
    <x319>01</x319>Is unrestricted
</epubusageconstraint>
<epubusageconstraint>
    <x318>06</x318>Lending
    <x319>02</x319>Is limited
    <epubusagelimit>
        <x320>52</x320>Up to 52
        <x321>10</x321>Occasions
    </epubusagelimit>
    <epubusagelimit>
        <x320>14</x320>For fourteen
        <x321>09</x321>Days
    </epubusagelimit>
    <epubusagelimit>
        <x320>0</x320>Unlimited
        <x321>07</x321>Concurrent users
    </epubusagelimit>
</epubusageconstraint>

If the number of concurrent users is not specified, the default is that there can be only one concurrent user. Zero concurrent users is a special case indicating there is no limit on concurrency. (In this particular case, a maximum of 52 concurrent users would have the same effect, as it would imply that all the possible 52 loans could be concurrent.)

Zero may be used in this way to give a positive indication that any aspect of some usage is unlimited, when other aspects of the same usage are limited – though it would be more usual simply to omit the relevant <EpubUsageLimit>. For example, if the number of lending occasions is not limited, then the <EpubUsageLimit> on number of occasions should normally be omitted. But using zero allows an explicit indication that it is unlimited, where such an indication is necessary.

e‑book purchase
using Reference names: the product is an e‑book ‘purchase’ – in reality, the purchase of a perpetual license to the product. The product is watermarked
<EpubTechnicalProtection>02</EpubTechnicalProtection>
<EpubUsageConstraint>
    <EpubUsageType>07</EpubUsageType>
    <EpubUsageStatus>01</EpubUsageStatus>
</EpubUsageConstraint>
using Short tags: perpetual license
<x317>02</x317>Watermarked
<epubusageconstraint>
    <x318>07</x318>Time limit
    <x319>01</x319>Is unrestricted
</epubusageconstraint>
e‑book rental – 30-day time-limited license to the product, enforced by DRM
using Reference names
<EpubTechnicalProtection>03</EpubTechnicalProtection>
<EpubUsageConstraint>
    <EpubUsageType>07</EpubUsageType>
    <EpubUsageStatus>02</EpubUsageStatus>
    <EpubUsageLimit>
        <Quantity>30</Quantity>
        <EpubUsageUnit>09</EpubUsageUnit>
    </EpubUsageLimit>
</EpubUsageConstraint>
using Short tags
<x317>03</x317>Adobe Content Server DRM
<epubusageconstraint>
    <x318>07</x318>Time limit
    <x319>02</x319>Is restricted
    <epubusagelimit>
        <x320>30</x320>
        <x321>09</x321>To 30 days (from day of purchase or activation)
    </epubusagelimit>
</epubusageconstraint>
Differentiating rentals from purchases in this way relies on using separate product identifiers for each. If only a single identifier is used for purchase and one or more rental periods, see <PriceCondition>.
e‑book rental – license limited to an academic year, enforced by DRM
using Reference names
<EpubTechnicalProtection>03</EpubTechnicalProtection>
<EpubUsageConstraint>
    <EpubUsageType>07</EpubUsageType>
    <EpubUsageStatus>02</EpubUsageStatus>
    <EpubUsageLimit>
        <Quantity>48</Quantity>
        <EpubUsageUnit>28</EpubUsageUnit>
    </EpubUsageLimit>
</EpubUsageConstraint>
using Short tags
<x317>03</x317>Adobe Content Server DRM
<epubusageconstraint>
    <x318>07</x318>Time limit
    <x319>02</x319>Is restricted
    <epubusagelimit>
        <x320>48</x320>
        <x321>28</x321>To 48 weeks (from publication date)
    </epubusagelimit>
</epubusageconstraint>
In this example, the license period has a fixed end date (around 11 months after the publication date). Copies of the product may be purchased at the beginning of the academic year, or half way through, but the licenses will expire simultaneously at the end of that year – irrespective of the purchase or activation date.
Digital product license composite

This composite can be used to deliver details of the license terms for a digital product. The license must have a name or title, and if the license is available on the internet, a link to the actual license may be provided (there may be several links to different expressions of the same license – for example a link to a legal document and a separate link to a summary intended for consumers).

Links to machine-readable license expressions – for example using ONIX-PL – are likely to become valuable in the future, particularly in library contexts.

EpubLicense EpubLicenseName EpubLicenseName EpubLicenseExpression EpubLicenseExpression EpubLicenseExpression EpubLicenseExpressionType EpubLicenseExpressionType EpubLicenseExpressionTypeName EpubLicenseExpressionTypeName EpubLicenseExpressionLink EpubLicenseExpressionLink
Open Access e‑book available under a CC-By license
using Reference names
<EpubLicense>
    <EpubLicenseName>Creative Commons Attribution 4.0 International Public License​</EpubLicenseName>
    <EpubLicenseExpression>
        <EpubLicenseExpressionType>02</EpubLicenseExpressionType>
        <EpubLicenseExpressionLink>https://creativecommons.org/​licenses/​by/​4.0/​legalcode</EpubLicenseExpressionLink>
    </EpubLicenseExpression>
</EpubLicense>
. . .
<TextContent>
    <TextType>20</TextType>
    <ContentAudience>00</ContentAudience>
    <Text>Open access under CC-By license</Text>
</TextContent>
. . .
<Publisher>
    <PublishingRole>01<PublishingRole>
    <PublisherName>Manchester University Press</PublisherName>
</Publisher>
<Publisher>
    <PublishingRole>14<PublishingRole>
    <PublisherName>Knowledge Unlatched</PublisherName>
</Publisher>
<Publisher>
    <PublishingRole>15<PublishingRole>
    <PublisherIdentifier>
        <PublisherIDType>32</PublisherIDType>
        <IDValue>10.13039/100004440</IDValue>
    </PublisherIdentifier>
    <PublisherName>Wellcome Trust</PublisherName>
</Publisher>
. . .
<Website>
    <WebsiteRole>29</WebsiteRole>
    <WebsiteDescription>OAPEN Repository</WebsiteDescription>
    <WebsiteLink>https://www.oapen.org/​download?​type=​document&​docid=​341341</WebsiteLink>
</Website>
. . .
<UnpricedItemType>01</UnpricedItemType>
using Short tags – with links to both human-readable and professional license expressions
<epublicense>
    <x511>Creative Commons Attribution 4.0 International Public License​</x511>
    <epublicenseexpression>
        <x508>01</x508>Human readable
        <x510>https://creativecommons.org/​licenses/​by/​4.0/​deed</x510>
    </epublicenseexpression>
    <epublicenseexpression>
        <x508>02</x508>‘Professional’ readable
        <x510>https://creativecommons.org/​licenses/​by/​4.0/​legalcode</x510>
    </epublicenseexpression>
</epublicense>
. . .
<textcontent>
    <x426>20</x426>Open access statement
    <x427>00</x427>
    <d104>Open access under CC-By license</d104>
</textcontent>
. . .
<publisher>
    <b291>01<b291>Publisher
    <b081>Manchester University Press</b081>
</publisher>
<publisher>
    <b291>14<b291>Publication funder
    <b081>Knowledge Unlatched</b081>
</publisher>
<publisher>
    <b291>15<b291>Research funder
    <publisheridentifier>
        <x447>32</x447>FundRef DOI
        <b244>10.13039/100004440</b244>
    </publisheridentifier>
    <b081>Wellcome Trust</b081>
</publisher>
. . .
<website>
    <b367>29</b367>Full content available from
    <b294>OAPEN Repository</b294>
    <b295>https://www.oapen.org/​download?​type=​document&​docid=​341341</b295>
</website>
. . .
<j192>01</j192>Free of charge
The <EpubLicense> composite is not applicable only to Creative Commons and proprietary ‘open access’ licenses – it may also be used for commercial and limited licenses as well. However, for open access and other free at the point of use digital products only, an ‘Open Access statement’ should always be provided in Group P.14 (use <TextType> code 20). Presence of this statement acts as a ‘flag’ to indicate the product is open access, and the statement text can be displayed as a one line summary of the license terms. For limited and commercial licenses, there should be no open access statement. Open access materials would normally also name the funder(s) in the <Publisher> composite, and are likely to be free of charge (denoted using <UnpricedItemType>). They may also specify a location from which the digital product can be downloaded. The <Website> composite might link to a repository managed by the author, funder, publisher, supplier or another party, and the composite should be used in the appropriate context.
Delayed open access
using Reference names
<TextContent>
    <TextType>20</TextType>
    <ContentAudience>00</ContentAudience>
    <Text>Open access – no commercial reuse</Text>
    <ContentDate>
        <ContentDateRole>14</ContentDateRole>
        <Date>20180524</Date>
    </ContentDate>
</TextContent>
. . .
<PublishingStatus>04</PublishingStatus>
<PublishingDate>
    <PublishingDateRole>01</PublishingDateRole>
    <Date>20171123</Date>
</PublishingDate>
. . .
<Price>
    <!-- non-OA price details omitted for brevity -->
    <PriceDate>
        <PriceDateRole>15</PriceDateRole>
        <Date>20180523</Date>
    </PriceDate>
</Price>
<Price>
    . . .
    <EpubLicense>
        <!-- OA license details omitted for brevity -->
    </EpubLicense>
    . . .
    <UnpricedItemType>01</UnpricedItemType>
    <PriceDate>
        <PriceDateRole>14</PriceDateRole>
        <Date>20180524</Date>
    </PriceDate>
</Price>
using Short tags
<textcontent>
    <x426>20</x426>Open Access statement
    <x427>00</x427>
    <d104>Open access – no commercial reuse</d104>
    <contentdate>
        <x429>14</x429>From
        <b306>20180524</b306>Six months after pub date
    </contentdate>
</textcontent>
. . .
<b394>04</b394>
<publishingdate>
    <x448>01</x448>Publication date
    <b306>20171123</b306>
</publishingdate>
. . .
<price>Initial price
    <!-- non-OA price details omitted for brevity -->
    <pricedate>
        <x476>15</x476>Until
        <b306>20180523</b306>Six months after pub date
    </pricedate>
</price>
<price>Change of status to OA
    . . .
    <epublicense>
        <!-- OA license details omitted for brevity -->
    </EpubLicense>
    . . .</epublicense>
    <j192>01</j192>Free of charge
    <pricedate>
        <x476>14</x476>From
        <b306>20180524</b306>Six months after pub date
    </pricedate>
</price>
The ‘Open Access statement’ can be linked with a From date in the future to indicate that a product currently available on limited or closed terms will become open access in the future. Delayed open access – the intention to make the product open access in the future – should be signalled in this way. The inevitable change of licensing and price can also be signalled in advance through use of <EpubLicense> and <UnpricedItemType> within <Price> and the relevant <PriceDate>.
P.3.21 Map scale

The main scale of a cartographic product should always be provided. If the map contains multiple panels at different scales, repeats of the <MapScale> element may be used to express the scales used in the significant panels – for example the Product record for a road map with inset city center street maps might include two <MapScale> elements.

When a cartographic product such as an atlas is comprised of maps at just one or a small number of scales, the same approach should be followed. If the maps in an atlas are drawn at a wide variety of scales, it is not useful to specify them all individually: specify only the two or three scales used most widely in the product.

Product classification composite

The <ProductClassification> composite can be used in international trading to indicate the customs or tax status of the product, most often using the World Customs Organization’s ‘Harmonized system’ of product classification, or one of its regional or national variations or extensions. This can be critical in international trading, and where prices are typically communicated exc-tax, the recipient of the ONIX data can usually decide the local tax rate or any tariffs that are applicable to the product based on the commodity code.

ProductClassification ProductClassificationType ProductClassificationType ProductClassificationCode ProductClassificationCode Percent
TARIC product classification for an ordinary book
using Reference names
<ProductClassification>
    <ProductClassificationType>05</ProductClassificationType>
    <ProductClassificationCode>4901000000</ProductClassificationCode>
</ProductClassification>
using Short tags
<productclassification>
    <b274>05</b274>TARIC
    <b275>4901000000</b275>for an ordinary book
</productclassification>
Mercosur/Mercosul product classification for an atlas
using Reference names
<ProductClassification>
    <ProductClassificationType>10</ProductClassificationType>
    <ProductClassificationCode>49059100</ProductClassificationCode>
</ProductClassification>
using Short tags
<productclassification>
    <b274>10</b274>Mercosur/Mercosul NCM commodity code
    <b275>49059100</b275>for an atlas
</productclassification>
Both Mercosul and TARIC are based on the WCO Harmonized System, so the TARIC code for an atlas is very similar – 4905910000.
Product classification for a multi-component product
using Reference names
<ProductClassification>
    <ProductClassificationType>01</ProductClassificationType>
    <ProductClassificationCode>490199</ProductClassificationCode>
    <Percent>75</Percent>
</ProductClassification>
<ProductClassification>
    <ProductClassificationType>01</ProductClassificationType>
    <ProductClassificationCode>852432</ProductClassificationCode>
    <Percent>25</Percent>
</ProductClassification>
using Short tags
<productclassification>
    <b274>01</b274>WCO Harmonized system
    <b275>490199</b275>Book / other
    <b337>75</b337>75% of value
</productclassification>
<productclassification>
    <b274>01</b274>WCO Harmonized system
    <b275>852432</b275>Recorded media for sound
    <b337>25</b337>25% of value
</productclassification>
Most product classification types can be expressed with periods separating the number into fields (eg 4901.99.00 in the second example above). The period characters are not usually included in the ONIX data.
The value percentage is a percentage of the overall price excluding tax. Tax may then have to be added based on the product classification itself.

Note that for multi-component products using <ProductPart>, the Product classification has to be described in P.3, not within each <ProductPart>. If the product consists of components that have different classifications – for example a children’s picture book bundled with an audio CD – then the <ProductClassification> composite is repeated, and the <Percent> element can be used to carry the percentage of the value of the product represented by each component.

P.4 Product parts

If the Product record describes a multi-component or multi-item product, then multiple repeats of the <ProductPart> composite are used to identify and describe the form of the various items or components of the product. As a result, much of the structure of the composite is identical to P.3, and similar best practices apply. Use of <ProductPart> implies nothing about whether each individual part or component within the product is available separately, and it may be used whether the various parts are of similar or different Product form.

If the Product record describes a single-item, single-component product, then <ProductPart> should be omitted entirely.

Product part composite

<ProductPart> specifies a relationship between a product and a component of that product that might otherwise – if the component is also for sale separately – be included in <RelatedProduct> in Block 5 using <ProductRelationCode> 02 (product includes related product). It is good practice to include identifiers for the individual saleable parts within multi-component or multi-item products in <ProductPart>, and not to repeat them in <RelatedProduct>. ONIX recipients wishing to identify related products should use identifiers from <ProductPart> alongside those listed in Group P.23.

ProductPart PrimaryPart ProductIdentifier ProductForm ProductFormDetail ProductFormDetail ProductFormFeature ProductFormFeature ProductPackaging ProductFormDescription ProductFormDescription ProductContentType ProductContentType Measure Measure NumberOfItemsOfThisForm NumberOfItemsOfThisForm NumberOfCopies NumberOfCopies CountryOfManufacture CountryOfManufacture must not omit both
three-volume work, paperback, in box (not a slip-case), individual parts not identified separately
using Reference names
<ProductComposition>10</ProductComposition>
<ProductForm>SA</ProductForm>
<ProductPackaging>09</ProductPackaging>
<!-- <Measure> omitted for brevity -->
<CountryOfManufacture>DE</CountryOfManufacture>
<ProductPart>
    <!-- volumes not individually identified -->
    <ProductForm>BC</ProductForm>
    <ProductFormDetail>B102</ProductFormDetail>
    <NumberOfItemsOfThisForm>3</NumberOfItemsOfThisForm>
</ProductPart>
using Short tags
<x314>10</x314>Multi-component product
<b012>SA</b012>Packaging unspecified
<b225>09</b225>In box (not slipcase)
<!-- <measure> omitted for brevity -->
<x316>DE</x316>Made in Germany
<productpart>
    <!-- volumes not individually identified -->
    <b012>BC</b012>Paperback
    <b333>B102</b333>Trade paperback (US usage)
    <x322>3</x322>Three vols
</productpart>
trade-only pack of 8 copies each of two different hardback books, to be retailed as 16 individual items
using Reference names
<ProductComposition>30</ProductComposition>
<ProductForm>XL</ProductForm>
<!-- <Measure> omitted for brevity -->
<ProductPart>
    <ProductIdentifier>
        <ProductIDType>03</ProductIDType>
        <IDValue>9780001234567</IDValue>
    </ProductIdentifier>
    <ProductIdentifier>
        <ProductIDType>15</ProductIDType>
        <IDValue>9780001234567</IDValue>
    </ProductIdentifier>
    <ProductForm>BB</ProductForm>
    <NumberOfCopies>8</NumberOfCopies>
    <CountryOfManufacture>IT</CountryOfManufacture>
</ProductPart>
<ProductPart>
    <ProductIdentifier>
        <ProductIDType>03</ProductIDType>
        <IDValue>9780001234584</IDValue>
    </ProductIdentifier>
    <ProductIdentifier>
        <ProductIDType>15</ProductIDType>
        <IDValue>9780001234584</IDValue>
    </ProductIdentifier>
    <ProductForm>BB</ProductForm>
    <NumberOfCopies>8</NumberOfCopies>
    <CountryOfManufacture>IT</CountryOfManufacture>
</ProductPart>
using Short tags
<x314>30</x314>Multiple-item trade pack
<b012>XL</b012>Shrink-wrapped pack
<!-- <measure> omitted -->
<productpart>
    <productidentifier>
        <b221>03</b221>GTIN-13
        <b244>9780001234567</b244>(of book A)
    </productidentifier>
    <productidentifier>
        <b221>15</b221>ISBN
        <b244>9780001234567</b244>
    </productidentifier>
    <b012>BB</b012>Hardback
    <x323>8</x323>Eight copies
    <x316>IT</x316>
</productpart>
<productpart>
    <productidentifier>
        <b221>03</b221>
        <b244>9780001234584</b244>GTIN-13
    </productidentifier>(of book B)
    <productidentifier>
        <b221>15</b221>ISBN
        <b244>9780001234584</b244>
    </productidentifier>
    <b012>BB</b012>Hardback
    <x323>8</x323>Eight copies
    <x316>IT</x316>Printed in Italy
</productpart>
softback book with two-disc audiobook in sleeve attached to inside back cover (the audio version is not available as a separate product)
using Reference names
<ProductComposition>10</ProductComposition>
<ProductForm>SF</ProductForm>
<!-- <Measure> omitted for brevity -->
<ProductPart>
    <PrimaryPart/>
    <ProductIdentifier>
        <ProductIDType>03</ProductIDType>
        <IDValue>9780001234567</IDValue>
    </ProductIdentifier>
    <ProductIdentifier>
        <ProductIDType>15</ProductIDType>
        <IDValue>9780001234567</IDValue>
    </ProductIdentifier>
    <ProductForm>BC</ProductForm>
    <NumberOfCopies>1</NumberOfCopies>
    <CountryOfManufacture>ES</CountryOfManufacture>
</ProductPart>
<ProductPart>
    <!-- no separate identifier available -->
    <ProductForm>AC</ProductForm>
    <ProductFormDetail>A101</ProductFormDetail>
    <NumberOfItemsOfThisForm>2</NumberOfItemsOfThisForm>
    <CountryOfManufacture>AT</CountryOfManufacture>
</ProductPart>
using Short tags
<x313>10</x313>Multi-component product
<b012>SF</b012>Part(s) enclosed within largest item
<!-- <measure> omitted -->
<productpart>
    <x457/>Book is primary part
    <productidentifier>
        <b221>03</b221>GTIN-13
        <b244>9780001234567</b244>(of book as single product)
    </productidentifier>
    <productidentifier>
        <b221>15</b221>ISBN
        <b244>9780001234567</b244>
    </productidentifier>
    <b012>BC</b012>Paperback
    <x323>1</x323>One book
    <x316>ES</x316>Printed in Spain
</productpart>
<productpart>
    <!-- no separate identifier available -->
    <b012>AC</b012>CD-Audio
    <b333>A101</b333>‘Red Book’ audio format
    <x322>2</x322>Two discs
    <x316>AT</x316>Pressed in Austria
</productpart>
The <Measure> composite cannot be included inside <ProductPart> (although some size information may be included within <ProductFormDetail>). The exact physical size of each item in a multi-component product or (more relevantly) in a multi-item trade-only pack must be expressed in separate ONIX records for the individual items.

The use of <ProductPart> is required whenever <ProductComposition> indicates a multi-component or multi-item product. But for some legacy systems, it may not be possible to provide full details of each component within the product. What is the minimum amount of component information that can be supplied?

Within <ProductPart>, only the <ProductForm> element is mandatory, although one of <NumberOfItemsOfThisForm> or <NumberOfCopies> must also be provided. So the absolute minimum information required is – in effect – the type and number of components there are:

using Reference names
<ProductPart>
    <ProductForm>BA</ProductForm>
    <NumberOfItemsOfThisForm>3</NumberOfItemsOfThisForm>
</ProductPart>
using Short tags
<productpart>
    <b012>BA</b012>Book – detail unspecified
    <x322>3</x322>
</productpart>
In this case, the only information about the components is that there are three different components, and that they are books (it is not stated whether they are hardcovers or paperbacks). Three identical components would use <NumberOfCopies> instead.

Providing such minimal information about multi-component products is obviously poor practice, and enhancing the data so it at least clearly specifies the product form of the components should be a priority.

Although <ProductIdentifier>, <NumberOfItemsOfThisForm> and <NumberOfCopies> are all optional within an instance of the <ProductPart> composite, only certain combinations of these three elements are allowed. At least one of <NumberOfItemsOfThisForm> and <NumberOfCopies> must be included, and <NumberOfItemsOfThisForm> may not be used if <ProductIdentifier> is present. This allows just four possible combinations:

  1. Specify <ProductForm> and <NumberOfItemsOfThisForm>, omitting both <ProductIdentifier> and <NumberOfCopies>: this option is used, for example, where a product consists of multiple distinct components of the same or of differing Product forms, and each component does not have its own identifier. There would be one instance of <ProductPart> per Product form, each covering all components of that form;
  2. Specify all three of <ProductForm>, <ProductIdentifier> and <NumberOfCopies>, omitting <NumberOfItemsOfThisForm>: this option is used, for example, where a product consists of multiple distinct components, and each component has its own identifier. There would be one repeat of <ProductPart> per component identifier. There may be multiple distinct copies of each component, or there may be just one copy of each component (and note that <NumberOfCopies> must be included even if it is 1).

Patterns A and B cover the most common cases, including boxed sets, quantity packs, etc. The essential difference between A and B is whether the product parts in question have identifiers. To some degree, within a single product with many disparate components, it may be necessary to use a mix of <ProductPart> composites with patterns A and B.

Of the two remaining options, C is rarely used and D should be avoided:

  1. Specify only <ProductForm> and <NumberOfCopies>, omitting both <ProductIdentifier> and <NumberOfItemsOfThisForm>. This option is used (for example) where a product consists of multiple copies of a single component, and that component lacks its own Product identifier (implying single copies cannot be traded individually). There would be just one repeat of <ProductPart> that covers all copies;
  2. In theory, a fourth combination is valid, with <ProductForm>, <NumberOfItemsOfThisForm> and <NumberOfCopies>, omitting <ProductIdentifier>. It could be used (for example) where there are two copies each of two different components (of the same Product form), and neither component has its own identifier. There would be one repeat of <ProductPart>, with Number of items = 4 and Number of copies = 2. However, for this use case, it would be much clearer to use two repeats of <ProductPart;, each following option C.
P.4.1 ‘Primary part’ indicator

This should only be used with multi-component retail products (<ProductComposition> code 10), and when one particular component within that multi-component product can be considered the primary part. Omission implies that all components are of similar importance.

Product identifier composite (product part)

It is recommended that the <ProductIdentifier> composite is used for any component or item within a multiple-component or multi-item product that carries any kind of separate identifier, even if that identifier cannot be used for separate ordering of a single component or item from within the product. For example, the individual volumes within a boxed set may or may not be available individually, but in either case may have individual ISBNs.

See Product identifier composite within P.2 for best practice guidance.

P.4.5 Product form code (product part)

The <ProductForm> element is mandatory within each repeat of the <ProductPart> composite.

P.4.6 Product form detail (product part)

See P.3.3 Product form detail for best practice guidance.

Product form feature composite (product part)

See Product form feature composite within Group P.3 for best practice guidance.

Note that product form features such as safety warnings should normally be described at product level, even if they apply to only one part of a multi-component product. Safety warnings should only be carried within Group P.4 for multi-item trade packs that are intended to be broken into individual products before retail.

P.4.12, P.4.13 Number of items or copies

Either <NumberOfItemsOfThisForm> or <NumberOfCopies> should be included in every <ProductPart> composite:

  • <NumberOfCopies should be used when a <ProductPart> composite is describing a particular item within a multi-item product (there may be one or several copies of that particular item within the multi-item product). There would normally be a <ProductIdentifier> composite within the <ProductPart> composite;
  • <NumberOfItemsOfThisForm> should be used only when a single <ProductPart> composite is used to describe several different – but undifferentiated – items of identical Product form included within a multi-item product. The most common use case would be in describing a product such as a boxed set comprised of several volumes which are not themselves available individually. Note that if they were available separately, they would each have product identifiers, and so in describing the boxed set, separate <ProductPart> composites for each volume (and each of those with <NumberOfCopies> set to 1) would be more appropriate.
P.4.14 Country of manufacture (product part)

See P.3.15 Country of manufacture for best practice guidance.

P.5 Collection

Group P.5 consists of the <Collection> composite and the <NoCollection/> flag. The <Collection> composite may be used to carry details of any ‘bibliographic collection’ to which a product belongs – a collection might formally be termed a ‘set’ or a ‘series’, or might be a more informal grouping of related products. Alternatively, similar bibliographic collection details may be carried in Group P.6.

DescriptiveDetail (P.5 to P.7) Continued from P.4 Collection NoCollection TitleDetail ThesisType ThesisPresentedTo ThesisPresentedTo ThesisYear Contributor ContributorStatement ContributorStatement NoContributor Continued in Group P.8

Collections can be prescribed by the publisher, or ascribed to a range of independent products by a party other than the publisher – for example by a wholesaler or data aggregator. In the former case, details of the collection will usually appear formally on the product’s title page, whereas the latter may be an ad hoc grouping of products created for marketing or merchandising reasons.

Members of a collection share a collective identity, including at least a common collection title, and may share other attributes. For example, each product in a collection might have the same contributors, and collections usually have a consistent physical form, size and design style. Each member of a collection also has a unique identity – the ‘unshared’ title text. A collection may have an identifier for the collection as a whole, and the whole collection may be available as a single product, or as many individual products – ONIX makes no distinction. It is possible – though relatively rare – for a single product to be included in more than one collection, in which case multiple <Collection> composites may be used.

Collection identifiers and the shared identity of ascribed collections are always carried in P.5. A prescribed collection’s shared identity might be carried in either of Groups P.5 or P.6. Choosing between P.5 or P.6 can be tricky:

  • the collective identity – the shared parts of the title – are the ‘collection-level title details’;
    • where one collection is nested inside another, larger collection, these may be arranged hierarchically, in collection, sub-collection, sub-sub-collection fashion;
    • prescribed collections sit logically ‘within’ imprints (see Group P.19), rather than spanning imprints;
  • the unique, unshared parts of the title are the ‘product-level title details’;
  • if the product-level title is sufficiently distinct on its own, then the collection-level title is carried in Group P.5, and the product-level title in P.6;
  • if the product-level title always needs to be qualified with the collection-level title to provide context, because it is not distinctive enough on its own, then both collection- and product-level titles should be carried in Group P.6;
  • a collection-level title should never appear in both P.5 and P.6.

As an illustration, if a product-level title is ‘Workbook 6’, then it makes little sense without the collection-level title ‘Focus on Mathematics’ that expresses which student course Workbook 6 is a part of – there may be a ‘Workbook 6’ in ‘Focus on Physics’ too. In this case, both collection- and product-level titles should be in Group P.6. If the title is ‘The Beautiful and Damned’, then that is sufficiently distinctive on its own, and any collection title (such as ‘Penguin Modern Classics’) should be carried in Group P.5:

The Beautiful and the Damned (illustrating the structure of collection- and product-level title elements only)
<!-- Group P.5 -->
<Collection>
    <TitleDetail>
        <-- collection-level title element = Penguin Modern Classics -->
    </TitleDetail>
</Collection>
<!-- Group P.6 -->
<TitleDetail>
    <-- product-level title element = The Beautiful and the Damned -->
</TitleDetail>
Focus on Mathematics – Workbook 6
<!-- Group P.6 -->
<TitleDetail>
    <-- collection-level title element = Focus on Mathematics -->
    <-- product-level title element = Workbook 6 -->
</TitleDetail>
Choosing to use the second method does not necessarily mean there is no <Collection> composite – it may still be present, if for example it contains a collection identifier or collection sequence composite.
A recipient of the data is expected to display details from P.6 as ‘the title’, and this may include collection-level title detail. Other collection-level title information from P.5 should also be displayed, but is logically separate.

Where the products within a collection have a particular enumeration or sequence indicated on the product itself and considered to be part of the title, the <PartNumber> data element (or perhaps the <YearOfAnnual> element) should be used. However, this is not part of the collective identity: it is product-level data. Thus while typically a part or volume number will appear in the same Group as the collection-level title (either P.5 or P.6, depending on whether the product-level title always needs to be qualified with the collection-level information), it appears in a separate repeat of <TitleElement> with a different (ie a product-level) Title element level.

In contrast, where products within a collection have a particular sequence that is not indicated on the product (or occasionally, is indicated but is not considered to be part of the title), the <CollectionSequence> composite should be used.

And in some circumstances, it is useful to include <CollectionSequence> in addition to <PartNumber> – for example if the Part number is in Roman numerals or words. Supplying a numeric collection sequence number make such collections much simpler to sort into order.

The <NoCollection/> empty element indicates that the product does not belong to any type of collection (ie it indicates that there are no collection details in either P.5 or P.6). <NoCollection/> does not simply indicate there is no <Collection> composite – so it’s entirely possible to have no P.5 content at all in an ONIX Product record. It is also possible that a collection identifier or collection sequence number be included in P.5, even when the collection title is supplied in P.6.

Additional guidance and extensive examples on the description of collections are included in a separate document ONIX for Books: Product Information Format: How to describe sets, series and multiple-item products.

Any product in a collection should also make use of repeated <RelatedProduct> composites in Group P.23 to link to other products in the collection using <ProductRelationCode> code 30. In addition, if the collection is available as a single product (eg a boxed set), the individual product can link to the set product using relation code 02 (‘is part of’) (and in reverse, the set product can link to the individual product using relation code 01).

Collection CollectionType SourceName CollectionIdentifier CollectionIdentifier CollectionSequence CollectionSequence TitleDetail Contributor ContributorStatement ContributorStatement NoContributor include here only if national guidelines mandate naming of contributors at collection level
CollectionIdentifier CollectionIDType IDTypeName IDValue CollectionSequence CollectionSequenceType CollectionSequenceType CollectionSequenceTypeName CollectionSequenceTypeName CollectionSequenceNumber CollectionSequenceNumber must include if ID is proprietary, otherwise omit must include if sequence type is proprietary, otherwise omit
product that is part of an unordered collection
using Reference names
<Collection>
    <CollectionType>10</CollectionType>
    <TitleDetail>
        <TitleType>01</TitleType>
        <TitleElement>
            <TitleElementLevel>02</TitleElementLevel>
            <NoPrefix/>
            <TitleWithoutPrefix textcase="02">Oxford World’s Classics​</TitleWithoutPrefix>
        </TitleElement>
    </TitleDetail>
</Collection>
<!-- Group P.6 -->
<TitleDetail>
    <TitleType>01</TitleType>
    <TitleElement>
        <TitleElementLevel>01</TitleElementLevel>
        <TitlePrefix textcase="02">The</TitlePrefix>
        <TitleWithoutPrefix textcase="02">Lost World</TitleWithoutPrefix>
        <Subtitle textcase="01">Being an account of the recent amazing adventures of Professor George E. Challenger, Lord John Roxton, Professor Summerlee, and Mr E. D. Malone of the Daily Gazette</Subtitle>
    </TitleElement>
<TitleDetail>
using Short tags
<collection>
    <x329>10</x329>Publisher’s collection
    <titledetail>
        <b202>01</b202>Distinctive title
        <titleelement>
            <x409>02</x409>Collection level
            <x501/>
            <b031 textcase="02">Oxford World’s Classics</b031>
        </titleelement>
    </titledetail>
</collection>
<!-- Group P.6 -->
<titledetail>
    <b202>01</b202>
    <titleelement>Distinctive title
        <x409>01</x409>Product level
        <b030 textcase="02">The</b030>
        <b031 textcase="02">Lost World</b031>
        <b029 textcase="01">Being an account of the recent amazing adventures of Professor George E. Challenger, Lord John Roxton, Professor Summerlee, and Mr E. D. Malone of the Daily Gazette</b029>
    </titleelement>
<titledetail>
product that is part of an ordered collection. Le jour du soleil is the first book in the XIII series
using Reference names
<Collection>
    <CollectionType>10</CollectionType>
    <CollectionSequence>
        <CollectionSequenceType>02</CollectionSequenceType>
        <CollectionSequenceNumber>1</CollectionSequenceNumber>
    </CollectionSequence>
    <TitleDetail>
        <TitleType>01</TitleType>
        <TitleElement>
            <TitleElementLevel>02</TitleElementLevel>
            <NoPrefix/>
            <TitleWithoutPrefix textcase="01">XIII</TitleWithoutPrefix>
        </TitleElement>
        <TitleElement>
            <TitleElementLevel>01</TitleElementLevel>
            <PartNumber>Tome 1</PartNumber>
        </TitleElement>
    </TitleDetail>
</Collection>
<!-- Group P.6 -->
<TitleDetail>
    <TitleType>01</TitleType>
    <TitleElement>
        <TitleElementLevel>01</TitleElementLevel>
        <TitlePrefix textcase="01">Le</TitlePrefix>
        <TitleWithoutPrefix textcase="01">jour du soleil​</TitleWithoutPrefix>
    </TitleElement>
</TitleDetail>
using Short tags
<collection>
    <x329>10</x329>
    <collectionsequence>
        <x479>02</x479>Title order (confirmation)
        <x481>1</x481>
    </collectionsequence>
    <titledetail>
        <b202>01</b202>Distinctive title
        <titleelement>
            <x409>02</x409>Collection level
            <x501/>
            <b031 textcase="01">XIII</b031>
        </titleelement>
        <titleelement>
            <x409>01</x409>Product level
            <x410>Tome 1</x410>First item in collection
        </titleelement>
    </titledetail>
</collection>
<!-- Group P.6 -->
<titledetail>
    <b202>01</b202>Distinctive title
    <titleelement>
        <x409>01</x409>Product level
        <b030 textcase="01">Le</b030>
        <b031 textcase="01">jour du soleil​</b031>
    </titleelement>
</titledetail>
Note that the collection title XXXI is carried as a title (in <TitleWithoutPrefix>) even though it superficially resembles a part number.
The part number itself (Tome 1) is product-level attribute, not a part of the collective identity, so it occurs with a <TitleElementLevel> code 01, but it occurs within P.5, because the product level title in P.6 is distinctive enough without it.
product is part of a nested subcollection. The History of Greek Philosophy is in several volumes, of which The Fifth Century Enlightenment is the third. This third volume comes in two Parts, of which this product is the second
using Reference names
<Collection>
    <CollectionType>10</CollectionType>
    <CollectionSequence>
        <CollectionSequenceType>02</CollectionSequenceType>
        <CollectionSequenceNumber>3.2</CollectionSequenceNumber>
    </CollectionSequence>
    <TitleDetail>
        <TitleType>01</TitleType>
        <TitleElement>
            <TitleElementLevel>02</TitleElementLevel>
            <TitlePrefix textcase="02">A</TitlePrefix>
            <TitleWithoutPrefix textcase="02">History of Greek Philosophy</TitleWithoutPrefix>
        </TitleElement>
        <TitleElement>
            <TitleElementLevel>03</TitleElementLevel>
            <PartNumber>Volume 3</PartNumber>
            <TitlePrefix textcase="02">The</TitlePrefix>
            <TitleWithoutPrefix textcase="02">Fifth Century Enlightenment</TitleWithoutPrefix>
        </TitleElement>
        <TitleElement>
            <TitleElementLevel>01</TitleElementLevel>
            <PartNumber>Part 2</PartNumber>
        </TitleElement>
    </TitleDetail>
</Collection>
<!-- Group P.6 -->
<TitleDetail>
    <TitleType>01</TitleType>
    <TitleElement>
        <TitleElementLevel>01</TitleElementLevel>
        <NoPrefix/>
        <TitleWithoutPrefix>Socrates</TitleWithoutPrefix>
    </TitleElement>
</TitleDetail>
using Short tags
<collection>
    <x329>10</x329>Publisher collection
    <collectionsequence>
        <x479>02</x479>Title order (confirmation)
        <x481>3.2</x481>Two-level numbering
    </collectionsequence>
    <titledetail>
        <b202>01</b202>Distinctive title
        <titleelement>
            <x409>02</x409>Collection level
            <b030 textcase="02">A</b030>
            <b031 textcase="02">History of Greek Philosophy</b031>
        </titleelement>
        <titleelement>
            <x409>03</x409>Subcollection level
            <x410>Volume 3</x410>
            <b030 textcase="02">The</b030>
            <b031 textcase="02">Fifth Century Enlightenment</b031>
        </titleelement>
        <titleelement>
            <x409>01</x409>Product level
            <x410>Part 2</x410>
        </titleelement>
    </titledetail>
</collection>
<!-- Group P.6 -->
<titledetail>
    <b202>01</b202>Distinctive title
    <titleelement>
        <x409>01</x409>Product level
        <x501/>
        <b031>Socrates</b031>
    </titleelement>
</titledetail>
It is certainly possible to argue that the collection and subcollection details in the example above should be presented in Group P.6: in cases like this, the choice between P.5 and P.6 is not clear cut.
Notice that ‘Part 2’ is provided at title element level 01 (Product level), which indicates that the product is the second item in the subcollection (the ‘next level up’ in the hierarchy). ‘Volume 3’ is provided at title element level 03 (subcollection level), which indicates that the subcollection is the third item in the collection as a whole (again, the next level up). The <CollectionSequenceNumber> makes the structure clear.
collection identifier only in Group P.5, collection title supplied in Group P.6
using Reference names
<Collection>
    <CollectionType>10</CollectionType
    <CollectionIdentifier>
        <CollectionIDType>02</CollectionIDType>
        <IDValue>00173231</IDValue>
    </CollectionIdentifier>
</Collection>
<!-- Group P.6 -->
<TitleDetail>
    <TitleType>01</TitleType>
    <TitleElement>
        <TitleElementLevel>02</TitleElementLevel>
        <TitleText textcase="02">Granta</TitleText>
        <Subtitle textcase="01">The magazine of new writing</Subtitle>
    </TitleElement>
    <TitleElement>
        <TitleElementLevel>01</TitleElementLevel>
        <PartNumber>109</PartNumber>
        <TitleText textcase="02">Work</TitleText>
    </TitleElement>
</TitleDetail>
using Short tags
<collection>
    <x329>10</x329Publisher collection
    <collectionidentifier>
        <x344>02</x344>ISSN
        <b244>00173231</b244>
    </collectionidentifier>
</collection>
<!-- Group P.6 -->
<titledetail>
    <b202>01</b202>Distinctive title
    <titleelement>
        <x409>02</x409>Collection level
        <b203 textcase="01">Granta</b203>Title
        <b029 textcase="01">The magazine of new writing</b029>Subtitle
    </titleelement>
    <titleelement>
        <x409>01</x409>Product level
        <x410>109</x410>Number within collection
        <b203 textcase="01">Work</b203>Title
    </titleelement>
</titledetail>
In this case, the sender’s system is unable to distinguish reliably between titles with non-sorting prefixes and those without, so it uses <TitleText> rather than a combination of <NoPrefix/> and <TitleWithoutPrefix> to hold the collection-level and product-level titles (respectively, Granta and Work).
a product that is not a part of any collection
using Reference names
<NoCollection/>
using Short tags
<x411/>
Collection composite

Much of the structure of the <Collection> composite is shared with the <TitleDetail> composite, and similar best practices apply.

Although it is possible to identify contributors to the collection (eg a series editor) within the <Collection> composite – and this may be normal practice in some countries – it is best practice to identify all contributors in Group P.7 in international usage.

P.5.1 Collection type code

The <CollectionType> element is mandatory within a <Collection> composite. It is best practice to use only codes 10 or 20 from List 148, and also to include a source for any ascribed collection in the <SourceName> element. Source names need not be supplied for ‘publisher’ collections, as they are always prescribed by the publisher.

Collection identifier composite

This composite should be used to specify any relevant identifiers for the collection as a whole. It is unlikely that any formal identifiers exist for ascribed collections, but it would be possible to include a proprietary ID for an ascribed collection. For bibliographic (publisher–defined) collections, identifiers such as an ISSN may be appropriate.

Note that collection identifiers can only be carried in Group P.5, and may be included in P.5 even when the title text for the collection is carried in P.6.

Collection sequence composite

Where the collection is ordered in some way, this composite should be used to provide or confirm that ordering. An order or enumeration may be more or less explicit in the title (‘Volume 7’ is likely to be the seventh in the collection) and this should be included in <TitleDetail> – but it may be repeated here for confirmation, using <CollectionSequenceType> code 02 – this is particularly useful when the ordering is described in Roman numerals or in words (eg The Ersatz Elevator, ‘Book the Sixth’ in A Series of Unfortunate Events), because such collections are difficult to sort. However, the main use for this composite is to provide sequence information that is not shown on the product, for example, a narrative order for a fiction collection, or an original publication order for collected works previously published independently.

It is possible for the products in a collection to have more than one order – for example the narrative order of a collection of fiction products may not be the same as the order the products are published in, and in this case, multiple <CollectionSequence> composites may be supplied. It’s also common for the sequence number of an existing product to be changed as a result of publication of later products.

The numbering provided in <CollectionSequence> is not intended for display as part of the title by data recipients – what should be displayed is provided in <TitleDetail>. But the numbering provided in <CollectionSequence> should be used to sort the items in the collection.

‘prequel’ – separate narrative and publication orders
using Reference names
<CollectionSequence>
    <CollectionSequenceType>03</CollectionSequenceType>
    <CollectionSequenceNumber>3</CollectionSequenceNumber>
</CollectionSequence>
<CollectionSequence>
    <CollectionSequenceType>04</CollectionSequenceType>
    <CollectionSequenceNumber>1</CollectionSequenceNumber>
</CollectionSequence>
using Short tags
<collectionsequence>
    <x479>03</x479>Publication order
    <x481>3</x481>Third
</collectionsequence>
<collectionsequence>
    <x479>04</x479>Narrative order
    <x481>1</x481>First
</collectionsequence>
In simple collections, the collection sequence number is an integer (1, 2, 3…). However, for sub-collections that are nested within larger collections, a multi-level number can be used – for example sequence number 3.2 may indicate the second item in a sub-collection, where the sub-collection is sequentially third in the larger collection.
Note that the first-published item in a collection need not have the sequence number 1 (except of course when collection sequence type is 03). If a later ‘prequel’ is planned from the outset, the initial publication might be sequence number 2. Think Star Wars – the first film was numbered IV (4), but could equally have been numbered 2.1 (first film in second trilogy). A prequel that was not planned from the outset may require revision of previously-supplied metadata for already-published products in the collection, as their narrative order will be affected. A multi-level number like 0.5 or 0.1 (ie less than 1) should not be used to indicate a prequel added before item 1 in the collection.
Multi-level numbers can also be used to indicate intercalations. A collection may have three items in narrative sequence, with matching print and e-publications. But an additional publication might be added as an optional bonus, perhaps as a digital exclusive, and without being critical to the overall narrative. If the additional publication has a suggested sequential position, this can be indicated with a multi-level number (eg 2.1 would indicate the first e-publication intercalated between items 2 and 3 in the collection, and 0.1 could be used to indicate an intercalation before the first main publication). If the numbering is two-level, while the collection information indicates only a simple one-level collection, the sequence number clearly indicates an intercalation.

There are several cases where the relatively simple numbering or multi-level numbering of the items within a collection of sub-collection breaks down:

  • For products that are in an ordered collection but outside the sequential ordering of that collection (such items are termed « hors série » in French), the <CollectionSequence> composite should be omitted. Such products are normally sorted after the ordered products in the collection;
  • For products arranged in a collection and sub-collection structure, where the numbering of each item ignores their sub-collection position (eg where the ordering is simply the publication order, and publication of each item is independent of the sequence of sub-collections), then <CollectionSequenceNumber> should also ignore the sub-collections. For example, a book may be number 37 in the collection as a whole, in addition to its position as fourteenth in the third sub-collection. As such, it could carry the sequence number 37 and the sequence number 3.14;
  • For products arranged in a collection and sub-collection structure, where the sub-collections are ordered internally, but the sub-collections themselves are not in a particular order within the overall collection (ie there are both ordered and unordered ‘layers’ within the collection and sub-collection hierarchy). In this case, a hyphen may be used to represent the unordered layer – if a book is fifth in its sub-collection, but the sub-collections are not in any particular order within the collection, then it could carry the sequence number -.5 (and note, this is not a negative number).
Structurally fourteenth in the third sub-collection, but published 37th in the collection as a whole
Using Reference names
<CollectionSequence>
    <CollectionSequenceType>02</CollectionSequenceType>
    <CollectionSequenceNumber>3.14</CollectionSequenceNumber>
</CollectionSequence>
<CollectionSequence>
    <CollectionSequenceType>03</CollectionSequenceType>
    <CollectionSequenceNumber>37</CollectionSequenceNumber>
</CollectionSequence>
Using Short tags, with additional sub-collection publication ordering
<collectionsequence>
    <x479>02</x479>Title order
    <x481>3.14</x481>14th in third sub-collection
</collectionsequence>
<collectionsequence>
    <x479>03</x479>Publication order
    <x481>37</x481>37th in the collection as a whole
</collectionsequence>
<collectionsequence>
    <x479>03</x479>Publication order
    <x481>-.12</x481>12th in the sub-collection
</collectionsequence>
The additional information that the fourteenth book in the sub-collection is published twelveth suggests that there are two planned ‘prequels’ included in the sub-collection.
Title detail composite

The structure of this composite is identical to <TitleDetail> in Group P.6, but it should be used here to specify a title for the collection (unless it is provided in P.6). The composite must include a <TitleType> – typically, this will be code 01 (Distinctive title), but other types of collection title may be specified. The <TitleDetail> composite must also include at least one repeat of the <TitleElement> composite to carry the actual title.

Title element composite

The <TitleElementLevel> data element may be used to differentiate between a collection title (code 02) and a subcollection title (code 03, used where one collection is nested inside another). Occasionally, most commonly in children’s publishing, a collection also carries a ‘master brand’ (code 05), which might be used across many non-book products. Other values from List 149 may not be used within Group P.5, and code 03 should not be used without an accompanying repeat of <TitleElement> that uses code 02.

Any of P.5.7 Part number through P.5.12 Title text without prefix may carry information about the collection title. In addition, the P.5.13 Subtitle element may be used to carry a subtitle that is shared by all items in the collection. Typically, the title of the collection would be in either <TitleText>, or in a combination of <TitlePrefix> and <TitleWithoutPrefix> – do not use both of these options. See the note about the use of <TitlePrefix> in section Group P.6 <TitleElement> composite.

See the note about the <PartNumber> and <YearOfAnnual> data elements in Group P.6 <TitleElement> composite.

Spacing and punctuation should follow that used on the book itself. However, see the note about the case of text in section Group P.6 <TitleElement> composite.

Occasionally, the product’s collection- and product-level titles do contain some repetition. Repetition of title elements on the product itself should be replicated in the metadata.

repetition of title elements on the product itself should be followed in the metadata
using Reference names
<Collection>
    <CollectionType>10</CollectionType>
    <TitleDetail>
        <TitleType>01</TitleType>
        <TitleElement>
            <TitleElementLevel>05</TitleElementLevel>
            <NoPrefix/>
            <TitleWithoutPrefix textcase="02">Barbie™​</TitleWithoutPrefix>
        </TitleElement>
        <TitleElement>
            <TitleElementLevel>02</TitleElementLevel>
            <NoPrefix/>
            <TitleWithoutPrefix textcase="02">Easy Reader with Large Print​</TitleWithoutPrefix>
        </TitleElement>
    </TitleDetail>
</Collection>
<!-- Group P.6 -->
<TitleDetail>
    <TitleType>01</TitleType>
    <TitleElement>
        <TitleElementLevel>01</TitleElementLevel>
        <NoPrefix/>
        <TitleWithoutPrefix textcase="02">Barbie as a Pilot​</TitleWithoutPrefix>
    </TitleElement>
<TitleDetail>
using Short tags
<collection>
    <x329>10</x329>Publisher’s collection
    <titledetail>
        <b202>01</b202>Distinctive title
        <titleelement>
            <x409>05</x409>Master brand
            <x501/>
            <b031 textcase="02">Barbie™</b031>
        </titleelement>
        <titleelement>
            <x409>02</x409>Collection level
            <x501/>
            <b031 textcase="02">Easy Reader with Large Print​</b031>
        </titleelement>
    </titledetail>
</collection>
<!-- Group P.6 -->
<titledetail>
    <b202>01</b202>
    <titleelement>Distinctive title
        <x409>01</x409>Product level
        <x501/>
        <b031 textcase="02">Barbie as a Pilot​</b031>
    </titleelement>
<titledetail>
The repetition in this case potentially also encompasses the <Edition> information – the publisher should decide whether ‘with Large Print’ is a part of the collection identity, or whether it should be described as a large print edition (code LTE from List 21 in <EditionType>, within Group P.9). This may depend on whether there is a ‘normal print’ version as well.
P.5.64 “No collection” indicator

This is one of the few ONIX for Books data elements that are defined as empty (or ‘void’) XML elements. The ‘self-closing’ or minimized XML syntax should always be used (ie use <NoCollection/>, not <NoCollection> followed by </NoCollection>).

Note that the function of the tag is to provide positive indication that the product is not part of a collection. That means it should be used only when there is no <Collection> composite and there is no collection-level information within Group P.6.

P.6 Product title detail

Group P.6 consists primarily of the <TitleDetail> composite, which carries the title of the product. Every Product record must carry a title.

It is best practice to deliver title text in a structured and granular fashion, rather than simply providing text with punctuation to indicate the difference between collection, main title and subtitle. By providing the title in a structured way, it ensures the recipient of the data can store and process it in the most appropriate way in their own system. With products that have both a shared ‘collection’ title and an individual product-level title, these should be delivered in separate repeats of the <TitleElement> composite having different values in the <TitleElementLevel> data element. (Note that collection-level titles might be provided in Group P.5 instead.)

Do not add extra information to the title that properly appears elsewhere in the ONIX record. For example, there is often a temptation to add information about the product form, edition or audience to the title ‘because the title is always displayed prominently in the online store.’

For products which are known under more than one title – for example the distinctive title that is on the product, plus a former title that the work was previously known by – the entire <TitleDetail> composite is repeatable, with different values of <TitleType>.

For products where the title is long and complex, a ‘distributor’s title’ is a useful addition, to suggest an abbreviated but consistent title for use in systems with severe limits on title length (eg a maximum of 30 characters).

TitleDetail TitleType TitleElement TitleStatement TitleElement SequenceNumber SequenceNumber TitleElementLevel TitleElementLevel PartNumber YearOfAnnual Title Subtitle must include at least one for the contents of this box, see the diagram below. There is no associated <Title> tag – <YearOfAnnual> is immediately ‘followed’ by one of <TitleText>, <TitlePrefix> or <NoPrefix>, though note the entire box is optional
Title TitleText TitlePrefix NoPrefix TitleWithoutPrefix TitleWithoutPrefix Use only in legacy systems, or for languages that do not use prefixes which are ignored for sorting purposes
<TitleText> should be avoided wherever possible, but it is sometimes used by legacy systems that cannot treat prefixes such as ‘A’ or ‘The’ correctly, or occasionally in languages that do not use articles such as ‘A’ and ‘The’ at all.
simple product not part of a collection (language does use prefixes, but sending system cannot reliably distinguish between titles with prefixes and without)
using Reference names
<!-- Group P.5 -->
<NoCollection/>
<!-- Group P.6 -->
<TitleDetail>
    <TitleType>01</TitleType>
    <TitleElement>
        <TitleElementLevel>01</TitleElementLevel>
        <TitleText textcase="02">Mordsfreunde</TitleText>
    </TitleElement>
</TitleDetail>
using Short tags
<!-- Group P.5 -->
<x411/>
<!-- Group P.6 -->
<titledetail>
    <b202>01</b202>Distinctive title
    <titleelement>
        <x409>01</x409>Product level
        <b203 textcase="02">Mordsfreunde</b203>
    </titleelement>
</titledetail>
simple product with title and subtitle (sending system can reliably distinguish between titles with prefixes and without)
using Reference names
<!-- Group P.5 -->
<NoCollection/>
<!-- Group P.6 -->
<TitleDetail>
    <TitleType>01</TitleType>
    <TitleElement>
        <TitleElementLevel>01</TitleElementLevel>
        <NoPrefix/>
        <TitleWithoutPrefix>خريف الغضب​</TitleWithoutPrefix>
        <Subtitle>قصة بداية ونهاية السادات</Subtitle>
    </TitleElement>
</TitleDetail>
using Short tags
<!-- Group P.5 -->
<x411/>
<!-- Group P.6 -->
<titledetail>
    <b202>01</b202>Distinctive title
    <titleelement>
        <x409>01</x409>Product level
        <x501/>
        <b031>خريف الغضب</b031>Title
        <b029>قصة بداية ونهاية السادات</b029>and subtitle
    </titleelement>
</titledetail>
simple product with an alternative title
using Reference names
<!-- Group P.5 -->
<NoCollection/>
<!-- Group P.6 -->
<TitleDetail>
    <TitleType>01</TitleType>
    <TitleElement>
        <TitleElementLevel>01</TitleElementLevel>
        <NoPrefix/>
        <TitleWithoutPrefix textcase="02">Slumdog Millionaire​</TitleWithoutPrefix>
    </TitleElement>
</TitleDetail>
<TitleDetail>
    <TitleType>08</TitleType>
    <TitleElement>
        <TitleElementLevel>01</TitleElementLevel>
        <NoPrefix/>
        <TitleWithoutPrefix textcase="02">Q &amp; A</TitleWithoutPrefix>
    </TitleElement>
</TitleDetail>
using Short tags
<!-- Group P.5 -->
<x411/>
<!-- Group P.6 -->
<titledetail>
    <b202>01</b202>Distinctive title
    <titleelement>
        <x409>01</x409>Product level
        <x501/>
        <b203 textcase="02">Slumdog Millionaire</b203>
    </titleelement>
</titledetail>
<titledetail>
    <b202>08</b202>Former title
    <titleelement>
        <x409>01</x409>Product level
        <x501/>
        <b031 textcase="02">Q &amp; A</b031>Must use entity for ‘&’
    </titleelement>
</titledetail>
product that is part of a collection specified in Group P.5
using Reference names
<!-- Group P.5 -->
<Collection>
    <CollectionType>10</CollectionType>
    <TitleDetail>
        <TitleType>01</TitleType>
        <TitleElement>
            <TitleElementLevel>02</TitleElementLevel>
            <NoPrefix/>
            <TitleWithoutPrefix textcase="02">Larousse Petits Classiques​</TitleWithoutPrefix>
        </TitleElement>
    </TitleDetail>
</Collection>
<!-- Group P.6 -->
<TitleDetail>
    <TitleType>01</TitleType>
    <TitleElement>
        <TitleElementLevel>01</TitleElementLevel>
        <TitlePrefix textcase="02">Les</TitlePrefix>
        <TitleWithoutPrefix textcase="02">Misérables</TitleWithoutPrefix>
    </TitleElement>
</TitleDetail>
using Short tags
<!-- Group P.5 -->
<collection>
    <x329>10</x329>Publisher collection
    <titledetail>
        <b202>01</b202>Distinctive title
        <titleelement>
            <x409>02</x409>Collection level
            <x501/>
            <b031 textcase="02">Larousse Petits Classiques</b031>
        </titleelement>
    </titledetail>
</collection>
<!-- Group P.6 -->
<titledetail>
    <b202>01</b202>Distinctive title
    <titleelement>
        <x409>01</x409>Product level
        <b030 textcase="02">Les</b030>
        <b031 textcase="02">Misérables</b031>
    </titleelement>
</titledetail>
omnibus edition of three novels, without a distinctive title of its own
using Reference names
<!-- no Group P.5 -->
<!-- Group P.6 -->
<TitleDetail>
    <TitleType>01</TitleType>
    <TitleElement>
        <SequenceNumber>1</SequenceNumber>
        <TitleElementLevel>01</TitleElementLevel>
        <NoPrefix/>
        <TitleWithoutPrefix>Sense and Sensibility / Pride and Prejudice / Northanger Abbey​</TitleWithoutPrefix>
    </TitleElement>
</TitleDetail>
using Short tags
<!-- no Group P.5 -->
<!-- Group P.6 -->
<titledetail>
    <b202>01</b202>
    <titleelement>
        <b034>1</b034>
        <x409>01</x409>
        <x501/>
        <b031 textcase="02">Sense and Sensibility / Pride and Prejudice / Northanger Abbey</b031>
    </titleelement>
</titledetail>
If the omnibus edition has a distinctive title of its own (something like The Jane Austen Omnibus, Part One), that should be used in preference. The constituent titles could then be listed as a subtitle if necessary. Multiple titles are conventionally separated by spaced slash characters. The more sophisticated alternative examples below list the novel titles individually, either in Group P.6 or in <ContentDetail> in Group P.18 (see Block 3). The Block 3 approach is preferred.
omnibus edition of three novels, with a distinctive title of its own and the novel titles listed individually in the subtitle (basic method)
using Reference names
<!-- no Group P.5 -->
<!-- Group P.6 -->
<TitleDetail>
    <TitleType>01</TitleType>
    <TitleElement>
        <TitleElementLevel>01</TitleElementLevel>
        <PartNumber>Part One</PartNumber>
        <TitlePrefix>The</TitlePrefix>
        <TitleWithoutPrefix>Jane Austen Omnibus</TitleWithoutPrefix>
        <Subtitle>Sense and Sensibility / Price and Prejudice / Northanger Abbey</Subtitle>
    </TitleElement>
    <TitleStatement>The Jane Austen Omnibus, Part One: Sense and Sensibility / Price and Prejudice / Northanger Abbey</TitleStatement>
</TitleDetail>
using Short tags
<!-- no Group P.5 -->
<!-- Group P.6 -->
<titledetail>
    <b202>01</b202>
    <titleelement>
        <x409>01</x409>Product level
        <x410>Part One</x410>
        <b030>The</b030>Title of the omnibus
        <b031>Jane Austen Omnibus</b031>
        <b029>Sense and Sensibility / Price and Prejudice / Northanger Abbey</b029>
    </titleelement>
    <x478>The Jane Austen Omnibus, Part One: Sense and Sensibility / Price and Prejudice / Northanger Abbey</x478>
</titledetail>
omnibus edition of three novels, with a distinctive title of its own and the novel titles listed individually in Group P.6 (not recommended unless the novel titles are listed on the title page)
using Reference names
<!-- no Group P.5 -->
<!-- Group P.6 -->
<TitleDetail>
    <TitleType>01</TitleType>
    <TitleElement>
        <SequenceNumber>1</SequenceNumber>
        <TitleElementLevel>01</TitleElementLevel>
        <PartNumber>Part One</PartNumber>
        <TitlePrefix>The</TitlePrefix>
        <TitleWithoutPrefix>Jane Austen Omnibus</TitleWithoutPrefix>
    </TitleElement>
    <TitleElement>
        <SequenceNumber>2</SequenceNumber>
        <TitleElementLevel>04</TitleElementLevel>
        <NoPrefix/>
        <TitleWithoutPrefix>Sense and Sensibility</TitleWithoutPrefix>
    </TitleElement>
    <TitleElement>
        <SequenceNumber>3</SequenceNumber>
        <TitleElementLevel>04</TitleElementLevel>
        <NoPrefix/>
        <TitleWithoutPrefix>Pride and Prejudice</TitleWithoutPrefix>
    </TitleElement>
    <TitleElement>
        <SequenceNumber>4</SequenceNumber>
        <TitleElementLevel>04</TitleElementLevel>
        <NoPrefix/>
        <TitleWithoutPrefix>Northanger Abbey</TitleWithoutPrefix>
    </TitleElement>
    <TitleStatement>The Jane Austen Omnibus, Part One: Sense and Sensibility / Price and Prejudice / Northanger Abbey</TitleStatement>
</TitleDetail>
using Short tags
<!-- no Group P.5 -->
<!-- Group P.6 -->
<titledetail>
    <b202>01</b202>
    <titleelement>
        <b034>1</b034>
        <x409>01</x409>Product level
        <x410>Part One</x410>
        <b030>The</b030>Title of the omnibus
        <b031>Jane Austen Omnibus</b031>
    </titleelement>
    <titleelement>First item in omnibus
        <b034>2</b034>
        <x409>04</x409>Content item level title
        <x501/>
        <b031>Sense and Sensibility</b031>
    </titleelement>
    <titleelement>Second item in omnibus
        <b034>3</b034>
        <x409>04</x409>Content item level title
        <x501/>
        <b031>Pride and Prejudice</b031>
    </titleelement>
    <titleelement>Third item in omnibus
        <b034>4</b034>
        <x409>04</x409>Content item level title
        <x501/>
        <b031>Northanger Abbey</b031>
    </titleelement>
    <x478>The Jane Austen Omnibus, Part One: Sense and Sensibility / Price and Prejudice / Northanger Abbey</x478>
</titledetail>
omnibus edition of three novels, with a distinctive title of its own and the novel titles listed individually in Block 3 (recommended method)
using Reference names
<!-- no Group P.5 -->
<!-- Group P.6 -->
<TitleDetail>
    <TitleType>01</TitleType>
    <TitleElement>
        <SequenceNumber>1</SequenceNumber>
        <TitleElementLevel>01</TitleElementLevel>
        <PartNumber>Part One</PartNumber>
        <TitlePrefix>The</TitlePrefix>
        <TitleWithoutPrefix>Jane Austen Omnibus</TitleWithoutPrefix>
    </TitleElement>
    <TitleStatement>The Jane Austen Omnibus, Part One</TitleStatement>
</TitleDetail>
. . .
<!-- Group P.18 -->
<ContentItem>
    <LevelSequenceNumber>1</LevelSequenceNumber>
    <TextItem>
        <TextItemType>01</TextItemType>
        <PageRun>
            <FirstPageNumber>1</FirstPageNumber>
        </PageRun>
    </TextItem>
    <TitleDetail>
        <TitleType>01</TitleType>
        <TitleElement>
            <TitleElementLevel>04</TitleElementLevel>
            <NoPrefix/>
            <TitleWithoutPrefix>Sense and Sensibility</TitleWithoutPrefix>
        </TitleElement>
    </TitleDetail>
</ContentItem>
<ContentItem>
    <LevelSequenceNumber>2</LevelSequenceNumber>
    <TextItem>
        <TextItemType>01</TextItemType>
        <PageRun>
            <FirstPageNumber>417</FirstPageNumber>
        </PageRun>
    </TextItem>
    <TitleDetail>
        <TitleType>01</TitleType>
        <TitleElement>
            <TitleElementLevel>04</TitleElementLevel>
            <NoPrefix/>
            <TitleWithoutPrefix>Sense and Sensibility</TitleWithoutPrefix>
        </TitleElement>
    </TitleDetail>
</ContentItem>
<ContentItem>
    <LevelSequenceNumber>3</LevelSequenceNumber>
    <TextItem>
        <TextItemType>01</TextItemType>
        <PageRun>
            <FirstPageNumber>865</FirstPageNumber>
        </PageRun>
    </TextItem>
    <TitleDetail>
        <TitleType>01</TitleType>
        <TitleElement>
            <TitleElementLevel>04</TitleElementLevel>
            <NoPrefix/>
            <TitleWithoutPrefix>Sense and Sensibility</TitleWithoutPrefix>
        </TitleElement>
    </TitleDetail>
</ContentItem>
using Short tags
<!-- no Group P.5 -->
<!-- Group P.6 -->
<titledetail>
    <b202>01</b202>
    <titleelement>
        <b034>1</b034>
        <x409>01</x409>Product level
        <x410>Part One</x410>
        <b030>The</b030>Title of the omnibus
        <b031>Jane Austen Omnibus</b031>
    </titleelement>
    <x478>The Jane Austen Omnibus, Part One</x478>
</titledetail>
. . .
<!-- Group P.18 -->
<contentitem>Third item in omnibus
    <b284>1</b284>
    <textitem>
        <b290>01</b290>
        <pagerun>
            <b286>1</b286>Starts page 1
        </pagerun>
    </textitem>
    <titledetail>
        <b202>01</b202>
        <titleelement>
            <x409>04</x409>Content item level title
            <x501/>
            <b031>Sense and Sensibility</b031>
        </titleelement>
    </titledetail>
</contentitem>
<contentitem>Third item in omnibus
    <b284>2</b284>
    <textitem>
        <b290>01</b290>
        <pagerun>
            <b286>417</b286>Starts page 417
        </pagerun>
    </textitem>
    <titledetail>
        <b202>01</b202>
        <titleelement>
            <x409>04</x409>Content item level title
            <x501/>
            <b031>Sense and Sensibility</b031>
        </titleelement>
    </titledetail>
</contentitem>
<contentitem>Third item in omnibus
    <b284>3</b284>
    <textitem>
        <b290>01</b290>
        <pagerun>
            <b286>865</b286>Starts page 865
        </pagerun>
    </textitem>
    <titledetail>
        <b202>01</b202>
        <titleelement>
            <x409>04</x409>Content item level title
            <x501/>
            <b031>Sense and Sensibility</b031>
        </titleelement>
    </titledetail>
</contentitem>
The <PageRun> information can be used to construct a detailed table of contents.
manga novel with collection title included in P.6
using Reference names
<!-- no Group P.5 -->
<!-- Group P.6 -->
<TitleDetail>
    <TitleType>01</TitleType>
    <TitleElement>
        <SequenceNumber>1</SequenceNumber>
        <TitleElementLevel>02</TitleElementLevel>
        <NoPrefix/>
        <TitleWithoutPrefix textcase="02">Kobato.</TitleWithoutPrefix>
    </TitleElement>
    <TitleElement>
        <SequenceNumber>2</SequenceNumber>
        <TitleElementLevel>01</TitleElementLevel>
        <PartNumber>3</PartNumber>
    </TitleElement>
    <TitleStatement>Kobato. 3</TitleStatement>
</TitleDetail>
using Short tags
<!-- no Group P.5 -->
<!-- Group P.6 -->
<titledetail>
    <b202>01</b202>Distinctive title
    <titleelement>
        <b034>1</b034>
        <x409>02</x409>Collection level
        <x501/>
        <b031 textcase="02">Kobato.</b031>
    </titleelement>
    <titleelement>
        <b034>2</b034>
        <x409>01</x409>Product level
        <x410>3</x410>
    </titleelement>
    <x478>Kobato. 3</x478>
</titledetail>
The part number is the only product-level title information for this product – there is no product level title text. The title statement is somewhat unnecessary here, since it is a simple concatenation of the title elements, but is provided for the avoidance of doubt about the nature of the product-level title.
Title detail composite

At least one <TitleDetail> composite is mandatory, to carry the product title. The composite must include a <TitleType> – typically, this will specify code 01 (Distinctive title) – and at least one repeat of the <TitleElement> composite.

Multiple repeats of the whole <TitleDetail> composite can be used to carry different types of title – for example a former title of a product whose name has been changed, or the original language title of a product published in translation. While a recipient might not display such alternative titles, they can be helpful as search terms.

Contrast the titles of the Shakespeare plays Twelfth Night, or What You Will, where the full title itself contains an ‘alternative’ name for the play, and Much Ado About Nothing which is occasionally known by the genuine alternative title of Benedick and Beatrice. The latter requires two <TitleDetail> composites, the former just one, with the complete title text in a single <TitleText> or <TitleWithoutPrefix> element.

It may also be useful to specify the distributor’s title: this is often abbreviated or truncated in order to fit on a single line on order confirmations, invoices and other documents, or sized to fit a fixed-length database field in a legacy sales order processing system – it is common for distribution systems to limit the length of a title to 30 or so characters. Such titles often also mix collection and product-level elements, or other non-title details such as binding type, edition and so on (eg 12th N sch ed w. class no 30pk). Thus a Distributor’s title can appear somewhat cryptic, and specifying it can be an aid if any matching against other documents (eg invoices) is required.

Title element composite

Any of P.6.3 <PartNumber> through P.6.8 <Subtitle> may carry information about the product title.

Conceptually, each of the elements of a title belongs to either ‘product’ or ‘collection’ level – that is, it is part of the identity of the product itself, or is part of the identity of a group of products.

Multiple repeats of the <TitleElement> composite within one <TitleDetail> are often needed if the product belongs to a collection and the full collection details are not included in Group P.5 (ie there are two or more <TitleElement> composites with different levels), or if the title contains several largely independent parts – for example an annual or yearbook may have both a textual title and a year or date (ie there are two or more <TitleElement> composites with the same level).

Where the presentation order of multiple title elements at different levels is important, then the <SequenceNumber> data element should be included within each repeat of <TitleElement> – thus <SequenceNumber> should be used to guide data recipients on whether a collection title should ideally be displayed before or after the product-level title. However, their display order (eg on a web page) may be dictated by the recipient’s screen design. Despite this, never carry a collection title in the <Subtitle> element ‘to ensure it is displayed after the main title’.

Where a title has multiple data elements at the same level – say it has a <PartNumber>, <TitleText>, plus a <Subtitle>, which are all at ‘product level’ – then these can be expressed in a single <TitleElement> composite, or in two separate repeats of <TitleElement> within a single <TitleDetail> (note that a <TitleElement> containing only a subtitle is not valid). Either is acceptable. Data recipients might concatenate these three elements for display purposes in a common-sense order (part number first, subtitle last), or – if each separate <TitleElement> contains a <SequenceNumber> – should follow the guidance of the <SequenceNumber>.

multiple title elements at the same level: a book entitled The Best Season Ever: 1998 in a collection Baseball Year by Year
using Reference names
<!-- collection title carried in Group P.5 -->
<TitleElement>
    <SequenceNumber>1</SequenceNumber>
    <TitleElementLevel>01</TitleElementLevel>
    <TitlePrefix textcase="02">The</TitlePrefix>
    <TitleWithoutPrefix textcase="02">Best Season Ever</TitleWithoutPrefix>
</TitleElement>
<TitleElement>
    <SequenceNumber>2</SequenceNumber>
    <TitleElementLevel>01</TitleElementLevel>
    <YearOfAnnual>1998</YearOfAnnual>
</TitleElement>
using Short tags
<!-- collection title carried in Group P.5 -->
<titleelement>
    <b034>1</b034>First part of
    <x409>01</x409>product-level title
    <b030 textcase="02">The</b030>
    <b031 textcase="02">Best Season Ever</b031>
</titleelement>
<titleelement>
    <b034>2</b034>Second part of
    <x409>01</x409>product-level title
    <b020>1998</b020>
</titleelement>
This approach is better than putting the title text and year of annual in the same <TitleElement> composite, because it ensures the recipient understands that the title is not 1998: Best Season Ever.
The sender’s system is unable to distinguish reliably between titles with and without prefixes, so it uses <TitleText> instead of <NoPrefix/> and <TitleWithoutPrefix>.
multiple title elements at different levels: a book called Descent: Book 3 of The Exo Cycle
using Reference names
<TitleElement>
    <SequenceNumber>1</SequenceNumber>
    <TitleElementLevel>01</TitleElementLevel>
    <NoPrefix/>
    <TitleText textcase="02">Descent</TitleText>
</TitleElement>
<TitleElement>
    <SequenceNumber>2</SequenceNumber>
    <TitleElementLevel>01</TitleElementLevel>
    <PartNumber>Book 3</PartNumber>
</TitleElement>
<TitleElement>
    <SequenceNumber>3</SequenceNumber>
    <TitleElementLevel>02</TitleElementLevel>
    <TitlePrefix textcase="02">The</TitlePrefix>
    <TitleWithoutPrefix textcase="02">Exo Cycle</TitleWithoutPrefix>
</TitleElement>
using Short tags
<titleelement>
    <b034>1</b034>First part of
    <x409>01</x409>product-level title
    <x501/>
    <b031 textcase="02">Descent</b031>
</titleelement>
<titleelement>
    <b034>2</b034>Second part of title
    <x409>01</x409>(at product level)
    <x410>Book 3</x410>
</titleelement>
<titleelement>
    <b034>3</b034>
    <x409>02</x409>
    <b030 textcase="02">The</b030>Third part of title
    <b031 textcase="02">Exo Cycle</b031>(at collection level)
</titleelement>
This makes it clear that the collection title is best placed after the product-level title (ie not The Exo Cycle – Book 3: Descent). Positioning of the collection title within P.6 rather than in P.5 is a complex decision. See the guidance in P.5 Collection.
In this case, the sender’s system can distinguish reliably between titles with and without prefixes that are ignored for sorting purposes. Thus the collection-level title The Exo Cycle uses <TitlePrefix> and the product-level title Descent makes use of <NoPrefix/> and <TitleWithoutPrefix>.

Optionally, if the title is particularly complex, and simple concatenation of the various title elements (in the order specified) is not enough, then a <TitleStatement> can be used (always in addition to the granular title elements). For recipients, if a title statement is provided, this should be used for display purposes wherever possible, while the individual title elements may be used for more advanced search or collation purposes. Note that a title statement should include the subtitle, and any intermediate punctuation, but should not include the text of any alternative titles – alternative titles may have a title statement of their own.

Typically, the main text of a title element would be in one of:

  • a combination of <NoPrefix/> and <TitleWithoutPrefix> or
  • a combination of <TitlePrefix> and <TitleWithoutPrefix> or
  • <TitleText>

The last of these options – <TitleText> – is reserved for use when the sending system cannot differentiate between titles that include a prefix and titles that do not. The other two choices should be used when the system can differentiate. <TitlePrefix> is used when the title begins with a prefix that should be ignored for collation purposes (depending on the language of the title text: in English, ‘A’, ‘An’ or ‘The’ are ignored for collation, in Spanish, «El», «La», «Las», «Lo», «Los», «Un», «Una», «Unas», «Unos»). <NoPrefix/> is an empty element that provides positive indication that there is no prefix. Note that a title beginning with ‘A to Z’ or with a place name like ‘El Paso’ would not normally use <TitlePrefix>, since ‘A’ or ‘El’ are not ignored for collation purposes in these circumstances. Titles beginning with quotation marks, an apostrophe or initial punctuation like ¡ or ¿ do not use <TitlePrefix> even though those marks are ignored for collation purposes. In rare cases where there is both initial punctuation and a non-sorting prefix, such as the title Spanish ¿La madre también?, <TitlePrefix> would be used for «¿La».

If limitations in internal systems mean that a data supplier genuinely cannot distinguish titles that carry prefixes from those that do not – and thus cannot use <TitlePrefix>, <NoPrefix/> and <TitleWithoutPrefix> correctly – then <TitleText> should be used. This means that a recipient which wishes to take definite account for prefixes when sorting titles needs to inspect all records using <TitleText>.

In some countries, specific local guidelines suggest that all titles use <TitleText>, either because few supply chain IT systems have the ability to differentiate or store prefixes separately (eg <TitleText>Het temmen van de feeks</TitleText>, Shakespeare’s The Taming of the Shrew in Dutch), or because the languages do not normally use definite and indefinite articles (eg <TitleText>Mannen på balkongen</TitleText>, Maj Sjöwall and Per Wallöö’s The Man on the Balcony in Swedish). However, even in these countries, records sent and received internationally should ideally use <TitlePrefix>, <NoPrefix/> and <TitleWithoutPrefix>.

When a title is not in the same language as the main text content of the product itself, the language attribute should be included.

product in English, with title in French – compare with the Larousse Petits Classiques version (above), which is in French throughout. Distributor’s title also included
using Reference names
<!-- Group P.5 -->
<Collection>
    <CollectionType>10</CollectionType>
    <TitleDetail>
        <TitleType>01</TitleType>
        <TitleElement>
            <TitleElementLevel>02</TitleElementLevel>
            <TitleText textcase="02">Penguin Classics</TitleText>
        </TitleElement>
    </TitleDetail>
</Collection>
<!-- Group P.6 -->
<TitleDetail>
    <TitleType>01</TitleType>
    <TitleElement>
        <TitleElementLevel>01</TitleElementLevel>
        <TitlePrefix language="fre" textcase="02">Les</TitlePrefix>
        <TitleWithoutPrefix language="fre" textcase="02">Misérables</TitleWithoutPrefix>
    </TitleElement>
</TitleDetail>
<TitleDetail>
    <TitleType>10</TitleType>
    <TitleElement>
        <TitleElementLevel>01</TitleElementLevel>
        <TitleText>LES MISERABLES (PENG CLASS B)</TitleText>
    </TitleElement>
</TitleDetail>
using Short tags
<!-- Group P.5 -->
<collection>
    <x329>10</x329>Publisher collection
    <titledetail>
        <b202>01</b202>Distinctive title
        <titleelement>
            <x409>02</x409>Collection level
            <b203 textcase="02">Penguin Classics​</b203>
        </titleelement>
    </titledetail>
</collection>
<!-- Group P.6 -->
<titledetail>
    <b202>01</b202>Distinctive title
    <titleelement>
        <x409>01</x409>Product level
        <b030 language="fre" textcase="02">Les</b030>Title is in French…
        <b031 language="fre" textcase="02">​Misérables​</b031>not translated into English as ‘The Wretched Ones’ or similar, and is in Title case
    </titleelement>
</titledetail>
<titledetail>
    <b202>10</b202>Distributor’s title
    <titleelement>
        <x409>01</x409>Product level
        <b203>LES MISERABLES (PENG CLASS B)​</b203>
    </titleelement>
</titledetail>
The Collection title given is paired with the Distinctive title, not the Distributor’s title, on the basis that they carry the same code in <TitleType>.

It is not normally expected that metadata provided by publishers follows formal library cataloging rules (for example the AACR2 or RDA content rules). With the exception of the case of the text, the title information provided in an ONIX record should follow the title as it is provided on the product title page (or equivalent). Acronyms and initialisms should be capitalized and punctuated as they are on the product’s title page.

In scripts with distinct upper and lower case (including Latin, Cyrillic etc, but not for example Arabic or Japanese Kanji), the textcase attribute is important with textual data elements such as <TitleText>, <TitlePrefix>, <TitleWithoutPrefix> and <Subtitle>. It is best practice to follow the conventions of the language of the title, and to include the textcase attribute. In many languages using a cased script, it is normal style to present titles and similar textual data in ‘sentence case’ (first word and all proper nouns carry an initial capital – note this means that the first character of <TitleWithoutPrefix> is lower case, unless it is a proper noun or a capitalized acronym). In English and some other cased languages, it is normal style to supply titles – but not subtitles – in ‘title case’ (all words carry an initial capital except for articles, most prepositions and most conjunctions that appear mid-sentence). Subtitles should always be presented in sentence case. Titles and similar textual data should never be presented in ALL UPPER CASE, and in instances where this is unavoidable (for example, with legacy data), use the textcase attribute with code 03.

Upper case titles constructed solely from acronyms or initialisms (eg ‘VAX FORTRAN’) are correct in both title and in sentence case, and should not usually marked with textcase code 03.

In scripts where the sort order is not essentially alphabetic – for example in Japanese Kanji where names and titles are sorted phonetically, or in Traditional or Simplified Chinese Hanzi where Pinyin or Zhuyin phonetics or (occasionally) the number of brush strokes in individual characters control the collation order – the collationkey attribute can be included. This would typically contain a phonetic transliteration of the data element (in Hiragana, Katakana, Pinyin or Zhuyin etc).

When the language of the title is not the expected language of the message, then the language attribute should also be provided.

Note that <PartNumber> indicates a sequential position within a collection, and should not be used unless details of the collection are included (either in Group P.5 or in P.6). A volume or part number is normally product-level information, not part of the shared identity of a collection, and would thus appear with <TitleElementLevel> 01 – and it might appear either in the same repeat of <TitleElement> as the product-level title or as a separate title element. It is a common error to supply a part number or year at collection level, when it belongs at product level. However, <PartNumber> may occasionally be sub-collection level information where one collection is nested inside another.

<PartNumber> might be a simple number, or might convey the ‘type’ of the item within the collection – a volume, a part, a book, a tome and so on. If anything more than a simple number is used, ensure the terminology matches that on the product, and that the text is presented consistently (including consistent spacing and abbreviation) so that items in the collection will sort correctly into order whenever possible. In this circumstance, it is good practice also to provide the ordinal position of the product within the collection in the <CollectionSequence> composite in Group P.5. Where it is provided, recipients should use <CollectionSequence> to sort members of a collection into order, in preference to using <PartNumber>. This composite is particularly useful with sub-collections.

<PartNumber>3</PartNumber> (number 3 in a series)
<PartNumber>Part 3</PartNumber> (a named Part 3)
<PartNumber>Volume 3</PartNumber> (a named Volume 3)
<PartNumber>Book III</PartNumber> (note that neither roman numerals nor a named ‘Book Three’ sort into the correct order alphabetically)
<PartNumber>Parts 3–5</PartNumber> (Parts 3, 4 and 5 of a collection in a single item)

Similar considerations apply to the use of <YearOfAnnual>, which might contain a simple year (‘2011’), or something qualified such as ‘2009/10 Season’. Consistency is important, or the individual products of a collection will not sort into the correct order (even when simple sorting is possible).

P.7 Authorship

The various contributors to a product are listed in repeats of the <Contributor> composite. It is best practice to include at least all the contributors named on the book’s title page (or those named with equivalent prominence on another type of product). However, it is normal to omit those such as ‘ghost writers’ not named on the product itself.

If there are no repeats of the <Contributor> composite, the <NoContributor/> empty element gives a positive indication that there are no contributors.

Contributor composite

Personal naming schemes are complex, sensitive and vary greatly between cultures, so data suppliers and recipients should take great care that names are presented correctly. The ONIX data elements for structured names attempt to isolate the parts of the name used for cataloging, advanced searching and sorting purposes, rather than trying to specify the ‘genealogical’ or familial structure of a name. Consider for example, three names, Sharon Stanton Russell, Anna Margaret Lindholm and Carmen Conde Abellán. For the (American) name Sharon Stanton Russell, Stanton is her unmarried family name (maiden name) retained after marriage, whereas for (British) Anna Margaret Lindholm, Margaret is a second given name. ONIX does not differentiate between these cases – ‘Russell’ and ‘Lindholm’ are the <KeyNames>, and Sharon Stanton and Anna Margaret would both be treated as <NamesBeforeKey>, even though one contains only given names and the other contains a family name. In the case of the (Spanish) name Carmen Conde Abellán, the <KeyNames> are ‘Conde Abellán’, since both are family names used for sorting purposes.

Contributor SequenceNumber SequenceNumber ContributorRole FromLanguage ToLanguage NameType NameIdentifier Personal or Corporate name UnnamedPersons UnnamedPersons AlternativeName Associated attributes Associated attributes UnnamedPersons UnnamedPersons ContributorPlace for the contents of these boxes, see the diagrams below. There is no tag associated with either box, so for example the end tag of <NameIdentifier> can be followed directly by the first tag of the personal or corporate name <PersonName> deprecated here. Use <UnnamedPersons> and AssociatedAttributes at the main location instead
Personal or Corporate name personal or corporate names should use one of these three options – a simple personal name (above), a structured personal name (left), or a corporate name (below) PersonName PersonNameInverted PersonNameInverted Gender must include at least one CorporateName CorporateNameInverted CorporateNameInverted must include at least one PersonName PersonNameInverted PersonNameInverted TitlesBeforeNames TitlesBeforeNames NamesBeforeKey NamesBeforeKey PrefixToKey KeyNames NamesAfterKey SuffixToKey LettersAfterNames LettersAfterNames TitlesAfterNames Gender there is some value in providing PersonName and PersonNameInverted in addition to a structured name
Associated attributes ContributorDate ProfessionalAffiliation ProfessionalAffiliation Prize Prize BiographicalNote BiographicalNote Website ContributorDescription ContributorDescription ContributorPlace ContributorPlace repeatable, to provide the contributor biography in multiple languages
single contributor, contributor identifiers (including an ISNI) and all three forms of name provided
using Reference names
<Contributor>
    <SequenceNumber>1</SequenceNumber>
    <ContributorRole>A01</ContributorRole>
    <NameIdentifier>
        <NameIDType>16</NameIDType>
        <IDValue>0000000020691583</IDValue>
    </NameIdentifier>
    <NameIdentifier>
        <NameIDType>01</NameIDType>
        <IDTypeName>Ullstein Buchverlage Autor ID</IDTypeName>
        <IDValue>01381</IDValue>
    </NameIdentifier>
    <PersonName>Nele Neuhaus</PersonName>
    <PersonNameInverted>Neuhaus, Nele</PersonNameInverted>
    <NamesBeforeKey>Nele</NamesBeforeKey>
    <KeyNames>Neuhaus</KeyNames>
    <Gender>f</Gender>
    <BiographicalNote textformat="05"><p><strong>Nele Neuhaus</strong> wurde 1967 als zweites von vier Kindern der Familie Löwenberg in Münster/Westfalen geboren. Sie wuchs in Paderborn auf, bevor sie im Alter von 11 Jahren mit ihrer Familie in den Taunus zog, als ihr Vater Landrat wurde. Schon seit frühester Kindheit schrieb Nele Neuhaus, zuerst handschriftlich in Schulhefte, später mit Reiseschreibmaschine und Computer.</p><p>Durch ihre Leidenschaft für Pferde lernte sie auf einem Reitturnier ihren Mann kennen, mit dem sie heute in Kelkheim/Taunus lebt.</p></BiographicalNote>
</Contributor>
using Short tags
<contributor>
    <b034>1</b034>First contributor
    <b035>A01</b035>Written by
    <nameidentifier>
        <x415>16</x415>ISNI
        <b244>0000000020691583</b244>
    </nameidentifier>
    <nameidentifier>
        <x415>01</x415>Proprietary ID
        <b233>Ullstein Buchverlage Autor</b233>
        <b244>01381</b244>
    </nameidentifier>
    <b036>Nele Neuhaus</b036>
    <b037>Neuhaus, Nele</b037>
    <b039>Nele</b039>
    <b040>Neuhaus</b040>
    <x524>f</x524>Female
    <b044 textformat="05"><p><strong>Nele Neuhaus</strong> wurde 1967 als zweites von vier Kindern der Familie Löwenberg in Münster/Westfalen geboren. Sie wuchs in Paderborn auf, bevor sie im Alter von 11 Jahren mit ihrer Familie in den Taunus zog, als ihr Vater Landrat wurde. Schon seit frühester Kindheit schrieb Nele Neuhaus, zuerst handschriftlich in Schulhefte, später mit Reiseschreibmaschine und Computer.</p><p>Durch ihre Leidenschaft für Pferde lernte sie auf einem Reitturnier ihren Mann kennen, mit dem sie heute in Kelkheim/Taunus lebt.</p></b044>Text uses XHTML markup, and message uses UTF‑8 encoding so non-ASCII characters such as ‘ü’ need not be expressed as numerical character references (and must not be carried as HTML entities such as ‘&uuml;’)
</contributor>
single corporate contributor, name provided in both normal and inverted form
using Reference names
<Contributor>
    <SequenceNumber>1</SequenceNumber>
    <ContributorRole>A09</ContributorRole>
    <CorporateName>CLAMP</CorporateName>
    <CorporateNameInverted>CLAMP</CorporateNameInverted>
    <BiographicalNote textformat="05"><p><strong>CLAMP</strong> is a renowned all-female mangaka collective. Over more than 20 years, it has created many internationally successful series, including <em>xxxHolic</em>, <em>Tsubasa Reservoir Chronicles</em>, <em>Card Captor Sakura</em>, <em>Magic Knight Rayearth</em>, <em>Chobits</em> and <em>Tokyo Babylon</em>.</p></BiographicalNote>
</Contributor>
using Short tags
<contributor>
    <b034>1</b034>
    <b035>A09</b035>Created by
    <b047>CLAMP</b047>
    <x443>CLAMP</x443>
    <b044 textformat="05"><p><strong>CLAMP</strong> is a renowned all-female mangaka collective. Over more than 20 years, it has created many internationally successful series, including <em>xxxHolic</em>, <em>Tsubasa Reservoir Chronicles</em>, <em>Card Captor Sakura</em>, <em>Magic Knight Rayearth</em>, <em>Chobits</em> and <em>Tokyo Babylon</em>.</p></b044>
</contributor>
single contributor with alternative name (and alternative name identifier)
using Reference names
<Contributor>
    <SequenceNumber>1</SequenceNumber>
    <ContributorRole>A01</ContributorRole>
    <NameIdentifier>
        <NameIDType>01</NameIDType>
        <IDTypeName>HCP Author ID</IDTypeName>
        <IDValue>6108</IDValue>
    </NameIdentifier>
    <PersonNameInverted>Westmacott, Mary</PersonNameInverted>
    <NamesBeforeKey>Mary</NamesBeforeKey>
    <KeyNames>Westmacott</KeyNames>
    <AlternativeName>
        <NameType>04</NameType>
        <NameIdentifier>
            <NameIDType>01</NameIDType>
            <IDTypeName>HCP Author ID</IDTypeName>
            <IDValue>1067</IDValue>
        </NameIdentifier>
        <PersonNameInverted>Christie, Agatha</PersonNameInverted>
        <NamesBeforeKey>Agatha</NamesBeforeKey>
        <KeyNames>Christie</KeyNames>
    </AlternativeName>
    <BiographicalNote textformat="05"><p><strong>Mary Westmacott</strong> was a pseudonym used on six novels by the ‘Queen of Crime’ Agatha Christie.</p><p>Agatha Christie was born in Torquay in 1890 and became, quite simply, the best-selling novelist in history, outsold only by The Bible and Shakespeare.</p><BiographicalNote>
</Contributor>
<ContributorStatement>Agatha Christie, writing as Mary Westmacott</ContributorStatement>
using Short tags
<contributor>
    <b034>1</b034>First contributor
    <b035>A01</b035>Written by
    <nameidentifier>
        <x415>01</x415>Proprietary
        <b233>HCP Author ID</b233>
        <b244>6108</b244>
    </nameidentifier>
    <b037>Westmacott, Mary</b037>
    <b039>Mary</b039>Name as on product
    <b040>Westmacott</b040>(a pseudonym)
    <alternativename>
        <x414>04</x414>Real name
        <nameidentifier>
            <x415>01</x415>Proprietary
            <b233>HCP Author ID</b233>
            <b244>1067</b244>
        </nameidentifier>
        <b037>Christie, Agatha</b037>
        <b039>Agatha</b039>Real name
        <b040>Christie</b040>of author
    </alternativename>
    <b044 textformat="05"><p><strong>Mary Westmacott</strong> was a pseudonym used on six novels by the ‘Queen of Crime’ Agatha Christie.</p><p>Agatha Christie was born in Torquay in 1890 and became, quite simply, the best-selling novelist in history, outsold only by The Bible and Shakespeare.</p><b044>
</contributor>
<b049>Agatha Christie, writing as Mary Westmacott</b049>Text to be used for display purposes
In this case, the proprietary <NameIdentifier> is different for the two names, even though they refer to the same person, and (arguably) to the same public identity.
multiple contributors
using Reference names
<Contributor>
    <SequenceNumber>1</SequenceNumber>
    <ContributorRole>B01</ContributorRole>
    <NameIdentifier>
        <NameIDType>16</NameIDType>
        <IDValue>0000000109680282<IDValue>
    </NameIdentifier>
    <PersonNameInverted>Jones, Steve</PersonNameInverted>
    <ProfessionalAffiliation>
        <ProfessionalPosition>Emeritus Professor, Dept. of Genetics, Evolution and Environment</ProfessionalPosition>
        <Affiliation>University College London</Affiliation>
    </ProfessionalAffiliation>
</Contributor>
<Contributor>
    <SequenceNumber>2</SequenceNumber>
    <ContributorRole>B01</ContributorRole>
    <!-- <NameIdentifier> omitted for brevity -->
    <PersonNameInverted>Martin, Robert</PersonNameInverted>
    <!-- <ProfessionalAffiliation> omitted -->
</Contributor>
<Contributor>
    <SequenceNumber>3</SequenceNumber>
    <ContributorRole>B01</ContributorRole>
    <PersonNameInverted>Pilbeam, David</PersonNameInverted>
</Contributor>
<Contributor>
    <SequenceNumber>4</SequenceNumber>
    <ContributorRole>B15</ContributorRole>
    <PersonNameInverted>Bunney, Sarah</PersonNameInverted>
</Contributor>
<Contributor>
    <SequenceNumber>5</SequenceNumber>
    <ContributorRole>A24</ContributorRole>
    <PersonNameInverted>Dawkins, Richard</PersonNameInverted>
</Contributor>
using Short tags
<contributor>
    <b034>1</b034>Contributor 1
    <b035>B01</b035>Edited by
    <nameidentifier>
        <x415>16</x415>ISNI
        <b244>0000000109680282<b244>
    </nameidentifier>
    <b037>Jones, Steve</b037>
    <professionalaffiliation>
        <b045>Emeritus Professor, Department of Genetics, Evolution and Environment</b045>
        <b046>University College London</b045>
    </professionalaffiliation>
</contributor>
<contributor>
    <b034>2</b034>Contributor 2
    <b035>B01</b035>Edited by
    <!-- <nameidentifier> omitted for brevity -->
    <b037>Martin, Robert</b037>
    <!-- <professionalaffiliation> omitted -->
</contributor>
<contributor>
    <b034>3</b034>Contributor 3
    <b035>B01</b035>Edited by
    <b037>Pilbeam, David</b037>
</contributor>
<contributor>
    <b034>4</b034>Contributor 4
    <b035>B15</b035>Editorial coordination by
    <b037>Bunney, Sarah</b037>
</contributor>
<contributor>
    <b034>5</b034>Contributor 5
    <b035>A24</b035>Introduction by
    <b037>Dawkins, Richard</b037>
</contributor>
It is normal to provide a combined biographical note for multiple contributors in Group P.14 (<TextType> code 12 from List 153).
an unnamed (anonymous) contributor
using Reference names
<Contributor>
    <SequenceNumber>1</SequenceNumber>
    <ContributorRole>A01</ContributorRole>
    <UnnamedPersons>02</UnnamedPersons>
</Contributor>
using Short tags, with additional alternative name
<contributor>
    <b034>1</b034>First contributor
    <b035>A01</b035>Written by
    <b249>02</b249>Anonymous
    <alternativename>But known to be…
        <nameidentifier>
            <x415>16</x415>ISNI
            <b244>0000000109838844</b244>
        </nameidentifier>
        <x414>04</x414>‘real’ name
        <b037>Klein, Joe</b037>
    </alternativename>
</contributor>
no contributors
using Reference names
<NoContributor/>
using Short tags
<n339/>
P.7.1 Contributor sequence number

<SequenceNumber> contains a simple sequential integer: the first contributor listed on the product’s title page (or its equivalent on a non-book product) should be number 1, and subsequent contributors numbered 2, 3 and so on. The sequence number should always reflect the order used on the product, and not, for example, alphabetical order or an order based on their roles.

This sequence number should always be used by ONIX recipients to collate and display contributors. Do not rely on the order that contributors are listed within the ONIX file, although where possible ONIX senders should arrange files so that the sequence numbers do occur in order in the Product record.

If there are also contributors listed in P.5, their sequence numbers should form part of the same sequence – sequence numbers should be unique within the whole Product record – and this may mean the order contributors occur within the file is not their correct collation order.

P.7.2 Contributor role

The contributor role specifies the function of a contributor in the creation of the product. Note that the <ContributorRole> element is repeatable, and it should be repeated where a single contributor has multiple roles in relation to the product – do not list the same contributor twice.

using Reference names
<ContributorRole>A24</ContributorRole>Introduced and
<ContributorRole>B06</ContributorRole>translated by…
using Short tags
<b035>A01</b035>Written and
<b035>A12</b035>illustrated by…
Repetition of roles can conflict with the arrangement of contributors in their correct sequence – for example, ‘Written by Charles Smith and Jonathan Green, read by Charles Smith’. In this case, Charles Smith is Contributor 1 (with two roles), and Jonathan Green is Contributor 2. There should be no Contributor 3: Charles Smith should not be repeated. This is a case where the <ContributorStatement> data element is valuable.
Name identifier composite

There are a number of possible standards for the unambiguous identification of contributors. In particular, there is ongoing development of the relatively new ISNI (International Standard Name Identifier), and support for it is growing rapidly – over 10 million ISNIs have been assigned. You can check whether a contributor already has an ISNI at http://isni.org/search. For academic works, the ORCID – to which ISNI is closely linked – may be appropriate. There are also many well-developed library name identifiers such as the LCCN or VIAF (to which ISNI is also closely linked), but none is widely used within the book trade.

NameIdentifier NameIDType IDTypeName IDValue must include if ID is proprietary, otherwise omit

The ISNI (like some other ‘name identifiers) is in fact an identifier for a ‘public identity’ or a ‘persona’, rather than for a single name or a single person, and that persona may be known by a ‘real name’ or a pseudonym. One ISNI can be associated with many slightly different forms of a name or name variations that are used by a single persona, and a single public identity may in fact be shared by more than one real person (eg a writing team may use a single pseudonym). A named ONIX contributor is a single persona, and an ISNI identifies that persona, rather than a particular name or name variation used by that contributor – so it is best practice to associate an ISNI with the primary name of a contributor. Note that an ISNI does not directly identify the ‘person’ or ‘party’ that uses the name in the way that an ID like a Social Security or passport number does.

ISNIs and some other name identifiers can also be used with corporate contributors, as well as for corporate identities in other contexts (eg ISNIs can be used for publishers and imprints).

Over ten million contributor names have been assigned an ISNI, and this is the preferred name identifier within ONIX.

So far, relatively few publishers have adopted the ISNI in a comprehensive way. However, many have internal identifiers for contributors. Even internal identifiers used by publishers can be helpful to ONIX data recipients who wish to collocate products by a contributor, or distinguish products by two contributors with similar or identical names. The form of a name may change on successive products by a single contributor (Steve Jones, Dr. Steve Jones, Prof. Steve Jones etc). A name may be very similar or identical to that used by a quite different contributor (one UK publisher publishes two separate authors called Professor Richard Holmes), or a contributor may use one or more pseudonyms without any particular wish for anonymity (eg Ruth Rendell and Barbara Vine). Names change over time (eg through marriage, legal changes, or through the addition of titles, qualifications and honors), and the exact form of a name used on a product may also be influenced by marketing requirements – a popular dieting book and an academic treatment of nutrition may use subtly different forms of name for the same contributor. In all of these cases, collocation is aided even by proprietary identifiers. When providing a proprietary identifier, always include a consistent name for the identifier in the <IDTypeName> element, so it can be distinguished from proprietary identifiers controlled by other organizations. Of course, a public identifier such as an ISNI is of greater utility for cases where multiple publishers are involved, or when a contributor is active in other creative fields too (a specific feature of ISNI is that it bridges between books, music and other creative fields).

P.7.9, P.7.10 Personal names

It is strongly preferred to supply personal contributor names in a fully-structured manner, using the elements P.7.11 to P.7.18, ideally with both <PersonName> and <PersonNameInverted> as well. However, publisher’s systems may not support such granularity. If structured names are not available, then there is great value in providing both <PersonName> and <PersonNameInverted>. Recipients may then use the former for display and the latter for collation (and possibly both for search). And if only one type of unstructured name can be included, the ‘inverted’ form of the name with family name before given name in <PersonNameInverted> is preferred to the use of <PersonName> alone.

The ‘inverted’ order is the normal order for Chinese, Japanese and many other Eastern naming systems, and for Hungarian names – and for these names, <PersonName> and <PersonNameInverted> would be identical.

<PersonName> alone is the ‘worst case’ option, used only when contributor names cannot be supplied in any other form. Note that names provided in this form cannot reliably be collated (ie sorted into alphabetical order).

The primary name supplied should be the name as it is used on the product, and should be the name used by recipients for display purposes. If the publisher wishes, alternative forms of the same name – or alternative names for the same contributor – can be provided in the <AlternativeName> composite. Providing alternative names and name identifiers can help collocation, where different forms of the same name are used on different products. In the rare case where two names for the same contributor are used on the same product, then the primary name should be the name used most prominently, with the less prominent name supplied as an <AlternativeName>.

<PersonName><PersonNameInverted>(key names in bold)
Dame Ngaio MarshMarsh, Dame Ngaio
Henry of HuntingdonHuntingdon, Henry of
Henriette d’AngevilleAngeville, Henriette d’
Mary O’ConnorO’Connor, Mary
Máire ó ConchobhairConchobhair, Máire ó
Gabriel Garcia MárquezGarcia Márquez, Gabriel
Megan Lloyd GeorgeLloyd George, Megan
His Holiness the Dalai LamaDalai Lama, His Holiness the
Luo GuanzhongLuo Guanzhong(family name first)
村上 春樹村上 春樹(Haruki Murakami, family name first)
Björk GuðmundsdóttirBjörk Guðmundsdóttir(patronymic is not key name)
प्रेमचंदप्रेमचंद(Premchand, only a single name)
שפרה הורןהורן, שפרה(Shifra Horn, text runs right to left)
Abu al-Hasan Ali
ibn al-Husayn ibn Ali
al-Mas'udi
Mas'udi, Abu al-Hasan
Ali ibn al-Husayn
ibn Ali al-
(أبو الحسن علي بن الحسين بن علي المسعودي)
For names and any other text in a script written right to left (Arabic, Hebrew etc), no special care need be taken over the character ordering in the data file: the first character of an RTL name occurs immediately following the > of <PersonName> in the file, even though when the ONIX data is printed or viewed on screen, the first character of the name appears immediately before the < of </PersonName>. So for שפרה הורן (Shifra Horn), the order of characters in the ONIX message is <PersonName>שפרה הורן</PersonName>. Those characters ש, פ, ר, ה etc are then displayed from right to left as שפרה הורן

Author names (and product titles) often have to be presented in alphabetical order, and <PersonNameInverted> or the various parts of a structured name usually facilitate this. But sorting text in a variety of scripts and – for text other than names – languages, and determining the correct ‘alphabetical’ order is dependent on the locale and expected user experience when the text is displayed. There is no single, canonical order: Ö sorts after Z in a Swedish context, but immediately follows O in a German context, and in a English language context, O and Ö are likely to be intermixed. A Swedish reader will expect a name beginning with Ö to appear after Z in a list even if the name is that of a German author. The sort order is not entirely intrinsic to the data itself, is not purely a feature of language or script, and in particular it’s almost never exactly the same as the numerical order of Unicode characters. Sort order is a feature of the user interface. Even converting between lower and upper case prior to sorting can be problematic – in Turkish, the upper case version of i is İ (with a dot above), and the lower case version of I is ı (a dotless i). For more on sorting, see the Unicode Collation Algorithm specification and the Common Locale Data Repository.

For non-alphabetic writing systems such as Chinese or Japanese, the collationkey attribute is important, and it should be used to provide phonetic or other sort order information for machine processing.

providing a sort order in Japanese
using Reference names
<PersonNameInverted collationkey="むらかみ はるき">村上春樹</PersonNameInverted>
using Short tags
<b037 collationkey="むらかみ はるき">村上春樹</b037>
Japanese personal names are written in Kanji and are conventionally sorted according to their phonetic reading. The name may be spelled out phonetically using Hiragana or Katakana characters. But many Kanji characters have multiple readings, so 彰 can be read as しよう (‘Shō’) or あきら (‘Akira’), and the chosen reading affects the sort order. The collationkey attribute provides the correct phonetic rendering. (It is also the case that one phonetic reading such as あきら (‘Akira’) may have many Kanji renderings including 明 or 晃). For Chinese names, Pinyin or Zhuyin phonetics would be used.

In cases where the reading of the name needs to be clarified for human readers, rather than for automated sorting, the phonetic information is provided in a ruby gloss. A gloss can be incorporated using either the XHTML <ruby> markup element – in ONIX data elements that allow XHTML – or using Unicode interlinear annotation delimiters in data elements that do not. Where phonetics are needed for both human reading and for sorting purposes, both a collationkey and a ruby text should be included.

<b037 collationkey="むらかみ はるき">&#xfff9;村上春樹&#xfffa;むらかみ はるき&#xfffb;</b037>
This uses Unicode interlinear annotation delimiters (&#xfff9;, &#xfffa; and &#xfffb;) to separate the Kanji from the ruby text Hiragana, as the <PersonNameInverted> element cannot use XHTML <ruby> markup. In other data elements where it is allowed, the equivalent XHTML markup must be used. The name above should be displayed as 村上春樹むらかみ はるき.

Unicode interlinear annotation delimiters cannot be rendered on-screen unless an application provides specific support for them. Few (if any) common software applications correctly render interlinear annotation delimiters. In order to display the name with its interlinear annotation (gloss) in a web browser using XHTML 1.1 (or non-standard HTML4), an application might:

  1. replace &#xfff9; with ‘<ruby><rb>’;
  2. change &#xfffa; to ‘</rb><rp> (</rp><rt>’;
  3. and substitute ‘</rt><rp>)</rp>’ for ‘&#xfffb;’.

For HTML5, correct practice would be to omit the <rb> and </rb> tags. However, this will prevent validation of the ONIX XML – implementation of <ruby> in ONIX is based on XHTML 1.1, and the <rb> tag is required.

In summary, there are three ways of incorporating phonetic glosses into ONIX data:

  • if the gloss is intended to be used for automated sorting purposes;
    • method 1 – use the collationkey attribute;
    • the attribute can only be included on elements that are likely to be used for sorting;
  • if the gloss is intended to be used for display purposes, either:
    • method 2 – use <ruby> where XHTML markup is allowed within the ONIX data element; or
    • method 3 – use Unicode interlinear annotation delimiters where XHTML is not allowed;
    • glosses for display can be incorporated into any textual data element.

Occasionally, as in the example above, a single data element may need a gloss provided as an attribute for sorting, and as a display gloss.

P.7.11 Titles before names

Parts of names in bold would be carried in this element.

Pope Benedict XVI
His Holiness the Dalai Lama
HRH Prince Charles
Dame Ngaio Marsh
General Sir Peter de la Billière
P.7.12 Names before key names
Dame Ngaio Marsh
General Sir Peter de la Billière
Henriette d’Angeville
Gabriel Garcia Márquez
Robert Louis Stephenson
Megan Lloyd George
Фёдор Достоевский(Fyodor Dostoyevsky)
Haruki Murakami(when name is Westernized)
علاء الأسواني(Alaa al-Aswany)
שפרה הורן(Shifra Horn)
P.7.13 Prefix to key names
His Holiness the Dalai Lama
General Sir Peter de la Billière
Henriette d’Angeville
Máire ó Conchobhair
علاء ال أسواني(Alaa Al Aswany)
Eric van Lustbader
Melissa de la Cruz
P.7.14 Key names

All names presented in fully-structured style must have a Key name – this is the part of the name that is used first for collation purposes. Note that although names are conventionally sorted using the family or inherited name, there are exceptions for names that include titles, where for example a given name (Charles), a taken name (Benedict) or a title (Dalai Lama) may be used as the key, and for other names that do not have a family component (such as Icelandic names, which consist of given name and patronymic). When constructing a structured name, always start with the key name element and arrange other parts of the name around it.

Pope Benedict XVI
His Holiness the Dalai Lama
HRH Prince Charles
Dame Ngaio Marsh
General Sir Peter de la Billière
Henriette d’Angeville
Mary O’Connor
Máire ó Conchobhair
Gabriel Garcia Márquez
Robert Louis Stephenson
Megan Lloyd George
Фёдор Достоевский(Fyodor Dostoyevsky)
Haruki Murakami(Westernized name order)
村上 春樹(Haruki Murakami, name order not Westernized)
علاء ال أسواني(Alaa Al Aswany)
שפרה הורן(Shifra Horn)
Eric van Lustbader
Melissa de la Cruz
Madonna
Björk Guðmundsdóttir(given name is key name)
प्रेमचंद(Premchand)
Luo Guanzhong(贯中, name order not Westernized)
Petőfi Sándor(Hungarian, name order not Westernized)

Exactly what constitutes the key name varies according to the culture from which the name arises. Prefixes like de, ó or van often get incorporated into the key name as the name passes from its original culture into another, so for example Máire ó Conchobhair becomes Mary O’Connor, the Dutch name ‘de Groot’ becomes ‘De Groot’ or the French name ‘de la Mare’ becomes the English ‘Delamere’. But this is a cultural shift, not a matter of language, and many also choose to retain their name structure (for example, English poet Walter de la Mare).

Except with names such as Madonna or Premchand which have no other parts, if <KeyNames> is used, all other parts of the name should be included in the relevant elements – <NamesBeforeKey>, <PrefixToKey> and so on. <KeyNames> is not intended merely to indicate which part of the name in <PersonName> is to be used for sorting.
P.7.15 Names after key names

While at first sight, this element would be used for Chinese and Japanese names, where the family name traditionally precedes the given name, it is also used for some European-style names. Hungarians traditionally put the family name first, for example.

村上 春樹(Haruki Murakami, name order not Westernized)
Björk Guðmundsdóttir(patronymic follows key name)
Luo Guanzhong(罗贯中, name order not Westernized)
Petőfi Sándor(name order not Westernized)
P.7.16 Suffix after key names

This element is only used for simple suffixes such as ‘Jr.’, ‘fils’ or ‘XVI’.

P.7.17 Qualifications and honors after names

This element is used to list qualifications (‘PhD’, ‘MD’ etc), and for honors and memberships (‘OBE’, ‘TD’, ‘FRCS’ etc).

P.7.18 Titles after names

This element is used to list titles and honorifics that follow a person’s names. Note that often, there is some choice about how names that include titles may be presented:

King Philip II of Spain
Philip II, King of Spain

Presentation of primary names should follow the form used on the product. A publisher may provide an alternative name when another form is more familiar.

P.18a Contributor gender

Within the ONIX framework, the gender of a personal contributor is the gender of the persona, not of the natural person ‘behind’ the persona. The persona is the public-facing identity the person chooses to present to the world, and its gender therefore not particularly private in nature. It is well-known for female novelists to take male pseudonyms – George Eliot, Robert Galbraith for example – and there are examples of male writers using female pseudonyms. If the contributor is ‘George Eliot’, the gender is male, even though the real-world Mary Evans was female. However, the element may be omitted, or a positive statement made that the gender is unknown or deliberately unstated for any reason.

There is no particular reason to include gender information for discoverability purposes. However, it can be used in cases where the recipient of the ONIX message uses the contributor data for other purposes – for example, for statistical market analysis, or for ISNI registration, where gender is an optional part of the registration metadata.

P.7.19, P.7.20 Corporate contributor names

Corporate names should be carried in <CorporateName>, unless they begin with a prefix that should be ignored for collation purposes – in which case it is best practice to (also) include <CorporateNameInverted>. If there is a prefix, there is some value in providing both forms (as with personal names). Corporate names should not include suffixes such as ‘Inc’, ‘SA’ or ‘Ltd’, unless they are used on the product itself.

no prefix (on the product)
<CorporateName>World Health Organization</CorporateName>
name with a prefix
<CorporateName>The editors of Rolling Stone Magazine</CorporateName>
<CorporateNameInverted>Rolling Stone Magazine, The editors of</CorporateNameInverted>
P.7.20a Unnamed person(s)

A product that has no specific named contributors may still have unnamed contributors – they may be unknown, anonymous, or indeed artificial – for example, a book may be written by ‘Anonymous’, and an audiobook or DAISY title using synthesized but prerecorded speech should carry an <UnnamedPersons> element with a contributor role code indicating ‘read by’.

Unnamed contributors can be combined with named contributors, and this is relatively common when the number of named contributors is limited by editorial policy – for example, if only three names are allowed, the fourth and fifth may be unnamed, and <UnnamedPersons> would carry the code value 03 (‘et al’). Note that in this case, a single <UnnamedPersons> composite stands for multiple contributors. In general, an unnamed et al contributor should be the last contributor as defined by the <SequenceNumber>, or at least the last contributor with a particular role (where other, named contributors with different roles follow). In very rare cases, a product might have more than one <UnnamedPersons> element, in different repeats of <Contributor> with different contributor roles.

Anonymous contributors are not necessarily completely unknown, nor are two books by ‘Anonymous’ necessarily written by the same ‘Anonymous’. Thus where it represents a single unnamed contributor (ie not where it represents et al or Various), <UnnamedPersons> can be combined with <NameIdentifier>, with <AlternativeName> (to give the real name where it has subsequently become known), and with any of the associated attributes such as <BiographicalNote>.

audiobook read by a synthesized voice
using Reference names
<Contributor>
    <SequenceNumber>1</SequenceNumber>
    <ContributorRole>A01</ContributorRole>
    <PersonNameInverted>Angeville, Henriette d’</PersonNameInverted>
</Contributor>
<Contributor>
    <SequenceNumber>2</SequenceNumber>
    <ContributorRole>E07</ContributorRole>
    <UnnamedPersons>06</UnnamedPersons>
</Contributor>
using Short tags
<contributor>
    <b034>1</b034>First contributor
    <b035>A01</b035>Written by
    <b037>Angeville, Henriette d’</b037>
</contributor>
<contributor>
    <b034>2</b034>Second contributor
    <b035>E07</b035>Read by
    <b249>06</b249>Female synthesized voice
</contributor>
multiple contributors, with et al
using Reference names
<Contributor>
    <SequenceNumber>1</SequenceNumber>
    <ContributorRole>B01</ContributorRole>
    <PersonNameInverted>Jones, Steve</PersonNameInverted>
</Contributor>
<Contributor>
    <SequenceNumber>2</SequenceNumber>
    <ContributorRole>B01</ContributorRole>
    <PersonNameInverted>Martin, Robert</PersonNameInverted>
</Contributor>
<Contributor>
    <SequenceNumber>3</SequenceNumber>
    <ContributorRole>Z98</ContributorRole>
    <UnnamedPersons>03</UnnamedPersons>
</Contributor>
<ContributorStatement textformat="05"><p>Edited by Steve Jones, Robert Martin <em>et al</em></p></ContributorStatement>
using Short tags
<contributor>
    <b034>1</b034>First contributor
    <b035>B01</b035>Edited by
    <b037>Jones, Steve</b037>
</contributor>
<contributor>
    <b034>2</b034>Second contributor
    <b035>B01</b035>Edited by
    <b037>Martin, Robert</b037>
</contributor>
<contributor>
    <b034>3</b034>Remaining contributors
    <b035>Z98</b035>(Various roles)
    <b249>03</b249>et al
</contributor>
<b049 textformat="05"><p>Edited by Steve Jones, Robert Martin <em>et al</em></p></b049>
Compare this example with the previous multiple contributor example.

This data element may also be used with products that are compilations or anthologies, where the contributors may be described as ‘Various’ – and in this case, repeats of the <ContentItem> composite in Group P.18 may be used to provide more information on the authorship of each section.

Alternative name composite

The <AlternativeName> composite provides a way of delivering another name (or an alternative form of the same name) for a contributor. Potential uses might include providing a previous name (where the contributor’s name has changed by marriage, for example, or the corporation has undergone a rebranding), an authority-controlled or otherwise standardized form of a name where the name on the actual product is presented in an unusual form, or where both a real name and a pseudonym are involved. Such alternative names can provide important search term matches, aiding discovery of the product online or within retailer systems.

Alternative name NameType Personal or Corporate name

While the primary contributor name (in P.7.9 to P.7.20) should always be the name as it appears on the product, the alternative name may be one of several types. It is mandatory to specify a <NameType> within <AlternativeName>. In contrast, the P.7.5 <NameType> element is not required (and is usually omitted) for the primary name.

The remainder of <AlternativeName> is identical to the data elements that carry the primary name, and similar best practice applies. Note that <AlternativeName> can include an alternative <NameIdentifier> composite, as well as any of the data elements holding the fully-structured, inverted or normal contributor name.

In general, each <AlternativeName> composite should contain a name with a different name type. However, it is also possible to provide transliterations of a name in two repeats with the same name type, or a single <AlternativeName> may contain a transliteration of the primary name. Transliterations are often useful where the recipient of the data may not be able to cope with the characters in the native script – for example selling a book in Russian, with a Cyrillic author name, in a country where many data recipients might only be able to deal with Latin characters. It is obviously preferable to supply the primary name in Cyrillic, for those recipients that can make use of it, and a Latin transliteration for those that cannot.

transliterated version of the primary name
using Reference names
<Contributor>
    <ContributorRole>A01</ContributorRole>
    <PersonName>다니엘 돔샤이트-베르크</PersonName>
    <PersonNameInverted>돔샤이트-베르크, 다니엘</PersonNameInverted>
    <AlternativeName>
        <NameType>05</NameType>
        <PersonName textscript="Latn">Daniel Domscheit-Berg</PersonName>
        <PersonNameInverted textscript="Latn">Domscheit-Berg, Daniel​</PersonNameInverted>
    </AlternativeName>
</Contributor>
using Short tags
<contributor>
    <b035>A01</b035>Written by
    <b036>다니엘 돔샤이트-베르크</b036>Hangul script used on the book
    <b037>돔샤이트-베르크, 다니엘</b037>
    <alternativename>
        <x414>05</x414>Transliteration of primary name
        <b036 textscript="Latn">Daniel Domscheit-Berg</b036>Latin script
        <b037 textscript="Latn">Domscheit-Berg, Daniel</b037>
    </alternativename>
</contributor>

ONIX takes the pragmatic view that while most textual metadata can be expressed in different languages, organizational or contributor names are not ‘in’ a particular language. However, names can be expressed in different scripts – فيودور دوستويفسكي and Фёдор Достоевский and Fyodor Dostoyevsky. So while <BiographicalNote> may carry a language attribute (see below), <PersonName> carries a textscript attribute instead.

Although in this particular case the author (Daniel Domscheit-Berg) is German by nationality, the book is in the Korean language, the majority of the metadata is in Korean, and the author name is listed on the book in Hangul (Korean script). Thus the primary name is in Hangul, and the name is also provided transliterated into Latin script in the <AlternativeName> composite. By contrast, a German or English language copy of the book would list the primary author’s name in Latin script, and if that copy were for sale in Korea, the transliteration into Hangul might be given: for this book, the Hangul and Latin versions of the name would be switched around.

Provision of transliterated names is quite different from provision of phonetic information for sorting (which would use the collationkey attribute), or provision of ruby glosses to disambiguate the reading of a name (which would use Unicode interlinear annotation delimiters): see the notes on Personal names in Group P.7.

Contributor date composite

Birth and death dates are often use in libraries to distinguish between authors of the same name. They are not typically made explicit in book trade metadata, but equivalent information may be incorporated into any biographical notes. In general, providing a name identifier such as an ISNI is better for disambiguation purposes.

ContributorDate ContributorDateRole ContributorDateRole DateFormat Date use dateformat attribute on <Date> element instead
Jane Austen (1775–1817)
using Reference names
<ContributorDate>
    <ContributorDateRole>50</ContributorDateRole>
    <Date dateformat="05">1775</Date>
</ContributorDate>
<ContributorDate>
    <ContributorDateRole>51</ContributorDateRole>
    <Date>18170717</Date>
</ContributorDate>
using Short tags
<contributordate>
    <x417>50</x417>Born…
    <b306 dateformat="05">1775</b306>Format is YYYY
</contributordate>
<contributordate>
    <x417>51</x417>Died…
    <b306>18170717</b306>Default format is YYYYMMDD
</contributordate>
Date formats such as YYYYMMDD (the default) or YYYY are limited to dates in the Common Era. For BCE dates, use dateformat code 12.
Professional affiliation composite

Affiliations – effectively a job title and organization name – are used when the professional position of the author is important to the market positioning of the product – for example to emphasize the credentials of academic author, or the credibility of any other expert.

ProfessionalAffiliation ProfessionalPosition ProfessionalPosition Affiliation must include at least one
multiple affiliations for an academic author
using Reference names
<ProfessionalAffiliation>
    <ProfessionalPosition>Emeritus Professor of Social Geography</ProfessionalPosition>
    <Affiliation>School of Geography and the Environment, University of Oxford</Affiliation>
</ProfessionalAffiliation>
<ProfessionalAffiliation>
    <ProfessionalPosition>Professor of Social Geography</ProfessionalPosition>
    <Affiliation>Institute for Social Change, Manchester University</Affiliation>
</ProfessionalAffiliation>
using Short tags
<professionalaffiliation>
    <b045>Emeritus Professor of Social Geography</b045>
    <b046>School of Geography and the Environment, University of Oxford</b046>
</professionalaffiliation>
<professionalaffiliation>
    <b045>Professor of Social Geography</b045>
    <b046>Institute for Social Change, Manchester University</b046>
</professionalaffiliation>
P.7.42 Biographical note

Any named contributor – personal or corporate – may be associated with a short biography. Typically these are relatively short, perhaps no more than 200 to 400 words – around 1500–3000 characters. Although there is no specified maximum, a practical upper limit of perhaps 5000 characters is reasonable for senders. The <BiographicalNote> element is best used when there are a small number of contributors (say three or fewer). A single combined biography for multiple contributors is best provided in the <TextContent> composite in Group P.14.

Simple biographical notes can be provided as plain text. However, because of the differing XML treatment of white space characters (including tabs, line feeds and carriage returns) among different XML parsers and in different databases, multi-paragraph text cannot reliably be delivered into a recipient’s system this way. For this and other reasons, <BiographicalNote> and other ONIX data elements can accept not only plain text but also text with embedded XHTML markup. Embedded markup is the only reliable way to deliver multi-line or multi-paragraph text.

If you have only plain text, and want to include multi-paragraph biographies, then you must include some markup within the data element. The simplest process would be to:

  • prefix the text of the biographical note with ‘<p>’ and suffix it with ‘</p>’;
  • replace any paragraph breaks with ‘</p><p>’;
  • replace any line breaks that do not represent new paragraphs by ‘<br />’;
  • add the textformat attribute with value 05.

Why do you need to add markup? By default, XML data processing is supposed to preserve whitespace characters – spaces, tabs, line breaks and so on – within data elements. But in practice, single or multiple consecutive whitespace characters are often ‘normalized’ so they are all treated as single spaces, particularly when the data is displayed. Expecting end-to-end preservation of whitespace is not reliable. ONIX data should be processed by normalizing whitespace. These:

<BiographicalNote>    Umberto Eco↩
is a    novelist.</BiographicalNote>
<BiographicalNote>Umberto➝    Eco is a novelist.</BiographicalNote>
<BiographicalNote>Umberto Eco is a novelist.</BiographicalNote>

(where ↩ is an explicit new line in the data and ➝ is a tab character) are equivalent. Data senders should aim to send only the third option, and recipients should normalize whitespace characters they receive.

This behavior applies to all ONIX tags, not just to <BiographicalNote>. But where a tag is intended to allow multiple lines or paragraphs of text, embedded markup provides the solution.

But why does inserting return characters sometimes seem to work? Because not all data recipients use full XML processing, or they treat textual data elements as special cases. However, this will never be reliable. It is much better to insert simple XHTML markup.

adding minimal XHTML markup
using Reference names – original plain text
<BiographicalNote>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.
    As well as novels, he also writes children’s books and academic works.</BiographicalNote>
preferred alternative including XHTML markup
<BiographicalNote textformat="05"><p>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.</p><p>As well as novels, he also writes children’s books and academic works.</p></BiographicalNote>
improved, semantically richer XHTML markup
<BiographicalNote textformat="05"><p>Umberto Eco, professor of semiotics at the University of Bologna, and author of <cite>The Name Of The Rose</cite> and <cite>Foucault’s Pendulum</cite>, is one of the world’s bestselling novelists.</p><p>As well as novels, he also writes children’s books and academic works.</p></BiographicalNote>
using Short tags – original plain text
<b044>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.
    As well as novels, he also writes children’s books and academic works.</b044>
paragraph breaks are likely to be lost
preferred alternative using XHTML markup
<b044 textformat="05"><p>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.</p><p>As well as novels, he also writes children’s books and academic works.</p></b044>XHTML markup should ensure paragraphs remain separate as data is processed by the recipient
improved, semantically richer XHTML markup
<b044 textformat="05"><p>Umberto Eco, professor of semiotics at the University of Bologna, and author of <cite>The Name Of The Rose</cite> and <cite>Foucault’s Pendulum</cite>, is one of the world’s bestselling novelists.</p><p>As well as novels, he also writes children’s books and academic works.</p></b044>
Compare the ‘improved’ example with the previous examples, and note the use of <cite> instead of <i> or <em>. By default, the <cite> XHTML tag has the same typographic effect as <i> or <em> – it italicizes the titles of the two books – but the markup is semantically richer. Modern web practice stresses the value of such semantic markup.

XHTML markup is strongly preferred to HTML, as it can be properly validated using the ONIX for Books schemas.

But not all XHTML markup tags are usable. First, there are limitations on what XHTML tags can be used within ONIX. Second, recipients will often strip out some tags, or might even ignore the supplied text altogether because they are reluctant to include the supplied tags on their website (even though they might be technically valid). In practice, the following ‘minimal set’ should be usable without problems:

  • <p> and <br /> for paragraphs and new lines;
  • <em>, <strong>, <i>, <b> and <cite>;
  • <ul>, <ol> and <li> for unordered and ordered lists;
  • <sub> and <sup> for subscripts and superscripts;
  • <dl>, <dt> and <dd> for description lists;
  • with east-Asian languages, <ruby>, <rb>, <rt> and <rp> for glosses.

It is strongly recommended that HTML markup is also restricted to this minimal set.

In addition, the following XHTML tags can be used, but are not recommended:

  • <address>, <abbr>, <small>, <q>, <code>, <samp>, <var> and <dfn> for limited ‘semantic’ markup of text should be okay, but it is good practice to avoid them. Their exact typographic effect – when the text is displayed by the recipient – is somewhat unpredictable, and the simpler your markup, the greater the likelihood the recipient will make use of it;
    • this list of allowed tags is not exhaustive. A complete list is given in the Appendix.

Headings, tables, <div> and <span> containers, image tags, links and imagemaps using the <a> or <map> tags, and attributes like style are also technically valid within the ONIX schema, but will often cause problems with recipients. Avoid them.

Forms, embedded objects, scripts, any tags that can only exist in the <head> section (eg <title>), any tags with event attributes like onclick and – critically – named character entities like ‘&ouml;’ are valid in XHTML itself, but cannot be used in XHTML embedded within ONIX.

The ‘top level’ XHTML elements should be block-level elements:

not recommended – no outer block-level (X)HTML element
<BiographicalNote textformat="05">some text</BiographicalNote>
<BiographicalNote textformat="05"><strong>some text</strong></BiographicalNote>
 
recommended – <p> and <ul> are both block-level
<BiographicalNote textformat="05"><p>some text</p></BiographicalNote>
<BiographicalNote textformat="05"><p>some text</p><ul><li>a list</li></ul></BiographicalNote>

To be ultra-cautious, stick to the very simplest tags:

  • <p>, <br />
  • <b> and <i>, <strong> and <em>
  • <ul>, <ol> and <li>
  • plus possibly <ruby>, <rb>, <rp> and <rt> if required

…of which <p>, <ul> and <ol> are block-level.

Where markup is used in an element with a length limit, it is included in any character count.

While embedding XHTML is the preferred option, it is not the only method of embedding markup in ONIX data elements. If it is impossible to use XHTML for any reason, then ordinary HTML can be included in one of two ways:

embedding HTML markup
using Reference names – HTML in CDATA option
<BiographicalNote textformat="02"><![CDATA[<p>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.<p>As well as novels, he also writes children’s books and academic works.</p>]]></BiographicalNote>
escaped HTML option
<BiographicalNote textformat="02">&lt;p>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.&lt;p>As well as novels, he also writes children’s books and academic works.&lt;/p></BiographicalNote>
using Short tags – HTML in CDATA option
<b044 textformat="02"><![CDATA[<p>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.<p>As well as novels, he also writes children’s books and academic works.</p>]]></b044>Enclose HTML within CDATA
escaped HTML option
<b044 textformat="02">&lt;p>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.&lt;p>As well as novels, he also writes children’s books and academic works.&lt;/p></b044>Replace < character with &lt; (and avoid also replacing > with &gt; or ‘double-escaping’ other characters)
The CDATA method is strongly preferred over escaped HTML, though neither is a best practice and XHTML (without either CDATA or escaping of the markup) is preferred to both. HTML markup should be limited to a similar set of simple tags as XHTML – and also limited to those data elements where XHTML is an option. CDATA should never be used except to embed HTML markup.

Although they are not recommended, named character entities like &hellip; or &ouml; should work within HTML text inside CDATA. They are not valid within ‘ordinary’ ONIX 3.0 data, but may be used within HTML (and of course, numerical character references like &#x2026; or &#xf6; will also work).

For the CDATA method, use the named entity or numerical reference as normal.

For the escaped HTML option, named entities are not valid – use numerical references instead.

For the escaped HTML option, it might appear that a named entity such as &hellip; or numerical reference like &#x2026; might require the ampersand to be escaped – just as the < character in the HTML markup is escaped to &lt;, the ampersand character within a named character entity or numerical reference could also be escaped, so a single ellipsis becomes &amp;hellip; or &amp;#x2026;. This is sometimes termed ‘double-escaping’, and it is strongly discouraged. Only the < character in the HTML markup needs to be modified (and you might also replace any < that is not part of the HTML markup – that is, a normal ‘less than’ symbol – by &#60;). You should not escape any other character, not even the > character that marks the end of each HTML tag.

If using named character entities or numerical references within embedded HTML markup, ensure proper end-to-end testing with each ONIX recipient. The likelihood of confusion and error with escaped characters and potentially double-escaped named character entities and numerical references is one reason why the CDATA method is preferred in ONIX 3.0. (In earlier versions of ONIX, the CDATA and escaped HTML methods were equally acceptable.)

Within HTML (but not within XHTML), the unescaped & character is valid. However, it is strongly recommended that the named entity &amp; is used instead, for both the CDATA and escaped HTML options. Using an unescaped & character in escaped HTML (ie without CDATA) will prevent the ONIX message validating.

Like many textual data elements, the <BiographicalNote> element is repeatable in order that the same text can be carried in multiple languages. Of course, in most cases, textual metadata is provided in the same language used in the book. Parallel metadata in multiple languages might be required in territories where multiple languages are in everyday use (for example, Switzerland), in language learning and gift giving scenarios where a book might be purchased by someone who cannot read the language used in the book itself, and in cases where the product itself contains parallel text. If parallel textual metadata is provided, then each repeat of <BiographicalNote> must carry a language attribute. This allows a recipient to either accept and process the multiple languages, or to select the single language that is most appropriate for their needs.

providing text in parallel languages
using Reference names
<BiographicalNote language="eng" textformat="05"><p><strong>Umberto Eco</strong>, professor of semiotics at the University of Bologna, and author of <cite>The Name Of The Rose</cite> and <cite>Foucault’s Pendulum</cite>, is one of the world’s bestselling novelists.</p><p>As well as novels, he also writes children’s books and academic works.</p></BiographicalNote>
<BiographicalNote language="ita" textformat="05"><p><strong>Umberto Eco</strong>, professore di semiotica all’Università di Bologna e autore di <cite>Il nome della rosa</cite> e <cite>Il pendolo di Foucault</cite>, è uno dei romanzieri più venduto al mondo.</p><p>Così come romanzi, lui scrive anche libri per bambini e opere accademici.</p></BiographicalNote>
using Short tags
<b044 language="eng" textformat="05"><p><strong>Umberto Eco</strong>, professor of semiotics at the University of Bologna, and author of <cite>The Name Of The Rose</cite> and <cite>Foucault’s Pendulum</cite>, is one of the world’s bestselling novelists.</p><p>As well as novels, he also writes children’s books and academic works.</p></b044>
<b044 language="ita" textformat="05"><p><strong>Umberto Eco</strong>, professore di semiotica all’Università di Bologna e autore di <cite>Il nome della rosa</cite> e <cite>Il pendolo di Foucault</cite>, è uno dei romanzieri più venduto al mondo.</p><p>Così come romanzi, lui scrive anche libri per bambini e opere accademici.</p></b044>
Contributor description

Contributors and publishers often want a succinct ‘catchline’ or headline – no more than a few words – to highlight or promote a particular aspect of the contributor’s identity, to differentiate them from other contributors with a similar name, or to highlight some achievement. This might be expanded upon in the contributor’s biography (ie in <BiographicalNote>). The <ContributorDescription> might be used alone, or used as a headline to introduce the fuller biography. (The relationship between <ContributorDescription> and <BiographicalNote> mirrors that between the Promotional headline and the Short or Long descriptions – <TextType> codes 10 and 02 or 03 – used within <TextContent>.)

Contributor place composite

Although not a core part of global best practice, the <ContributorPlace> composite is a key part of some national schemes to promote local authors. It should be included, for example, on products sold in Canada where a contributor is a Canadian citizen. Retailers value it – and particularly <LocationName> – as a way of supporting ‘local author’ promotions.

ContributorPlace ContributorPlaceRelator ContributorPlaceRelator CountryCode RegionCode LocationName must include one or the other (and ideally not both)
Although the ONIX schema allows use of both Country and Region codes together, it is strongly recommended that only one or the other is used in a particular <ContributorPlace> composite. Region codes already include the relevant country designation. A location name cannot be used without also including either a country or region code.
designating a contributor as Canadian
using Reference names
<ContributorPlace>
    <ContributorPlaceRelator>08</ContributorPlaceRelator>
    <CountryCode>CA</CountryCode>
</ContributorPlace>
using Short tags, also indicating residency
<contributorplace>
    <x418>08</x418>Citizen of
    <b251>CA</b251>Canada
</contributorplace>
<contributorplace>
    <x418>04</x418>Currently lives in
    <b398>CA-NL</b398>Newfoundland and Labrador
    <j349>Stephenville</j349>and specifically, in Stephenville
</contributorplace>

More detailed information about where a contributor lives may also be incorporated into <BiographicalNote>, but the structured information in <ContributorPlace> can be particularly useful.

P.7.51 Contributor statement

This data element should be used to carry readable text showing how the contributor’s names and roles should be displayed. This is particularly critical when a simple concatenation of the contributor’s roles and names would not give satisfactory results – for example when one contributor has multiple roles, or when for example a familial relationship between two contributors may alter how their names are presented.

The contributor statement should not include any collection-level contributors listed separately in Group P.5 (although best practice is to avoid collection-level contributors altogether, and to include all contributors in Group P.7).

<ContributorStatement>Written and illustrated by Colin and Jacqui Hawkins. Series edited by Cliff Moon</ContributorStatement>
<ContributorStatement>By Richard and Alastair Fitter, illustrated by Marjorie Blamey</ContributorStatement>

Recipients of ONIX records that contain this element should use the supplied contributor statement for display, while using the names supplied in the <Contributor> composite for search, collation, collocation and other processing. The same applies to the equivalent <ContributorStatement> within Group P.5, though that should only be used where specific national practice requires contributors such as series editors to be identified at collection level.

In common with many other textual data elements, <ContributorStatement> is repeatable if supplying parallel text in multiple languages, and may also include XHTML markup.

P.7.52 “No authorship” indicator

This element should be used to give a positive indication that there are no contributors, either named or unnamed, in either P.7 or in P.5 where contributors to a collection can be listed.

This is one of the few ONIX for Books data elements that are defined as empty elements. The ‘self-closing’ XML syntax should always be used (ie <NoContributor/>, not <NoContributor></NoContributor>).

P.8 Event

If the product is not linked to a particular event, this Group can be ignored entirely. But if the ONIX record describes a product such as monograph containing the proceedings of a conference, a book linked to an artistic event, or a programme linked to a sporting fixture or championship, then the Group P.8 should be used to specify details about the event – the name, theme, date and so on. These details may be important for certain publishers, particularly in the academic and technical sectors, and for library cataloging.

In many cases, the event details may repeat information that is also included in the title of the product.

Event composite
Event EventRole EventName EventName EventAcronym EventAcronym EventNumber EventNumber EventTheme EventTheme EventDate EventPlace EventSponsor EventSponsor Website
Proceedings of the Frontiers in Science Education Research Conference
using Reference names
<Event>
    <EventRole>02</EventRole>
    <EventName>Frontiers in Science Education Research Conference</EventName>
    <EventAcronym>FISER ’09</EventAcronym>
    <EventDate dateformat="06">2009032220090324</EventDate>
</Event>
using Short tags
<event>
    <x515>02</x515>Proceedings of conference
    <x516>Frontiers in Science Education Research Conference</x516>
    <x517>FISER ’09</x517>
    <x520 dateformat="06">2009032220090324</x520>22–24 March 2009
</event>

P.9 Edition

An ‘edition’ generally means all copies of a book that contain the same content, usually published by the same publisher. More loosely, an ‘edition’ may be a product produced for a specific sales channel or market segment – a book club edition, library edition, large print edition and so on. So different editions may be distinguished by their content (by the addition, revision or removal of material), or more occasionally by some other aspect of their product form or nature.

Group P.9 is used to specify three different sorts of edition information:

  • various edition types (of the same work);
    • facsimile, special or prebound editions, where editions generally imply little or no change of content, but emphasize some other aspect of the product that differs from a previous or parallel version of the same work;
    • Braille, large print, high-readability, digital original, limited (numbered) or media tie-in editions, where the edition type is simply a feature or attribute somewhat related to the product form, and does not necessarily imply the existence of any previous or parallel version – though where such other versions do exist, there is little or no change of content;
    • other distinctions that are merely differences of product form are not distinct ‘editions’: metadata that differentiates a ‘hardback edition’ from a ‘paperback edition’ lies within Group P.3 Product form;
  • various edition types (which imply a different but closely-related work);
    • abridged, illustrated, annotated, enlarged, revised, enhanced, student and teacher’s editions, where editions generally do imply some material difference in content between this and some previous or parallel product (such as an unabridged, text-only or edition without annotations);
    • omnibus (combined) editions are works in their own right, derived from multiple ‘grandparent works’;
    • reprints or reissues that incorporate only minor corrections are not new editions;
  • ordinal numbered editions;
    • in <EditionNumber>, second, third edition etc – where editions imply significant revisions to the content of a previous product (and are always different works);
    • in <EditionVersionNumber>, minor revisions (of a digital product) that denote mostly technical fixes or minor updates that do not significantly revise the content.

The historical meaning of ‘edition’ (which is synonymous with ‘impression’ or ‘print run’, and which is still sometimes used in book collecting – as in ‘a valuable first edition’) is generally not used in ONIX, as ONIX is not normally concerned with individual impressions or manufacturing batches (the exceptions: ‘limited edition’, and sometimes also minor updates in <EditionVersionNumber>).

Group P.9 is also used to convey detailed information about religious texts.

DescriptiveDetail (P.8 to P.10) Continued from P.7 Event Conference EditionType EditionNumber EditionVersionNumber EditionVersionNumber EditionStatement ReligiousText NoEdition Language Continued in Group P.11 should not omit both
Abridged edition
using Reference names
<EditionType>ABR</EditionType>
using Short tags
<x419>ABR</x419>
IVth edition
using Reference names
<EditionNumber>4</EditionNumber>
<EditionStatement>IVth edition</EditionStatement>
using Short tags
<b057>4</b057>
<b058>IVth edition</b058>
Centenary edition
using Reference names
<EditionType>SPE</EditionType>
<EditionStatement language="eng">Centenary edition</EditionStatement>
<EditionStatement language="fre">Édition du centenaire</EditionStatement>
using Short tags
<x419>SPE</x419>Special edition
<b058 language="eng">Centenary edition</b058>Parallel text in English
<b058 language="fre">Édition du centenaire</b058>and French
Facsimile first edition
using Reference names
<EditionType>FAC</EditionType>
<EditionNumber>1</EditionNumber>
using Short tags
<x419>FAC</x419>
<b057>1</b057>
Limited and numbered edition
using Reference names
<EditionType>NUM</EditionType>
<EditionType>SIG</EditionType>
<EditionStatement>Limited edition of 100 copies, individually numbered and signed by the author</EditionStatement>
using Short tags
<x419>NUM</x419>
<x419>SIG</x419>
<b058>Limited edition of 100 copies, individually numbered and signed by the author</b058>
Use code UNN for a limited edition where copies are not individually numbered.
P.9.1 Edition type code

Most edition type codes from List 21 are self-explanatory.

Codes STU (Student) and TCH (Teacher) should be used for two editions of a school or college textbooks, where only the teacher’s edition contains model answers to questions and/or other notes for the teacher. Code SCH should be used where there is a special school or college edition of a book that is different from the ‘normal’ trade edition – for example, a school version of a work of classic literature that is separate from the normal version might have extra footnotes or annotations, or it may be exactly the same as the main edition but have a lower price and some limitations on how it can be sold (eg may only be sold direct to schools or through education sales channels).

Use codes UBR (Unabridged), ILL (Illustrated) or ENH (Enhanced, for digital products) only to avoid doubt, when an abridged, non-illustrated or ‘un-enhanced’ edition also exists – or when it might be expected to exist. For example, because many audiobooks on CD are abridged, an unabridged product may carry the UBR Edition type code, even when no abridged version is available. Note that an abridged version must carry the ABR code. Conversely, DGO (digital original) should be used to indicate either where no physical counterpart of a digital product exists (because the normal expectation is that a physical version does exist), or where a physical counterpart does exist, that the digital version was published a significant time before the physical version (because the normal expectation is that the physical and digital versions were published together or that the physical version came first).

It is a common error to use DGO to indicate ‘digital exclusive’. ‘Digital original’ is a permanent feature of a product – if the digital version was published before a paper version, it remains the original, but is not digital exclusive. For products that are true digital exclusives, see Group P.14. and <TextType> code 21.

Use code SPE (Special edition) when no more specific code applies, and use <EditionStatement> to describe the nature of the edition.

Codes NED (New edition) and REV (Revised) should be used with care, and ideally only when editions are not numbered. If combined with an <EditionNumber>, then the meaning is somewhat unclear: a ‘third revised edition’ is not the same as a ‘revised third edition’. Where such a usage is unavoidable – that is, when the third edition has been revised, but not revised enough to justify naming it the fourth edition, and a distinction needs to be drawn with the unrevised third edition – always include an <EditionStatement> that makes the meaning clear – for example ‘Updated version of 3rd Edition’. When the ‘third revised edition’ simply means the second edition has been revised to create the third, do not use an unnecessary Edition type code like NED or REV – use only <EditionNumber> 3.

Note that <EditionType> is repeatable, to describe an edition that is, as an example, both Abridged (code ABR) and Large type (LTE).

P.9.2 Edition number

This data element should be included (as an integer, 2, 3, 4…) even when editions are numbered using Roman numerals (II, III, IV…) on the product itself. If Roman numerals are used on the product, use a normal integer in <EditionNumber>, and include the Roman edition number in <EditionStatement>.

It is best practice not to include the Edition number for ‘first’ editions, unless this is a particular feature of a product produced after a subsequent edition has been released, for example with a facsimile edition, when the first edition and a later edition are both orderable or available at the same time, or when using <EditionVersionNumber>. Thus occasionally, it may be necessary to populate <EditionNumber> with 1.

Edition number may also be used to carry a version number for a software product, where for example numbered major revisions of the software are released and the number is not considered part of the title. Minor revisions of the software version can also be carried in <EditionVersionNumber> if required.

using Reference names
<EditionNumber>3</EditionNumber>
<EditionVersionNumber>2</EditionVersionNumber>
using short tags
<b057>3</b057>v3.2 of a software product, or
<b217>2</b217>second minor update of a 3rd edition of a book
An e‑book publisher may choose to maintain a two- or three-level version numbering scheme, such as is common with software products. A change of edition number would indicate a major revision of the content – and a change of the product and work identifiers – as with the first edition followed by the second edition of a conventional book. Within a given edition, smaller updates can be designated using the edition version number, so a version 3.0.2 is the second minor update of the Third edition. Typically, minor updates would contain only fixes to typos in the text or small technical corrections in the e‑book files (eg to fix layout errors). For a version 3.0.2, the <EditionNumber> would be 3 and the <EditionVersionNumber> would be 0.2. A version 3.1 is a more significant update of the Third edition, with some new content or added functionality – more significant than just corrections, though not significant enough to trigger a change of the Edition number and of the product identifiers. Some e‑book vendors may choose to push these smaller updates out to previous purchasers automatically, whereas other vendors make them available to previous purchasers if they specifically choose to re-download.
Occasionally – in the case of a minor update to a first or unnumbered edition – the use of <EditionVersionNumber> requires the use of <EditionNumber> 1, where normally edition 1 would be omitted. This serves to emphasize that what has been updated does not constitute a new edition.
P.9.4 Edition statement

An <EditionStatement> element should be included whenever a simple concatenation of the edition type and number is not sufficient for display purposes: it should be complete in itself and incorporate the edition type and number information, and should not occur if both <EditionType> and <EditionNumber> are omitted (it augments rather than replaces them). When provided, recipients should use the <EditionStatement> for display, while using any edition type or number for search and collation purposes.

The Edition statement may be repeated in multiple, parallel languages if required. If it is repeated, the language attribute much be included with each repeat.

P.9.5 “No edition” indicator

This element should be included whenever there is no other edition information. It is one of the few ONIX data elements that is defined as an empty element.

P.10 Language

Group P.10 consists solely of the <Language> composite.

Language composite

For books in a single language, this is entirely straightforward – the <Language> composite specifies the language, and its ‘role’ (language of the text, code 01 from List 22), and for translated works, a second repeat of the composite specifies the original language from which the text was translated.

If a book contains only a few individual phrases, small passages or quotations in a second language, then that second language should not be listed in a <Language> composite.

But if a product contains significant content in more than one language (eg a bilingual dictionary that can be used for translation ‘both ways’, or a book with parallel texts in two or more languages), then separate repeats of the <Language> composite with <LanguageRole> code 01 (Language of text) are appropriate. For example, a full bilingual dictionary with Spanish-to-English and English-to-Spanish sections would have two <Language> composites, specifying <LanguageRole> code 01 for both English and Spanish languages. It would be equally useful for native Spanish readers and native English readers.

Products like phrasebooks or textbooks for foreign language learning need different treatment. While it might contain significant content in both Spanish and English, a book designed for use by Spanish students learning English should be coded using only one <Language> composite, with <LanguageRole> code 01 and <LanguageCode> code spa (Spanish). Such a book would not be useful to an English student trying to learn Spanish!

One way of clarifying this is to ask, ‘Is the book in a particular language, or about a particular language?’ In the former case, the language should be listed in a <Language> composite. If it’s about a language, it should not – although the secondary language may be indicated using some subject classification schemes. A second useful criterion – for such language teaching products and phrasebooks – is the language of the primary readership the product is intended for.

Using this second criterion, it’s also possible to classify a translation dictionary containing, for example, only Spanish-to-English (ie Spanish headwords with their English equivalents), although fine judgement is required about the target market or likely audience for the product. It contains significant text in both languages, and might be useful (in slightly different circumstances) for both English and Spanish readers. But if it’s for casual use (ie it’s akin to a phrasebook) or is a beginner-level dictionary for the teaching of English to Spanish readers), then it’s ‘in’ Spanish. If it’s for professional or scholarly use, then it’s more likely to be used by English translators translating from Spanish, so is ‘in’ English.

Two final uses for the <Language> composite are to define a regional variant or variety of a language using <CountryCode>, and the script that the product uses in <ScriptCode>. Some languages – a well-known example being Serbian – can be expressed in two entirely separate scripts, in this case both Latin and Cyrillic. (There are a handful of other languages which have changed script in relatively recent times, for example Turkish and Vietnamese, and since the 1950s, simplified Chinese characters have replaced traditional characters in mainland China.) Other languages have distinct regional varieties, for example there are well-known differences between British English and US English, Iberian Spanish and Mexican Spanish, Québécois (ie Canadian) French and Metropolitan French, or Brazilian and Iberian Portuguese. Where such distinctions are an important product attribute, they should be specified.

However, Braille can also be treated as a script in the relevant ISO code list. It is not recommended that Braille books be described or discovered only or primarily via a script code. For Braille, see <EditionType> in Group P.9 and <ProductFormDetail> in Group P.3 for the preferred methods of description.

Language LanguageRole LanguageCode CountryCode ScriptCode
The ONIX codes for language, script and country can almost always be concatenated with hyphens to create a single ‘portmanteau’ code in line with IETF BCP 47 language tagging (RFC 5646) – for example por-BR (Brazilian Portuguese) or yue-Hant-HK (Hong Kong Cantonese written in Traditional Chinese characters). A few potential combinations of ONIX codes are not valid according to RFC 5646, as ONIX uses a few ‘local codes’ in List 74 (eg qav for Valencian, a distinct dialect of Catalan) that do not have equivalents in the ISO 639 standard. Similarly, there may be some codes valid according to BCP 47 that cannot be expressed in ONIX as, inter alia, ONIX does not provide any equivalent to the UN M.49 region codes (for regions larger than a country). But for most purposes, there is a very broad compatibility.
work written and published in Portuguese
using Reference names
<Language>
    <LanguageRole>01</LanguageRole>
    <LanguageCode>por</LanguageCode>
</Language>
using Short tags, additionally specifying Brazilian Portuguese
<language>
    <b253>01</b253>Language of text
    <b252>por</b252>Portuguese
    <b251>BR</b251>Brazilian variant
</language>
work written in Portuguese, translated and published in English
using Reference names
<Language>
    <LanguageRole>01</LanguageRole>
    <LanguageCode>eng</LanguageCode>
</Language>
<Language>
    <LanguageRole>02</LanguageRole>
    <LanguageCode>por</LanguageCode>
</Language>
using Short tags
<language>
    <b253>01</b253>Language of text
    <b252>eng</b252>
</language>
<language>
    <b253>02</b253>Original language
    <b252>por</b252>
</language>
tourist phrasebook for German tourists visiting Japan
using Reference names
<Language>
    <LanguageRole>01</LanguageRole>
    <LanguageCode>ger</LanguageCode>
</Language>
using Short tags
<language>
    <b253>01</b253>Language of text
    <b252>ger</b252>
</language>
Use <Subject> to specify Japan and/or Japanese.
Braille novel in French
using Reference names
<EditionType>BRL</EditionType>
. . .
<Language>
    <LanguageRole>01</LanguageRole>
    <LanguageCode>fre</LanguageCode>
</Language>
using Short tags
<x419>BRL</x419>Braille edition
. . .
<language>
    <b253>01</b253>Language of text
    <b252>fre</b252>
</language>
An English-language Braille edition should additionally use <ProductFormDetail> to indicate the use of Contracted or Uncontracted Braille. Similar codes indicating the grade of Braille for other languages are not yet defined.
book in Mandarin Chinese, using traditional Chinese characters
using Reference names
<Language>
    <LanguageRole>01</LanguageRole>
    <LanguageCode>cmn</LanguageCode>
    <ScriptCode>Hant<ScriptCode>
</Language>
using Short tags
<language>
    <b253>01</b253>Language of text
    <b252>cmn</b252>Mandarin Chinese
    <x420>Hant<x420>Written in traditional characters
</language>
Note that the Chinese language code chi in List 74 specifies a macrolanguage, a family of closely-related languages. The specific Mandarin or Cantonese languages (which are not mutually intelligible when spoken) can be specified using codes cmn and yue.
Much modern Mandarin material is written in simplified characters, which would be specified using <ScriptCode> Hans. However, some modern and all historical Mandarin is written in traditional characters, <ScriptCode> Hant. Similarly, Cantonese content can be written in either simplified or traditional characters.
multilingual book with parallel text in three languages
using Reference names
<EditionType>MLL</EditionType>
<Language>
    <LanguageRole>01</LanguageRole>
    <LanguageCode>ger</LanguageCode>
</Language>
<Language>
    <LanguageRole>01</LanguageRole>
    <LanguageCode>eng</LanguageCode>
</Language>
<Language>
    <LanguageRole>01</LanguageRole>
    <LanguageCode>fre</LanguageCode>
</Language>
using Short tags
<x419>MLL</x419>Multilingual edition
<language>
    <b253>01</b253>Language of text
    <b252>ger</b252>German
</language>
<language>
    <b253>01</b253>
    <b252>eng</b252>and English
</language>
<language>
    <b253>01</b253>
    <b252>fre</b252>and French
</language>
For a bilingual book, the BLL Edition type should be used.

P.11 Extents and other content

Group P.11 is primarily used to specify the extent of a product – the number of pages, or the running time of an audiobook. It also covers ancillary content such as illustrations.

DescriptiveDetail (P.11 to P.13) Continued from P.10 Extent Illustrated NumberOfIllustrations NumberOfIllustrations IllustrationsNote AncillaryContent Subject NameAsSubject AudienceCode Audience AudienceRange AudienceDescription AudienceDescription Complexity Use <Audience> instead
page count of a simple book with no significant front or back matter
using Reference names
<Extent>
    <ExtentType>11</ExtentType>
    <ExtentValue>245</ExtentValue>
    <ExtentUnit>03</ExtentUnit>
</Extent>
using Short tags
<extent>
    <b218>11</b218>Content page count
    <b219>245</b219>
    <b220>03</b220>Pages
</extent>
running time of an audiobook
using Reference names
<Extent>
    <ExtentType>09</ExtentType>
    <ExtentValue>285</ExtentValue>
    <ExtentUnit>05</ExtentUnit>
</Extent>
using Short tags
<extent>
    <b218>09</b218>Running time
    <b219>285</b219>4 hours 45 mins
    <b220>05</b220>In minutes
</extent>
page count of a book with extensive front and back matter plus a plate section
using Reference names, ancillary content listed in simple <IllustrationsNote>
<Extent>
    <ExtentType>00</ExtentType>
    <ExtentValue>245</ExtentValue>
    <ExtentUnit>03</ExtentUnit>
</Extent>
<Extent>
    <ExtentType>03</ExtentType>
    <ExtentValue>12</ExtentValue>
    <ExtentValueRoman>xii</ExtentValueRoman>
    <ExtentUnit>03</ExtentUnit>
</Extent>
<Extent>
    <ExtentType>04</ExtentType>
    <ExtentValue>14</ExtentValue>
    <ExtentValueRoman>xiv</ExtentValueRoman>
    <ExtentUnit>03</ExtentUnit>
</Extent>
<Extent>
    <ExtentType>12</ExtentType>
    <ExtentValue>16</ExtentValue>
    <ExtentUnit>03</ExtentUnit>
</Extent>
<Extent>
    <ExtentType>11</ExtentType>
    <ExtentValue>287</ExtentValue>
    <ExtentUnit>03</ExtentUnit>
</Extent>
<IllustrationsNote>8 color plates, 15 mono plates, 2 maps. Includes index</IllustrationsNote>
using Short tags, using <AncillaryContent>
<extent>
    <b218>00</b218>Main content page count
    <b219>245</b219>
    <b220>03</b220>Pages
</extent>
<extent>
    <b218>03</b218>Front matter page count
    <b219>12</b219>
    <x421>xii</x421>
    <b220>03</b220>Pages
</extent>
<extent>
    <b218>04</b218>Back matter page count
    <b219>14</b219>
    <x421>xiv</x421>
    <b220>03</b220>Pages
</extent>
<extent>
    <b218>12</b218>Unnumbered insert page count
    <b219>16</b219>
    <b220>03</b220>Pages
</extent>
<extent>
    <b218>11</b218>Content page count
    <b219>287</b219>
    <b220>03</b220>Pages
</extent>
<ancillarycontent>
    <x423>24</x423>Color plates
    <b257>8</b257>
</ancillarycontent>
<ancillarycontent>
    <x423>23</x423>Mono plates
    <b257>15</b257>
</ancillarycontent>
<ancillarycontent>
    <x423>14</x423>Maps
    <b257>2</b257>
</ancillarycontent>
<ancillarycontent>
    <x423>25</x423>Index
    <!-- number of index pages unspecified -->
</ancillarycontent>
The 8 color and 15 mono plates make up the 16-page unnumbered insert (plate section). The maps and index are counted within the main content page count.
filesize of a downloadable e-publication, with extent of print counterpart
using Reference names
<Extent>
    <ExtentType>22</ExtentType>
    <ExtentValue>1.4</ExtentValue>
    <ExtentUnit>19</ExtentUnit>
</Extent>
<Extent>
    <ExtentType>08</ExtentType>
    <ExtentValue>320</ExtentValue>
    <ExtentUnit>03</ExtentUnit>
</Extent>
using Short tags
<extent>
    <b218>22</b218>Filesize
    <b219>1.4</b219>
    <b220>19</b220>In megabytes
</extent>
<extent>
    <b218>08</b218>Extent of print counterpart
    <b219>320</b219>
    <b220>03</b220>Pages
</extent>
Extent composite

The <Extent> composite carries the page count of a book or e-publication, or a similar measure such as running time for an audio product (including downloadable audio) or filesize – and possibly the word count – for a downloadable product. The composite should contain a mandatory <ExtentType>, a number for the extent in <ExtentValue>, and must specify the units the value is measured in (pages, minutes, megabytes etc) in the <ExtentUnit> element.

For books where front and back matter are relatively insignificant and there are no inserts – for example, most novels – it is best practice to provide only a single extent, and the preferred measure is the content page count (code 11 from List 23). In very simple cases, this extent might be equal to the highest page number.

Where a book contains any significant front or back matter, or an insert / plate section, it is best practice to specify the page count for the key parts of a book individually:

  • front matter – for example, the title page, introduction and preface, often termed the ‘prelims’ (code 03 from List 23);
  • the main content (code 00 from List 23);
    • this might include a few blank pages, where for example blanks are included to ensure all chapters start on a recto page, or where pages are intended to be filled in by the consumer, but it does not include any unnumbered pages in an insert or plate section;
  • unnumbered pages in any insert(s) such as plate sections (code 12 from List 23);
  • back matter – notes and appendices, index etc (code 03 from List 23);
    • this excludes any sample or ‘teaser’ material for other works, or any other advertising pages;
    • this excludes any blank pages that are included to ensure a convenient signature size during manufacture;
  • if the front matter, main content and back matter page counts cannot be provided separately, then a total count of numbered pages may be provided (code 05), together with a count of any unnumbered pages in inserts or plate sections (code 12);
  • the content page count (code 11) should always be provided when the more granular combinations of extents are not available, and could be provided in addition to the granular extents for recipients who want just a simple, single number.

Where for any reason a publisher can only provide a single repeat of the <Extent> composite, the preferred measure is the content page count (which includes any unnumbered inserts or plate sections) or – if this is genuinely unavailable – the total numbered page count (which excludes unnumbered inserts or plate sections). Note that neither of these necessarily matches the highest page number in the book (which in most cases will be the total numbered page count minus any Roman-numbered front matter). Nor do they match the production page count.

For front matter (and possibly back matter) that is numbered with Roman numerals, the extent should be stated as an Arabic integer as normal, in <ExtentValue>, but may additionally be stated in Roman numerals in <ExtentValueRoman>. It is not best practice to supply only Roman numerals. Recipients should accept Roman numerals in either upper or lower case, though lower case is more usual when numbering pages.

For audio running times, values in minutes are preferred to hours and minutes or just hours (ie 195 minutes is preferred to 3 hours and 15 minutes or simply three hours). The unit of measure should be included in the <ExtentUnit> element.

For e-publications that have a fixed pagination (ie they are not ‘reflowable‘), the extent should be provided exactly as for printed books, or by specifying the absolute page count (code 07). For reflowable e-publications without a fixed pagination, then the extent should be specified either by providing the extent of the printed counterpart (code 08) or by providing a ‘notional’ extent (ie what would be the extend of the print version, if such a counterpart existed).

For downloadable e-publications such as e‑books or downloadable audio, the size of the downloadable file (or total size of some downloadable package of files) should be included, measured in kilobytes for filesizes below 1MB (code 18 from List 24 in the <ExtentUnit> element), and in megabytes (code 19) for larger files. There is no real benefit in a precision greater than two significant digits (ie 220 kilobytes or 1.3 megabytes, not 223.75 kilobytes and 1.325 megabytes).

Extents can also be specified by the number of words. However, while the weightiness of a 200,000 word manuscript is familiar to some within the publishing industry, word counts are not always simple for consumers to interpret. They are not recommended as the only indication of extent – though they may become more useful in future as reflowable publications become the norm.

Extent ExtentType ExtentValue ExtentValueRoman ExtentValueRoman ExtentUnit must not omit both

List 23 allows the number of pages in a book (or an e-publication) to be specified in various ways: the diagram illustrates the relationship between the parts of the book in spine order, and the various page counts. For example, the total page count (List 23 code 05) counts all numbered pages in the front matter, the main content and back matter, but excludes unnumbered pages in any insert or plate section. In contrast, the content page count (code 11) includes those unnumbered pages.

Best practice is to provide one of the combinations of extents A, B or C in repeats of <Extent> – codes 03, 00, 04 plus 12 (if relevant) make up combination A, and codes 05 plus 12 (if relevant) make up combination B. The diagram is in rough order of preference, so combination A is preferred to combination B, and B is preferred to C (code 11 alone) because the former is more granular, and recipients who receive granular data but wish to use only a single figure can easily sum the various extents provided in a combination.

Types of Extent unnumbered insert / plate section (12) front cover front matter (03) main content (00) back matter (04) ² other + blank ³ back cover A total numbered (05) content (11) production (06) absolute (07) ¹ total in print counterpart (08) ¹ notional total (10) ¹ A B C

¹ Absolute extent is rarely used, and only with non-reflowable e-publications. Counterpart and notional page counts are only used with reflowable e-publications or audiobooks, but word counts may be equally appropriate
² Back matter does not include advertising pages
³ ‘Other + blank’ pages may include advertising pages, including extracts and ‘teaser’ content from other works

Various extent types used for printed books have direct equivalents for audio material. Content page count (code 11) has an equivalent in Duration (code 09). Similarly, code 03 ≍ 13, code 00 ≍ 14, code 04 ≍ 15 and code 06 ≍ 16.

It is likely that the exact extent – whether a page count or a running time – will not be known until relatively late in the production of a new product. Extents provided more than three months prior to publication should be treated as estimates, and publishers should provide more accurate values as early as possible. Filesizes are unlikely to be finalized more than a month prior to publication.

Audiobook products on CD are commonly divided into many tracks – the equivalent of songs on a music CD – typically around three to six minutes per track. These tracks are important for navigation, as CD players typically don’t maintain a ‘bookmark’ or current playback position if playback is stopped and restarted later. It may sometimes be useful to be able to declare the number of tracks in the metadata – though this should never be at the expense of describing the actual running time.

Number of physical tracks in a CD audiobook
using Reference names, a 12-track CD
<Extent>
    <ExtentType>09</ExtentType>Duration
    <ExtentValue>12</ExtentValue>
    <ExtentUnit>11</ExtentUnit>12 tracks
</Extent>
using Short tags, a 92½ minute, 20 track CD with the first track being introductory music and the final track being cast credits or other end matter
<Extent>
    <b218>09</b218>Duration (total running time)
    <b219>92.5</b219>
    <b220>05</b220>92½ minutes
</Extent>
<Extent>
    <b218>13</b218>Duration of introduction
    <b219>1</b219>
    <b220>11</b220>1 track
</Extent>
<Extent>
    <b218>14</b218>Duration of main content
    <b219>18</b219>
    <b220>11</b220>18 tracks
</Extent>
‘Tracks’ is treated as – in effect – a unit of time, equivalent to something between 3 and 6 minutes.
Physical CD tracks have an equivalent with downloadable audio files, when a single book is delivered as a collection of individual MP3 files (or similar audio files).

For multi-component products which are sold as a single item (with <ProductComposition> code 10), the extent is the total of the extents of the components included in the product. (This is necessary because <Extent> cannot be included within <ProductPart> or Block 3 <ContentDetail>.) So a product which consists of four 300-page volumes in a slipcase has a combined extent of 1200 pages. And a product that includes both a book and an audio version of the text might have both a page extent and a running time. However, you should not include extents for multi-item products that are sold individually at retail (<ProductComposition> codes 11 or 30). A trade pack of four copies of a 300-page book does not have a combined extent of 1200 pages.

P.11.7 Illustrations and other contents note

Where <AncillaryContent> cannot be supplied for any reason, any illustrations and other important non-textual content such as an extensive tabular material, a bibliography or an index should be listed here. <IllustrationsNote> is not just for describing the number and type of any included illustrations.

Note this is a text field that can accept XHTML encoding: this could be used to provide a marked-up bulleted list of the ancillary content – but it is unlikely that a data provider would be able to provide that level of detail, yet not be able to provide the data in the <AncillaryContent> composite.

However, if various repeats of the <AncillaryContent> composite are used to specify non-textual content, it may still be beneficial to include a description of the non-text content in <IllustrationsNote>, for recipients who are not able to make use of the <AncillaryContent> composite, or to provide a more ‘readable’ alternative where a simple concatenation of various <AncillaryContent> elements would not produce a suitable description. If provided in this way, recipients should use <IllustrationsNote> for display purposes, while using the granular data in <AncillaryContent> for processing.

<IllustrationsNote>Includes 32 full-page color reproductions of the artist’s work printed on high-quality paper, and 20 further full-color images</IllustrationsNote>

Note there is some overlap between detailed text that might be included in <IllustrationNote>, descriptive text about the product that might be included in the <TextContent> composite within Block 2: Marketing collateral. <IllustrationNote> should be very brief, and is not intended to be heavily formatted (even though XHTML markup is valid in this element).

Ancillary content composite

This composite is the preferred way of listing details of the number and type of any graphical and other material within a primarily textual product. It can be used to highlight extensive tabular content, maps, charts and diagrams, or the presence and extent of any bibliography or index. Repetitions of the composite are used to specify ancillary content of more than one type.

The composite must contain an <AncillaryContentType> element to specify the type of the ancillary content, and may contain a <Number> element to specify the amount of that type of content. The ‘measure’ used is primarily ‘number of…’ – so 16 graphs or diagrams or plates, not 16 pages of graphs, diagrams or plates. However, for bibliographies and indexes (<AncillaryContentType> codes 25 and 26), the measure is the number of pages that content comprises. If an <AncillaryContent> composite is supplied without a <Number> element, then it simply serves as a flag that some content of the specified type is present.

<AncillaryContent> is not generally used to specify the number of maps with products like atlases, where the non-textual content is the primary content of the product, but can be used to specify additional larger-scale inset maps within a cartographic product. Gazetteer content within an atlas may be counted as an index.

AncillaryContent AncillaryContentType AncillaryContentType AncillaryContentDescription AncillaryContentDescription Number

The code values in List 25 specify the type of ancillary content in the <AncillaryContentType> data element. But because of differences in terminology used in different countries, the meanings of the common codes for images included in a book are not always clear. The primary distinction is whether the images occur within the ‘main content’ of the book (illustrations – they might be photos, graphs, diagrams, charts, inset maps etc), or whether they occur in an insert (plates – these are usually photos, and the insert usually uses a higher-quality paper than the remainder of the book). The secondary distinction is whether they are color (using multiple inks) or mono (using a single ink, thus usually a black and white image). The tertiary distinction is whether they use a halftoning process (thus allowing graduated shades or tints) or are line art (solid ink only, no halftoning). This is primarily a ‘production’ classification, which takes no account of the editorial function of each illustration or plate:

List 25 code values ‘production-led’ classification of ancillary content
location color mono unspecified
halftone line art halftone line art halftone line art
‘plates’ insert 24 23 22
‘illustrations’ main content 04 06 03 05 10 12
tabular material main content 08 07 11
printed music main content 20
bibliography main content 26
index main content 25

It is also possible to use an ‘editorial’ classification with some types of ancillary content, which emphasizes the nature of (in particular) illustrations. Unfortunately in this case, the distinctions between tables, figures, diagrams, graphs and charts are not at all clear cut, and usage of these terms varies:

List 25 code values ‘editorially-led’ classification of ancillary content
color mono unspecified
photographs / similar images 02 01 09
figures 17
diagrams 16
graphs 21
charts 18
maps 14
inset maps 27
tabular material 08 07 11
printed music 20
bibliography 26
index 25

Do not mix the two types of classification – use either a production- or editorially-led approach. Note there are a couple of ‘special case’ codes not included in the above tables.

P.12 Subject

This Group is used to describe what or who the product is about, independent of the physical or digital nature of the product.

Note the <Subject> composite is also used to carry some classifications that are not strictly subject categories – for example the (UK) Publishers Association’s Children’s Book Marketing Code (CBMC), or the BISG Educational Taxonomy – and a variety of proprietary subject classifications.

Subject MainSubject SubjectSchemeIdentifier SubjectSchemeIdentifier SubjectSchemeName SubjectSchemeName SubjectSchemeVersion SubjectSchemeVersion SubjectCode SubjectHeadingText SubjectHeadingText NameAsSubject NameType NameIdentifier Personal or Corporate name AlternativeName SubjectDate ProfessionalAffiliation ProfessionalAffiliation must include if ID is proprietary, otherwise omit must not omit both
product about the architecture of the English Arts and Crafts movement, classified using both BIC and BISAC subject classification schemes, plus keywords
using Reference names
<Subject>
    <MainSubject/>
    <SubjectSchemeIdentifier>12</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>2.0</SubjectSchemeVersion>
    <SubjectCode>AMX</SubjectCode>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>12</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>2.0</SubjectSchemeVersion>
    <SubjectCode>ACVN</SubjectCode>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>13</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>2.0</SubjectSchemeVersion>
    <SubjectCode>1DBKE</SubjectCode>
</Subject>
<Subject>
    <MainSubject/>
    <SubjectSchemeIdentifier>15</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>2.0</SubjectSchemeVersion>
    <SubjectCode>3JH</SubjectCode>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>15</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>2.0</SubjectSchemeVersion>
    <SubjectCode>3JJ</SubjectCode>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>20</SubjectSchemeIdentifier>
    <SubjectHeadingText>William Morris; Kelmscott House; Augustus Pugin; John Ruskin; Philip Webb; Red House; Charles Voysey; Edwin Lutyens; Edward Schroeder Prior; Voewood; Euston fire station; vernacular architecture; medieval revival; gothic revival</SubjectHeadingText>
</Subject>
<Subject>
    <MainSubject/>
    <SubjectSchemeIdentifier>10</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>2009</SubjectSchemeVersion>
    <SubjectCode>ARC005070</SubjectCode>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>10</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>2009</SubjectSchemeVersion>
    <SubjectCode>ART015030</SubjectCode>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>11</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>2009</SubjectSchemeVersion>
    <SubjectCode>1.1.2.2.0.0.0</SubjectCode>
</Subject>
using Short tags
<subject>
    <x425/>Main
    <b067>12</b067>BIC subject category
    <b068>2.0</b068>(latest is 2.1)
    <b069>AMX</b069>History of architecture
</subject>
<subject>
    <b067>12</b067>BIC subject category
    <b068>2.0</b068>
    <b069>ACVN</b069>Art and design styles: Arts and Crafts
</subject>
<subject>
    <b067>13</b067>BIC geographical qualifier
    <b068>2.0</b068>
    <b069>1DBKE</b069>England
</subject>
<subject>
    <x425/>Main
    <b067>15</b067>BIC time period qualifier
    <b068>2.0</b068>
    <b069>3JH</b069>19th Century
</subject>
<subject>
    <b067>15</b067>BIC time period qualifier
    <b068>2.0</b068>
    <b069>3JJ</b069>20th Century
</subject>
<subject>
    <b067>20</b067>Keywords
    <b070>William Morris; Kelmscott House; Augustus Pugin; John Ruskin; Philip Webb; Red House; Charles Voysey; Edwin Lutyens; Edward Schroeder Prior; Voewood; Euston fire station; vernacular architecture; medieval revival; gothic revival</b070>Selection of likely search terms, though the book is not specifically ‘about’ any individual architect
</subject>
<subject>
    <x425/>Main
    <b067>10</b067>BISAC Subject Heading
    <b068>2009</b068>(latest is 2011)
    <b069>ARC005070</b069>Architecture / History / Modern (late 19th Century to 1945)
</subject>
<subject>
    <b067>10</b067>BISAC Subject Heading
    <b068>2009</b068>
    <b069>ART015030</b069>Art / European
</subject>
<subject>
    <b067>11</b067>BISAC regional theme
    <b068>2009</b068>
    <b069>1.1.2.2.0.0.0</b069>England
</subject>
There can be only one subject nominated as ‘main’, per scheme.
If the product concentrated on a particular architect, their name should be included in a <NameAsSubject> composite, and BIC and BISAC subject coding would also differ (probably AMB and ARC006020, respectively).
using the new Thema global subject classification scheme for a product about Gauguin and the Pont Aven school
using Reference names
<Subject>
    <MainSubject/>
    <SubjectSchemeIdentifier>93</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>1.3</SubjectSchemeVersion>
    <SubjectCode>AGA</SubjectCode>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>93</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>1.3</SubjectSchemeVersion>
    <SubjectCode>AFCL</SubjectCode>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>94</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>1.3</SubjectSchemeVersion>
    <SubjectCode>1DD-FR-FB</SubjectCode>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>96</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>1.3</SubjectSchemeVersion>
    <SubjectCode>3MNQX</SubjectCode>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>99</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>1.3</SubjectSchemeVersion>
    <SubjectCode>6SV</SubjectCode>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>20</SubjectSchemeIdentifier>
    <SubjectHeadingText>Pont Aven</SubjectHeadingText>
</Subject>
<NameAsSubject>
    <NameIdentifier>
        <NameIDType>16</NameIDType>
        <IDValue>000000012100026X</IDValue>
    </NameIdentifier>
    <PersonNameInverted>Gauguin, Paul</PersonNameInverted>
</NameAsSubject>
<NameAsSubject>
    <PersonNameInverted>Bernard, Émile</PersonNameInverted>
</NameAsSubject>
using short names
<subject>
    <x425/>Main
    <b067>93</b067>Thema subject classification
    <b068>1.3</b068>
    <b069>AGA</b069>History of art
</subject>
<subject>
    <b067>93</b067>
    <b068>1.3</b068>
    <b069>AFCL</b069>Painting in oil
</subject>
<subject>
    <b067>94</b067>
    <b068>1.3</b068>
    <b069>1DDF-FR-FB</b069>Finistère
</subject>
<subject>
    <b067>96</b067>
    <b068>1.3</b068>
    <b069>3MNQX</b069>1880s
</subject>
<subject>
    <b067>99</b067>
    <b068>1.3</b068>
    <b069>6SV</b069>Synthetism
</subject>
<subject>
    <b067>20</b067>Keywords
    <b070>Pont Aven</b070>
</subject>
<nameassubject>
    <nameidentifier>
        <x415>16</x415>ISNI
        <b244>000000012100026X</b244>
    </nameidentifier>
    <b037>Gauguin, Paul</b037>
</nameassubject>
<nameassubject>
    <b037>Bernard, Émile</b037>
</nameassubject>
Thema is the international, multi-lingual subject classification for a global book trade. For further details, see the EDItEUR website. It is available in languages including Arabic, Danish, English, French, German, Italian, Hungarian, Japanese, Polish, Spanish, Norwegian, Swedish, Turkish, and other translations are in preparation.
Subject composite

Repeats of the <Subject> composite must each contain either a code drawn from one of the many classification schemes listed in List 27, or a classification drawn from a proprietary subject code list, or a set of keywords. In all cases, the scheme used must be identified in <SubjectSchemeIdentifier>, and for proprietary schemes, the name of the scheme should be carried in <SubjectSchemeName>. The composite should include:

  • For an established classification scheme;
    • <SubjectSchemeIdentifier> (almost any code from List 27);
    • <SubjectSchemeVersion> (as far as possible with an individual scheme, this should be a simple number, and should not incorporate words such as ‘version’ or ‘release’);
    • <SubjectCode> (in whatever format specified by the individual scheme);
      • <SubjectHeadingText> is unnecessary;
  • For a proprietary subject scheme;
    • <SubjectSchemeIdentifier> (codes 23 or 24 from List 27);
    • <SubjectSchemeName>;
    • <SubjectSchemeVersion>;
    • one or both of <SubjectCode> and <SubjectHeadingText>;
  • For a list of keywords;
    • <SubjectSchemeIdentifier> (code 20 from List 27);
    • <SubjectHeadingText> (semicolon-separated keyword terms).

For established classification schemes which use codes (including Thema, BIC, BISAC etc), there is no need to embed the name or heading text of the selected category in <SubjectHeadingText> – that text is made explicit in the authority list for the scheme, and there is no great value in repeating it. However, the version or revision number of the scheme should usually be included in <SubjectSchemeVersion>, because many schemes regularly introduce new categories or deprecate old ones.

For less well-known schemes which may not be understood by recipients, or for schemes which do not specify a code for each heading, the heading text should be included in <SubjectHeadingText>.

Commonly-used subject schemes and <SubjectSchemeVersion> numbers
SchemeCurrentSelected previous versions
BIC2.12.0, 1.1 etc
BISAC20182014, 2011, 2010, 2.9, 2.6 etc
CCE2.0 
CLIL20182014, 2010, 2006 etc
Thema1.31.2, 1.1, 1.0
Warengruppen-Systematik neu2.0 

Where classification schemes allow multiple classifications to be supplied, ensure one is labelled as the primary classification using <MainSubject/>, and it is good practice to list the others in order of importance (this makes it more likely that a data recipient which accepts only a limited number of codes accepts the most important).

It is common to provide two, three or more subject classifications from a single scheme. But note there is diminishing value in providing more and more codes: two or three thoughtfully-chosen, detailed and relevant subject categories are more useful to a retailer – and to a potential purchaser – than 12 or 13 that are less relevant or overly broad. Do not supply multiple classifications simply in an attempt to get the product listed under as many headings as possible within a retail system. And with hierarchical schemes such as BIC, BISAC or Thema, do not provide a broad classification where you also provide a more specific code – always use the most specific classification that is appropriate.

Many major subject classification schemes have a hierarchical structure. Where this is the case, it is best practice to ‘use the most specific classification that is appropriate’. Including a ‘general’ or less specific code where the book also carries a more specific code should be avoided.

If the book is Historical fiction, do not also classify it as Fiction.

For a more detailed illustration of this principle, consider a book that is correctly classified using the BISAC subject category scheme as MAT007020 (ie it is about partial differential equations). The BISAC scheme is hierarchical, with – in effect – three levels, and MAT007020 is Mathematics / Differential Equations / Partial. This code is automatically included in any selection of ‘all books that are about maths’ (which would be a selection of any books that match MAT******, where * is a ‘wildcard’ in a search). Conversely, it would not be included in a selection of general books that cover the whole of mathematics as a subject – for that, you can search for MAT000000.

If the partial differential equations book were classified as both MAT007020 and MAT000000, it ‘pollutes’ the search for general maths books (where the book would not be suitable, because it is much too specialized and clearly not what the potential purchaser is searching for).

So following best practice allows a differentiation between ‘all books about any aspect of maths’ and ‘any books about all aspects of maths’.

If the book’s subject encompasses both partial differential equations and game theory, it should be classified as MAT007020 and MAT011000 – still not as MAT000000. At least in principle, high-level codes such as MAT000000 imply the subject matter is very broad or introductory and covers all sub-categories of MAT****** – arithmetic, algebra, geometry, topology, statistics and probability etc, as well as differential equations and game theory.

As well as the well-known and standardized ‘trade-focused’ subject classification schemes, the <Subject> composite can also include library-focused schemes.

Library classifications for a book of Australian agricultural statistics (20th century)
Using Reference names
<Subject>
    <SubjectSchemeIdentifier>09</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>11</SubjectSchemeVersion>
    <SubjectCode>63:31(94)"19"</SubjectCode>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>01</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>23</SubjectSchemeVersion>
    <SubjectCode>338.10973</SubjectCode>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>03</SubjectSchemeIdentifier>
    <SubjectCode>HD1751.A7</SubjectCode>
</Subject>
<Subject>
    <MainSubject/>
    <SubjectSchemeIdentifier>04</SubjectSchemeIdentifier>
    <SubjectCode>sh2007100879</SubjectCode>
    <SubjectHeadingText>Agriculture--Economic aspects--Australia</SubjectHeadingText>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>04</SubjectSchemeIdentifier>
    <SubjectCode>sh85047239</SubjectCode>
    <SubjectHeadingText>Farm produce</SubjectHeadingText>
</Subject>
Using Short tags
<subject>
    <b067>09</b067>UDC
    <b068>11</b068>MRF 11
    <b069>63:31(94)"19"</b069>
</subject>
<subject>
    <b067>01</b067>Dewey
    <b068>23</b068>23rd edition
    <b069>338.10973</b069>
</subject>
<subject>
    <b067>03</b067>LCC
    <b069>HD1751.A7</b069>
</subject>
<subject>
    <x425/>Main subject (within this scheme)
    <b067>04</b067>LCSH
    <b069>sh2007100879</b069>
    <b070>Agriculture--Economic aspects--Australia</b070>
</subject>
<subject>
    <b067>04</b067>LCSH
    <b069>sh85047239</b069>
    <b070>Farm produce</b070>
</subject>

UDC (Universal Decimal Classification) is a complex library classification scheme that uses codes and ‘auxiliaries’ (somewhat like Thema qualifiers), and a special syntax to indicate coordination, extension, relationships etc. The full classification should be carried in a single string within <SubjectCode> to preserve this syntax.

For proprietary classifications – <SubjectSchemeIdentifier> codes 23 or 24 from List 27 – the name of the proprietary scheme should always be included in a consistent and likely-to-be-unique way in <SubjectSchemeName>. Proprietary schemes may also need version numbering. Code 23 should be used for publisher’s own categorizations, and code 24 for proprietary schemes that may be applied to multiple publishers’ products (eg a distributor’s, wholesaler’s or retailer’s own scheme). If the scheme is coded, then the meaning of each code and the structure of the scheme must clearly be shared in advance with ONIX recipients. Alternatively, the classification text may be explicit in <SubjectHeadingText>. In the latter case, it is still good practice to share details of the scheme up front with recipients.

incorporating publisher’s and retailer’s proprietary subject category schemes
using Reference names
<Subject>
    <SubjectSchemeIdentifier>23</SubjectSchemeIdentifier>
    <SubjectSchemeName>FantasyBooks LLC Subject​</SubjectSchemeName>
    <SubjectSchemeVersion>1.1</SubjectSchemeVersion>
    <SubjectCode>405</SubjectCode>
    <SubjectHeadingText>Steampunk​</SubjectHeadingText>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>24</SubjectSchemeIdentifier>
    <SubjectSchemeName>BigBooks Inc Merchandising Category​</SubjectSchemeName>
    <SubjectSchemeVersion>2009</SubjectSchemeVersion>
    <SubjectHeadingText>Science Fiction​</SubjectHeadingText>
</Subject>
using Short tags
<subject>
    <b067>23</b067>Publisher’s own category
    <b171>FantasyBooks LLC Subject​</b171>
    <b068>1.1</b068>
    <b069>405</b069>
    <b070>Steampunk​</b070>
</subject>
<subject>
    <b067>24</b067>Proprietary subject scheme
    <b171>BigBooks Inc Merchandising Category​</b171>
    <b069>2009</b069>
    <b070>Science Fiction​</b070>
</subject>
The publisher’s scheme is coded, but the text of the category heading is also included. The proprietary scheme is not coded, but is simply a controlled vocabulary of subject headings.

When supplying keywords, the keywords should be carried in a single semicolon-separated list, which makes it possible to have ‘keyword’ terms that are in fact short phrases including spaces or other punctuation. Keywords can be invaluable as matches for natural language search terms: for fiction, choose character names, historical settings, locations, perhaps even narrative themes; for non-fiction, key terms of art, locations, events, periods and people can all be used to drive search results in an online context.

Choose keywords that are likely to be used as search terms by potential book buyers. While there’s often a temptation to include a very large number of keywords, experience shows that five to ten carefully-chosen keywords are more valuable than 20 or 50 that are poorly-chosen. Be mindful that while overly-generic terms may generate more search ‘hits’, those hits will be of lower quality (ie your book will be found, but so will thousands of others). Highly specific keywords work better than overly broad or generic terms. Nouns and uncommon verbs work better than common verbs and adjectives. Keywords should not repeat words from the title of the product or from contributor names, nor should they simply repeat words already included in the subject heading text of the subject categories in any other <Subject> composite, or the names in <NameAsSubject> composites. For recipients, keywords should be a source of matchable search terms in addition to the content of other structured metadata elements – and most of those other elements are likely to be weighted more highly than the unstructured keywords. One possible exception is that you may wish to repeat words from the short or long description as keywords. Some recipients automatically index the whole of the descriptive text to provide matchable search terms, but others do not.

For senders, there should be no need to supply many variations on the same root word – for example ‘catalyst; catalysts; catalysis; catalyze; catalyzer’ – as recipients are likely to implement stemming of search terms (that is, a single term like ‘catalyst’ would be matched by any word based on that root). Search engines also deal well with variant spellings through fuzzy matching, so only one of ‘organisation’ and ‘organization’ need be supplied as a keyword. However, it is a good idea to provide synonyms – both eggplant and aubergine.

In particular, avoid trying to ‘game’ the system. Do not include keywords that have little or nothing to do with the book’s subject matter, just because they are popular online search targets – don’t list 50 Shades of Grey, ‘cute cats’, Harry Potter, ‘free’ or ‘bestseller’ as keywords for every product. Doing so is likely to result in recipients rejecting the entire list of keywords. (Some retailers restrict or disallow the use of obviously promotional keywords like ‘free’ or ‘bestseller’. And note that genuine competitive, comparable or related titles can be listed using the <RelatedProduct> composite.)

Finally – and particularly for non-fiction – reconsider keywords throughout the lifecycle of the product. New terminology or newsworthy topics become relevant and could be added to the keyword list, as other topics fade from public consciousness. This changes what potential readers search for on retail websites, so keeping your keywords up-to-date improves discoverability.

It is common to include spaces following each separator semicolon. Spaces make the keywords easier to read in a single list, but recipients should not rely on either the presence or absence of spaces. Either is acceptable.

<SubjectHeadingText>Unity Church;Fallingwater;Taliesin;Guggenheim Museum</SubjectHeadingText>
<SubjectHeadingText>Unity Church; Fallingwater; Taliesin; Guggenheim Museum</SubjectHeadingText>

There should be only one repeat of the <Subject> composite with <SubjectSchemeIdentifier> code 20 (keywords), and therefore a <MainSubject/> flag is inappropriate. Note that the suggested limit of 500 characters in the P.12.6 <SubjectHeadingText> element is adequate for a practical set of at least 30 and up to perhaps 50 keywords, but not all recipients will accept that many – they may truncate the list and accept only a certain number, so put your ‘best’ keywords first. There is little practical value in long lists of more than perhaps 20 keywords.

And although <SubjectHeadingText> is repeatable within a single <Subject> composite, each keyword does not occupy an individual <SubjectHeadingText> element – keywords are provided in a single list, and the repeatability of <SubjectHeadingText> is intended solely for parallel lists of keywords in multiple languages. Normally, the ability to repeat <SubjectHeadingText> is not used, as there is little benefit in providing keywords in multiple languages, and although a few subject schemes provide heading text in multiple languages (UDC for example), there is little reason to provide <SubjectHeadingText> at all for standard schemes. In rare cases, keywords in multiple languages may be useful where the product itself uses multiple languages (eg a bilingual or parallel text edition). In this case, the language attribute must be included for each <SubjectHeadingText>.

Some keywords might deserve special weighting within the data recipient’s search algorithm. In particular, character names and possibly location names can be isolated and supplied in a separate keyword list, using codes B4 and B5. Note first that since these codes are relatively new, it would be worthwhile to repeat character and location names in the usual code 20 keyword list as well as in the code B4 and B5 lists. And note also that this does not replace the use of <NameAsSubject>, which should be used for the most important names – for example the subject of a biography or the protagonist of a novel.

Keywords are not intended for display to consumers. But occasionally, recipients do display the list of keywords, for example in a ‘tag cloud’ on a consumer–facing website, and this almost never causes a problem. Very rarely, where there is a particular strong reason to prevent public display of a keyword – for example, some keywords from a medical textbook might potentially cause offense if taken out of context – then certain keywords can be specified as not suitable for display, using <SubjectSchemeIdentifier> code B2. But note that use of code B2 should be exceptional. If code B2 is used, then other (potentially displayable) keywords should be provided using code 20 as usual, and for recipient’s indexing and search purposes, the two lists should be combined. It is not necessary to repeat words in both lists. Using code B2 for all keywords is likely to mean the keywords are ignored by many recipients.

For educational books, it may be useful to list specific alignments with common or national curricula, alongside the usual trade-focused subject schemes. This can be particularly valuable information for schools or teachers selecting resources for classroom use.

alignment with US Common Core State Standards and BISG Educational Objectives Taxonomy
using Reference names
<Subject>
    <MainSubject/>
    <SubjectSchemeIdentifier>10</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>2013</SubjectSchemeVersion>
    <SubjectCode>EDU029010</SubjectCode>
</Subject>
<Subject>
    <MainSubject/>
    <SubjectSchemeIdentifier>A4</SubjectSchemeIdentifier>
    <SubjectCode>CCSS.MATH.CONTENT.4.MD.A.1</SubjectCode>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>A4</SubjectSchemeIdentifier>
    <SubjectCode>CCSS.MATH.CONTENT.4.MD.A.2</SubjectCode>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>B1</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>1.0</SubjectSchemeVersion>
    <SubjectCode>EDTX530</SubjectCode>
</Subject>
<Subject>
    <SubjectSchemeIdentifier>B1</SubjectSchemeIdentifier>
    <SubjectSchemeVersion>1.0</SubjectSchemeVersion>
    <SubjectCode>EDTX550</SubjectCode>
</Subject>
using Short tags
<subject>
    <x425/>
    <b067>10</b067>BISAC subject scheme
    <b068>2013</b068>
    <b069>EDU029010</b069>Education / Teaching methods and materials / Maths
</subject>
<subject>
    <x425/>
    <b067>A4</b067>Common Core State Standards
    <b069>CCSS.MATH.CONTENT.4.MD.A.1​</b069>Relates particularly to requirements for Fourth Grade maths involving measurement and conversion of units
</subject>
<subject>
    <b067>A4</b067>
    <b069>CCSS.MATH.CONTENT.4.MD.A.2​</b069>…and to arithmetic problems involving distance, time, mass, volume etc
</subject>
<subject>
    <b067>B1</b067>BISG Educational Objectives Taxonomy
    <b068>1.0</b068>
    <SubjectCode>EDTX530</SubjectCode>Model with mathematics
</subject>
<subject>
    <b067>B1</b067>
    <b068>1.0</b068>
    <b069>EDTX550</b069>Perform contextualized problem solving using graphs, tables and equations
</subject>
The CCSS scheme uses the full dot notation rather than the abbreviated notation or URI/GUID options to identify CCSS learning requirements. This allows US state-specific variations of CCSS to be included as well, where they include compatible notations.

For locations, there are a number of coding schemes, including BIC or Thema Geographical qualifiers, BISAC Regional themes and GeoNames IDs.

incorporating a GeoName ID for a travel book featuring Brazzaville, Congo Republic
using Reference names
<Subject>
    <SubjectSchemeIdentifier>86</SubjectSchemeIdentifier>
    <SubjectCode>2260535</SubjectCode>
    <SubjectHeadingText>Brazzaville​</SubjectHeadingText>
</Subject>
using Short tags
<subject>
    <b067>86</b067>GeoNames ID
    <b069>2260535</b069>
    <b070>Brazzaville​</b070>
</subject>

It is a common error to try to use the <Subject> composite to specify the language of a book. Many subject schemes contain entries for languages (for example, Thema has a hierarchy of language qualifiers). These language entries should be used to describe the language the book is about, and the <Language> composite in Group P.10 should be used to specify the language the book is in. A book about the Japanese language may be written in (or translated into) English – so <Subject> would specify Japanese and <Language> would specify English.

Name as subject composite

Where a product is about or partly about a real person or organization – a biography, memoir, or corporate history, for example – then <NameAsSubject> should be used to carry the name of the subject of the product.

The structure of the <NameAsSubject> composite is essentially the same as the core parts of the <Contributor> composite in Group P.7, and the same best practices apply. The names of subjects can include name identifiers, and corporate names as well as personal names, and the composite can encompass alternative names, professional affiliations and the dates and places associated with the subject. For example, for a biography of George Orwell, a <NameAsSubject> composite with both a name and an alternative name could be supplied, carrying both his ‘real’ name Eric Blair and his pen name, as well as the ISNI identifiers 0000000368645684 and 0000000121441305.

Where a product is closely concerned with several people, then several repeats of <NameAsSubject> may be used. A historical examination of some event might list the key participants, but with a practical limit of around three to five names.

It is also possible to use <NameAsSubject> to carry the name of an entirely fictional character or organization, or of a fictionalized version of a real person or organization, for fiction, for a fiction companion, or in critical works. This usage should be reserved for just one or two main characters, and less important character names should be specified as keywords (using <SubjectSchemeIdentifier> codes B4 or 20).

Fictional names as subjects
Using Reference names
<NameAsSubject>
    <NamesBeforeKey>Tony</NamesBeforeKey>
    <KeyNames>Stark</KeyNames>
    <AlternativeName>
        <NameType>00</NameType>
        <KeyNames>Iron Man</KeyNames>
    </AlternativeName>
</NameAsSubject>
<NameAsSubject>
    <CorporateName>Stark Industries</CorporateName>
</NameAsSubject>
Using Short tags
<nameassubject>
    <b039>Tony</b039>
    <b040>Stark</b040>
    <alternativename>
        <x414>00</x414>
        <b040>Iron Man</b040>
    </alternativename>
</nameassubject>
<nameassubject>
    <b047>Stark Industries</b047>
</nameassubject>
These <NameAsSubject> composites could be included in the <Product> record for a graphic novel featuring the Marvel Comics character Iron Man, a fictional biography of Tony Stark/Iron Man, or even a critical study of Marvel Studios’ Iron Man films.

P.13 Audience

Group P.13 consists primarily of the <Audience> and <AudienceRange> composites, which provide a way of describing the intended readership – not necessarily the intended commercial market – for the product. To illustrate the difference, a picture book may be aimed at an audience 3- to 4-year old children, but the commercial target market is their parents. A textbook might be intended for an audience of Grade 7 school students, but the purchasers of the book would in most cases be their school.

Audience AudienceCodeType AudienceCodeType AudienceCodeTypeName AudienceCodeTypeName AudienceCodeValue AudienceCodeValue AudienceRange AudienceRangeQualifier AudienceRangeQualifier AudienceRangePrecision AudienceRangePrecision AudienceRangeValue AudienceRangeValue AudienceRangePrecision AudienceRangePrecision AudienceRangeValue AudienceRangeValue
simple audience description using only an ONIX code
using Reference names
<Audience>
    <AudienceCodeType>01</AudienceCodeType>
    <AudienceCodeValue>06</AudienceCodeValue>
</Audience>
using Short tags
<audience>
    <b204>01</b204>Using ONIX audience codes
    <b206>06</b206>Professional and scholarly
</audience>
The ONIX audience code from List 28 can be delivered using the <AudienceCode> data element, but using the <Audience> composite is strongly preferred. Use of the <AudienceCode> element is deprecated.
book generally suitable for adults, but with a content warning
using Reference names
<Audience>
    <AudienceCodeType>01</AudienceCodeType>
    <AudienceCodeValue>01</AudienceCodeValue>
</Audience>
<Audience>
    <AudienceCodeType>22</AudienceCodeType>
    <AudienceCodeValue>04</AudienceCodeValue>
</Audience>
using Short tags
<audience>
    <b204>01</b204>Using ONIX audience codes
    <b206>01</b206>Non-specialist adult audience
</audience>
<audience>
    <b204>22</b204>ONIX Adult audience rating
    <b206>04</b206>Content warning (violence)
</audience>
ONIX Adult audience ratings from List 203 are intended to be applied by the publisher only when the content is likely to offend a particular section of the adult audience. It is not the intent that every romance has a ‘sexual content’ warning, or every thriller a ‘violence’ warning. If a book is suitable for a juvenile or young adult audience (codes 02 or 03 from List 28, or their equivalent in other schemes) a content warning is never appropriate, nor are content warnings appropriate in educational or professional settings.
multiple coded audience descriptions
using Reference names
<Audience>
    <AudienceCodeType>01</AudienceCodeType>
    <AudienceCodeValue>03</AudienceCodeValue>
</Audience>
<Audience>
    <AudienceCodeType>23</AudienceCodeType>
    <AudienceCodeValue>C2</AudienceCodeValue>
</Audience>
<Audience>
    <AudienceCodeType>02</AudienceCodeType>
    <AudienceCodeTypeName>BookBag Audience Group</AudienceCodeTypeName>
    <AudienceCodeValue>BB-LM</AudienceCodeValue>
</Audience>
using Short tags
<audience>
    <b204>01</b204>ONIX audience code
    <b206>03</b206>Young adult
</audience>
<audience>
    <b204>23</b204>Common European Framework for Language Learning
    <b206>C2</b206>
</audience>
<audience>
    <b204>02</b204>Proprietary code
    <b205>BookBag Audience Group</b205>
    <b206>BB-LM</b206>
</audience>
senior year college textbook
using Reference names
<Audience>
    <AudienceCodeType>01</AudienceCodeType>
    <AudienceCodeValue>05</AudienceCodeValue>
</Audience>
<AudienceRange>
    <AudienceRangeQualifier>11</AudienceRangeQualifier>
    <AudienceRangePrecision>01</AudienceRangePrecision>
    <AudienceRangeValue>16</AudienceRangeValue>
</AudienceRange>
using Short tags
<audience>
    <b204>01</b204>Using ONIX audience codes
    <b206>05</b206>College/Higher education
</audience>
<audiencerange>
    <b074>11</b074>US school grade range
    <b075>01</b075>Exact
    <b076>16</b076>College Senior
</audiencerange>
audience description for a primary/elementary education product
using Reference names
<Audience>
    <AudienceCodeType>01</AudienceCodeType>
    <AudienceCodeValue>04</AudienceCodeValue>
</Audience>
<AudienceRange>
    <AudienceRangeQualifier>17</AudienceRangeQualifier>
    <AudienceRangePrecision>03</AudienceRangePrecision>
    <AudienceRangeValue>12</AudienceRangeValue>
    <AudienceRangePrecision>04</AudienceRangePrecision>
    <AudienceRangeValue>14</AudienceRangeValue>
</AudienceRange>
<AudienceRange>
    <AudienceRangeQualifier>18</AudienceRangeQualifier>
    <AudienceRangePrecision>03</AudienceRangePrecision>
    <AudienceRangeValue>9</AudienceRangeValue>
    <AudienceRangePrecision>04</AudienceRangePrecision>
    <AudienceRangeValue>10</AudienceRangeValue>
</AudienceRange>
<Complexity>
    <ComplexitySchemeIdentifier>06</ComplexitySchemeIdentifier>
    <ComplexityCode>HL680L</ComplexityCode>
</Complexity>
using Short tags
<audience>
    <b204>01</b204>Using ONIX audience codes
    <b206>04</b206>Primary and secondary/elementary and high school
</audience>
<audiencerange>
    <b074>17</b074>Interest age
    <b075>03</b075>From
    <b076>12</b076>Age 12
    <b075>04</b075>To
    <b076>14</b076>Age 14
</audiencerange>
<audiencerange>
    <b074>18</b074>Reading age
    <b075>03</b075>From
    <b076>9</b076>Age 9
    <b075>04</b075>To
    <b076>10</b076>Age 10
</audiencerange>
<complexity>
    <b077>05</b077>Lexile measure
    <b078>HL680L</b078>‘high-low’ title
</complexity>
This is a so-called ‘high-low’ title with an interest age higher than the reading age, suitable for reluctant readers.
Audience composite

Specifying the ‘ONIX-style’ intended audience using <Audience> is strongly preferred to using <AudienceCode>. Use <AudienceCodeType> code 01 from List 29, and the relevant value from the ONIX Audience code list, List 28.

The <Audience> composite must include an <AudienceCodeType> and an <AudienceCodeValue>.

For a proprietary audience code scheme, <AudienceCodeType> code 02 from List 29, a consistent name for the scheme should be included in <AudienceCodeTypeName>, and the meanings of the code values in the scheme must be shared in advance with the data recipients.

For products aimed at a general adult audience only (not those aimed at young adults, or those intended to be used in an educational or academic context), an additional content rating may also be supplied, using List 203. When it is supplied by the publisher, this rating can help libraries provide improved automated selections to their borrowers, or inform retailers that the product may require sensitive or specialist merchandising.

Audience range composite

Like the <Audience> composite, <AudienceRange> describes the intended readership of the product. The difference is that <AudienceRange> is intended to carry considerably more detailed specification of the suitability of a product, particularly for children and within school education.

<AudienceRange> and some audience coding schemes may reflect a separation between the ‘interest age’ of a product and the ‘reading age’ of the intended audience. Reading age is primarily a proxy measure of the complexity of the text and its relative difficulty of comprehension, and Interest age is a measure of the appeal of the subject matter of the text. With most products, the two are broadly aligned – a book of interest to seven year olds is usually written in a style suitable for seven year olds. However, the two diverge when books are intended for ‘reluctant readers’ or for emergent adult literacy, where the subject matter may be of interest to an age group notably above the reading age of the text. Titles for teenage reluctant readers may well tackle typical teen or young adult subject matter, but using language that is more normally appropriate for say, an eleven-year old.

General products (not specifically educational) aimed at a children’s or young adult audience should specify reading age and/or interest age rather than calendar age. Educational products (including those intended for home-schooling) can be specified similarly in terms of reading and/or interest age, or more specifically in terms of school year or grade within various national education systems. School year or grade is preferred where the product is closely related to a defined curriculum (primarily, textbooks), and reading/​interest age if the product is a more general title for independent reading. Formal or quantitative measures of text complexity – based on intrinsic features of the text such as word length, sentence construction and vocabulary – can also be specified, in the <Complexity> composite.

When providing audience age or grade ranges, data suppliers should be as precise as possible – ranges on children’s or educational material should rarely exceed two years at the lower end of the age range, reflecting the core appeal or purpose of the content of the product. The range can be wider, perhaps three or four years, at the upper end of the children’s age range. An overly broad range – say, ages 6–11, or grades 2–7 – or open-ended ranges such as ‘ages 6+’ or ‘up to grade 7’ are much less realistic and are considerably less useful to the data recipient than a narrow range of ‘ages 8–9’. However an open-ended range such as 12+ that shades into young adult can be useful for certain types of book. Do not use overly broad ranges such as 6–11 even if the book might be applicable to a few 6- or 11-year-olds – limit the range to the core audience for the book.

Complexity composite

The <Complexity> composite is used to convey specific quantitative measures of text complexity or other objective ‘leveling’ assessments. Such information is used to select suitable material for teaching reading, matching books to the reading ability of the learner. The leveling may be carried out by the publisher – usually according to a third-party formula – or by an assessment agency. Since different educators tend to prefer different leveling schemes, it is common to provide multiple complexity measures using repeats of the <Complexity> composite.

Typical leveling or readability metrics take account of average word length or syllable count, sentence length, word frequencies such as the ratio of rare to common words, and sometimes the complexity of the sentence construction or grammar and the use of specific graded vocabularies. Presence or absence of illustrations, signposting and design, and any intertextual dependencies can also be taken into account.

A particular educational aim of some schemes is to highlight books whose text level is mismatched to its subject matter – for example where the reading age is well below or well above the interest age – as these books are particularly suitable for reluctant or advanced readers. For example, the Lexile scheme labels some books as HL (high interest age, low reading age, for reluctant readers) or NC (non-conforming, where the text and vocabulary is above the interest age of the subject matter).

Complexity ComplexitySchemeIdentifier ComplexitySchemeIdentifier ComplexityCode
ATOS text complexity scheme
using Reference names
<Complexity>
    <ComplexitySchemeIdentifier>07</ComplexitySchemeIdentifier>
    <ComplexityCode>7.6</ComplexityCode>
</Complexity>
using Short tags
<complexity>
    <b077>07</b077>ATOS for Books scheme, used in
    <b078>7.6</b078>Accelerated Reader scheme
</complexity>
<Complexity> was previously deprecated in ONIX 3.0, but that deprecation has now been removed. It is the recommended way of communicating formal or quantitative measures of text complexity or reading difficulty using metrics such as Lexile, Fountas and Pinnell or the Fry Readability formula.

Block 2: Marketing collateral detail

Collateral detail composite

The supply of rich descriptive and illustrative collateral material for each product is fundamental to the business rationale for ONIX.

Block 2 is intended to carry information related to marketing material associated with a product. This collateral material may be intended for either business-to-business use or business-to-consumer use – it may be aimed at the distributor’s sales team or wholesaler buyer, at the retailer or the retailer’s customer, at the librarian or the library reader. This material may include a variety of descriptive text, sample images or pages from the product, or links to material such as published reviews. Three different types of collateral material may be used:

  • P.14 <TextContent> composites contain descriptive text that is included within the ONIX message itself;
  • P.15 <CitedContent> composites contain links to third-party cited content such as published reviews;
  • P.16 <SupportingResource> composites contain links to first-party supporting resources such as sample images or pages.

The provision of rich descriptive and illustrative collateral material for each product is fundamental to the business rationale for ONIX. It’s use in an online consumer-facing context is clear, where descriptive metadata is a key part of engaging the customer with your product. But equally, buyers for wholesalers, retailers and libraries all need to understand the products they are purchasing.

CollateralDetail TextContent CitedContent SupportingResource SupportingResource Prize must include at least one, unless product record is a partial or ‘block update’ (when <CollateralDetail/> may be empty in order to ‘delete’ previously supplied data)

Note that whatever collateral materials are included or linked to, they are normally assumed to be ‘globally’ applicable – that is, they are not intended to be specific to individual geographical markets, and can be used wherever the product is for sale. However, <TextContent>, <CitedContent> and <SupportingResource> may each include the <Territory> composite, to indicate specific collateral material is geographically targeted. So for example, ONIX can support the provision of different, geographically-tailored long descriptions or front cover images for each market (where the individual markets themselves can be specified in the same way, with <Territory>, in Block 6).

P.14 Descriptions and other supporting text

TextContent TextType ContentAudience Territory Text ReviewRating TextAuthor TextSourceCorporate TextSourceCorporate SourceTitle ContentDate
brief product summary, formatted back cover copy and celebrity endorsement
using Reference names
<TextContent>
    <TextType>02</TextType>
    <ContentAudience>00</ContentAudience>
    <Text textformat="05"><p>The essential pocket guide to UML 2.0, now updated to cover the very latest in UML.</p></Text>
</TextContent>
<TextContent>
    <TextType>05</TextType>
    <ContentAudience>00</ContentAudience>
    <Text textformat="05"><p>Dan Pilone’s <em>UML 2.0 Pocket Reference</em> is a handy-sized aid for software developers who use the Unified Modelling Language.</p><p>Updated to cover the very latest in UML, it includes coverage of all the main UML diagram types:</p>​<ul>​<li>Class diagrams</li>​<li>Component diagrams</li>​<li>Sequence diagrams</li>​<li>Communication diagrams</li>​<li>Deployment diagrams</li>​<li>Use case diagrams</li>​<li>State diagrams</li>​</ul>​<p><em>UML 2.0 Pocket Reference</em> is intended for developers who are already familiar with UML, and provides a convenient, detailed reference guide.</p></Text>
</TextContent>
<TextContent>
    <TextType>09</TextType>
    <ContentAudience>00</ContentAudience>
    <Text textformat="05"><p>‘There no better quick reference guide for UML modellers.’​</p>​</Text>
    <TextAuthor>Richard Ayton, CEO, Universal Consulting LLP</TextAuthor>
</TextContent>
using Short tags
<textcontent>
    <x426>02</x426>Short description
    <x427>00</x427>For any audience
    <d104 textformat="05"><p>The essential pocket guide to UML 2.0, now updated to cover the very latest in UML.​</p>​</d104>
</textcontent>
<textcontent>
    <x426>05</x426>Flap / cover copy
    <x427>00</x427>For any audience
    <d104 textformat="05">
        <p>Dan Pilone’s <em>UML 2.0 Pocket Reference​</em> is a handy-sized aid for software developers who use the Unified Modelling Language.​</p>XHTML split over several lines for clarity only
        <p>Updated to cover the very latest in UML, it includes coverage of all the main UML diagram types:</p>​
        <ul>​
            <li>Class diagrams</li>​
            <li>Component diagrams</li>​
            <li>Sequence diagrams</li>​
            <li>Communication diagrams</li>​
            <li>Deployment diagrams</li>​
            <li>Use case diagrams</li>​
            <li>State diagrams</li>​
        </ul>​
        <p><em>UML 2.0 Pocket Reference</em> is intended for developers who are already familiar with UML, and provides a convenient, detailed reference guide.</p>
    </d104>
</textcontent>
<textcontent>
    <x426>09</x426>Endorsement
    <x427>00</x427>For any audience
    <d104 textformat="05"><p>‘There no better quick reference guide for UML modellers.’​</p>​</d104>
    <d107>Richard Ayton, CEO, Universal Consulting LLP</d107>
</textcontent>
The short description and endorsement could have been provided without a textformat attribute – they contain (effectively) no markup, and the default is unformatted text. However, the cover copy requires markup such as the XHTML shown to format the multiple paragraphs and bulleted list, so the attribute must be specified.
The XHTML content in the Short tags example is formatted with extra line breaks and indented for clarity only – the unbroken XHTML in the Reference names example is exactly equivalent, except that extra white space characters (line breaks, tabs or spaces) have been added to the content of the <d104> tag. The XHTML tags and any extra white space are treated as data content by recipients, not as markup and will therefore count against any limitations on the length of text that can be stored by the recipient. As a result, the unbroken form used in the Reference example is preferred.
Although XHTML itself allows the use of named character entities like &eacute; or &euro; (for é and €), they are not allowed within ONIX textual data with textformat 05. You can use the native characters (providing they are available in whatever encoding you declared at the top of the ONIX file) or equivalent numeric entities &#233; and &#8364; (or the hexadecimal equivalents &#xe9; or &#x20ac;).
Text content composite

The <TextContent> composite is the only constituent of Group P.14, and since it is optional, P.14 can be omitted if no collateral text is available. This is likely if an initial Product record is released several months in advance of publication. As descriptive text is written and approved, it should be added to the Product record, and an updated ONIX message distributed.

P.14.1 Text type code

Within each repeat of the <TextContent> composite, a <TextType> data element is mandatory, to signal the type of text included in <Text>.

Multiple repeats of the <TextContent> composite can be used to carry different types of descriptive text, distinguished by different code values from List 153 in the <TextType> data element, and possibly also by different code values from List 154 in <ContentAudience> (so short descriptions can be aimed at separate trade and consumer audiences).

Short and long descriptions of the book – the former limited to about 50 words or more specifically, to 350 characters – should give the potential purchaser a sense of the content of the book. For fiction, give a description of the narrative and key characters and themes (without giving away too much of the plot). For non-fiction, include an overall summary of the content. Pick out features that make the book interesting or different. Back cover copy is often suitable. But avoid hyperbole. Avoid time-sensitive descriptions such as ‘the latest book by…’, unless you are able to ensure the description will be updated when it’s no longer the latest. And avoid anything that isn’t straightforward description. If you have a review or the table of contents, supply it as review text or as a table of contents, not within the description.

In addition to the short and long descriptions, it is good practice to supply additional text types:

  • promotional headline (code 10), a single line of promotional text that might be used by a retailer on its own, or to headline either short or long description;
    • text such as ‘The summer’s most gripping read’ or ‘Bestselling book club selection’ should be sent as a promotional headline;
    • whenever possible, data recipients should display the promotional headline prominently to consumers;
      • this encourages data senders to follow best practice, keeping promotional messages out of key bibliographic fields such as <Subtitle>;
    • many data senders modify this promotional headline text very frequently throughout the life of the product;
  • table of contents (code 04), particularly valuable for non-fiction products;
    • use the <ContentDetail> composite (which constitutes Block 3) instead when a more detailed and structured description of the contents is required – for example where the authorship of each chapter is important, or where the product is an omnibus edition;
  • review quotes (codes 06, 07 or 08) and endorsements (code 09);
    • reviews and endorsements should be provided with one review quote or endorsement per <TextContent> composite. It is a common error to combine several short review quotes into a single <Text> element (although sometimes this is unavoidable due to limitations within legacy data management systems);
    • for review quotes and endorsements, the text in <Text> should include appropriate quotation marks;
      • use the marks suitable for the language of the quotation itself – for example ‘…’ or “…” for English, « … » for French, „…“ or ‚…‘ for German, and 「…」 or 『…』 for Japanese;
    • quotations should be short, and suitable for promotional use without further permission from the copyright holder;
    • where multiple quotations are provided, the order of the quotations is not significant (though equally, data recipients have little reason to change the order, and those that accept only a limited number may ignore those provided last);
    • review quotes, endorsements and other text not authored by the publisher should be accompanied by a <TextAuthor> data element and – particularly for reviews – by a <SourceTitle> element;
  • biographical note (code 12), a combined biography of multiple contributors (but see the <BiographicalNote> element in Group P.7 for the biography of a single contributor. It is a common error to include a single contributor’s biography in Group P.14).

For some values of <TextType> there should be only a single <TextContent> composite. For some other text types, multiple <TextContent> composites can be included so long as their <ContentAudience> codes differ. For the remaining types, multiple <TextContent> composites can be included with the same or different audiences:

  • one – only a single <TextContent> composite with a <TextType> of 04 or 15 etc and <ContentAudience> 00 is expected, since the table of contents or index clearly cannot be varied by audience. This would apply to text types 04, 05, 15, 19, 20, 21;
  • one per audience – there may be multiple <TextContent> composites with a <TextType> of 02 or 03 (short or long description), but each should have a unique <ContentAudience> and/or <Territory> – so typically, either a single composite of a specific type for an unrestricted general audience, or one intended for an end-customer audience plus one tailored for the trade or press, or one intended for use in the Americas and one intended for use elsewhere etc would be included. As far as possible the audiences should not overlap. This would apply to text types 02, 03, 10, 12, 16, 17;
  • multiple – there may be multiple <TextContent> composites with a <TextType> of 06 or 09 and <ContentAudience> of 00, since for example there may be several reviews or endorsements intended for the general audience, or multiple publisher statements for the booktrade audience. This would apply to text types 06, 07, 08, 09, 11, 13, 14, 18, 22.

Where a specific item of text is intended for multiple audiences, <ContentAudience> is repeatable.

There is no upper limit on the length of the <Text> element, and depending on the type of text – a review, a long description, a combined biography of several contributors, a table of contents or an excerpt from the work itself – typical lengths vary. Short descriptions have an explicit limit of 350 characters (which is about 50 words in English). Promotional headlines, open access and digital exclusivity statements are not explicitly limited, but senders might in practice apply a limit of 150 characters (perhaps 20 words in English). Review quotations, endorsements and feature text are usually also quite short, though again not explicitly limited: a practical limit of 1000 characters (around 150 words in English) might be reasonable for senders to apply. Long descriptions and combined biographies are typically 200–400 words (or 1500–3000 characters), and a practical upper limit of 5000 characters might be reasonable for senders. Tables of contents are also unlikely to require a greater number of characters than this.

It is also possible to include a substantial excerpt of text from the product – for example the text of a first chapter, or the entire index. However, it is unreasonable to expect recipients to accept an unlimited amount of text: it is good practice to limit each excerpt <Text> element to 25,000 characters or fewer – around 3500 words in English. For larger excerpts, prior discussion with the data recipient is likely to be necessary.

Short review quotations are likely to be covered by acceptable ‘fair use’ or ‘fair dealing’ – quoting a single sentence of a review is generally fine without having to seek permission. But quoting a whole review article, or a substantial section of a review, would generally require permission to be sought from the original publisher or author of a review, and such review text should not be included in the ONIX unless permission has been obtained. (In contrast, linking to a review using Group P.15 does not require permission, but is not as often used by ONIX recipients.)

If a short description contains embedded markup (XHTML or HTML, though the former is strongly preferred), the markup counts as a part of the data – and thus must count against the 350 character limit for short descriptions. For example:

<Text textformat="05"><p>Some text.</p></Text>

contains 17 characters of data, not 10. And depending on details of the recipient’s system, any leading or trailing spaces may count too, so avoid them.

The 350 character length limit on short descriptions is fixed. For other text types, there are no fixed limits, but practical limits for senders are suggested – and delimiters such as the semicolons within a list of keywords or any embedded XHTML or HTML markup count towards these practical limits too.

Length limits are specified in characters, not bytes, as character limits are independent of the technical details of the sender and recipient systems. The number of bytes required varies according to the character encoding and the language. For example, plain English text in UTF‑8 requires just a little more than one byte per character. Other Latin-script languages need up to about 1.5 bytes per character. Languages like Russian or Arabic require around two bytes per character, and East Asian languages (eg Chinese, Japanese, Korean) around 2.5 or three bytes per character. Text stored in UTF‑16 will require the same or slightly fewer bytes for most scripts, but up to twice as many for simple English).

A few text type codes carry special significance, in particular any Open Access statement (code 20) or statement of digital exclusivity (code 21). The very presence of these codes acts as a ‘flag’ to indicate some kind of open access or digital exclusivity. Note that the text in the <Text> element may not be blank – the <Text> element is mandatory, and may not be empty – but it may be minimal. The text should be suitable for display to the expected audience, and might simply say ‘Open access’ or ‘Digital exclusive’, or it may give further details, for example noting the type of open access (‘Available under a Creative Commons CC-By v4.0 license’) or the limits of exclusivity (‘Exclusively available as an EPUB until 15th May’). The latter – the ending of digital exclusivity – should also be confirmed with a <ContentDate> composite.

Digital exclusive
using Reference names
<TextContent>
    <TextType>21</TextType>
    <ContentAudience>00</ContentAudience>
    <Text>Exclusively available as an EPUB until 15th May</Text>
    <ContentDate>
        <ContentDateRole>15<ContentDateRole>
        <Date>20140515</Date>
    </ContentDate>
</TextContent>
using Short tags
<textcontent>
    <x426>21</x426>Digital exclusivity
    <x427>00</x427>For any audience
    <d104>Exclusively available as an EPUB until 15th May</d104>
    <contentdate>
        <x429>15<x429>Until
        <b306>20140515</b306>
    </contentdate>
</textcontent>
In the example, digital exclusivity lasts until 15th May. It could reasonably be assumed that the publication date of a related print product is 16th May.

Another specialized text type is a JSON‑LD data snippet that can contain schema.org data that can be embedded in HTML web pages about the product created by the recipient. In this case, using a ready-made JSON‑LD snippet created by the data supplier reduces the technical knowledge required of the recipient. The supplier can help the recipient improve the search ranking of the recipient’s web page and thus the discoverability of the supplier’s products. However, it is important that recipients ensure the supplied snippet contains only JSON data, as any executable JavaScript code could raise security issues.

Providing a schema.org snippet
using Reference names (JSON formatted for clarity)
<TextContent>
    <TextType>24</TextType>
    <ContentAudience>09</ContentAudience>
    <Text>
        {
            "@context" : "http://schema.org/",
            "@type"    : "Book",
            "name"     : "The Mill on the Floss",
            "isPartOf" : {
                "@type" : "BookSeries",
                "name"  : "Penguin Classics"
                },
            "author"   : {
                "@type"      : "Person",
                "givenName"  : "George",
                "familyName" : "Eliot"
                }
        }
    </Text>
</TextContent>
using Short tags
<textcontent>
    <x426>24</x426>schema.org snippet
    <x427>09</x427>for search engine use
    <d104>{ "@context" : "http://schema.org/","@type" : "Book","name" : "The Mill on the Floss","isPartOf" : { "@type" : "BookSeries","name" : "Penguin Classics" },"author" : { "@type" : "Person","givenName" : "George","familyName" : "Eliot" } }</d104>
</textcontent>
This snippet of JSON data would be inserted into a web page within an HTML <script> tag as below. The braces, colons and commas in the snippet are all critical parts of the JSON syntax, and the JSON data must be encoded using Unicode. The syntax can be tested with Google’s Structured Data Testing Tool (https://search.google.com/structured-data/testing-tool).
<script type="application/ld+json">{ "@context" : "http://schema.org/", "@type" : "Book", "name" : "The Mill on the Floss", "isPartOf" : { “@type": "BookSeries", "name" : "Penguin Classics" }, "author" : { "@type" : "Person", "givenName" : "George", "familyName" : "Eliot" } }</script>

For textbooks linked to specific course or exam, it’s possible to name the course or exam and – importantly – the body responsible for the endorsement or official recommendation to use that textbook, typically the examination board or qualification awarding body. Because exams and curricula may change, this can also be linked to a date for the first or last exam year to which the textbook is applicable.

Supplying exam, examination board and date or year of first exam
using Reference names
<TextContent>
    <TextType>22</TextType>
    <ContentAudience>00</ContentAudience>
    <Text>For IGCSE Geography</Text>
    <TextSourceCorporate>Edexcel<TextSourceCorporate>
    <ContentDate>
        <ContentDateRole>31</ContentDateRole>
        <Date>20180601</Date>
    </ContentDate>
</TextContent>
using Short tags, specifying only a year
<textcontent>
    <x426>22</x426>
    <x427>00</x427>
    <d104>For IGCSE Geography</d104>Name or title of course or examination
    <b374>Edexcel<b374>Exam board
    <contentdate>
        <x429>31</x429>Associated start date (first exam year)
        <b306 dateformat="05">2018</b306>
    </contentdate>
</textcontent>
Provision of curriculum, course or examination detail like this is not a substitute for detailed subject and audience range detail in P.12 and P.13. However, using <TextContent> provides a way of naming official bodies endorsing textbooks for specific exams.
In the case of a product being recommended by multiple bodies for a single course or exam, list the bodies, comma-separated, in a single <TextSourceCorporate> element. Where a product is suitable for multiple courses or exams, treat each separately in repeats of <TextContent>.
P.14.2 Text audience

The <ContentAudience> element must be used to specify that the text in a particular repeat of the <TextContent> composite is intended for a specific audience – typically, most text supplied is unrestricted and suitable for all audiences, but the <ContentAudience> code is particularly important where the text is intended exclusively for trade or press use, or where the text has been tailored for a specific set of potential customers – teachers, students or librarians for example.

It is particularly valuable to provide short and/or long descriptions tailored for use within the trade (ie a business-to-business description of the product), and separate descriptions tailored for presentation to the end customer.

Separate descriptions for trade and consumer audiences
using Reference names
<TextContent>
    <TextType>02</TextType>
    <ContentAudience>03</ContentAudience>
    <Text>The latest fantasy novel from children’s author Claudia Monteverde.</Text>
</TextContent>
<TextContent>
    <TextType>02</TextType>
    <ContentAudience>02</ContentAudience>
    <Text>Published to coincide with promotion around release of the animated movie.</Text>
</TextContent>
using Short tags
<textcontent>
    <x426>02</x426>Short description
    <x427>03</x427>For end customers
    <d104>The latest fantasy novel from children’s author Claudia Monteverde.</d104>
<textcontent>
<textcontent>
    <x426>02</x426>Short description
    <x427>02</x427>For book trade
    <d104>Published to coincide with promotion around release of the animated movie.<d104>
<textcontent>

Recipients of ONIX data must take great care that when an audience is specified, they limit visibility of the text to that particular audience. If a recipient cannot do this because of limitations in their internal systems, then they should ignore any text provided that is not marked as Unrestricted or for general end-customer use (codes 00 or 03 in List 154).

The <ContentAudience> element is repeatable, so for example, text intended for librarians and teachers – but not students – can be specified without using separate repetitions of <TextContent>.

Territory composite

The <Territory composite is used to specify that the text is intended only for use in a specific market or range of countries and regions. Its structure is identical to that in Group P.21

For example, a book may have separate long descriptions, both aimed at the consumer audience, in Castilian and Mexican (or Latin American) varieties of Spanish. Now the <Text> element may be repeated for parallel text in different languages within a single <TextContent> composite – but the text may not be parallel, the available language codes do not distinguish between Castilian and Mexican Spanish, and the Mexican Spanish version may well be intended for use throughout Latin America rather than just in Mexico. In this case, two separate <TextContent> composites can be used, with <Territory> composite used to target one at a specific market.

Note that the <Territory> need not align with a particular market as specified in P.24, though it may often do so. Data senders should take care to avoid inadvertently targeting more than one long description (or other text type where only one instance is appropriate) at a particular country.

Note also that one <TextContent> composite (for a particular text type) should be left without a <Territory>, for use in ‘all other countries’. Faced with a number of short descriptions, for example, recipients should first try to select the one that is specifically targeted for use in the appropriate country, and use the one without a <Territory> composite if no targeted version is available.

Targeted Castilian and Mexican Spanish descriptions
using Reference names
<TextContent>
    <TextType>02</TextType>
    <ContentAudience>00</ContentAudience>
    <Text>… Ellos usan el ordenador…</Text>
</TextContent>
<TextContent>
    <TextType>02</TextType>
    <ContentAudience>00</ContentAudience>
    <Territory>
        <CountriesIncluded>AR BO CA CL CR CU DO EC GT HN MX NI PA PE PR PY SV US UY VE</CountriesIncluded>
    </Territory>
    <Text lang="spa">… Ellos usan la computadora…</Text>
    <Text lang="eng">… They use the computer…</Text>
</TextContent>
using Short tags
<textcontent>
    <x426>02</x426>Short description
    <x427>00</x427>For any audience
    <d104>… Ellos usan el ordenador…</d104>Castilian Spanish
</textcontent>
<textcontent>
    <x426>02</x426>Short description
    <x427>00</x427>For any audience
    <territory>Within the
        <x449>AR BO CA CL CR CU DO EC GT HN MX NI PA PE PR PY SV US UY VE</x449>Spanish-speaking countries in the Americas
    </territory>
    <d104 lang="spa">… Ellos usan la computadora…</d104>Latin-American Spanish
    <d104 lang="eng">… They use the computer…</d104>… or English
</textcontent>
In this example, a data recipient in a Spanish-speaking country in the Americas (ie a recipient within the targeted territory) should choose to use one of the language options in the second <TextContent> composite – and in most cases would probably choose ‘la computadora’. A data recipient in the US (which is within the targeted territory) could choose either ‘la computadora’ or the English equivalent text. A data recipient elsewhere in the world (ie a recipient outside the targeted territory) should use the Castilian option in the first <TextContent> composite. A data recipient in Spain (outside the targeted territory) should choose ‘el ordenador’.
P.14.3 Text

Every <TextContent> composite requires a <Text> element.

Text included in the <Text> element comes with an express invitation for the data recipient to use it for purposes of marketing or sale of the product. Senders including text items such as review excerpts, where rights in the text are controlled by a third party, should ensure that the excerpts are sufficiently short that they do not infringe those rights.

Simple textual material can be provided as plain text, either without a textformat attribute, or by including the attribute with value 06 (plain text). However, because of the differing XML treatment of white space characters (including tabs, line feeds and carriage returns) among different XML parsers and in different databases, multi-paragraph text or other formatting cannot reliably be delivered into a recipient’s system. For this reason, this and some other ONIX data elements can accept not only plain text but also text with embedded XHTML markup (with textformat code 05) or embedded HTML markup (with textformat code 02). If you wish to deliver multi-paragraph text or other formatting, then you must include some markup within this data element, and XHTML is strongly preferred to HTML (or other XML).

What XHTML markup can be embedded? The ONIX schema allows anything that XHTML 1.1 itself allows inside an XHTML document <body>, excluding forms, scripts, event attributes or other ‘active’ elements, and excluding special characters as named entity references. In practice, ONIX recipients are unlikely to accept such a broad range of markup, given that they are likely to embed the provided data in their own web pages. So stick to the very simplest markup: see the notes in P.7.42 for details.

Using simple XHTML markup makes it possible to provide a formatted table of contents for the product or a version history for an e‑book that has been updated:

providing a simple table of contents (explicit numbering provided)
using Reference names – XHTML formatted for clarity
<TextContent>
    <TextType>04</TextType>
    <ContentAudience>00</ContentAudience>
    <Text textformat="05">
        <ul>
            <li>Preface</li>
            <li>Chapter I – Living things</li>
            <li>Chapter II – The plant kingdom</li>
            <li>Chapter III – Historical survey</li>
            <li>Chapter IV – The flowering plant</li>
            <li>Chapter V – Special forms and functions of plant organs</li>
            <li>Chapter VI – Food of living things</li>
            <li>Chapter VII – Some other plant products</li>
            <li>Chapter VIII – Enzyme action and digestion</li>
            <li>Chapter IX – Protoplasm and the colloidal state</li>
            <li>Chapter X – Internal organization of living things</li>
            <li>. . .</li>
            <li>Chapter XXX – Classification of angiosperms</li>
            <li>Index</li>
        </ul>
    </Text>
</TextContent>
using Short tags – XHTML compacted for efficiency
<textcontent>
    <x426>04</x426>Table of contents
    <x427>00</x427>For any audience
    <d104 textformat="05">​<ul>​<li>Preface​</li>​<li>Chapter I – Living things​</li>​<li>Chapter II – The plant kingdom​</li>​<li>Chapter III – Historical survey​</li>​<li>Chapter IV – The flowering plant​</li>​<li>Chapter V – Special forms and functions of plant organs​</li>​<li>Chapter VI – Food of living things​</li>​<li>Chapter VII – Some other plant products​</li>​<li>Chapter VIII – Enzyme action and digestion​</li>​<li>Chapter IX – Protoplasm and the colloidal state​</li>​<li>Chapter X – Internal organization of living things​</li>​<li>. . .​</li>​<li>Chapter XXX – Classification of angiosperms​</li>​<li>Index​</li>​</ul>​</d104>
</textcontent>
providing a nested table of contents (with automatic numbering)
using Reference names – XHTML formatted
<TextContent>
    <TextType>04</TextType>
    <ContentAudience>00</ContentAudience>
    <Text textformat="02">
        <![CDATA[<ol type="I">Use Roman numerals
            <li>Introduction</li>
            <li>Context and objectives
                <ol>
                    <li>The skills gap</li>
                    <li>The technological environment</li>
                    <li>Providing the means</li>
                </ol>
            </li>
            <li>Methodology
                <ol start="4">Continue numbering
                    <li>Defining terminologies</li>
                    <li>The semantic web</li>
                </ol>
            </li>
            <li>. . .</li>
        </ol>]]>
    </Text>
</TextContent>
using Short tags – XHTML compacted
<textcontent>
    <x426>04</x426>
    <x427>00</x427>
    <d104 textformat="02"><![CDATA[<ol type="I"><li>Introduction</li><li>Context and objectives<ol><li>The skills gap</li><li>The technological environment</li><li>Providing the means</li></ol></li><li>Methodology<ol start="4"><li>Defining terminologies</li><li>The semantic web</li></ol></li><li>. . .</li></ol>]]></d104>
</textcontent>

The table of contents should render like this:

  1. Introduction
  2. Context and objectives
    1. The skills gap
    2. The technological environment
    3. Providing the means
  3. Methodology
    1. Defining terminologies
    2. The semantic web
  4. . . .

Note the use of the type attribute to control the use of upper-case Roman numerals in the outer ordered list, and the start attribute to avoid restarting the minor numbering at 1 in the second inner ordered list. Currently, this use of start and style attributes will only work in combination with CDATA. Ordered and unordered lists (using <ol>, <ul> and <li> tags), and definition lists (using the <dl>, <dt> and <dd> tags), can be nested as necessary to produced complex Tables of contents structures.

providing a version history
using Reference names
<EditionNumber>3</EditionNumber>
<EditionVersionNumber>0.2</EditionVersionNumber>
. . .
<TextContent>
    <TextType>19</TextType>
    <ContentAudience>00</ContentAudience>
    <Text textformat="05">
        <dl>
            <dt>3.0.2</dt>
            <dd>Added an extra section in chapter 2</dd>
            <dd>Added animated diagrams in chapter 4</dd>
            <dd>
                <p>Also fixed the following technical issues:</p>
                <ul>
                    <li>inconsistent margin size</li>
                    <li>scrolling problem with tables in Chapter 7</li>
                </ul>
            </dd>
            <dt>3.0.1</dt>
            <dd>Corrected typos in the initial text of the Third Edition</dd>
        </dl>
    </Text>
<TextContent>
using Short tags
<b057>3</b057>Third edition
<b217>0.2</b217>version 0.2
. . .
<textcontent>
    <x426>19</x426>Version history
    <x427>00</x427>For any audience
    <d104 textformat="05">​<dl>​<dt>​3.0.2​</dt>​<dd>​Added an extra section in chapter 2​</dd>​<dd>​Added animated diagrams in chapter 4​</dd>​<dd>​<p>​Also fixed the following technical issues:​</p>​<ul>​<li>inconsistent margin size​</li>​<li>scrolling problem with tables in Chapter 7​</li>​</ul>​</dd>​<dt>​3.0.1​</dt>​<dd>Corrected typos in the initial text of the Third Edition​</dd>​</dl>​</d104>
<textcontent>

The version history should render like this:

3.0.2
Added an extra section in chapter 2
Added animated diagrams in chapter 4

Also fixed the following technical issues:

  • inconsistent margin size
  • scrolling problem with tables in Chapter 7
3.0.1
Corrected typos in the initial text of the Third Edition

XHTML should usually be sent without extra spaces or tab characters, which are used in the Reference names examples above to indent the markup for clarity only. Any extra ‘whitespace’ characters are unnecessary, and count against any character limits imposed for particular data elements. Return/new line characters can also be removed if desired.

Where a particular type of descriptive text needs to be delivered in multiple languages, separate repeats of the <Text> element can be used, with differing language attributes attached to each element. For example, books in both French and English are popular in France. When selling a book in English, a French online retailer may wish to display a description of the book in both French (the native language of most customers) and English (the language of the product itself):

providing the same <TextContent> in multiple languages
using Reference names
<TextContent>
    <TextType>02</TextType>
    <ContentAudience>00</ContentAudience>
    <Text language="eng" textformat="05"><p>On the eve of his death, Dr. Watson feels a duty to set down the last adventure of Sherlock Holmes…</p></Text>
    <Text language="fre" textformat="05"><p>A la veille de sa mort, le docteur Watson se sent le devoir de coucher sur le papier la dernière aventure de Sherlock Holmes…</p></Text>
</TextContent>
using Short tags
<textcontent>
    <x426>02</x426>Short description
    <x427>00</x427>For any audience
    <d104 language="eng" textformat="05"><p>On the eve of his death, Dr. Watson feels a duty to set down the last adventure of Sherlock Holmes…​</p>​</d104>In English
    <d104 language="fre" textformat="05"><p>A la veille de sa mort, le docteur Watson se sent le devoir de coucher sur le papier la dernière aventure de Sherlock Holmes…​</p>​</d104>…and in French
</textcontent>
If there is more than one repeat of the <Text> element within a <TextContent> composite, every one must carry a language attribute, and each should be unique.
It is not currently possible to target the text more precisely than by language (for example, it is not possible to list one text for Castilian Spanish and another for Latin American Spanish, since both would use code spa for the language attribute).

If for any reason HTML markup must be used – and it cannot be converted to XHTML – then the textformat attribute should be set to 02, and either:

  • the HTML content must be enclosed within XML <![CDATA[ … ]]> tags, or
  • all HTML tags must have their initial ‘<’ character replaced by ‘&lt;’;
  • the former is preferred;
  • see the notes on embedding HTML within P.7.42.
Review rating composite

Where the descriptive text in the <Text> element is a short extract from a review, it can be useful to provide any ‘star rating’ from the review as structured data, rather than simply including the reviewer’s rating within the text of the review extract. Of course, not every review provides a rating.

ReviewRating Rating RatingLimit RatingUnits
4.5-star review, where a maximum of five stars are on offer
using Reference names
<ReviewRating>
    <Rating>4.5</Rating>
    <RatingLimit>5</RatingLimit>
    <RatingUnits>stars</RatingUnits>
</ReviewRating>
using Short tags, with additional multilingual units
<reviewrating>
    <x525>4.5</x525>
    <x526>5</x526>
    <x527 language="eng">stars</x527>
    <x527 language="fre">étoiles</x527>
</reviewrating>
P.14.4 to P.14.6 Text source

Where the descriptive text in the <Text> element is a short excerpt from a review, or an endorsement, the source of the quotation should be specified. Endorsements should specify the name of the endorser in the <TextAuthor> element, and review quotes should specify the source publication in <SourceTitle>, and possibly also the name of the reviewer in <TextAuthor>.

providing multiple review quotes, naming the review authors and publications
using Reference names
<TextContent>
    <TextType>08</TextType>
    <ContentAudience>00</ContentAudience>
    <Text>‘a deeply felt and intelligently told tale, expressed in the taut style of an experienced journalist, yet conveying more – much more – than mere facts.’</Text>
    <TextAuthor>Nuala O’Carroll</TextAuthor>
    <SourceTitle>Financial Times</SourceTitle>
</TextContent>
<TextContent>
    <TextType>06</TextType>
    <ContentAudience>00</ContentAudience>
    <Text>‘Sharp and pacy, it reads like a thriller.’</Text>
    <TextAuthor>Evan Moore</TextAuthor>
    <SourceTitle>City AM</SourceTitle>
</TextContent>
using Short tags
<textcontent>
    <x426>08</x426>Quote from review of previous work
    <x427>00</x427>
    <d104>‘a deeply felt and intelligently told tale, expressed in the taut style of an experienced journalist, yet conveying more – much more – than mere facts.’</d104>No textformat attribute or markup, so the text is in the default plain text format using encoding specified at top of file
    <d107>Nuala O’Carroll</d107>Review author
    <x428>Financial Times</x428>Review published in
</textcontent>
<textcontent>
    <x426>06</x426>Quote from review of this product
    <x427>00</x427>
    <d104>‘Sharp and pacy, it reads like a thriller.’</d104>
    <d107>Evan Moore</d107>
    <x428>City AM</x428>
</textcontent>
Where <TextAuthor> and possibly a <SourceTitle> are provided for a review or endorsement, the <Text> content would normally be enclosed in quotation marks.
<TextAuthor> is repeatable when there are multiple authors for a single review.
Where the text author is a corporate author, <TextSourceCorporate> may be used instead of <TextAuthor>. It should not be used for the corporate affiliation of the text author – affiliations should be included inside <TextAuthor> (see the example at the beginning of Section P.14).

For other types of descriptive text, the source of the text should be assumed to be the publisher and may be omitted.

Content date composite

The most critical function of the <ContentDate> composite is to specify date limits that a publisher may set to control use of any descriptive text – and specifically, to set an embargo date on the use of any text extract from the product. The composite should also be used to indicate when the collateral text was last updated.

Note also that if an sales embargo date (also known as a ‘strict on-sale date’) is specified in the <PublishingDate> composite in Group P.20 or the equivalent <MarketDate> composite in Group P.25, that embargo date applies also to any excerpt or preview of the product (ie where <TextType> is code 14 from List 153). If both sales embargo date and a specific From date are supplied, then the From date applies to the excerpt or preview material. Sales embargo dates do not affect the use of other text types.

<ContentDate> with a Content date role code 14 from List 155 (From date) is used to specify an embargo on use of the collateral text. Role code 15 (Until date) indicates when use of the supplied collateral text should end, and in particular, an Until date in the past shows the text should be taken down from any consumer-facing website.

An indication of when the collateral text was added or last updated is immensely useful for data recipients. Processing may include editorial comparisons needing expensive and time-consuming human judgement. On receipt, any Last updated date can be compared with a stored date, and unnecessarily reprocessing unchanged text can be avoided.

ContentDate ContentDateRole DateFormat Date use dateformat attribute on <Date> element instead
excerpt last updated 25th February, but embargoed until 7th March 2011
using Reference names
<TextContent>
    <TextType>14</TextType>
    <ContentAudience>00</ContentAudience>
    <Text textformat="05"><h1>Chapter 1</h1><p>It was a dark and stormy night…</p></Text>
    <ContentDate>
        <ContentDateRole>17</ContentDateRole>
        <Date dateformat="00">20110225</Date>
    </ContentDate>
    <ContentDate>
        <ContentDateRole>14</ContentDateRole>
        <Date dateformat="00">20110307</Date>
    </ContentDate>
</TextContent>
using Short tags
<textcontent>
    <x426>14</x426>Excerpt
    <x427>00</x427>For any audience
    <d104 textformat="05"><h1>Chapter 1</h1><p>It was a dark and stormy night…​</p>​</d104>
    <contentdate>
        <x429>17</x429>Last updated date
        <b306 dateformat="00">20110225</b306>
    </contentdate>
    <contentdate>
        <x429>14</x429>From date
        <b306 dateformat="00">20110307</b306>
    </contentdate>
</textcontent>
<ContentDateRole> code 01 from List 155 (Publication date) refers to the nominal publication date of, for example, a newspaper review from which a quotation is taken, and not to the publication date of the product described in the Product record or the publication embargo date for any excerpt. Use code 14 (From date) to express an embargo date for use of the review snippet.
Use of <ContentDateRole> code 17 is preferred to use of the datestamp attribute to indicate the Last updated date for the collateral text.

ONIX recipients must make every effort to comply with embargo dates supplied with collateral material in this way. If a recipient cannot do this because of limitations in their internal systems, then they should ignore any descriptive text associated with a From date (code 14 in List 155) to avoid the risk of using the collateral prior to an embargo. Text provided without a From date and where no Embargo date applies to sales of the product itself should be treated as having no limitation on the earliest date it can be used.

The same effort must be made to comply with Use until dates (code 15 in List 155), and collateral text beyond its Use until date should be removed from retail websites, online catalogs etc. If a recipient’s internal system cannot support removal on the specified date, the text should not be used at all in order to avoid the risk of using the collateral beyond its end date.

The other circumstance where From and Until content dates are critical is to control the changeover of collateral materials when a product is reissued. The <Reissue> composite in Group 26 is deprecated – see the detailed notes with <Reissue>. The reissue process replaces one set of collateral material with another set. At some point in the process, where there is no gap between last availability of the old version and first availability of the new version, both old and new collateral material may be carried or referenced in the same ONIX Product record. Old material can be accompanied by an Until date (<ContentDateRole> code 15 from List 155), and new material by a From date (<ContentDateRole> code 14).

P.15 Cited content

The Cited content Group is one of the more rarely used sections of ONIX for Books. However, it has a potentially powerful use: it’s a way of tying product metadata supplied in the Product record into the wider context of the whole web. It allows links to be made between products and third-party reviews of those products, feature articles or published bestseller lists for example.

Cited content is most useful when it is available online. However, P.15 can also specify printed or broadcast content.

Citations are quite different from supporting text included in Group P.14. Firstly, supporting text is embedded in the ONIX message itself, whereas Group P.15 carries only links to other (usually online) content. Second, supporting text is clearly intended for use by the recipient in commercial activities related to the product (the implied license), whereas cited content is the intellectual property of a third party, is subject to that party’s copyright or other rights, and can only be used indirectly (ie by including a link or reference to it on a retailer website, rather than by including the cited content itself on the retailer website).

Cited content composite
CitedContent CitedContentType CitedContentType ContentAudience Territory SourceType ReviewRating SourceTitle ListName PositionOnList CitationNote ResourceLink ContentDate must not omit both
citing a review and bestseller list
using Reference names
<CitedContent>
    <CitedContentType>01</CitedContentType>
    <ContentAudience>00</ContentAudience>
    <ReviewRating>
        <Rating>5</Rating>
        <RatingLimit>5</RatingLimit>
    </ReviewRating>
    <SourceTitle>The Guardian</SourceTitle>
    <CitationNote>Review of Jonathan Franzen’s ‘Freedom’ by Blake Morrison</CitationNote>
    <ResourceLink>https://www.​guardian.​co.​uk/​books/​2010/​sep/​18/​jonathan-​franzen-​freedom-​blake-​morrison</ResourceLink>
    <ContentDate>
        <ContentDateRole>01</ContentDateRole>
        <Date dateformat="00">20100918</Date>
    </ContentDate>
</CitedContent>
<CitedContent>
    <CitedContentType>02</CitedContentType>
    <ContentAudience>00</ContentAudience>
    <ListName>New York Times Hardcover Fiction</ListName>
    <PositionOnList>1</PositionOnList>
    <ContentDate>
        <ContentDateRole>01</ContentDateRole>
        <Date dateformat="00">20100926</Date>
    </ContentDate>
</CitedContent>
using Short tags
<citedcontent>
    <x430>01</x430>Review
    <x427>00</x427>Any audience
    <reviewrating>
        <x525>5</x525>5-star review
        <x526>5</x526>
    </reviewrating>
    <x428>The Guardian</x428>
    <x434>Review of Jonathan Franzen’s ‘Freedom’ by Blake Morrison</x434>
    <x435>https://www.​guardian.​co.​uk/​books/​2010/​sep/​18/​jonathan-​franzen-​freedom-​blake-​morrison</x435>URL
    <contentdate>
        <x429>01</x429>Published
        <b306 dateformat="00">20100918</b306>
    </contentdate>
</citedcontent>
<citedcontent>
    <x430>02</x430>Bestseller list
    <x427>00</x427>Any audience
    <x432>New York Times Hardcover Fiction</x432>
    <x433>1</x433>Position on list
    <contentdate>
        <x429>01</x429>Published
        <b306 dateformat="00">20100926</b306>
    </contentdate>
</citedcontent>
<ContentAudience> could be omitted, as if an audience is not specified, the audience can be assumed to be unrestricted. The bestseller list cited is in fact available online, but the URL has been omitted from the citation to illustrate that not all resources need be web-accessible.
P.15.1 Cited content type code

Within each repeat of the <CitedContent> composite, a <CitedContentType> data element is mandatory.

Multiple repeats of the <CitedContent> composite can be used to carry references to various material, and the material must be classified using List 156. It is good practice to supply links to selected reviews of the product, and to any published bestseller/sales charts on which the product is prominently featured.

P.15.2 Target audience

The <ContentAudience> element should be used to specify that the cited material in a particular repeat of the <CitedContent> composite is intended for a limited audience – typically this should be used where the material is intended primarily for trade use, or more generally where a link to the material would not be appropriate in a consumer context.

Note that <ContentAudience> is optional within <CitedContent>, whereas it is mandatory within P.14 and P.16. Recipients of ONIX data should take some care that when an audience is specified, they limit visibility of any links or references to that particular audience. If a recipient cannot do this because of limitations in their internal systems, then they should ignore any citation that is not marked as Unrestricted or for general end-customer use (codes 00 or 03 in List 154). Citations provided without any specification of the target audience should be treated as Unrestricted.

P.15.3 Source type

If this data element is included, it refers to the primary medium of any cited content. For example, a review published in a (printed) literary magazine which also makes its full content available online should use code 01 (printed media) from List 157, not code 02 (website). The fact that the cited material is available online is made explicit by inclusion of a URL in the <ResourceLink> element. However, code 02 would be appropriate if the review were a ‘web exclusive’ and appeared solely on the magazine’s website (and not in the printed edition).

P.15.4 Source title

A newspaper or magazine title, or a broadcast program title, should be provided to indicate the source of a review, feature article or other media mention.

Ideally, the publication or first broadcast date of the material should also be provided in a <ContentDate> composite.

P.15.5, P.15.6 Bestseller lists

For references to published bestseller lists or sales charts, both the name of the list and the position reached should be provided.

In most cases, the name of a sponsoring publication is included in the name of the list – for example, ‘The New York Times Paperback Mass-Market Fiction’ list – so a <SourceTitle> element is unnecessary.

Ideally, the publication date of the list should also be provided in a <ContentDate> composite.

Content date composite

The <ContentDate> composite is identical to that in Group P.14. But for cited material, the <ContentDate> composite cannot be used to provide date limits or to embargo the cited material (From date, Until date), since access to cited content is ultimately beyond the control of either the sender or recipient of ONIX data. However, it can be used to provide an indication of the publication or broadcast date of any cited material – this is especially useful for cited material that is not available online.

P.16 Links to supporting resources

Group P.16 describes various collateral marketing material. Like P.14, it comes with an express invitation to the data recipient to use the material for purposes of marketing or sale of the product. But in contrast to collateral text in P.14, P.16 describes material that is not embedded in the ONIX message itself – it must be either linked to or downloaded. Typically, P.16 is used to deliver links to an image of the cover of a product, sample pages, audio or video extracts and other non-text material.

The Group consists entirely of the <SupportingResource> composite. It’s optional, so the entire group can be omitted if there are no supporting resources available. But for online sales, supporting resources – most especially a cover image – form an important part of the merchandising of a product, so publishers supplying ONIX data will usually wish to include at least one repeat of the composite. Where there are many supporting resources, there can be many repeats of the composite.

Supporting resource composite

The <SupportingResource> composite has a two-level structure. There should be one repeat of <SupportingResource> for each ‘resource’. The resource has a ‘type’, which might specify that it is a front cover, or some sample audiobook content, and a ‘mode’, which might specify audio or a still image. A resource can be associated with a caption or credit via the <ResourceFeature> composite. Then within a particular <SupportingResource> composite, a single resource can be available in different versions, each described within a <ResourceVersion> composite. Resource versions are different ‘renderings’ of the same resource – high and low quality versions of an image, for example, or .wav and .mp3 versions of the same audio clip. Each version may be associated with various features that are unique to that version in <ResourceVersionFeature>, and may also be subject to limitations on when it can be used.

SupportingResource ResourceContentType ResourceContentType ContentAudience Territory ResourceMode ResourceFeature ResourceVersion ResourceVersion ResourceForm ResourceVersionFeature ResourceVersionFeature ResourceLink ContentDate

The <ResourceForm> element is most often used to indicate whether the resource version will be hosted by the ONIX supplier (or a third party) – in which case the ONIX recipient should use the URL provided as the src attribute in an HTML <img> or <a> link – or whether the ONIX recipient should download the resource from the URL provided and use that independent copy of the file.

It is best practice to provide at least:

  • a high-quality cover image (or equivalent) at least 640 pixels (and probably no more than 1000 pixels) in smallest dimension;
    • some major e‑book vendors request images of much higher quality, up to 1600 pixels in smallest dimension, to provide optimized images for high-resolution tablet devices, but also place file size limits on images (eg no more than 5MB file size);
    • images should be flat (not 3D perspective views), cropped so that no background is shown;
    • image files should be sRGB colorspace, 24 bits per pixel color depth, JPEG with no clearly visible artifacts;
    • it is good practice to attach an ICC color profile to the image, particularly if a colorspace other than sRGB is used (for example, the wider-gamut Adobe RGB). CMYK should be avoided;
    • a TIFF version may also be supplied for download by the recipient (other details as above);
    • note that no fixed resolution is recommended – it is the number of pixels in the image that is important, as the resolution depends not only on the image itself, but also on the size it is reproduced at by the ONIX recipient;
  • a ‘thumbnail’ cover image (or equivalent) at a size of 125 pixels in smallest dimension;
    • thumbnail files should be JPEG only, but otherwise as for high-quality images;
    • it may be useful to ‘simplify’ thumbnail images, as important details of the large images may not be visible when reduced in size (for example, removing small cover text that would otherwise render as a grey blur in a thumbnail);
  • the high-quality JPEG, a TIFF and the thumbnail JPEG files would usually be versions of the same resource, using <ResourceContentType> code 01 from List 158;
    • if a 3D perspective view of the book showing the cover is also provided, use code 03;
  • where a cover is not available, it is not considered good practice to supply a placeholder image or dummy cover as if it were the cover. A temporary ‘holding image’ may be supplied using Resource content type code 45, clearly indicating the resources is not the cover but might be used in its place until the cover is available;
    • if a holding image is supplied, the data sender must remove it as soon as a cover image is available, and recipients must then ensure replacement of the holding image with the cover image on both public-facing and internal business systems;
  • for multi-volume products – for example, four paperbacks in a slipcase – multiple images (multiple resources) may be provided;
    • the decorative box cover or a ‘3D’ image of the slipcase may be more appropriate;
  • for products containing audio content, an audio excerpt of around 2–5 minutes length;
    • audio files should be MP3 or AAC, mono or stereo, 44.1kHz sample rate, 64kbits per channel per second data rate (or better);
    • a ‘CD-quality’ WAV or AIFF version may also be supplied (mono or stereo, 44.1kHz or 48kHz sample rate, 16 bits per channel per sample) for download by the recipient;
  • low- and high-quality audio files, or two files of equivalent quality but using different codecs, would be different versions of the same audio resource, using code 15 from List 158;
  • for physical products that are not flat and rectangular, products where the style of packaging is important, or other products which do not have a conventional cover (eg boxed products, toys or other merchandise, point-of-sale material such as dumpbins etc), an image of the product in 3D perspective – a photograph or digital rendering – should be supplied instead, using <ResourceContentType> code 03 from List 158;
    • the background behind product images should be predominantly white.

Images where the width is fixed (eg at 125 pixels) should vary in height according to the aspect ratio of the product (and of course, vice versa). Images should never be distorted to fit a specific shape.

Other types of resource that may commonly be provided are:

  • portrait images of contributors, as high-quality or thumbnail images – best practice for these images should follow that for covers above;
  • sample content, eg as text, JPEG images of sample spreads, or PDF, HTML or EPUB-format files that can be read on most e-reading devices;
  • downloadable reading guides for book groups, as text, PDF, HTML, or as an EPUB-format files;
  • embeddable applications, or sample content in the form of an embeddable ‘widget’ (a book-preview application). Note that for most resources, the URL is the resource (<ResourceForm> code 01), or the resource itself is downloaded from the URL specified in <ResourceLink> (<ResourceForm> code 02). In contrast, embeddable applications and widgets:
    • require an <iframe> or <object> to be embedded into the ONIX recipient’s web page;
    • the code to embed should be downloaded from the URL in <ResourceLink>;
    • these embeddable resources should carry <ResourceMode> code 01 and <ResourceForm> code 03.
    Note that other ‘widgets’ are simple URLs linking to stand-alone websites. The URL in <ResourceLink> is usually the target of a link on the recipient’s web page – nothing need be downloaded by the ONIX recipient;
    • these resources should carry <ResourceMode> code 06 and <ResourceForm> code 01.

Filenames for these resources may be arbitrary, in that the filename is carried as part of the URL in in the <ResourceLink> data element and need not comply with any predetermined naming scheme. Since the resources are in most cases intended for downloading by the ONIX recipient, and will in most cases be processed to produce images of sized specifically for the recipient’s website, catalog etc, the recipient may rename the file for their own convenience at that time. However, senders may at least find it convenient to incorporate the ISBN of the product, or the ONIX <RecordReference> from Group P.1, in the filename.

It should be noted that it’s common for suppliers to make the same supporting resources such as cover and audio samples available also to supply chain partners who are not themselves ONIX recipients. In these cases, it is much more important to follow a predetermined naming scheme that also describes the nature of the resource. A simple scheme is used in the examples below, and more comprehensive guidelines are available on the EDItEUR website.

Downloadable resources: front cover resource as thumbnail and high quality images, plus embargoed audio excerpt of author reading content from the product
using Reference names
<SupportingResource>
    <ResourceContentType>01</ResourceContentType>
    <ContentAudience>00</ContentAudience>
    <ResourceMode>03</ResourceMode>
    <!-- no <ResourceFeature> composite needed -->
    <ResourceVersion>
        <ResourceForm>01</ResourceForm>
        <ResourceVersionFeature>
            <ResourceVersionFeatureType>01​</ResourceVersionFeatureType>
            <FeatureValue>D502</FeatureValue>
        </ResourceVersionFeature>
        <ResourceVersionFeature>
            <ResourceVersionFeatureType>03​</ResourceVersionFeatureType>
            <FeatureValue>125</FeatureValue>
        </ResourceVersionFeature>
        <ResourceLink>http://www.publisher.com/b2b/​covers/​9780001234567​-fc125px.jpg​</ResourceLink>
        <ContentDate>
            <ContentDateRole>17</ContentDateRole>
            <Date dateformat="00">20101117</Date>
        </ContentDate>
    </ResourceVersion>
    <ResourceVersion>
        <ResourceForm>02</ResourceForm>
        <ResourceVersionFeature>
            <ResourceVersionFeatureType>01​</ResourceVersionFeatureType>
            <FeatureValue>D502</FeatureValue>
        </ResourceVersionFeature>
        <ResourceVersionFeature>
            <ResourceVersionFeatureType>03​</ResourceVersionFeatureType>
            <FeatureValue>650</FeatureValue>
        </ResourceVersionFeature>
        <ResourceLink>http://www.publisher.com/​b2b/​covers/​9780001234567​-fc650px.jpg​</ResourceLink>
        <ContentDate>
            <ContentDateRole>17</ContentDateRole>
            <Date dateformat="00">20101117</Date>
        </ContentDate>
    </ResourceVersion>
    <ResourceVersion>
        <ResourceForm>02</ResourceForm>
        <ResourceVersionFeature>
            <ResourceVersionFeatureType>01​</ResourceVersionFeatureType>
            <FeatureValue>D504</FeatureValue>
        </ResourceVersionFeature>
        <ResourceVersionFeature>
            <ResourceVersionFeatureType>03​</ResourceVersionFeatureType>
            <FeatureValue>1535</FeatureValue>
        </ResourceVersionFeature>
        <ResourceLink>http://www.publisher.com/​b2b/​covers/​9780001234567​-fc300dpi.tif​</ResourceLink>
        <ContentDate>
            <ContentDateRole>17</ContentDateRole>
            <Date dateformat="00">20101117</Date>
        </ContentDate>
    </ResourceVersion>
</SupportingResource>
<SupportingResource>
    <ResourceContentType>13​</ResourceContentType>
    <ContentAudience>00</ContentAudience>
    <ResourceMode>02</ResourceMode>
    <ResourceFeature>
        <ResourceFeatureType>04​</ResourceFeatureType>
        <FeatureValue>3</FeatureValue>
    </ResourceFeature>
    <ResourceFeature>
        <ResourceFeatureType>02​</ResourceFeatureType>
        <FeatureNote textformat="05"><p>Ferenc Júlia reading an excerpt from Petőfi Sándor’s poem <em>A régi, jó Gvadányi</em> (in Hungarian)​</p>​</FeatureNote>
    </ResourceFeature>
    <ResourceVersion>
        <ResourceForm>02</ResourceForm>
        <ResourceVersionFeature>
            <ResourceVersionFeatureType>01​</ResourceVersionFeatureType>
            <FeatureValue>A103</FeatureValue>
        </ResourceVersionFeature>
        <ResourceLink>http://www.publisher.com/​b2b/​audio/​9780001234567​-ex300s.mp3​</ResourceLink>
        <ContentDate>
            <ContentDateRole>17</ContentDateRole>
            <Date dateformat="00">20110114</Date>
        </ContentDate>
        <ContentDate>
            <ContentDateRole>14</ContentDateRole>
            <Date dateformat="00">20110117</Date>
        </ContentDate>
    </ResourceVersion>
</SupportingResource>
using Short tags
<supportingresource>First resource
    <x436>01</x436>Front cover
    <x427>00</x427>For any audience
    <x437>03</x437>Still image
    <!-- no <ResourceFeature> needed -->
    <resourceversion>First version of resource #1
        <x441>01</x441>Linkable file
        <resourceversionfeature>
            <x442>01</x442>File format
            <x439>D502</x439>JPEG
        </resourceversionfeature>
        <resourceversionfeature>
            <x442>03</x442>Width
            <x439>125</x439>125 pixels
        </resourceversionfeature>
        <x435>http://www.publisher.com/​b2b/​covers/​9780001234567​-fc125px.jpg​</x435>
        <contentdate>
            <x429>17</x429>Last updated
            <b306 dateformat="00">20101117​</b306>
        </contentdate>
    </resourceversion>
    <resourceversion>Second version of resource #1
        <x441>02</x441>Downloadable file
        <resourceversionfeature>
            <x442>01</x442>File format
            <x439>D502</x439>JPEG
        </resourceversionfeature>
        <resourceversionfeature>
            <x442>03</x442>Width
            <x439>650</x439>650 pixels
        </resourceversionfeature>
        <x435>http://www.publisher.com/​b2b/​covers/​9780001234567​-fc650px.jpg​</x435>
        <contentdate>
            <x429>17</x429>Last updated
            <b306 dateformat="00">20101117​</b306>
        </contentdate>
    </resourceversion>
    <resourceversion>Third version of resource #1
        <x441>02</x441>Downloadable file
        <resourceversionfeature>
            <x442>01</x442>File format
            <x439>D504</x439>TIFF
        </resourceversionfeature>
        <resourceversionfeature>
            <x442>03</x442>Width
            <x439>1535</x439>1535 pixels
        </resourceversionfeature>
        <x435>http://www.publisher.com/​b2b/​covers/​9780001234567​-fc300dpi.tif​</x435>
        <contentdate>
            <x429>17</x429>Last updated
            <b306 dateformat="00">20101117​</b306>
        </contentdate>
    </resourceversion>
</supportingresource>
<supportingresource>Second resource
    <x436>13</x436>Contributor reading
    <x427>00</x427>For any audience
    <x437>02</x437>Audio
    <resourcefeature>
        <x438>04</x438>Length
        <x439>3</x439>3 minutes
    </resourcefeature>
    <resourcefeature>
        <x438>02</x438>Caption
        <x440 textformat="05"><p>Ferenc Júlia reading an excerpt from Petőfi Sándor’s poem <em>A régi, jó Gvadányi</em> (in Hungarian)​</p>​</x440>With XHTML markup
    </resourcefeature>
    <resourceversion>Sole version of resource #2
        <x441>02</x441>Downloadable file
        <resourceversionfeature>
            <x442>01</x442>File format
            <x439>A103</x439>MP3
        </resourceversionfeature>
        <x435>http://www.publisher.com/​b2b/​audio/​9780001234567​-ex300s.mp3​</x435>
        <contentdate>
            <x429>17</x429>Last updated
            <b306 dateformat="00">20110114​</b306>
        </contentdate>
        <contentdate>
            <x429>14</x429>Embargoed until
            <b306 dateformat="00">20110117​</b306>
        </contentdate>
    </resourceversion>
</supportingresource>
Note the three different versions of the first resource – a thumbnail JPEG, a medium-sized JPEG and a large TIFF, all versions of a single cover image. Why are these differentiated by pixel dimension rather than resolution? Generally a ‘low-res’ or ‘screen res’ image is something around 75–100 pixels per inch (or around 30–40 pixels per cm), and a high-res image is generally at least 300 pixels per inch (120 pixels per cm). So an image that is 225 pixels in width is ‘screen resolution’ if it is printed or displayed at 7.5cm across (because 225 ÷ 7.5 = 30 pixels per cm). Yet exactly the same 225 pixel JPEG is ‘high-res’ if it is displayed it at 1.5cm across (225 ÷ 1.5 = 150 pixels per cm). Digital images don’t have an inherent ‘resolution’ – only a number of pixels – and the eventual resolution depends on the physical size when the image is displayed or printed. (In some circumstances, a resolution or physical size can be described in separate metadata attached to an image, but this is really just a ‘preferred display size’, not an inherent property of the image.)
Different versions of the same resource may have differing resource forms – the thumbnail sized cover image is linkable whereas the larger cover image files are downloadable. The defining feature of a downloadable resource is that the resource must be downloaded by the ONIX recipient, and to display that resource to consumers, a new copy must be hosted on a server independently of the original data supplier. In contrast, for a linkable resource, the ONIX recipient may use the URL eg as the src attribute in an <img> tag, as hosting services for the resource will be provided by the data supplier.
Linkable resources: linking to the publisher’s reading group guide
using Reference names
<SupportingResource>
    <ResourceContentType>19</ResourceContentType>
    <ContentAudience>03</ContentAudience>
    <ContentAudience>04</ContentAudience>
    <ResourceMode>04</ResourceMode>
    <ResourceFeature>
        <ResourceFeatureType>02</ResourceFeatureType>
        <FeatureNote textformat="06">Download the Reading Group guide​</FeatureNote>
    </ResourceFeature>
    <ResourceVersion>
        <ResourceForm>01</ResourceForm>
        <ResourceVersionFeature>
            <ResourceVersionFeatureType>01​</ResourceVersionFeatureType>
            <FeatureValue>D401</FeatureValue>
        </ResourceVersionFeature>
        <ResourceLink>http://www.publisher.com/​b2c/​rguides/​9780001234567​-rgg.pdf​</ResourceLink>
    </ResourceVersion>
</SupportingResource>
using Short tags
<supportingresource>
    <x436>19</x436>Reading group guide
    <x427>03</x427>For end customers
    <x427>04</x427>and Librarians
    <x437>04</x437>Primarily text
    <resourcefeature>
        <x438>02</x438>Caption
        <x440 textformat="06">Download the Reading Group guide​</x440>
    </resourcefeature>
    <resourceversion>
        <x441>01</x441>Linkable resource
        <resourceversionfeature>
            <x442>01</x442>File format
            <x439>D401</x439>PDF
        </resourceversionfeature>
        <x435>http://www.publisher.com/​b2c/​rguides/​9780001234567​-rgg.pdf​</x435>
    </resourceversion>
</supportingresource>

For linkable resources, the supplied URL can be added to the recipient’s web page in numerous ways. The simplest is as the href attribute of a link:

  • <p><a href="http:/www.publisher.com/​b2c/​rguides/​9780001234567-rgg.pdf" rel="external">Download the Reading Group Guide</a></p>

If the linked resource is a simple image, it might be used like this. Note the use of the supplied caption as alt text to improve accessibility:

  • <img src="http:/www.publisher.com/​b2c/​covers/​9780001234567​-fc125px.jpg" width="125" alt="Front cover of No Logo by Naomi Klein" />

The defining feature of a linkable resource is that it is the publisher or some third party that will host the resource: the ONIX recipient need not keep their own copy, and is invited to link to the primary version. However, note that some retailers are reluctant to use such linkable resources. They may of course download a copy and host it themselves, subject to any license terms pertaining to the resource.

Embeddable resources: supplying details of an embeddable application (eg a YouTube video player)
using Reference names
<SupportingResource>
    <ResourceContentType>13</ResourceContentType>
    <ContentAudience>00</ContentAudience>
    <ResourceMode>01</ResourceMode>
    <ResourceFeature>
        <ResourceFeatureType>04</ResourceFeatureType>
        <FeatureValue>5</FeatureValue>
    </ResourceFeature>
    <ResourceFeature>
        <ResourceFeatureType>02</ResourceFeatureType>
        <FeatureNote textformat="06">The author reads her story to an audience of schoolchildren​</FeatureNote>
    </ResourceFeature>
    <ResourceVersion>
        <ResourceForm>03</ResourceForm>
        <ResourceVersionFeature>
            <ResourceVersionFeatureType>02​</ResourceVersionFeatureType>
            <FeatureValue>640</FeatureValue>
        </ResourceVersionFeature>
        <ResourceVersionFeature>
            <ResourceVersionFeatureType>03​</ResourceVersionFeatureType>
            <FeatureValue>390</FeatureValue>
        </ResourceVersionFeature>
        <ResourceLink>http://www.publisher.com/​b2b/​embed/​9780001234567-youtube.txt​</ResourceLink>
    </ResourceVersion>
</SupportingResource>
using Short tags
<supportingresource>
    <x436>13</x436>Contributor reading
    <x427>00</x427>For any audience
    <x437>01</x437>Application
    <resourcefeature>
        <x438>04</x438>Length
        <x439>5</x439>5 minutes
    </resourcefeature>
    <resourcefeature>
        <x438>02</x438>Caption
        <x440 textformat="06">The author reads her story to an audience of schoolchildren​</x440>
    </resourcefeature>
    <resourceversion>
        <x441>03</x441>Embeddable application
        <resourceversionfeature>
            <x442>03</x442>Width
            <x439>640</x439>640 pixels
        </resourceversionfeature>
        <resourceversionfeature>
            <x442>02</x442>Height
            <x439>390</x439>390 pixels
        </resourceversionfeature>
        <x435>http://www.publisher.com/​b2b/​embed/​9780001234567-youtube.txt​</x435>URL
    </resourceversion>
</supportingresource>

Querying the specified URL should return a text file containing HTML or other embeddable application code that may be embedded in the recipient’s web page. For a YouTube video, the URL should return a text snippet something like:

  • <iframe type="text/html" title="YouTube player" class="youtube-player" src="http://www.youtube.com/​embed/​9780001234567​?rel=0" frameborder="0" width="640" height="390" allowFullScreen​</iframe>

Adding this chunk of HTML to a web page within the ONIX recipient’s online store embeds the YouTube video on the page. The height and width of the resource should be provided in the <ResourceVersionFeature> composite so the recipient can control the page layout automatically.

Note that that this is not the only way of specifying a link to a YouTube video (or similar) – it is used here simply an example of a chunk of embeddable code.

P.16.1 Resource content type code

<ResourceContentType> is used to indicate what the resource is, independent of the way that it’s delivered.

P.16.2 Target audience

As with P.14 Descriptions and other supporting text, and as recommended with P.15 Cited content, the <ContentAudience> element must be used to specify when the resource is intended for a limited audience – typically this should be used where the material is intended primarily for trade use, or more generally where a link to the material would not be appropriate in a consumer context. The element is mandatory in Group P.16, so if there is no restriction, <ContentAudience> could carry codes 00 or 03.

Territory composite

The <Territory composite is used to specify that the resource is intended only for use in a specific market or range of countries and regions. Its structure is identical to that in Group P.21, and in use it works identically to <Territory> in Group P.14.

For example, a book may be for sale with two separate covers, one for the UK and international market, and one for North America, without necessarily having two separate ISBNs. In this case, two separate <SupportingResource> composites can be used, with <Territory> used to target one at a specific North American market.

Note that the <Territory> need not align with a particular market as specified in P.24, though it may often do so. Data senders should take care to avoid inadvertently targeting more than one cover image (or other resource type where only one instance is appropriate) at a particular country.

Note also that one <SupportingResource> composite (for a particular resource type) should be left without a <Territory>, for use in ‘all other countries’. Faced with a number of cover images, for example, recipients should first try to select the one that is specifically targeted for use in the appropriate country, and then use the one without a <Territory> composite if no targeted version is available.

Separate North American and British/International covers
using Reference names
<SupportingResource>
    <ResourceContentType>01</ResourceContentType>
    <ContentAudience>00</ContentAudience>
    <Territory>
        <CountriesIncluded>US CA MX</CountriesIncluded>
    </Territory>
    <ResourceMode>03</ResourceMode>
    <ResourceVersion>
        <ResourceForm>02</ResourceForm>
        <-- resource version features omitted for brevity -->
        <ResourceLink>http://www.publisher.com/​b2b/​covers/​9780001234567​-US​-fc125px.jpg​</ResourceLink>
    </ResourceVersion>
</SupportingResource>
<SupportingResource>
    <ResourceContentType>01</ResourceContentType>
    <ContentAudience>00</ContentAudience>
    <ResourceMode>03</ResourceMode>
    <ResourceVersion>
        <ResourceForm>02</ResourceForm>
        <-- resource version features omitted for brevity -->
        <ResourceLink>http://www.publisher.com/​b2b/​covers/​9780001234567​-UK​-fc125px.jpg​</ResourceLink>
    </ResourceVersion>
</SupportingResource>
using Short tags
<supportingresource>First resource
    <x436>01</x436>Front cover
    <x427>00</x427>For any audience
    <territory>Within the
        <x449>CA MX US</x449>Countries of North America
    </territory>
    <x437>03</x437>Still image
    <resourceversion>
        <x441>02</x441>Downloadable file
        <-- resource version features omitted for brevity -->
        <x435>http://www.publisher.com/​b2b/​covers/​9780001234567​-US​-fc125px.jpg​</x435>
    </resourceversion>
</supportingresource>
<supportingresource>Second resource
    <x436>01</x436>Front cover
    <x427>00</x427>For any audience
    <x437>03</x437>Still image
    <resourceversion>
        <x441>02</x441>Downloadable file
        <-- resource version features omitted for brevity -->
        <x435>http://www.publisher.com/​b2b/​covers/​9780001234567​-UK​-fc125px.jpg​</x435>
    </resourceversion>
</supportingresource>
In this example, a recipient in the US should choose the targeted North American cover in preference to the untargeted cover. A recipient in the UK should use the untargeted cover because there is no appropriate targeted version.
P.16.3 Resource mode

<ResourceMode> adds detail to the nature of the resource specified in <ResourceContentType>. For example, an interview with a contributor might be delivered primarily as text, as audio or as video – all three would have the same value for <ResourceContentType> (specifically, they would all use code 11 from List 158), but they would have different values for <ResourceMode> (List 159 codes 04, 02 and 05 respectively).

Resources with differing resource modes – back cover image and back cover text
using Reference names
<SupportingResource>
    <ResourceContentType>02</ResourceContentType>
    <ContentAudience>00</ContentAudience>
    <ResourceMode>03<ResourceMode>
    <ResourceVersion>
        <ResourceForm>02</ResourceForm>
        <ResourceVersionFeature>
            <ResourceVersionFeatureType>01</ResourceVersionFeatureType>
            <FeatureValue>D502</FeatureValue>
        </ResourceVersionFeature>
        <ResourceVersionFeature>
            <ResourceVersionFeatureType>02</ResourceVersionFeatureType>
            <FeatureValue>125</FeatureValue>
        </ResourceVersionFeature>
        <ResourceLink>http://www.publisher.com/b2b/​covers/​9780001234567​-bc125px.jpg</ResourceLink>
    </ResourceVersion>
</SupportingResource>
<SupportingResource>
    <ResourceContentType>02</ResourceContentType>
    <ContentAudience>00</ContentAudience>
    <ResourceMode>04<ResourceMode>
    <ResourceVersion>
        <ResourceForm>02</ResourceForm>
        <ResourceVersionFeature>
            <ResourceVersionFeatureType>01</ResourceVersionFeatureType>
            <FeatureValue>E112</FeatureValue>
        </ResourceVersionFeature>
        <ResourceLink>http://www.publisher.com/b2b/​covers/​9780001234567​-text.txt</ResourceLink>
    </ResourceVersion>
<SupportingResource>
using Short tags
<supportingresource>First resource
    <x436>02</x436>Back cover
    <x427>00</x427>For any audience
    <x437>03<x437>Image
    <resourceversion>
        <x441>02</x441>Downloadable file
        <resourceversionfeature>
            <x442>01</x442>File format
            <x439>D502</x439>JPEG
        </resourceversionfeature>
        <resourceversionfeature>
            <x442>02</x442>Width in pixels
            <x439>125</x439>
        </resourceversionfeature>
        <x435>http://www.publisher.com/b2b/​covers/​9780001234567​-bc125px.jpg</x435>URL
    </resourceversion>
</supportingresource>
<supportingresource>Second resource
    <x436>02</x436>Back cover
    <x427>00</x427>For any audience
    <x437>04<x437>Text
    <resourceversion>
        <x441>02</x441>Downloadable file
        <resourceversionfeature>
            <x442>01</x442>File format
            <x439>E112</x439>Plain text
        </resourceversionfeature>
        <x435>http://www.publisher.com/b2b/​covers/​9780001234567​-text.txt</x435>URL
    </resourceversion>
<supportingresource>
There are two resources here, an image of the back cover and the text from the back cover, distinguished by their <ResourceMode>. (Note text from the jacket flaps should be treated as back cover copy.)
Resource feature composite

The <ResourceFeature> is used to specify features shared by all versions of a particular resource – for example a caption or a required credit, or the running time of a video or audio resource.

ResourceFeature ResourceFeatureType ResourceFeatureType FeatureValue FeatureNote

It is best practice to use <ResourceFeature> to attach a caption to any image of a contributor, to identify the contributor. Normally the caption should simply be the name of the contributor, but if the image shows several people, it should carry more explanation:

Caption for contributor image resource, with identifier for the contributor
using Reference names
<ResourceFeature>
    <ResourceFeatureType>02<ResourceFeatureType>
    <FeatureNote>Michael Marshall, left, with agent Jonny Geller</FeatureNote>
</ResourceFeature>
<ResourceFeature>
    <ResourceFeatureType>05<ResourceFeatureType>
    <FeatureValue>0000000121034451</FeatureValue>
</ResourceFeature>
using Short tags, with additional required credit
<resourcefeature>
    <x438>02<x438>Caption
    <x440>Michael Marshall, left, with agent Jonny Geller</x440>
</resourcefeature>
<resourcefeature>
    <x438>05<x438>ISNI of contributor
    <x439>0000000121034451</x439>
</resourcefeature>
<resourcefeature>
    <x438>01<x438>Required photo credit
    <x440>© Well Lit Photo Agency</x440>
</resourcefeature>
The identifier (an ISNI in this example, but a proprietary ID could also be used) is only required when there are multiple contributors, and it becomes necessary to link photos unambiguously to particular contributors. Somewhat obviously, the identifier must also appear in a <Contributor> composite within the same ONIX record.
Note that credits specified with <ResourceFeatureType> code 01 are required, and displaying the credit alongside the resource (eg on a retailer website) should be treated by ONIX recipients as a condition of use of the resource.

If required, captions and credits can carry XHTML markup, but this is rarely necessary.

Resource version composite

The <ResourceVersion> composite describes a particular version of a resource: there may be other versions in subsequent repeats of the composite – for example high quality and thumbnail versions of an image, highly-compressed and CD-quality versions of audio, or video content compressed using different codecs.

P.16.7 Resource form

This element is used to differentiate between:

  • ‘downloadable resources’ – URLs from which an ONIX recipient may download a resource, for example an image that can then be added to the catalog page. Practically, these might be http:, https: or ftp: protocol URIs from which a resource such as an image or other file may be downloaded;
  • ‘linkable resources’ that are simply URLs that the recipient might add to a web page (for example, a catalog page within an online store might list a variety of URIs leading to further information). For practical purposes, these will be http: or https: protocol URIs, and would most likely be used as the value of a src attribute of an <img> tag or the value of an href attribute of an <a> tag;
    • this is sometimes known as ‘deep linking’;
    • linkable resources are also – by their nature – often downloadable too, but recipients should use resources in the manner intended by the provider;
  • ‘embeddable resources’, URLs from which the recipient may download embeddable HTML snippets (for example, <iframe> or <object> content that should be embedded into the catalog page).

In all cases, the URL itself is specified in the <ResourceLink> data element, but the manner in which it should be used depends on the Resource form.

Resource version feature composite

The <ResourceVersionFeature> composite is used to specify various features of a particular version of resource – for example the file format and pixel size of an image, or the filesize of any necessary download.

ResourceVersionFeature ResourceVersionFeatureType ResourceVersionFeatureType FeatureValue FeatureNote

It is best practice to provide at least the following metadata ‘features’ for each resource version:

  • for image and video resources, the pixel dimensions;
  • for all types of resources, the file format;
  • for time-based resources such as audio and video, the running time should be provided (in the <ResourceFeature> composite, not in <ResourceVersionFeature>).

Note the difference between <ResourceFeature> which carries attributes shared by all versions of a resource, and <ResourceVersionFeature> which carries attributes applying to a single specific version of that resource.

Content date composite

The most critical function of the <ContentDate> composite is to specify date limits that a publisher may set to control use of any supporting resources – most pointedly, to set an embargo date on the use of any cover image or text extract from the product. An embargo date indicates that the resource should not be used before a particular date – but equally a content date can indicate that a resource should not be used after a particular date. As such, they can indicate that a resource is no longer relevant and should be removed from display – and this provides a mechanism for removal of previously-supplied resources without requiring a substitute to be provided (eg ‘deleting’ an outdated cover image from an online store without replacing it with a revised cover image).

The composite should also be used to indicate when the collateral resource was last updated. Note that a date with <ContentDateRole> code 17 (Last updated) is of critical importance when dealing with downloaded or embedded resources, and it should always be used by data providers to indicate a new version of the resource is available. Recipients should check this date and re-download a new version of the resource whenever required. Note that use of <ContentDateRole> code 17 is preferred to use of the datestamp attribute to indicate the Last updated date for the resource.

Timed cover reveal: embargo on use of cover image
using Reference names
<ResourceVersion>
    <ResourceForm>02</ResourceForm>
    <ResourceVersionFeature>
        <ResourceVersionFeatureType>03</ResourceVersionFeatureType>
        <FeatureValue>1750</FeatureValue>
    </ResourceVersionFeature>
    <ResourceLink>http://www.sagepublications.com/​covers/​9780001234567.jpeg​</ResourceLink>
    <ContentDate>
        <ContentDateRole>27</ContentDateRole>
        <Date dateformat="00">20141021</Date>
    </ContentDate>
    <ContentDate>
        <ContentDateRole>17</ContentDateRole>
        <Date dateformat="00">20141021</Date>
    </ContentDate>
    <ContentDate>
        <ContentDateRole>14</ContentDateRole>
        <Date dateformat="13">20141023T1200Z​</Date>
    </ContentDate>
</ResourceVersion>
using Short tags
<resourceversion>
    <x441>02</x441>Downloadable resource
    <resourceversionfeature>
        <x442>03</x442>Width in pixels
        <x439>1750</x439>
    </resourceversionfeature>
    <x435>http://www.sagepublications.com/​covers/​9780001234567.jpeg​</x435>
    <contentdate>
        <x429>27</x429>Available from
        <b306 dateformat="00">20141021</b306>21st October
    </contentdate>
    <contentdate>
        <x429>17</x429>Last updated date
        <b306 dateformat="00">20141021</b306>
    </contentdate>
    <contentdate>
        <x429>14</x429>Use from (ie embargoed until)
        <b306 dateformat="13">20141023T1200Z​</b306>noon (UTC) on 23rd October
    </contentdate>
</resourceversion>
In this example, the cover will be (or has been) available for download from 21st October, but must not be used (displayed) to consumers until the embargo expires at noon on 23rd October.

P.17 Prizes

For literary prizes and other awards, best practice is to list key prizes and awards gained by the product itself – or perhaps more often, by the work manifested in the product. So for example a literary prize awarded to a work when the hardcover was the only version available, applies equally to the softcover, and should be listed in the ONIX Product record for both versions. However, an award for exceptional quality printing and binding likely applies to only one version, and should not be listed on the other. If a product has been awarded nothing (so far!) then the entire <Prize> composite should be omitted.

Generalized awards given to contributors should not be listed here, nor should awards given to other works by the same contributor etc. These can if required be listed within the relevant <Contributor> composite.

Prize or award composite
Prize PrizeName PrizeYear PrizeCountry PrizeCode PrizeStatement PrizeJury
Winner of the 2010 Prix Renaudot
using Reference names
<Prize>
    <PrizeName>Prix Renaudot</PrizeName>
    <PrizeYear>2010</PrizeYear>
    <PrizeCode>01</PrizeCode>
    <PrizeStatement>Lauréat du Prix Renaudot 2010</PrizeStatement>
</Prize>
using Short tags, with alternative language prize statements
<prize>
    <g126>Prix Renaudot</g126>
    <g127>2010</g127>
    <g129>01</g129>Winner
    <x503 language="fre">Lauréat du Prix Renaudot, 2010</x503>
    <x503 language="eng">Winner of the Prix Renaudot, 2010</x503>
</prize>
<PrizeCode> should always be included, even if the particular prize does not name a runner up or a shortlist. Not all prizes use the long-list / short-list / winner terminology from List 41 to denote degrees of success. A particular prize may use terminology like ‘nominated’, ‘semi-finalist’ or any other term. If the term used indicates that a book is selected by the judging panel for the final category before the winner is announced – as does semi-finalist, for example – then ‘short listed’ (code 04) is a reasonable choice in <PrizeCode>. For a prize like the Newbery Medal, the Medal-winning book may be termed the ‘winner’ (<PrizeCode> 01) and Honor books as ‘commended’ (code 03). In all cases, an additional <PrizeStatement> can make it clear what the proper terminology is for the particular prize.

It may occasionally be useful to list the country in which an award is given within a <Prize> composite – for example, with works in translation, awards given to the original language version may be unfamiliar to potential readers of the translated version.

If a product or work has been awarded multiple prizes, each should be listed in a separate repeat of the <Prize composite. In XML terms, the order they are listed in is not significant: however, it is best practice to list them in descending order of prestige – some ONIX recipients may only retain and use information on the first few repeats of the composite, and providing a very high number of prizes – say more than ten – is unnecessary and undesirable.

There is no option to list prizes and awards in a free-text manner within Group P.17. If a structured description of prizes and awards is not available, then data providers could include a free-text description as part of the normal descriptive text provided in <TextContent> within Group P.14.

Block 3: Content detail

Content detail composite

Block 3 – the <ContentDetail> composite – contains one or more repeats of the <ContentItem> composite. It’s intended to allow the structured description of articles, chapters and other parts of a textual publication, usually in much more detail than a single table of contents. <ContentDetail> is appropriate for describing books in an omnibus, chapters in a book, articles in a scholarly monograph or conference report, poems or short stories in an anthology, and can provide much more detail about volumes in a collection sold as a multi-component product (commonly called a ‘set’) than could be included in <ProductPart> in Group P.4 (<ProductPart> is concerned only with the physical or digital nature of the individual components, and not their titles, collation order, authorship and so on). The entire composite is unnecessary for simple fiction or narrative non-fiction products where a table of contents is more simply provided in Group P.14, and in many cases might be omitted entirely.

ContentDetail ContentItem must include at least one, unless product record is a partial or ‘block update’ (when <ContentDetail/> may be empty in order to ‘delete’ previously supplied data)

It should be said that extensive use of Block 3 may be beyond the technical capabilities of all but the most sophisticated data providers and recipients.

P.18 Content items

The structure of the <ContentItem> composite that forms the whole of Group P.18 is akin to a complete ONIX record in miniature – and since some parts of a product may in fact be products in their own right (eg parts in a multi-component product, or articles or chapters from a book sold individually), it may be very similar to sections of the ONIX record for those individual products:

  • <ContentItem> composite – describes a single part, chapter, article etc;
    • <LevelSequenceNumber> – describes the position of the item in the hierarchy of content items;
    • <TextItem> composite – nature of the content item, including any identifiers for the item, and the extent;
      • <TextItemType>;
      • <TextItemIdentifier> composite;
      • <PageRun> composite;
      • <NumberOfPages>;
    • <ComponentTypeName> (eg Chapter, Part, Article);
    • <ComponentNumber> (eg a chapter or article number);
    • <TitleDetail> composite – see Group P.6;
    • <Contributor> composite – see Group P.7;
    • <Subject> composite – see Group P.12;
    • <NameAsSubject> composite – see Group P.12;
    • <TextContent> composite – see Group P.14;
    • <CitedContent> composite – see Group P.15;
    • <SupportingResource> composite – see Group P.16;
    • <RelatedWork> composite – see Group P.22.
ContentItem LevelSequenceNumber LevelSequenceNumber TextItem AVItem ComponentTypeName ComponentTypeName ComponentNumber ComponentNumber TitleDetail Contributor ContributorStatement ContributorStatement NoContributor NoContributor Language Subject NameAsSubject TextContent CitedContent SupportingResource SupportingResource RelatedWork RelatedProduct continued in part 2 continued from part 1 must not omit both
items within a multi-volume boxed set
using Reference names
<DescriptiveDetail>
    <ProductComposition>10</ProductComposition>
    <ProductForm>SC</ProductForm>
    . . .
    <NoCollection/>
    <TitleDetail>
        <TitleType>01</TitleType>
        <TitleElement>
            <TitleElementLevel>01</TitleElementLevel>
            <TitleText textcase="02">His Dark Materials​</TitleText>
        </TitleElement>
    </TitleDetail>
    . . .
</DescriptiveDetail>
. . . .
<ContentDetail>
    <ContentItem>
        <LevelSequenceNumber>1</LevelSequenceNumber>
        <TextItem>
            <TextItemType>01</TextItemType>
            <TextItemIdentifier>
                <TextItemIDType>03</TextItemIDType>
                <IDValue>9780375823459</IDValue>
            </TextItemIdentifier>
            <TextItemIdentifier>
                <TextItemIDType>15</TextItemIDType>
                <IDValue>9780375823459</IDValue>
            </TextItemIdentifier>
        </TextItem>
        <ComponentTypeName>Book</ComponentTypeName>
        <ComponentNumber>One</ComponentNumber>
        <TitleDetail>
            <TitleType>01</TitleType>
            <TitleElement>
                <TitleElementLevel>04</TitleElementLevel>
                <TitlePrefix textcase="02">The</TitlePrefix>
                <TitleWithoutPrefix textcase="02">Golden Compass​</TitleWithoutPrefix>
            </TitleElement>
        </TitleDetail>
        <TitleDetail>
            <TitleType>08</TitleType>
            <TitleElement>
                <TitleElementLevel>04</TitleElementLevel>
                <TitleText textcase="02">Northern Lights​</TitleText>
            </TitleElement>
        </TitleDetail>
    </ContentItem>
    <ContentItem>
        <LevelSequenceNumber>2</LevelSequenceNumber>
        <TextItem>
            <TextItemType>01</TextItemType>
            <TextItemIdentifier>
                <TextItemIDType>03</TextItemIDType>
                <IDValue>9780375823466</IDValue>
            </TextItemIdentifier>
            <TextItemIdentifier>
                <TextItemIDType>15</TextItemIDType>
                <IDValue>9780375823466</IDValue>
            </TextItemIdentifier>
        </TextItem>
        <ComponentTypeName>Book</ComponentTypeName>
        <ComponentNumber>Two</ComponentNumber>
        <TitleDetail>
            <TitleType>01</TitleType>
            <TitleElement>
                <TitleElementLevel>04</TitleElementLevel>
                <TitlePrefix textcase="02">The</TitlePrefix>
                <TitleWithoutPrefix textcase="02">Subtle Knife​</TitleWithoutPrefix>
            </TitleElement>
        </TitleDetail>
    </ContentItem>
    <ContentItem>
        <LevelSequenceNumber>3</LevelSequenceNumber>
        <TextItem>
            <TextItemType>01</TextItemType>
            <TextItemIdentifier>
                <TextItemIDType>03</TextItemIDType>
                <IDValue>9780375823350</IDValue>
            </TextItemIdentifier>
            <TextItemIdentifier>
                <TextItemIDType>15</TextItemIDType>
                <IDValue>9780375823350</IDValue>
            </TextItemIdentifier>
        </TextItem>
        <ComponentTypeName>Book</ComponentTypeName>
        <ComponentNumber>Three</ComponentNumber>
        <TitleDetail>
            <TitleType>01</TitleType>
            <TitleElement>
                <TitleElementLevel>04</TitleElementLevel>
                <TitlePrefix textcase="02">The</TitlePrefix>
                <TitleWithoutPrefix textcase="02">Amber Spyglass​</TitleWithoutPrefix>
            </TitleElement>
        </TitleDetail>
    </ContentItem>
</ContentDetail>
using Short tags
<descriptivedetail>
    <x314>10</x314>Multi-component product
    <b012>SC</b012>In slipcase
    . . .Various elements omitted
    <x411/>No collection detail
    <titledetail>
        <b202>01</b202>Distinctive title
        <titleelement>
            <x409>01</x409>Product level
            <b203 textcase="02">His Dark Materials​</b203>Title case
        </titleelement>
    </titledetail>
    . . .
</descriptivedetail>
. . . .
<contentdetail>
    <contentitem>
        <b284>1</b284>First content item
        <textitem>
            <b290>01</b290>Textual work
            <textitemidentifier>
                <b285>03</b285>GTIN-13
                <b244>9780375823459</b244>of this content item
            </textitemidentifier>
            <textitemidentifier>
                <b285>15</b285>ISBN
                <b244>9780375823459</b244>of this content item
            </textitemidentifier>
        </textitem>
        <b288>Book</b288>
        <b289>One</b289>
        <titledetail>
            <b202>01</b202>Distinctive title
            <titleelement>
                <x409>04</x409>Content item level
                <b030 textcase="02">The</b030>
                <b031 textcase="02">Golden Compass​</b031>
            </titleelement>
        </titledetail>
        <titledetail>
            <b202>08</b202>Former title
            <titleelement>
                <x409>04</x409>Content item level
                <b203 textcase="02">Northern Lights​</b203>
            </titleelement>
        </titledetail>
    </contentitem>
    <contentitem>
        <b284>2</b284>Second content item
        <textitem>
            <b290>01</b290>Textual work
            <textitemidentifier>
                <b285>03</b285>GTIN-13
                <b244>9780375823466</b244>of this content item
            </textitemidentifier>
            <textitemidentifier>
                <b285>15</b285>ISBN
                <b244>9780375823466</b244>of this content item
            </textitemidentifier>
        </textitem>
        <b288>Book</b288>
        <b289>Two</b289>
        <titledetail>
            <b202>01</b202>Distinctive title
            <titleelement>
                <x409>04</x409>Content item level
                <b030 textcase="02">The</b030>
                <b031 textcase="02">Subtle Knife​</b031>
            </titleelement>
        </titledetail>
    </contentitem>
    <contentitem>
        <b284>3</b284>Third content item
        <textitem>
            <b290>01</b290>Textual work
            <textitemidentifier>
                <b285>03</b285>GTIN-13
                <b244>9780375823350</b244>of this content item
            </textitemidentifier>
            <textitemidentifier>
                <b285>15</b285>ISBN
                <b244>9780375823350</b244>of this content item
            </textitemidentifier>
        </textitem>
        <b288>Book</b288>
        <b289>Three</b289>
        <titledetail>
            <b202>01</b202>Distinctive title
            <titleelement>
                <x409>04</x409>Content item level
                <b030 textcase="02">The</b030>
                <b031 textcase="02">Amber Spyglass​</b031>
            </titleelement>
        </titledetail>
    </contentitem>
</contentdetail>
The product as a whole – the three slipcased volumes – is not part of a collection, although if sold separately, the individual volumes are part of a collection entitled ‘His Dark Materials’. This collection title is used as the product title of the slipcased product. Used like this, <ContentDetail> is a natural complement for <ProductPart>. Three <ProductPart> composites would indicate that each volume in the slipcase is a softback – the three product identifiers that apply to the individual parts may be duplicated between Group P.4 and Group P.18.
detailed table of contents, with contributors listed for each chapter
using Reference names
<ContentDetail>
    <ContentItem>
        <LevelSequenceNumber>1​</LevelSequenceNumber>
        <TextItem>
            <TextItemType>02</TextItemType>
            <PageRun>
                <FirstPageNumber>ix​</FirstPageNumber>
            </PageRun>
        </TextItem>
        <TitleDetail>
            <TitleType>01</TitleType>
            <TitleElement>
                <TitleElementLevel>04​</TitleElementLevel>
                <TitleText textcase="02">Acknowledgements​</TitleText>
            </TitleElement>
        </TitleDetail>
    </ContentItem>
    <ContentItem>
        <LevelSequenceNumber>2​</LevelSequenceNumber>
        <TextItem>
            <TextItemType>02</TextItemType>
            <PageRun>
                <FirstPageNumber>1​</FirstPageNumber>
            </PageRun>
        </TextItem>
        <TitleDetail>
            <TitleType>01</TitleType>
            <TitleElement>
                <TitleElementLevel>04​</TitleElementLevel>
                <TitleText textcase="02">Introduction​</TitleText>
            </TitleElement>
        </TitleDetail>
        <Contributor>
            <SequenceNumber>1</SequenceNumber>
            <ContributorRole>A24</ContributorRole>
            <PersonNameInverted>Bordo, Michael D.​</PersonNameInverted>
        </Contributor>
        <Contributor>
            <SequenceNumber>2</SequenceNumber>
            <ContributorRole>A24</ContributorRole>
            <PersonNameInverted>Taylor, Alan M.​</PersonNameInverted>
        </Contributor>
        <Contributor>
            <SequenceNumber>3</SequenceNumber>
            <ContributorRole>A24</ContributorRole>
            <PersonNameInverted>Williamson, Jeffrey​</PersonNameInverted>
        </Contributor>
    </ContentItem>
    <ContentItem>
        <LevelSequenceNumber>3​</LevelSequenceNumber>
        <TextItem>
            <TextItemType>03</TextItemType>
        </TextItem>
        <TitleDetail>
            <TitleType>01</TitleType>
            <TitleElement>
                <TitleElementLevel>04​</TitleElementLevel>
                <PartNumber>Part I​</PartNumber>
                <TitlePrefix textcase="02">The​</TitlePrefix>
                <TitleWithoutPrefix textcase="02">Rise and Fall (and Rise) of Market Integration​</TitleWithoutPrefix>
            </TitleElement>
        </TitleDetail>
    </ContentItem>
    <ContentItem>
        <LevelSequenceNumber>3.1​</LevelSequenceNumber>
        <TextItem>
            <TextItemType>03</TextItemType>
            <PageRun>
                <FirstPageNumber>13​</FirstPageNumber>
            </PageRun>
        </TextItem>
        <TitleDetail>
            <TitleType>01</TitleType>
            <TitleElement>
                <TitleElementLevel>04​</TitleElementLevel>
                <PartNumber>1</PartNumber>
                <TitleText textcase="02">Commodity Market Integration, 1500–2000​</TitleText>
            </TitleElement>
        </TitleDetail>
        <Contributor>
            <SequenceNumber>1</SequenceNumber>
            <ContributorRole>A01​</ContributorRole>
            <PersonNameInverted>Findlay, Ronald​</PersonNameInverted>
        </Contributor>
        <Contributor>
            <SequenceNumber>2</SequenceNumber>
            <ContributorRole>A01</ContributorRole>
            <PersonNameInverted>O’Rourke, Kevin H.​</PersonNameInverted>
        </Contributor>
    </ContentItem>
    <ContentItem>
        <LevelSequenceNumber>3.2</LevelSequenceNumber>
        <TextItem>
            <TextItemType>03</TextItemType>
            <PageRun>
                <FirstPageNumber>65​</FirstPageNumber>
            </PageRun>
        </TextItem>
        <TitleDetail>
            <TitleType>01</TitleType>
            <TitleElement>
                <TitleElementLevel>04​</TitleElementLevel>
                <PartNumber>2</PartNumber>
                <TitleText textcase="02">International Migration and the Integration of Labor Markets​</TitleText>
            </TitleElement>
        </TitleDetail>
        <Contributor>
            <SequenceNumber>1</SequenceNumber>
            <ContributorRole>A01</ContributorRole>
            <PersonNameInverted>Chiswick, Barry R.​</PersonNameInverted>
        </Contributor>
        <Contributor>
            <SequenceNumber>2</SequenceNumber>
            <ContributorRole>A01</ContributorRole>
            <PersonNameInverted>Hatton, Timothy J.​</PersonNameInverted>
        </Contributor>
    </ContentItem>
    <ContentItem>
        <LevelSequenceNumber>3.3​</LevelSequenceNumber>
        <TextItem>
            <TextItemType>03</TextItemType>
            <PageRun>
                <FirstPageNumber>121​</FirstPageNumber>
            </PageRun>
        </TextItem>
        <TitleDetail>
            <TitleType>01</TitleType>
            <TitleElement>
                <TitleElementLevel>04​</TitleElementLevel>
                <PartNumber>3</PartNumber>
                <TitleText textcase="02">Globalization and Capital Markets​</TitleText>
            </TitleElement>
        </TitleDetail>
        <!-- contributors omitted for brevity -->
    </ContentItem>
    <ContentItem>
        <LevelSequenceNumber>4​</LevelSequenceNumber>
        <TextItem>
            <TextItemType>03</TextItemType>
        </TextItem>
        <TitleDetail>
            <TitleType>01</TitleType>
            <TitleElement>
                <TitleElementLevel>04​</TitleElementLevel>
                <PartNumber>Part II​</PartNumber>
                <TitlePrefix textcase="02">The​</TitlePrefix>
                <TitleWithoutPrefix textcase="02">Great Divergence, Geography, and Technology​</TitleWithoutPrefix>
            </TitleElement>
        </TitleDetail>
    </ContentItem>
    <ContentItem>
        <LevelSequenceNumber>4.1​</LevelSequenceNumber>
        <TextItem>
            <TextItemType>03</TextItemType>
            <PageRun>
                <FirstPageNumber>191​</FirstPageNumber>
            </PageRun>
        </TextItem>
        <TitleDetail>
            <TitleType>01</TitleType>
            <TitleElement>
                <TitleElementLevel>04​</TitleElementLevel>
                <PartNumber>4</PartNumber>
                <TitleText textcase="02">Globalization and Convergence​</TitleText>
            </TitleElement>
        </TitleDetail>
        <!-- contributors omitted for brevity -->
    </ContentItem>
    <ContentItem>
        <LevelSequenceNumber>4.2​</LevelSequenceNumber>
        <TextItem>
            <TextItemType>03</TextItemType>
            <PageRun>
                <FirstPageNumber>227​</FirstPageNumber>
            </PageRun>
        </TextItem>
        <TitleDetail>
            <TitleType>01</TitleType>
            <TitleElement>
                <TitleElementLevel>04​</TitleElementLevel>
                <PartNumber>5</PartNumber>
                <TitleText textcase="02">Does Globalization Make the World More Unequal?​</TitleText>
            </TitleElement>
        </TitleDetail>
        <!-- contributors omitted for brevity -->
    </ContentItem>
    . . .
</ContentDetail>
using Short tags
<contentdetail>
    <contentitem>
        <b284>1</b284>Item 1
        <textitem>
            <b290>02</b290>Front matter
            <pagerun>
                <b286>ix</b286>
            </pagerun>
        </textitem>
        <titledetail>
            <b202>01</b202>Distinctive title
            <titleelement>
                <x409>04</x409>Content item level
                <b203 textcase="02">Acknowledgements​</b203>
            </titleelement>
        </titledetail>
    </contentitem>
    <contentitem>
        <b284>2</b284>Item 2
        <textitem>
            <b290>02</b290>Front matter
            <pagerun>
                <b286>1</b286>
            </pagerun>
        </textitem>
        <titledetail>
            <b202>01</b202>Distinctive title
            <titleelement>
                <x409>04</x409>Content item level
                <b203 textcase="02">Introduction​</b203>
            </titleelement>
        </titledetail>
        <contributor>
            <b034>1</b034>
            <b035>A24</b035>
            <b037>Bordo, Michael D.​</b037>
        </contributor>
        <contributor>
            <b034>2</b034>
            <b035>A24</b035>
            <b037>Taylor, Alan M.​</b037>
        </contributor>
        <contributor>
            <b034>3</b034>
            <b035>A24</b035>
            <b037>Williamson, Jeffrey​</b037>
        </contributor>
    </contentitem>
    <contentitem>
        <b284>3</b284>Item 3
        <textitem>
            <b290>03</b290>Body matter
        </textitem>
        <titledetail>
            <b202>01</b202>Distinctive title
            <titleelement>
                <x409>04</x409>Content item level
                <x410>Part I</x410>
                <b030 textcase="02">The​</b030>
                <b031 textcase="02">Rise and Fall (and Rise) of Market Integration​</b031>
            </titleelement>
        </titledetail>
    </contentitem>
    <contentitem>
        <b284>3.1</b284>Item 3 subitem 1
        <textitem>
            <b290>03</b290>Body matter
            <pagerun>
                <b286>13</b286>
            </pagerun>
        </textitem>
        <titledetail>
            <b202>01</b202>Distinctive title
            <titleelement>
                <x409>04</x409>Content item level
                <x410>1</x410>
                <b203 textcase="02">Commodity Market Integration, 1500–2000​</b203>
            </titleelement>
        </titledetail>
        <contributor>
            <b034>1</b034>
            <b035>A01</b035>
            <b037>Findlay, Ronald​</b037>
        </contributor>
        <contributor>
            <b034>2</b034>
            <b035>A01</b035>
            <b037>O’Rourke, Kevin H.​</b037>
        </contributor>
    </contentitem>
    <contentitem>
        <b284>3.2</b284>Item 3 subitem 2
        <textitem>
            <b290>03</b290>Body matter
            <pagerun>
                <b286>65</b286>
            </pagerun>
        </textitem>
        <titledetail>
            <b202>01</b202>Distinctive title
            <titleelement>
                <x409>04</x409>Content item level
                <x410>2</x410>
                <b203 textcase="02">International Migration and the Integration of Labor Markets​</b203>
            </titleelement>
        </titledetail>
        <contributor>
            <b034>1</b034>
            <b035>A01</b035>
            <b037>Chiswick, Barry R.​</b037>
        </contributor>
        <contributor>
            <b034>2</b034>
            <b035>A01</b035>
            <b037>Hatton, Timothy J.​</b037>
        </contributor>
    </contentitem>
    <contentitem>
        <b284>3.3</b284>Item 3 subitem 3
        <textitem>
            <b290>03</b290>Body matter
            <pagerun>
                <b286>121</b286>
            </pagerun>
        </textitem>
        <titledetail>
            <b202>01</b202>Distinctive title
            <titleelement>
                <x409>04</x409>Content item level
                <x410>3</x410>
                <b203 textcase="02">Globalization and Capital Markets​</b203>
            </titleelement>
        </titledetail>
        <!-- contributors omitted for brevity -->
    </contentitem>
    <contentitem>
        <b284>4</b284>Item 4
        <textitem>
            <b290>03</b290>Body matter
        </textitem>
        <titledetail>
            <b202>01</b202>Distinctive title
            <titleelement>
                <x409>04</x409>Content item level
                <x410>Part II</x410>
                <b030 textcase="02">The​</b030>
                <b031 textcase="02">Great Divergence, Geography, and Technology​</b031>
            </titleelement>
        </titledetail>
    </contentitem>
    <contentitem>
        <b284>4.1</b284>item 4 subitem 1
        <textitem>
            <b290>03</b290>Body matter
            <pagerun>
                <b286>191</b286>
            </pagerun>
        </textitem>
        <titledetail>
            <b202>01</b202>Distinctive title
            <titleelement>
                <x409>04</x409>Content item level
                <x410>4</x410>
                <b203 textcase="02">Globalization and Convergence​</b203>
            </titleelement>
        </titledetail>
        <!-- contributors omitted for brevity -->
    </contentitem>
    <contentitem>
        <b284>4.2</b284>Item 4 subitem 2
        <textitem>
            <b290>03</b290>Body matter
            <pagerun>
                <b286>227</b286>
            </pagerun>
        </textitem>
        <titledetail>
            <b202>01</b202>Distinctive title
            <titleelement>
                <x409>04</x409>Content item level
                <x410>5</x410>
                <b203 textcase="02">Does Globalization Make the World More Unequal?​</b203>
            </titleelement>
        </titledetail>
        <!-- contributors omitted for brevity -->
    </contentitem>
    . . .
</contentdetail>

The above table of contents is structured like so:

  • Acknowledgements
  • Introduction, by Michael D. Bordo, Alan M. Taylor and Jeffrey G. Williamson
  • Part I – The Rise and Fall (and Rise) of Market Integration
    • 1. Commodity Market Integration, 1500–2000, by Ronald Findlay and Kevin H. O’Rourke
    • 2. International Migration and the Integration of Labor Markets, by Barry R. Chiswick and Timothy J. Hatton
    • 3. Globalization and Capital Markets, further contributors omitted for brevity
  • Part II – The Great Divergence, Geography, and Technology
    • 4. Globalization and Convergence
    • 5. Does Globalization Make the World More Unequal?

The Introduction and each of the Arabic numbered ‘chapters’ has individual contributors and page numbers, whereas the roman numbered Parts do not.

It would clearly be possible for the same table of contents to be provided in an XHTML-marked up list in Group P.14:

  • <Text textformat="05"><ul><li>Acknowledgements​</li><li>Introduction, <em>by Michael D. Bordo, Alan M. Taylor and Jeffrey G. Williamson</em>​</li><li>Part I – The Rise and Fall (and Rise) of Market Integration<ul><li>1. Commodity Market Integration, 1500–2000, <em>by Ronald Findlay and Kevin H. O’Rourke</em>​</li><li>2. International Migration and the Integration of Labor Markets, <em>by Barry R. Chiswick and Timothy J. Hatton</em>​</li><li>3. Globalization and Capital Markets, <em>further contributors omitted for brevity</em>​</li></ul>​</li><li>Part II – The Great Divergence, Geography, and Technology<ul><li>4. Globalization and Convergence​</li><li>5. Does Globalization Make the World More Unequal?​</li><li>…​</li>​</ul>​</li>​</ul>​</Text>

However, P.14 cannot be used to attach an abstract for each of the individual papers presented as ‘chapters’, or provide identifiers or subject categories for each of the chapters individually: this is possible using <TextContent>, <TextItemIdentifier> or <Subject> within each of the <ContentItem> composites.

DOIs assigned to each chapter
using Reference names
<ContentDetail>
    <ContentItem>
        <LevelSequenceNumber>1</LevelSequenceNumber>
        <TextItem>
            <TextItemType>03</TextItemType>
            <TextItemIdentifier>
                <TextItemIDType>06</TextItemIDType>
                <IDValue>10.4400/zuim.rdfg</IDValue>
            </TextItemIdentifier>
        </TextItem>
        <ComponentTypeName>Chapter</ComponentTypeName>
        <ComponentNumber>1</ComponentNumber>
    </ContentItem>
    <ContentItem>
        <LevelSequenceNumber>2</LevelSequenceNumber>
        <TextItem>
            <TextItemType>03</TextItemType>
            <TextItemIdentifier>
                <TextItemIDType>06</TextItemIDType>
                <IDValue>10.4400/zuim.qftk</IDValue>
            </TextItemIdentifier>
        </TextItem>
        <ComponentTypeName>Chapter</ComponentTypeName>
        <ComponentNumber>2</ComponentNumber>
    </ContentItem>
    . . .
</ContentDetail>
using Short tags
<contentdetail>
    <contentitem>
        <b284>1</b284>Item 1
        <textitem>
            <b290>03</b290>Body matter
            <textitemidentifier>
                <b285>06</b285>DOI for
                <b244>10.4400/zuim.rdfg</b244>Chapter 1
            </textitemidentifier>
        </textitem>
        <b288>Chapter</b288>
        <b289>1</b289>
    </contentitem>
    <contentitem>
        <b284>2</b284>Item 2
        <textitem>
            <b290>03</b290>Body matter
            <textitemidentifier>
                <b285>06</b285>DOI for
                <b244>10.4400/zuim.qftk</b244>Chapter 2
            </textitemidentifier>
        </textitem>
        <b288>Chapter</b288>
        <b289>2</b289>
    </contentitem>
    . . .
</contentdetail>
In the above example, the DOIs have been assigned to each chapter largely for marketing and discoverability purposes, as the chapters are not available as individual products. If each were available separately (eg each as a very small e‑book), then it would be appropriate to include each product’s ISBN or GTIN identifier.
Content item composite

This composite is repeated for each content item in the product. A single repeat of <ContentItem> within <ContentDetail> is unlikely, as it provides no more information than can be carried in other, more frequently used, parts of the Product record – in which case, the whole of Block 3 should be omitted.

P.18.1 Level sequence number

<LevelSequenceNumber> is concerned solely with the order and hierarchy of the content items – it does not necessarily match the numbering or naming scheme used within the product itself, so Chapter 1 might be numbered 3 if it is preceded by two front matter content items.

Numbering should proceed like this to indicate the sequential order and nesting of content items:

  • 1
  • 2
    • 2.1
      • 2.1.1
      • 2.1.2
    • 2.2
  • 3

Subsections can be nested to any necessary depth.

Text item composite

<ContentItem> must include either a text item or an audiovisual item. The former is used for paged media (including reflowable text)

The <TextItem> composite must contain a <TextItemType> element, and may contain an identifier for the text item – particularly if the item is also available as a solus product (for example where chapters in a book might also be available individually as print-on-demand chapters or e-publications, or where each of the content items is a volume also available for sale independently).

Possible values for <TextItemType> are limited to 01 for full works – where a work in included within a multi-component product – and 02–04 for front, body and back matter. Code 03 is used for individual body matter chapters within a book.

If <ContentItem> is used to deliver a fully-structured table of contents, then page numbering can also be included within <TextItem>.

TextItem TextItemType TextItemIdentifier PageRun NumberOfPages TextItemIdentifier TextItemIDType IDTypeName IDValue PageRun FirstPageNumber FirstPageNumber LastPageNumber LastPageNumber must include if ID is proprietary, otherwise omit
Audiovisual item composite

<ContentItem> must include either a text item or an audiovisual item. The latter is used for time-based media.

The <AVItem> composite must contain an <AVItemType> element, and may contain an identifier for the audiovisual item – particularly if the item is also available as a solus product (for example, where audio short stories withinin an audiobook might also be available individually as individual stories. Possible values for <AVItemType> are limited to 01 for full works such as individual short stories, and 02–04 for front, body and back matter. Code 03 is used for individual ‘chapters’ within an audiobook.

If <ContentItem> is used to deliver a fully-structured table of contents, then timecodes for each chapter or section can also be included within <AVItem>.

AVItem AVItemType AVItemIdentifier TimeRun AVDuration AVItemIdentifier AVItemIDType IDTypeName IDValue TimeRun StartTime EndTime must include if ID is proprietary, otherwise omit
Timecode for chapter three (there is no chapter title)
using Reference names
<ContentItem>
    <LevelSequenceNumber>4</LevelSequenceNumber>
    <AVItem>
        <AVItemType>03</AVItemType>
        <TimeRun>
            <StartTime>0010721</StartTime>
            <EndTime>0013214</EndTime>
        </TimeRun>
        <Duration>0002453</Duration>
    </AVItem>
    <ComponentTypeName>Chapter</ComponentTypeName>
    <ComponentNumber>3</ComponentNumber>
</ContentItem>
using Short tags
<ContentItem>
    <LevelSequenceNumber>4</LevelSequenceNumber>
    <AVItem>
        <AVItemType>03</AVItemType>
        <TimeRun>
            <StartTime>0010721</StartTime>67 mins 21 secs from beginning
            <EndTime>0013214</EndTime>
        </TimeRun>
        <Duration>0002453</Duration>24 mins 52 secs long
    </AVItem>
    <ComponentTypeName>Chapter</ComponentTypeName>
    <ComponentNumber>3</ComponentNumber>
</ContentItem>
AV timing counts from the beginning of the product. It is common to split audio or video material into ‘chunks’ for delivery, and there is not necessarily any relationship between chapters and sections of the book and the chunks – there may be several chapters per chunk, or more than a single chunk per chapter. Furthermore, chunks may be joined or split as they are traded through the supply chain, Because of this potential ‘rechunking’, timings counting from the start of a chunk are unreliable, and would have to be accompanied by a manifest listing each chunk.
P.18.9, P.18.10 Component type name and number

Note the contrast with <LevelSequenceNumber>. Level sequence number is concerned only with ordering of items within <ContentItem>, whereas <ComponentTypeName> and <ComponentNumber> must match the naming and numbering scheme used within the product itself.

Note also the potential overlap between Component type name and number and <PartNumber> within <TitleDetail>: in general, use <ComponentTypeName> and <ComponentNumber> only when there is no individual title for the content item (eg when chapters are named simply ‘Chapter 2’, ‘Chapter 3’ and so on), or when naming and numbering items within a multi-component product.

Title detail composite

<TitleDetail> should not in general carry any collection-level or product-level titles. For content items such as chapters or articles that feature in a table of contents, or works within an omnibus, <TitleElementLevel> should be code 04, which specifies a content item within a product. This also applies to components within a multi-component product, even if those components are also available as separate products. Of course, the Product records for those individual products would contain the same title element, but with <TitleElementLevel> 01 – because the title is the title of a product, not a content item within a product. Those records might include collection-level title elements too.

Contributor composite to Related product composite

These composites are identical to those in Groups P.7, P.10, P.12, P.14, P.15, P.16 and P.22, and similar best practices apply. It is through these composites that <ContentItem> adds value – without them, Block 3 is nothing more than a table of contents.

Note that sequence numbering within a group of <Contributor> composites should be independent of the sequence numbering of the contributors to the product as a whole, and of the numbering of contributors to other content items. Contributors to a content item should be numbered as if the item were itself a product.

Block 4: Publishing detail

Publishing detail composite

Block 4 – the <PublishingDetail> composite – is intended to carry information describing the branding (imprint) of the product, the publisher and the ‘global’ publishing status of the product, plus the publisher’s sales rights associated with the product.

Note that the ‘global’ publishing status information in Group P.20 may not apply to all markets where the product is available. Market-specific publishing status may be carried in Group P.25.

PublishingDetail Imprint Publisher CityOfPublication CountryOfPublication CountryOfPublication ProductContact PublishingStatus PublishingStatusNote PublishingStatusNote PublishingDate LatestReprintNumber LatestReprintNumber CopyrightStatement CopyrightStatement SalesRights ROWSalesRightsType ROWSalesRightsType SalesRestriction must include one or both use <SalesRestriction> within <SalesRights> instead

P.19 Publisher

Group P.19 is effectively mandatory within Block 4.

<Publisher> can also include links to websites associated with the publisher or its brands and business units.

There is often significant confusion over the nature of the imprint and publisher. In almost all cases, this can be clarified through understanding that the imprint is merely a brand name, whereas the publisher is a legal entity of some kind (often but not necessarily a commercial organization). The uncertainty arises because the organization may use its own name as its brand – this is almost always the case with small publishers. And naturally, when one publisher acquires another, one organization disappears, but its brand name may live on as a brand of the acquiring publisher. Over time, large publishers acquire a portfolio of brands or imprints.

Further uncertainly can arise where a series or collection of products becomes very large – does it become a brand in its own right? Ultimately, identities can be arranged in a hierarchy, from the narrowest (the title of a single book), through sub-series and series with their collection titles, to the imprint or brand which may encompass many books and collections of books, to a publisher with one or many brands, and eventually to the broadest (a conglomerate that owns several publishing companies). A workable rule of thumb is that the imprint is the broadest entity in that hierarchy that is not a legal entity, and the publisher is the narrowest entity that is a legal entity.

Imprint ImprintIdentifier ImprintName ImprintIdentifier ImprintIDType IDTypeName IDValue must not omit both must include if ID is proprietary, otherwise omit
Publisher PublishingRole PublisherIdentifier PublisherIdentifier PublisherName Funding Website PublisherIdentifier PublisherIDType IDTypeName IDValue must not omit both must include if ID is proprietary, otherwise omit
simple imprint and publisher
using Reference names
<Imprint>
    <ImprintName>Ballantine Books<ImprintName>
</Imprint>
<Publisher>
    <PublishingRole>01</PublishingRole>
    <PublisherName>Random House</PublisherName>
    <Website>
        <WebsiteRole>18</WebsiteRole>
        <WebsiteLink>http://ballantine.​atrandom.​com​</WebsiteLink>
    </Website>
</Publisher>
<CityOfPublication>New York</CityOfPublication>
<CountryOfPublication>US</CountryOfPublication>
using Short tags
<imprint>
    <b079>Ballantine Books<b079>Imprint or ‘brand’
</imprint>
<publisher>
    <b291>01</b291>Publisher
    <b081>Random House</b081>
    <website>
        <b367>18</b367>Publisher’s consumer website
        <b295>http://ballantine.​atrandom.​com​</b295>
    </website>
</publisher>
<b209>New York</b209>
<b083>US</b083>
imprint and publisher with publisher identifier
using Reference names
<Imprint>
    <ImprintName>Gabler<ImprintName>
</Imprint>
<Publisher>
    <PublishingRole>01</PublishingRole>
    <PublisherIdentifier>
        <PublisherIDType>05</PublisherIDType>
        <IDValue>5106257</IDValue>
    </PublisherIdentifier>
    <PublisherName>Gabler Verlag</PublisherName>
    <Website>
        <WebsiteRole>18</WebsiteRole>
        <WebsiteLink>http://www.​gabler.​de/​</WebsiteLink>
    </Website>
</Publisher>
<CityOfPublication>Wiesbaden</CityOfPublication>
<CountryOfPublication>DE</CountryOfPublication>
using Short tags
<imprint>
    <b079>Gabler<b079>
</imprint>
<publisher>
    <b291>01</b291>
    <publisheridentifier>
        <x447>05</x447>German ISBN Agency publisher ID
        <b244>5106257</b244>
    </publisheridentifier>
    <website>
        <b367>18</b367>Publisher’s consumer website
        <b295>http://www.​gabler.​de/​</b295>
    </website>
    <b081>Gabler Verlag</b081>
</publisher>
<b209>Wiesbaden</b209>
<b083>DE</b083>
transfer of ownership of product from one publisher to another – update from divesting publisher
using Reference names
<RecordReference>f3a85abd-f29e-4e0b-92cc-2fa6a0833022</RecordReference>
<NotificationType>08</NotificationType>
<RecordSourceType>01</RecordSourceType>
<RecordSourceName>XYZ Publishers</RecordSourceName>
<ProductIdentifier>
    <ProductIDType>15</ProductIDType>
    <IDValue>9780001234567</IDValue>
</ProductIdentifier>
. . .
<Publisher>
    <PublishingRole>09</PublishingRole>
    <PublisherName>ABCQ Books</PublisherName>
</Publisher>
<Publisher>
    <PublishingRole>13</PublishingRole>
    <PublisherName>XYZ Publishers</PublisherName>
</Publisher>
. . .
<PublishingDate>
    <PublishingDateRole>28</PublishingDateRole>
    <Date>20150105</Date>
</PublishingDate>
. . .
<ProductSupply>
    <SupplyDetail>
        . . .
        . . .
        <ProductAvailability>51</ProductAvailability>
        . . .
    </SupplyDetail>
</ProductSupply>
using Short tags
<a001>f3a85abd-f29e-4e0b-92cc-​2fa6a0833022​</a001>XYZ’s reference
<a002>08</a002>Notice of sale
<a194>01</a194>From publisher
<a197>XYZ Publishers</a197>
<productidentifier>
    <b221>15</b221>ISBN
    <b244>9780001234567</b244>
</productidentifier>
. . .
<publisher>
    <b291>09</b291>
    <b081>ABCQ Books</b081>New publisher
</publisher>
<publisher>
    <b291>13</b291>
    <b081>XYZ Publishers</b081>Old publisher
</publisher>
. . .
<publishingdate>
    <x448>28</x448>Date of transfer
    <b306>20150105</b306>
</publishingdate>
. . .
<productsupply>
    <supplydetail>
        . . .Old supplier
        . . .Returns conditions
        <j396>51</j396>Publisher no longer sells product in market
        . . .Last date for returns
    </supplydetail>
</productsupply>
transfer of ownership – matching update from acquiring publisher
using Reference names
<RecordReference>uk.co.abcq.1234567</RecordReference>
<NotificationType>09</NotificationType>
<RecordSourceType>01</RecordSourceType>
<RecordSourceName>ABCQ Books</RecordSourceName>
<ProductIdentifier>
    <ProductIDType>15</ProductIDType>
    <IDValue>9780001234567</IDValue>
</ProductIdentifier>
. . .
<Publisher>
    <PublishingRole>09</PublishingRole>
    <PublisherName>ABCQ Books</PublisherName>
</Publisher>
<Publisher>
    <PublishingRole>13</PublishingRole>
    <PublisherName>XYZ Publishers</PublisherName>
</Publisher>
. . .
<PublishingDate>
    <PublishingDateRole>28</PublishingDateRole>
    <Date>20150105</Date>
</PublishingDate>
. . .
<ProductSupply>
    <SupplyDetail>
        . . .
    </SupplyDetail>
</ProductSupply>
using Short tags
<a001>uk.co.abcq.1234567</a001>ABCQ’s reference
<a002>09</a002>Notice of acquisition
<a194>01</a194>From publisher
<a197>ABCQ Books</a197>
<productidentifier>
    <b221>15</b221>ISBN
    <b244>9780001234567</b244>
</productidentifier>
. . .
<publisher>
    <b291>09</b291>
    <b081>ABCQ Books</b081>New publisher
</publisher>
<publisher>
    <b291>13</b291>
    <b081>XYZ Publishers</b081>Old publisher
</publisher>
. . .
<publishingdate>
    <x448>28</x448>
    <b306>20150105</b306>Date of transfer
</publishingdate>
. . .
<productsupply>
    <supplydetail>
        . . .New supplier, availability and prices
    </supplydetail>
</productsupply>

The product was originally published by XYZ Publishers, but responsibility and existing stock has been transferred to ABCQ Books. Each publisher sends an update, notification type 08 for the divesting publisher, and 09 for the acquiring publisher. If block updates are in use, then assuming no other information is changing, at least ‘block zero’, Block 4 and Block 6 must be sent. Both publishers must name the acquiring publisher, ABCQ Books, as the publisher in Block 4, and should list the divesting publisher as well. Block 6 is optional for the divesting publisher, but may be used to specify returns details, which would often extend after the transition to the new publisher. Each publisher should use their own unique record reference. If necessary, the records can be paired on the basis of the product identifier (for example the ISBN).

To avoid possible problems with ONIX recipients who cannot process acquisitions and divestments correctly, the transfer of ownership update from the divesting publisher should be sent before the matching update from the acquiring publisher. No further updates should be sent by the former publisher.

Subsequent updates from ABCQ should simply use Publishing role code 01. Some while later, when any transferred stock is exhausted, ABCQ is likely to state the old ISBN is out of print, and to re-publish the product under its own new ISBN. The new Product record should then use <RelatedProduct> to state that the new ISBN replaces the old.

joint-branded flip-book (two books in one, bound back to back)
using Reference names
<Imprint>
    <ImprintName>Bloomsbury<ImprintName>
</Imprint>
<Imprint>
    <ImprintName>Scholastic Children’s Books<ImprintName>
</Imprint>
<Publisher>
    <PublishingRole>02</PublishingRole>
    <PublisherName>Bloomsbury Publishing</PublisherName>
    <Website>
        <WebsiteRole>18</WebsiteRole>
        <WebsiteLink>http://www.​bloomsbury.​com/​childrens​</WebsiteLink>
    </Website>
</Publisher>
<Publisher>
    <PublishingRole>02</PublishingRole>
    <PublisherName>Scholastic</PublisherName>
    <Website>
        <WebsiteRole>18</WebsiteRole>
        <WebsiteLink>http://http://www.​scholastic.​co.​uk/​zone/​</WebsiteLink>
    </Website>
</Publisher>
<CityOfPublication>London</CityOfPublication>
<CountryOfPublication>UK</CountryOfPublication>
using Short tags
<imprint>
    <b079>Bloomsbury<b079>Joint branding
</imprint>
<imprint>
    <b079>Scholastic Children’s Books<b079>
</imprint>
<publisher>
    <b291>02</b291>Co-publisher
    <b081>Bloomsbury Publishing</b081>
    <website>
        <b367>18</b367>
        <b295>http://www.​bloomsbury.​com/​childrens​</b295>
    </website>
</publisher>
<publisher>
    <b291>02</b291>Co-publisher
    <b081>Scholastic</b081>
    <website>
        <b367>18</b367>
        <b295>http://www.​scholastic.​co.​uk/​zone/​</b295>
    </website>
</publisher>
<b209>London</b209>
<b083>UK</b083>
Co-publishers can be listed as ‘publisher and co-publisher’, or as two co-publishers as shown above. The former approach is preferred when the two publishers have separate ISBNs for the same product (and thus there are two ONIX records), and the latter when a single shared ISBN is used.
Note that co-publisher (PublishingRole = 02) is not related to the idea of a ‘co-edition’. Co-publication means that both publishers are responsible for making a single product available. A co-edition is an arrangement where two publishers share manufacturing arrangements (eg sharing some printing plates), but each make a different product available.
book published in cooperation with another organization
using Reference names
<Imprint>
    <ImprintName>Kogan Page<ImprintName>
</Imprint>
<Publisher>
    <PublishingRole>01</PublishingRole>
    <PublisherName>Kogan Page</PublisherName>
</Publisher>
<Publisher>
    <PublishingRole>07</PublishingRole>
    <PublisherName>Chartered Institute of Public Relations</PublisherName>
</Publisher>
using Short tags, with additional contributor
<contributor>
    <b034>3</b034>
    <b035>A24</b035>Introduction by
    <b037>Swift, Dr. Antonia</b037>
    <professionalaffiliation>
        <b045>Chief Executive</b045>
        <b046>Chartered Institute of Public Relations</b046>
    </professionalaffiliation>
</contributor>
. . .
<imprint>
    <b079>Kogan Page<b079>
</imprint>
<publisher>
    <b291>01</b291>Publisher
    <b081>Kogan Page</b081>
</publisher>
<publisher>
    <b291>07</b291>In association with
    <b081>Chartered Institute of Public Relations</b081>
</publisher>
The professional association is not a co-publisher, but lends its brand to the publication. The association or its staff may also be involved editorially.
Imprint or brand composite

Imprint or branding information is typically provided as a simple imprint name – the name that appears on the title page or title verso of a book, or the equivalent in a non-book product. In the case where a product is joint-branded, the <Imprint> composite is repeatable – however, unlike the similar <Publisher> composite, there is no ‘role’ associated with each imprint or brand. It is simply assumed that all imprints are imprints or brands directly associated with the product.

Imprint or brand names should not include any extra text that, for example, indicates their ownership: while ‘Prentice Hall Business, an imprint of Pearson Education’ may be listed on the title page or title verso, the <ImprintName> should simply be ‘Prentice Hall Business’. And where an abbreviated name is used because space is limited, for example on the book spine, the full name should be used: the spine may list ‘HBS Press’, but the full name from the title page or title verso – ‘Harvard Business School Press’ – should be supplied. Consistency is important, and a data supplier should avoid the case where some records list the imprint as ‘Touchstone’ and others as ‘Touchstone Books’.

Note that <Imprint> is a ‘brand name’ or marque, whereas <Publisher> is an organization or company name (and is a legal entity). It is common for a publisher to use its own name as a brand, and in this case, it is still best practice to supply both <Imprint> and <Publisher>, even though they might contain the same text. This can be particularly confusing since many imprint or brand names originated as the names of independent publishing companies, which have since been bought by larger publishers. The name of the small publisher may live on as a brand of the larger publisher. (In the case of a self-publisher, it is possible for publisher, imprint and contributor all to contain the same name.)

It is sometimes useful to deliver an imprint identifier or ‘brand code’ as well as the imprint name. This is particularly so where the code can deliver more granular information about the business unit responsible for a product, where within a large publisher a particular imprint or brand may be shared between several business units. But imprint identifiers – sometimes also termed list codes – can be generally useful to recipients even if they do not provide extra granularity, for example to guard against inconsistent naming of imprints, and at least one major global recipient requires a ‘brand code’ purely for this reason. This can be accomplished using an <ImprintIdentifier> composite and an arbitrary proprietary identifier.

imprint name plus a proprietary ‘list’ code (‘brand code’ or imprint ID)
using Reference names
<Imprint>
    <ImprintIdentifier>
        <ImprintIDType>01</ImprintIDType>
        <IDTypeName>HCP UK List Codes<IDTypeName>
        <IDValue>HCUKCNF</IDValue>
    </ImprintIdentifier>
    <ImprintName>Collins</ImprintName>
</Imprint>
using Short tags, with both standard and proprietary identifiers
<imprint>
    <imprintidentifier>
        <x445>16</x445>ISNI identifying
        <b244>0000000123641546</b244>brand name
    </imprintidentifier>
    <imprintidentifier>
        <x445>01</x445>Proprietary list gives
        <b233>HCP UK List Codes</b233>more granular details
        <b244>HCUKCNF</b244>where business units
    </imprintidentifier>share an imprint/brand
    <b079>Collins</b079>
</imprint>
It is a common error to assume that ‘Proprietary’ here is an indication of the publisher’s trademark or other proprietary rights held over the brand or imprint name itself. It is not. It indicates only that the identifier scheme used (ie the scheme named in <IDTypeName> and from which the value of <IDValue> is drawn) is proprietary.

Note that, although it is possible to provide an <Imprint> composite that contains only an <ImprintIdentifier>, this is bad practice. Provision of a name is vital where a proprietary identifier is used, as otherwise a recipient unaware of the nature of the proprietary code list has no imprint name to work with.

So there are three different ways to provide an imprint name:

  • <Imprint> composite containing only the imprint name;
  • <Imprint> composite containing a public or proprietary identifier, plus the imprint name;
  • <Imprint> composite containing multiple identifiers, plus the imprint name.

Similar practice applies to the use of proprietary and public identifiers inside the <Publisher> composite. Note that List 44 is used to control values for both <ImprintIDType> and <PublisherIDType>: ensure that the <Imprint> composite is used to identify an imprint (which is similar in concept to a ‘brand’ or ‘marque’), and the <Publisher> composite used to identify a publisher (which is a company or organization).

Publisher composite

Publishers associated with the product in various ways should be identified via the <Publisher> composite. This need not be limited to the publisher or co-publishers of the product – it can include a former publisher, a body working in association with the publisher (eg a learned society working with a publisher), or even the publisher of a previous version of the work (eg the original language version).

Publisher names are names of organizations or companies responsible for making the product available, but suffixes indicating the legal nature of the organization – Ltd, SA, LLC, Inc and so on – should be omitted.

In some countries, national libraries or other agencies maintain authoritative publisher identifiers (for example the Deutsche Nationalbibliothek publisher identifier). Where available, these publisher identifiers should be included within the <Publisher> composite. Where there is no accepted national scheme, it is fairly common to use a location identifier such as the GLN (of course, a GLN only identifies the publisher by proxy, as the publisher operating at that location).

Publishing companies are often themselves subsidiaries of larger corporate entities – publishing groups or holding companies. Supply chain partners deal with the publishing company, not its owner, so there is usually little reason to list the publishing group or holding company in the metadata. However, both publisher and group can be included if the need arises.

Publisher and publishing group
using Reference names
<Publisher>
    <PublishingRole>01</PublishingRole>
    <PublisherName>株式会社エンターブレイン</PublisherName>
</Publisher>
<Publisher>
    <PublishingRole>10</PublishingRole>
    <PublisherName>株式会社角川グループホールディングス</PublisherName>
</Publisher>
using Short tags
<publisher>
    <b291>01</b291>Publisher
    <b081>株式会社エンターブレイン</b081>Enterbrain
</publisher>
<publisher>
    <b291>10</b291>Publishing group
    <b081>株式会社角川グループホールディングス</b081>Kadokawa Group Holdings
</publisher>
Website composite

It can be useful to include links to a publisher’s website. Where possible, the <WebsiteRole> data element should be used to identify whether the website is primarily business-to-business or consumer-focused (codes 17 and 18 respectively on List 73).

Website WebsiteRole WebsiteDescription WebsiteDescription WebsiteLink

More generally, website links can be specified in several different ‘contexts’:

  • within <Contributor>;
  • within <Event> or <Conference>;
  • within <Publisher>;
  • within <PublisherRepresentative>;
  • within <Supplier>.

Role codes from List 73 cover a variety of types of website, and should be included whenever possible. Suppliers should attempt to provide the most relevant links within each context – for example, a link to a website maintained by an author and promoting a specific work (role code 10) should be provided in a <Contributor> context, not within <Publisher>, and a publisher’s business to business website should be listed in <Publisher> (or possibly within <Supplier>, if the publisher operates its own distribution). A publisher’s website linked to a particular contributor might in principle be listed in either <Contributor> or <Publisher>, but not both – and in practice, the latter location is preferred. The simplest guide on placement of a particular web link is to consider which party (person or organization) is responsible for the website – if it is the author, use <Website> composite within <Contributor>, whereas if it is the publisher, use the website within <Publisher>.

It is best practice always to include the full URI, including the protocol (ie the http: or https:) within the <WebsiteLink> element, even though in common usage, the http: and even on occasion the www part is often omitted.
If the publisher maintains its website in multiple languages, the <WebsiteLink> is repeatable to list different weblinks for each different language. If repeated, <WebsiteLink> requires the language attribute.
Multilingual weblinks
using Reference names
<WebsiteLink language="wel">https://www.cllc.org.uk/hafan</WebsiteLink>
<WebsiteLink language="eng">https://www.cllc.org.uk/home</WebsiteLink>
using Short tags
<b295 language="wel">https://www.cllc.org.uk/hafan</b295>
<b295 language="eng">https://www.cllc.org.uk/home</b295>
P.19.13 City of publication

<CityOfPublication> is the town or city where the publisher is based, and may occasionally be different from the location where publication takes place. For example, a London-based publisher may publish a book in Australia, and in this case, <CityOfPublication> should be London (in the United Kingdom) and not a location in Australia.

The city or town of publication is normally listed on the title page of a book, and the <CityOfPublication> element normally carries this name in the form that it is listed. Alternatively, some ONIX implementations may be consistent with the publisher’s ‘house style’, and may be slightly different from the exact listing on the book.

Occasionally, the city name may not be enough, even when coupled with a country code in <CountryOfPublication>. In this case, a state or province suffix may be added to the city name.

Some publishers list a single location in more than one language, or list more than one location. <CityOfPublication> is repeatable in either of these cases – but in the first case, the language attribute is mandatory and in the second it may be omitted.

One location, with State suffix
using Reference names
<CityOfPublication>Springfield, IL</CityOfPublication>
using Short tags
<b209>Springfield, IL</b209>
One location in two languages
using Reference names, Brussels, in both Flemish and French
<CityOfPublication language="dut">Brussel</CityOfPublication>
<CityOfPublication language="fre">Bruxelles</CityOfPublication>
using Short tags, Moscow, in French and Russian
<b209 language="fre">Moscou</b209>
<b209 language="rus">Москва</b209>
Two locations, London and Toronto
using Reference names
<CityOfPublication>London</CityOfPublication>
<CityOfPublication>Toronto</CityOfPublication>
Two locations, London and Paris, in both English and French
using Reference names
<CityOfPublication language="eng">London</CityOfPublication>
<CityOfPublication language="fre">Londres</CityOfPublication>
<CityOfPublication>Paris</CityOfPublication>
Two locations, Rome and Paris, in both Italian and French
using Reference names
<CityOfPublication language="ita">Roma</CityOfPublication>
<CityOfPublication language="ita">Parigi</CityOfPublication>
<CityOfPublication language="fre">Rome</CityOfPublication>
<CityOfPublication language="fre">Paris</CityOfPublication>
There is no particular meaning ascribed to the order of the various repeats. However, it’s good practice to assume that recipients may be limited in the number of location names they can store, and might select just the first one or two – so put the ‘most important’ first.

When combining both multiple locations and multiple languages, data senders should ensure that they avoid this, which leaves the English name of one city unknown:

<CityOfPublication language="eng">London</CityOfPublication>
<CityOfPublication language="ita">Londra</CityOfPublication>
<CityOfPublication language="ita">Roma</CityOfPublication>

Each individual location should be listed either in the full set of specified languages, or without any language attribute (ie suitable for all specified languages). Both the London / Paris and the Rome / Paris examples are correct, whereas the London / Rome combination is not.

Recipients can then easily select all locations for which there is no language attribute, plus all locations which carry their preferred option from the languages available.

P.19.14 Country of publication

<CountryOfPublication> is the country where the publisher is based, and may be different from the country in which publication takes place – for example, a UK-based publisher may publish a book in Australia, and in this case, <CountryOfPublication> should be the United Kingdom. The country of publication may also be distinct from the country of manufacture (see Group P.3).

The country of publication is useful in library cataloging (and is vital for ISBN registration purposes), so should always be provided. While less critical, the city or cities wherein the publisher is based can also be useful, so should be supplied where possible. Cities and countries of publication are usually listed on a book’s title page or the title verso.

For multi-national publishers, the country of publication is the country in which the particular business unit that produced the product is based, and usually the country from whose ISBN agency the ISBN is drawn.

Product contact composite

The product contact composite is intended to carry the name and other details of a contact person (usually at the publisher) who is responsible for some aspect of this particular product. A direct contact like this might help facilitate particular retail promotions, author tours, or access to the publisher’s production files (to meet the needs of print-impaired readers). Such contact details are clearly business-to-business contacts, and data recipients must not use them in consumer-facing contexts.

ProductContact ProductContactRole ProductContactRole ProductContactIdentifier ProductContactIdentifier ProductContactName ProductContactName ContactName EmailAddress ProductContactIdentifier ProductContactIDType ProductContactIDType IDTypeName IDValue must not omit both must include if ID is proprietary, otherwise omit
providing promotional contact details
using Reference names
<ProductContact>
    <ProductContactRole>02</ProductContactRole>
    <ProductContactName>Effectiv Promos LLC</ProductContactName>
    <ContactName>Georgia Fremont, +1 212 555 0123</ContactName>
    <EmailAddress>gfremont@effectiv.com</EmailAddress>
</ProductContact>
using Short tags
<productcontact>
    <x482>02</x482>Promotional contact
    <x484>Effectiv Promos LLC</x484>
    <x299>Georgia Fremont, +1 212 555 0123</x299>
    <j272>gfremont@effectiv.com</j272>
</productcontact>
The <ProductContactIdentifier> and <ProductContactName> refer to an organization, not to a specific person. The contact name and e‑mail address refer to a person within that organization.

There is a strong contrast with the contact details provided in the <Sender> composite in the message header – the header contact is responsible for the message as a whole, and is often a technical contact. The <ProductContact> composite is specific to each product in a message.

P.20 Global publishing status and dates / copyright

Group P.20 conveys the essential information about the lifecycle of a product, as it is defined by the publisher. This includes status information about whether the product is not yet published, active and available for sale, or is unavailable, and it includes dates (both past and future) for events such as initial publication or when a product is declared out of print. The status and dates are expressly the global status and dates. That is, a publication date quoted in P.20 must be the original (earliest) publication date of the product in any territory or market, and an out of print date should be the latest of any territory or market. ONIX providers can specify local, market-specific status and dates – for example a publication date that applies within a specific market – in Group P.25.

In the simple case, when a product is only available in a single market, provision of the publishing status and dates in either P.20 or P.25 is all that is required. Note that ‘single market’ does not mean ‘single country’, but any size of territory defined by rights and distribution arrangements (for a fuller definition, see Block 6).

In the more complex case when a product is available in a variety of different markets, market-specific details must be provided in P.24 and P.25 within separate repeats of the Block 6 <ProductSupply> composite – one repeat for each market.

In either case, it is valuable to include both ‘global’ information in Group P.20 and market-specific information in Group P.25, and doing so is considered best practice even when it’s not essential. But data providers must ensure that the status and dates provided in Group P.20 reflect the true global position. It is common for a publisher operating in multiple markets to consider one the primary or ‘home’ market, but it is a mistake to assume that a ‘global’ status or date is necessarily the same as the ‘status or date in the primary market’. Early publication in a secondary market, for example, means that the secondary market publication date is the basis for the global publication date. Early publication in the secondary market should in this case be viewed as ‘delayed availability in the primary market’.

Note that a publisher representative in a specific market – see Group P.25 – may not always be aware of the full ‘global’ publishing information, in which case details from Group P.20 might need to be omitted if the representative supplies ONIX Product records. Market-specific details should not be specified in P.20 in place of missing global details.

forthcoming product with an embargo on sales
using Reference names
<PublishingStatus>02</PublishingStatus>
<PublishingDate>
    <PublishingDateRole>01</PublishingDateRole>
    <Date dateformat="00">20110428</Date>
</PublishingDate>
<PublishingDate>
    <PublishingDateRole>02</PublishingDateRole>
    <Date dateformat="00">20110428</Date>
</PublishingDate>
using Short tags
<b394>02</b394>Forthcoming
<publishingdate>
    <x448>01</x448>Nominal pub date
    <b306 dateformat="00">20110428</b306>YYYYMMDD format
</publishingdate>
<publishingdate>
    <x448>02</x448>Sales embargo date
    <b306 dateformat="00">20110428</b306>
</publishingdate>
out of print product
using Reference names
<PublishingStatus>07</PublishingStatus>
<PublishingDate>
    <PublishingDateRole>01</PublishingDateRole>
    <Date dateformat="00">20080925</Date>
</PublishingDate>
<PublishingDate>
    <PublishingDateRole>13</PublishingDateRole>
    <Date dateformat="00">20100311</Date>
</PublishingDate>
<PublishingDate>
    <PublishingDateRole>11</PublishingDateRole>
    <Date dateformat="00">20070920</Date>
</PublishingDate>
using Short tags
<b394>07</b394>Out of print
<publishingdate>
    <x448>01</x448>Nominal pub date (of this product)
    <b306 dateformat="00">20080925</b306>YYYYMMDD format
</publishingdate>
<publishingdate>
    <x448>13</x448>Out-of-print date (of this product)
    <b306 dateformat="00">20100311</b306>
</publishingdate>
<publishingdate>
    <x448>11</x448>First publication (of work)
    <b306 dateformat="00">20070920</b306>
</publishingdate>
provision of multiple dates for an e‑book
using Reference names
<PublishingStatus>04</PublishingStatus>
<PublishingDate>
    <PublishingDateRole>11</PublishingDateRole>
    <Date dateformat="05">1811</Date>
</PublishingDate>
<PublishingDate>
    <PublishingDateRole>19</PublishingDateRole>
    <Date dateformat="01">198510</Date>
</PublishingDate>
<PublishingDate>
    <PublishingDateRole>01</PublishingDateRole>
    <Date dateformat="00">20110428</Date>
</PublishingDate>
using Short tags
<b394>04</b394>Active (‘in print’)
<publishingdate>
    <x448>11</x448>Date of first publication of work
    <b306 dateformat="05">1811</b306>Only the year is available
</publishingdate>
<publishingdate>
    <x448>19</x448>Publication date of print equivalent
    <b306 dateformat="01">198510</b306>Year and month available
</publishingdate>
<publishingdate>
    <x448>01</x448>Publication date
    <b306 dateformat="00">20110428</b306>Exact date in YYYYMMDD format
</publishingdate>
The contemporary e‑book is based on conversion of a backlist product from 1985, though the work was first published 200 years ago. The dateformat attribute is used to control the differing precision of each of the dates.
P.20.1 Publishing status

This is the product’s global status as defined by the publisher.

Several status codes in List 64 preclude the sending of a publication date. For other statuses, at least the publication date should be included in a repeat of the <PublishingDate> composite, as well as any other relevant dates.

Meaning of the main publishing status codes in List 64:

Types of PublishingStatus Yes Yes Was published? Was published? No Planning to publish? Yes Forthcoming 02 Responsible? Responsible? No Not our product 05 No No Canceled 01 No No Postponed indefinitely 03 Yes Yes Should fulfill Should fulfill order now, or order now, or within known time? within known time? Yes Active 04 Unknown 09 Unstated 00 Recalled 15 Temporarily withdrawn 16 Withdrawn 11 Yes Firm date? Inactive 08 No No Formally out of print? Formally out of print? Yes Yes Out of print 07 No Stock? Yes Remaindered 10 No No Out of stock indefinitely 06

A similar diagram in the Specification illustrates how the status may change over time, through the lifecycle of the product.

Some publishers use the term ‘reprint under consideration’ (RUC) to describe a product which is out of stock, and for which there is no current plan to reprint and bring it back into stock. In many cases, this is a transitional status while decisions are taken: orders will be accepted, and there is a reasonable expectation that a reprint decision will be made and the product will become available again. But in some cases, this RUC status persists so long that it’s clear the product is effectively out of print and will never become available: orders may be accepted, but will never be fulfilled. Publishers are encouraged to use <PublishingStatus> code 06 only where a reprint decision is realistically being considered. Code 07 should be applied when the product is formally out of print, and code 08 is available to indicate ‘effectively out of print’.

Subject to any Consumer announcement date, retailers may wish to present ‘Forthcoming’ or ‘not yet published’ titles to consumers more positively as ‘Available for advance order’ or ‘Pre-order now’. Orders placed by retailers with the publisher or distributor while a product is forthcoming are sometimes termed ‘subscription orders’. If a retailer lists a forthcoming product that is subsequently canceled (abandoned before publication), then the product listing (eg on a website) should be removed – or at the very least, the ‘Pre-order now’ button for advance orders should be removed.

Publishing date composite

Several dates can be provided for a single product – not just the date of publication, but also announcement dates to control when metadata becomes available (eg in an online store) or an embargo date to control when sales may begin.

PublishingDate PublishingDateRole PublishingDateRole DateFormat Date use dateformat attribute on <Date> element instead
Most dates in ONIX can be specified by default as year, month and day, or as any of a number of other formats, including YYYY, YYYYMM if the dateformat attribute (or the deprecated <DateFormat> data element) is included. As standard, the exact date is not checked as part of a validation process. However, the advanced schema does check dates, and it will invalidate dates like 30th February or any date prior to 1st January 1000 (two exceptions – <ContributorDate> and <SubjectDate> accept any Common Era date). Earlier dates should be described as text using date format 12.

There is some variation in terminology regarding dates. ONIX uses the following key terms throughout, and these are listed for use with <PublishingDate> composite in List 163:

  • Publication date – the date on which the product is nominally ‘published’. This date is used for advance planning, and is associated with various business processes: it may be linked to the invoice date for product copies delivered prior to publication, to delivery guarantees offered to retailers, to the timing of promotional activity, or to bibliographic cataloging. However, it is not necessarily the date on which copies of the product will be delivered to retailers, nor the earliest date a retailer may begin retail sales to consumers, nor is it the earliest date on which a consumer may place an advance order (‘pre-order’) a copy of the product. Actual availability of stock to the retailer may be no more than a few days prior to the nominal publication date (see Expected availability date), and (excepting cases of issues in distribution) no later than the publication date;
    • retailers receiving stock prior to the publication date are not expected to wait until the publication date to begin retail sales or pre-order fulfillment, unless an embargo has been set. In the absence of an embargo, fulfillment to consumers may begin as soon as stock is available;
    • since most products do not have an embargo date, it is very common for retail sales or advance order fulfillment to begin a few days before the publication date;
    • advertising and promotional activity is often timed to coincide with (or refer to) the publication date, but if exact synchronization is required, an embargo or strict on-sale date should be set;
    • some publishers choose to term the earliest date on which a consumer may take possession of a product as a ‘publication date’. In ONIX, this is a ‘sales embargo date’, and in an ONIX message, any such embargo date must be set in addition to the publication date, not instead of a pub date;
  • Market publication date – For internationally-traded books, the ‘publication date’ often varies between markets. For any one market, there is a single date, and strictly, only the earliest of these dates across several markets is the publication date. Later dates, in other markets, are often termed market publication dates, local publication dates and so on. In ONIX, where there are several market publication dates, the earliest of these should be listed in the <PublishingDate> composite in Group P.20 to reflect the ‘global’ status of the book. The individual market publication dates should be listed in the <MarketDate> composite in P.25;
    • in most cases, the earliest date will be the date of publication in the publisher’s home or primary market, but this is not always the case. Where a publisher arranges early availability in an foreign market, the arrangement should be treated as delayed availability in the home market. It is that early date that is the publication date quoted in the <PublishingDate> composite. To avoid any doubt, both markets should include an explicit market publication date in the <MarketDate> composite;
  • Sales embargo date – the sales embargo date is the earliest date on which a customer can take possession of a product (ie the date the embargo expires). In general, it is assumed that retailers may begin retail sales of the product (or begin to fulfill orders placed in advance) as soon as stock is available. This is commonly several days prior to the nominal publication date. If for any reason a publisher wishes to control the earliest date of retail sale or pre-order fulfillment, a sales embargo date should be supplied (in addition to the publication date). If retailers receive stock prior to the stated embargo date, it must be sequestered by the retailer until the embargo has expired;
    • embargoes are set by the publisher, so they are carried in <PublishingDate>. Occasionally, embargoes apply only within a single market, so a market-specific embargo may be carried in <MarketDate>;
      • where there is a single market, any embargo should be supplied in <PublishingDate>. If there’s more than a single market, any embargo should be included in <MarketDate>. It is good practice to provide the embargo date in both places, and they would typically be the same. Occasionally, the embargo in a particular market may be earlier or later than the ‘global’ embargo, so the <MarketDate> embargo may be different than the global embargo in <PublishingDate>;
      • an embargo might also be carried for confirmation purposes in <SupplyDate> (see Group P.26) – although very, very rarely, a special embargo might apply only to copies sources from a specific supplier;
      • data recipients should take care to obey the most specific embargo that applies. An embargo in Supply data applies to copies sourced from that supplier, but in the absence of a supplier embargo, the market-specific embargo applies across the whole market. In the absence of a market embargo, the global embargo applies;
    • fulfillment by mail order may usually begin one day prior to expiry of an embargo, since delivery to the consumer will occur the following day (at the earliest);
    • in North America, embargo dates are often known as ‘strict on-sale dates’, ‘on-sale dates’, or ‘national-’ or ‘one-day laydown dates’, and embargoes are often backed by legal affidavit. In other territories, industry-wide agreements and codes of practice govern retail activity when an embargo has been set. ONIX recipients must respect embargo dates whether or not an affidavit has been signed;
      • some North American publishers distinguish between ‘strict’ and non-strict on-sale dates – the latter are, in effect, embargo dates for which an affidavit has not been signed. In ONIX, they are treated the same as strict on-sale dates, as retailers are expected to treat strict and non-strict on-sale dates identically (ie whether an affidavit exists or not). In ONIX, both strict and non-strict on-sale dates are sales embargo dates;
    • in other media (eg music or electronic games), an embargo date is known as a ‘street date’;
    • embargoes are often set where book content is serialized in newspapers, or when a release needs to be synchronized (‘day and date’) with other media releases (eg film or TV tie-ins);
    • embargoes are also used to control the retail release of e-publications, where retailers may be supplied with master files some time in advance of publication, perhaps several weeks in advance. The time taken for conversion of the master files to the specific file format used by the retailer may be unpredictable. Setting an embargo date ensures that the release can be synchronized across several retailers, giving retailers a ‘level playing field’ and ensuring that the start of retail activity coincides with any planned promotional effort;
    • the embargo date need not coincide with the nominal publication date, although most commonly it does;
    • such an embargo does not apply to the product metadata. A retailer may display a product catalog entry (eg in an online store) and may accept advance orders from consumers (pre-orders) prior to expiry of the embargo, but must not fulfill those orders until expiry;
    • the embargo does apply to display of sample or preview content – even sample content that is supplied alongside other product metadata that may itself be displayed – except when a ‘Valid from’ date that allows earlier display is supplied alongside the sample content in Block 2;
    • if the publisher wishes to set different embargo dates for sales and for samples/previews, then the date applying to the sample or preview should be associated directly with it in Block 2. An explicit ‘Valid from’ date supplied with sample content in Block 2 takes precedence over any embargo date in P.20 or P.26. The embargo date in <PublishingDate> of course remains in place for actual product sales or fulfillment of advance orders;
    • in ONIX 2.1, the embargo date was carried in the <OnSaleDate> element;
  • Expected availability date – the date on which physical stock is expected to be released from the distributor or wholesaler to the retailer, sometimes also called the ‘expected ship date’ or the ‘release date’. For electronic products, this is the date on which master files are expected to be released to the retail platform or retailer;
    • this is never carried in <PublishingDate>. It is specified in <SupplyDate> (List 166), as it is a feature of the distribution arrangements for the product, but is discussed here for convenience;
    • the Expected availability date is typically a week or so before the nominal publication date. Physical stock may take a few days after the Expected availability date to reach the retailer, so should be delivered to the retailer prior to publication. In the absence of an Embargo date, it may be placed on sale to end-customers immediately;
    • in ONIX 2.1, the expected availability date was carried in the <ExpectedShipDate> element;
  • Expected warehouse date – like the Expected availability date, this is used in <SupplyDate> rather than in <PublishingDate>. It is the date on which physical stock is expected to be delivered to the distributor or wholesaler — it’s a ‘goods in date’ to match the ‘goods out date’ represented by the Expected availability date;
  • Consumer (or Public) announcement date – in general, it is assumed that retailers may publicize a forthcoming product as soon as they receive the necessary metadata for that product. And this implies also that retailers may begin to gather pre-orders as soon as they receive the necessary metadata. If a data supplier such as a publisher wishes to control the public availability of metadata and the earliest date that retailers may accept pre-orders, a Consumer announcement date should be supplied. If retailers receive a Product record prior to the stated announcement date, it may be used for internal purposes, but must not be exposed in a consumer-facing context (eg a public-accessible website) and pre-orders must not be accepted until the stated date;
    • if the data supplier wishes to control the public announcement of the product separately from the acceptance of advance orders (pre-orders), then a Pre-order embargo date may also be supplied;
    • data suppliers should take special care in managing Consumer announcement dates. It is common to link Consumer announcement dates to planned Publication dates, for example automatically setting Consumer announcement dates to six months prior to the publication date. If the planned publication date is modified, the announcement date might be adjusted automatically so that it remains six months prior to the new publication date. But of course, such automatic adjustments should not be made after the product is announced – once a product has been announced, it cannot be ‘unannounced’;
    • data recipients should also take care to ensure that metadata does not appear in a consumer-facing context prior to any Consumer announcement date;
  • Trade announcement date – in cases where ONIX records are supplied to data aggregators, who subsequently supply the data to retailers, it is generally assumed that the aggregators may pass on metadata as soon as they receive it (and after it has passed through any internal editorial processes the aggregator uses). If a data supplier wishes to provide an aggregator with data, but delay its onward supply for any reason, a trade announcement date should be supplied. If data aggregators receive a Product record prior to the stated trade announcement date, it may be used for internal purposes, but should not be exposed to supply chain partners who receive the aggregator’s data (or of course, to consumers);
    • management of Trade announcement dates is similar to that for Consumer announcement dates;
  • Date of first publication – this is the nominal publication date of the first manifestation of the work of which this product is a manifestation. So for a typical mass-market paperback, this is the publication date of the equivalent hardback or trade paperback. For a copy of Pride and Prejudice, it is 1813. The ‘work’ here should be understood in ISTC terms, and the work in question may be identified in Group P.22;
    • for a second or subsequent edition, the date of first publication refers to earliest publication of this edition, not the earliest publication of the first edition, since each new edition is a new work (albeit derived from the previous edition);
    • for an e‑book, this may be the same as the Publication date of print counterpart, or it may be different. For a 2011 e‑book version of a book first published in 1995 then republished in paperback form in 2001, the Date of first publication is 1995, the Publication date of the print counterpart could be 2001, and the Publication date is 2011;
      • the print counterpart can be important for accessibility, as it is the source of any print-equivalent page numbers that may be embedded within an e‑book. The print counterpart can be identified in <RelatedProduct>;
    • for works in translation only, the Date of first publication in original language is the Date of first publication, as above, for the ISTC ‘grandparent work’ from which the current work (of which the product is a manifestation) has been derived. For example, the date of first publication of The Girl with the Dragon Tattoo is 2008, but the Date of first publication in original language (ie the date of first publication of Män som hattar kvinnor in Swedish) is 2005. For works in translation where there are multiple independent translations – Les Misèrables for example – the Date of first publication in original language is always the same (1862 in this case), but the Date of first publication differs between translations (for English translations, 1887 for the Isabel Florence Hapgood translation, 1976 for Norman Denny, 2013 for Christine Donougher);
    • in ONIX 2.1, the date of first publication was carried in the <YearFirstPublished> element (which obviously only included the year part of the date).

Some of these dates should be provided whether they are in the future or the past – a publication date or any out of print/deletion date, for example. Others such as a passed embargo or announcement date have no relevance, and should not be included if they are in the past.

‘Deletion’ here refers to deletion of the product or removal from a catalog of available products (cf <NotificationType> in Group P.1).

These dates apply equally to digital products. In the absence of any embargo, a digital retailer or company providing digital fulfillment services may commence delivery of files to consumers immediately upon receipt of the ‘master files’. If a publisher aims to deliver master files to retailers (or their service companies), allow ample time for testing and quality assurance, and yet still control the timing of earliest fulfillment of sales to consumers in any way, an Embargo date should be provided.

Dates quoted in a <Date> element – whether within <PublishingDate> or elsewhere in the Product record – should use the Gregorian calendar, the de facto global civil and commercial calendar. The exception to this is where dates might have a special significance and must be quoted using another calendar for cultural reasons – for example the use of the Hijri lunar calendar for dates linked to Islamic religious texts. Use of alternative calendars should be strictly minimized, as there is no guarantee that data recipients will be able to correctly interpret them.

When supplying dates in ONIX, the dateformat attribute can be supplied to specify the format of the date (YYYY, YYYYMM or YYYYMMDD, for example). If the attribute is omitted – and without the similar but deprecated <DateFormat> element – most dates require a default format of YYYYMMDD. Do not use a dummy date such as 1st January of a particular year if only the year is known – use dateformat to limit the precision of the date, for example dateformat="05", and supply only YYYY.

Most dates are simply that – dates. But increasingly, particularly for e-publications, embargo dates are set to specific times. Some date formats available in List 55 allow a time to be included. Embargoes (and other dates) can specify either a ‘rolling’ local time, or a specific instant in time. As an illustration of the difference, consider the meaning of these three embargo dates:

<Date dateformat="13">20120815T1500</Date>
<Date dateformat="13">20120815T1500-0400</Date>
<Date dateformat="13">20120815T1900Z</Date>

The first has no timezone information, and is therefore a ‘rolling time’, meaning that retail sales are embargoed until 3pm local time – thus the product goes on sale in New York at 3pm – but sales can begin some five hours earlier in London (ie at 3pm in London), and cannot begin for a further three hours in Seattle (ie at 3pm in Seattle). The second and third examples specify a particular instant in time – 3pm in a time zone four hours behind UTC, or 7pm UTC. This means that the product can be sold beginning at 3pm in New York (because New York is four hours behind UTC), and sales can begin in London and Seattle at exactly the same instant (ie at 8pm in London, because London is one hour ahead of UTC, and at noon in Seattle because Seattle is seven hours behind UTC).

It is critical that publishers setting embargoes with exact time parameters decide whether the embargo time is rolling or instantaneous, and that they use the correct format to specify the time. Note that it may not be possible for e‑book or online retailers selling to customers in many countries (or even within a single country that stretches across several time zones) to apply rolling time embargoes properly.

Times that include timezone information (ie instants in time) should wherever possible express that time in UTC.

It may appear that midnight embargoes can be specified with a time of either 24:00 or 00:00 – the former logically indicates an embargo that expires at the end of a day, and the latter indicates expiry at the beginning of the following day – and these are of course exactly the same time. The following two examples appear to indicate an identical rolling embargo time – but of the two, the latter is very strongly preferred:

<Date dateformat="13">20120815T2400</Date>(end of 15th August)
<Date dateformat="13">20120816T0000</Date>(beginning of 16th August)

ONIX dates are inclusive, and in general, it is natural to use 00:00 for midnight datetimes that express start dates (eg a Valid from date in an ONIX <Date> element), and 24:00 for midnight datetimes that express end dates (eg a Valid to date). That is, something starts at the beginning of the day on the specified date, and ends at the end of the day on the specified date.

For sales embargoes, it is important to understand that the date represents the earliest date on which sales are allowed, not the last day on which sales are embargoed, so it is a start date. It’s therefore natural to use 00:00 to indicate midnight at the beginning of the day on which sales are allowed. The same is true of other embargo dates in ONIX <Date> elements.

When the date is an end or Valid to date, either 24:00 or 00:00 are acceptable options, though 00:00 is clearly less natural than 24:00 – it’s ‘00:00 on the day after’ rather than midnight at the end of the day.

Note that use of a time of 24:00 to indicate midnight has the potential to cause problems in some recipient systems where dates and times are handled programmatically. Digital clocks tick over from 11:59 to 00:00, not to 24:00, and some systems do not treat 24:00 as a valid time. For data senders, if 24:00 is impractical and 00:00 on the day after seems unclear (ie 20120815T2400 or 20120816T0000 for a price that is valid to the end of 15th August), use a time of 23:59 (or even 23:59:59) instead (ie use 20120815T2359 for a price that is valid to the end of 15th August). For data recipients, 24:00 may need to be treated as a special case, and equated to 00:00 of the following day.

Dates without times of any kind can be thought of as a special kind of rolling time, aligned with the business day, essentially meaning ‘the start of the business day’ (or for ‘to’ dates, the end of the business day). So a date of 20120816 perhaps means 9am on that day for a physical bookstore, but 00:00 at the beginning of that day for an online bookstore that operates 24×7. Of course for an online store, the question is, 'Midnight where?’ It’s for this reason that, as noted above, a rolling time can present special difficulties online. However, since online stores use geolocation techniques so the correct sales rights, prices, taxes and currencies can be used with each customer, they should be able to use the customer’s local timezone too.

Copyright statement composite

This composite can be used to record details of any copyrights or neighboring rights (for example the phonogram or database rights) held in the content of the product. The whole composite is repeatable for products incorporating multiple rights – for example, the author and the reader of an audiobook could hold separate copyright and phonogram rights. And any single right may be held jointly by multiple owners.

However, it should never be interpreted as being comprehensive – there may be other rights in the product that are not listed, for example various image rights, over and above any specified text copyright.

When listing a particular copyright owner, note that it is possible to provide only an identifier, but this is strongly discouraged. Wherever possible include the name (either corporate or personal) as well.

CopyrightStatement CopyrightType CopyrightYear CopyrightOwner CopyrightOwner CopyrightOwnerIdentifier CopyrightOwnerIdentifier PersonName CorporateName must include at least one
CopyrightOwnerIdentifier CopyrightOwnerIDType CopyrightOwnerIDType IDTypeName IDValue must include if ID is proprietary, otherwise omit
joint copyright shared between author and publisher
using Reference names
<CopyrightStatement>
    <CopyrightType>C</CopyrightType>
    <CopyrightYear dateformat="11">20042013</CopyrightYear>
    <CopyrightOwner>
        <PersonName>Amelia Winstanley</PersonName>
    </CopyrightOwner>
    <CopyrightOwner>
        <CorporateName>General Text Inc.</CorporateName>
    </CopyrightOwner>
</CopyrightStatement>
using Short tags
<copyrightstatement>
    <x512>C</x512>© Copyright, may be omitted as C is the default
    <b087 dateformat="11">20042013</b087>
    <copyrightowner>
        <b036>Amelia Winstanley</b036>
    </copyrightowner>
    <copyrightowner>
        <b047>General Text Inc.</b047>
    </copyrightowner>
</copyrightstatement>
separate text copyright and phonogram right, with rightsholders’ ISNIs
using Reference names
<CopyrightStatement>
    <CopyrightType>C</CopyrightType>
    <CopyrightYear>1924</CopyrightYear>
    <CopyrightYear>1936</CopyrightYear>
    <CopyrightYear>1979</CopyrightYear>
    <CopyrightYear>1983</CopyrightYear>
    <CopyrightOwner>
        <CopyrightOwnerIdentifier>
            <CopyrightOwnerIDType>16</CopyrightOwnerIDType>
            <IDValue>0000000121694257</IDValue>
        </CopyrightOwnerIdentifier>
        <CorporateName>King’s College, Cambridge</CorporateName>
    </CopyrightOwner>
</CopyrightStatement>
<CopyrightStatement>
    <CopyrightType>P</CopyrightType>
    <CopyrightYear>2008</CopyrightYear>
    <CopyrightOwner>
        <CopyrightOwnerIdentifier>
            <CopyrightOwnerIDType>16</CopyrightOwnerIDType>
            <IDValue>0000000404773473</IDValue>
        </CopyrightOwnerIdentifier>
        <CorporateName>Canongate Books</CorporateName>
    </CopyrightOwner>
</CopyrightStatement>
using Short tags
<copyrightstatement>
    <x512>C</x512>© Copyright
    <b087>1924</b087>Default YYYY format
    <b087>1936</b087>Copyright renewed
    <b087>1979</b087>several times
    <b087>1983</b087>
    <copyrightowner>
        <copyrightowneridentifier>
            <b392>16</b392>ISNIs can identify organization
            <b244>0000000121694257</b244>names as well as personal names
        </copyrightowneridentifier>
        <b047>King’s College, Cambridge</b047>
    </copyrightowner>
</copyrightstatement>
<copyrightstatement>
    <x512>P</x512>Ⓟ Phonogram right
    <b087>2008</b087>
    <copyrightowner>
        <copyrightowneridentifier>
            <b392>16</b392>ISNI
            <b244>0000000404773473</b244>
        </copyrightowneridentifier>
        <b047>Canongate Books</b047>
    </copyrightowner>
</copyrightstatement>
Note the different date formats in the two examples, and the repeat of <CopyrightYear> in the second. The first example might be rendered as ‘© 2004–2013 Amelia Winstanley and General Text Inc.’, whereas the second example might be rendered as ‘© 1924, 1936, 1979, 1983 King’s College, Cambridge. Ⓟ 2008 Canongate Books’.

P.21 Territorial rights and other sales restrictions

ONIX is product-focused: it is not primarily concerned with the publishing rights held by a publisher in a work – only in those rights that the publisher is exploiting in the particular product. Group P.21 lists the territorial extent of those rights (‘sales rights’).

These sales rights should clearly be a subset of – or the same as – the publishing rights held by the publisher. They should also be the same as – or a superset of – the distribution rights held by a particular supplier and specified in the <Market> composite in Group P.24.

With increasing globalization in the book supply chain – seen most particularly in the growth of e‑book retail platforms with global scope, and with online retailers increasingly able to fulfill orders globally – it is no longer adequate to supply sales rights details for only those countries where ONIX recipients are based, or which a publisher considers its core market. ONIX suppliers should aim to provide a complete statement of the sales rights in all territories, although if necessary it is still possible to list certain territories where the rights position is unknown or unstated. The intent is to provide a precise, reliable statement of the rights information that can be used by an automated system to determine whether a product can or cannot be sold.

However, ONIX can communicate something about the publishing rights held, insofar as it can state whether the publisher’s rights are exclusive or non-exclusive. These types of publishing right generally pertain at work rather than product level. By claiming exclusive sales rights (<SalesRightsType> 01), the publisher is stating that no other publisher has the right to exploit the work in that territory – and this implies that other publisher’s manifestations of the work on sale in the same territory may be ‘infringing’.

Additional guidance on the description of sales rights in ONIX 3.0 will be found in a separate document ONIX for Books Product Information Message: How to Specify Markets and Suppliers in ONIX 3.

Specifying geographical areas – territories – can be accomplished in either an additive or subtractive manner. Territories can be built by defining an aggregation of countries or sub-national regions, or by excluding countries or regions from a ‘WORLD’ region. Finally, there is a data element that must be used to describe the sales rights for any geographical area not already covered (which may be those areas where the rights position is unclear, unknown, or which must remain unstated).

The <SalesRestriction> composite allows particular <SalesRights> composites to be further constrained, so that the product is saleable only through particular channels or outlets within the territory.

Only WORLD, national and sub-national entities are used to define territories. Supra-national regions other than WORLD are not used. Although supra-national terms like ‘Europe’ or ‘Commonwealth’ are in common use in discussing territorial rights, these groupings often have a dynamic nature and are difficult to interpret. For example, a publisher has exclusive rights throughout the European Economic Area (which consists of the EU and three EFTA countries), and either non-exclusive or no rights elsewhere. What happens when a new country joins the EU? Does the publisher automatically gain exclusive rights in the new country? Or has it lost EEA exclusivity because some other publisher had and still retains rights in that new country? This can only be answered through study of the relevant contract – is the area of exclusivity contractually defined as ‘the EEA’, or as ‘the EEA as at the effective date of the contract’, or as a fixed list of countries? Within ONIX, territories are always defined by a list of countries, which avoids ambiguity and allows publishers to express rights in a granular manner. It is for the publisher to expand terms such as EEA into the correct list of countries, as that can only be done with access to contractual detail.

SalesRights SalesRightsType Territory SalesRestriction ProductIdentifier PublisherName Territory CountriesIncluded CountriesIncluded RegionsIncluded RegionsIncluded CountriesExcluded CountriesExcluded RegionsExcluded RegionsExcluded must include one or both
Code ROW (Rest of world) from List 49 – the list of regions used in <RegionsIncluded> and <RegionsExcluded> – is not valid in ONIX 3.0. In general, it is best practice to use an explicitly-defined territory either including a list of countries, or including WORLD and excluding a list of countries. Whenever practical, use of <ROWSalesRightsType> should be limited to the case where sales rights in the rest of the world are unknown. Code ECZ (Eurozone) is also not used in <SalesRights>, and its use is strongly discouraged elsewhere – use an explicit list of countries instead.
exclusive world rights excluding India (version 1)
using Reference names
<SalesRights>
    <SalesRightsType>01</SalesRightsType>
    <Territory>
        <RegionsIncluded>WORLD</RegionsIncluded>
        <CountriesExcluded>BD BT IN LK MV NP PK</CountriesExcluded>
    </Territory>
</SalesRights>
<SalesRights>
    <SalesRightsType>06</SalesRightsType>
    <Territory>
        <CountriesIncluded>BD BT IN LK MV NP PK</CountriesIncluded>
    </Territory>
</SalesRights>
using Short tags
<salesrights>
    <b089>01</b089>For sale (exclusive)
    <territory>
        <x450>WORLD</x450>
        <x451>BD BT IN LK MV NP PK</x451>
    </territory>
</salesrights>
<salesrights>
    <b089>06</b089>Not for sale (no rights)
    <territory>
        <x449>BD BT IN LK MV NP PK</x449>
    </territory>
</salesrights>
The exclusions from the first <SalesRights> composite are dealt with in the second, so no <ROWSalesRightsType> element is required – by definition, there can be no ‘rest of world’. However, <ROWSalesRightsType> could be used in place of either of the composites to convey exactly the same meaning, as below. As a matter of best practice, where the sales rights can be expressed as ‘world excluding a few countries’, method 1 is preferred, although there are circumstances where method 2 is necessary (eg where the sales rights in some or all of the excluded countries are unknown).
exclusive world rights excluding India (version 2)
using Reference names
<SalesRights>
    <SalesRightsType>01</SalesRightsType>
    <Territory>
        <RegionsIncluded>WORLD</RegionsIncluded>
        <CountriesExcluded>BD BT IN LK MV NP PK</CountriesExcluded>
    </Territory>
</SalesRights>
<ROWSalesRightsType>06</ROWSalesRightsType>
using Short tags
<salesrights>
    <b089>01</b089>For sale (exclusive)
    <territory>
        <x450>WORLD</x450>
        <x451>BD BT IN LK MV NP PK</x451>
    </territory>
</salesrights>
<x456>06</x456>Not for sale (no rights) in rest of world – by definition, this is BD, BT, IN, LK, MV, NP and PK
exclusive sales rights in EEA plus Switzerland, no rights in North America, non-exclusive rights in the rest of the world
using Reference names
<SalesRights>
    <SalesRightsType>01</SalesRightsType>
    <Territory>
        <CountriesIncluded>AT BE BG CY CZ DE DK EE ES FI FR GB GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO</CountriesIncluded>
    </Territory>
</SalesRights>
<SalesRights>
    <SalesRightsType>06</SalesRightsType>
    <Territory>
        <CountriesIncluded>CA MX US</CountriesIncluded>
    </Territory>
</SalesRights>
<ROWSalesRightsType>02</ROWSalesRightsType>
using Short tags
<salesrights>
    <b089>01</b089>For sale (exclusive)
    <territory>
        <x449>AT BE BG CY CZ DE DK EE ES FI FR GB GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO</x449>EU, EFTA
    </territory>
</salesrights>
<salesrights>
    <b089>06</b089>Not for sale (no rights)
    <territory>
        <x449>CA MX US</x449>
    </territory>
</salesrights>
<x456>02</x456>For sale (non-exclusive)
exclusive world rights except in North America, but product is not sold in Spain and an alternative is offered
using Reference names
<SalesRights>
    <SalesRightsType>01</SalesRightsType>
    <Territory>
        <RegionsIncluded>WORLD</RegionsIncluded>
        <CountriesExcluded>CA ES MX US</CountriesExcluded>
    </Territory>
</SalesRights>
<SalesRights>
    <SalesRightsType>06</SalesRightsType>
    <Territory>
        <CountriesIncluded>CA MX US</CountriesIncluded>
    </Territory>
</SalesRights>
<SalesRights>
    <SalesRightsType>04</SalesRightsType>
    <Territory>
        <CountriesIncluded>ES</CountriesIncluded>
    </Territory>
    <ProductIdentifier>
        <ProductIDType>03</ProductIDType>
        <IDValue>9788401234569</IDValue>
    </ProductIdentifier>
    <ProductIdentifier>
        <ProductIDType>15</ProductIDType>
        <IDValue>9788401234569</IDValue>
    </ProductIdentifier>
</SalesRights>
using Short tags
<salesrights>
    <b089>01</b089>For sale (exclusive)
    <territory>
        <x450>WORLD</x450>
        <x451>CA ES MX US</x451>
    </territory>
</salesrights>
<salesrights>
    <b089>06</b089>Not for sale (no rights)
    <territory>
        <x449>CA MX US</x449>
    </territory>
</salesrights>
<salesrights>
    <b089>04</b089>Not for sale (but exclusive rights)
    <territory>
        <x449>ES</x449>
    </territory>
    <productidentifier>Alternative product for Spain
        <b221>03</b221>GTIN-13
        <b244>9788401234569</b244>
    </productidentifier>
    <productidentifier>
        <b221>15</b221>ISBN
        <b244>9788401234569</b244>
    </productidentifier>
</salesrights>
exclusive sales rights in North America, no rights in Europe, rights elsewhere unknown
using Reference names
<SalesRights>
    <SalesRightsType>01</SalesRightsType>
    <Territory>
        <CountriesIncluded>CA MX US</CountriesIncluded>
    </Territory>
</SalesRights>
<SalesRights>
    <SalesRightsType>06</SalesRightsType>
    <Territory>
        <CountriesIncluded>AT BE BG CY CZ DE DK EE ES FI FR GB GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO</CountriesIncluded>
    </Territory>
</SalesRights>
<ROWSalesRightsType>00</ROWSalesRightsType>
using Short tags
<salesrights>
    <b089>01</b089>For sale (exclusive)
    <territory>
        <x449>CA MX US</x449>North America
    </territory>
</salesrights>
<salesrights>
    <b089>06</b089>Not for sale (no rights)
    <territory>
        <x449>AT BE BG CY CZ DE DK EE ES FI FR GB GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO</x449>EU, EFTA
    </territory>
</salesrights>
<x456>00</x456>ROW rights unknown or unstated
exclusive world rights, but this product is an own-brand exclusive to Fnac. An alternative product is identified for other retailers
using Reference names
<SalesRights>
    <SalesRightsType>01</SalesRightsType>
    <Territory>
        <RegionsIncluded>WORLD</RegionsIncluded>
    </Territory>
    <SalesRestriction>
        <SalesRestrictionType>05</SalesRestrictionType>
        <SalesOutlet>
            <SalesOutletIdentifier>
                <SalesOutletIDType>03</SalesOutletIDType>
                <IDValue>FNC</IDValue>
            </SalesOutletIdentifier>
            <SalesOutletName>Fnac</SalesOutletName>
        </SalesOutlet>
    </SalesRestriction>
    <ProductIdentifier>
        <ProductIDType>03</ProductIDType>
        <IDValue>9782001234561</IDValue>
    </ProductIdentifier>
    <ProductIdentifier>
        <ProductIDType>15</ProductIDType>
        <IDValue>9782001234561</IDValue>
    </ProductIdentifier>
</SalesRights>
using Short tags
<salesrights>
    <b089>01</b089>For sale with restrictions
    <territory>
        <x450>WORLD</x450>
    </territory>
    <salesrestriction>
        <b381>05</b381>Retailer-exclusive (own brand)
        <salesoutlet>
            <salesoutletidentifier>
                <b393>03</b393>ONIX outlet ID
                <b244>FNC</b244>FNAC
            </salesoutletidentifier>
            <b382>Fnac</b382>
        </salesoutlet>
    </salesrestriction>
    <productidentifier>Alternative product
        <b221>03</b221>GTIN-13
        <b244>9782001234561</b244>
    </productidentifier>
    <productidentifier>
        <b221>15</b221>ISBN
        <b244>9782001234561</b244>
    </productidentifier>
</salesrights>
Sales rights composite

A typical <PublishingDetail> composite would include one or more <SalesRights> composites, each of which must specify a geographical territory and the type of sales rights that pertain there. In the very simplest case where exclusive worldwide publishing rights are held, just a single <SalesRights> composite is required. In a more complex case there may be two or three (occasionally more), plus a <ROWSalesRightsType> element. However, there should not normally be more than one <SalesRights> composite for each <SalesRightsType> (and any <ROWSalesRightsType> should carry a different value too).

In most cases, the <SalesRights> composite consists of just the <SalesRightsType> element and a <Territory> within which the specified sales rights apply. Broadly, these sales rights indicate:

  • For sale with exclusive rights – the publisher holds the exclusive rights to publish and sell the work in the specified territory, and has chosen to exercise those rights;
    • this means that no other publisher has rights to exploit the work in the territory – though there may be other territories where another publisher does have rights;
    • it is a common error to assume that ‘with exclusive rights’ implies exclusivity to particular distributors or retailers in the territory, or that the list of countries in the territory is an exhaustive list (ie the product is exclusive to the territory and not available outside the territory). It does not. The same product may well be available in other territories, under different sales rights. ‘For sale with exclusive rights’ means only that the sales rights are derived from exclusive rights to publish;
    • retailer-exclusivity can be specified using <SalesRestriction>;
  • For sale with non-exclusive rights – the publisher holds rights to publish and sell the work in the territory, and has chosen to exercise those rights, but the publisher’s rights are non-exclusive. That is, another publisher may also hold rights to publish and sell the same work in the same territory;
    • this means that another publisher may be offering a very similar product to customers in the same territory;
    • this is relatively common in English-language publishing, for example where rights are often shared between US- and UK-based publishers. Each publisher has an exclusive ‘home territory’, and there may also be a non-exclusive shared territory where both may exploit the work, and where they compete to sell similar products to the same customers;
    • it is a common error to assume that ‘with non-exclusive rights’ means the list of countries and regions included in the territory is not an exhaustive list. In fact it means that the sales rights are derived from non-exclusive rights to publish;
  • Not for saleeither the publisher has no rights to publish or sell the work in the territory, or has the required rights but has chosen not to exercise them;
    • though the net effect for the retailer is the same – the product is not for sale – codes 04, 05 and 06 may be used to remove any ambiguity and indicate why the book is not for sale;
      • code 04 indicates the publisher has chosen to make the product not for sale, despite holding exclusive rights;
      • code 05 indicates the publisher has chosen to make the product not for sale, despite holding non-exclusive rights;
      • code 06 indicates the product is not for sale because the publisher does not hold the relevant rights;
      • together with codes 01 and 02, codes 04, 05 and 06 can reveal the geographical extent of the publisher’s publishing rights as well as the sales rights;
  • Sales rights unknown or unstated – sales rights type code 00 may not be used within <SalesRightsType>. With <ROWSalesRightsType>, code 00 allows publishers to deliver an explicit indication that the sales rights information is incomplete.

In addition to the usual <SalesRightsType> element and <Territory> composite, <SalesRights> composites within which <SalesRightsType> codes 03, 04, 05 or 06 indicate that the product is not for sale (and possibly also the deprecated codes 07 and 08, which indicate it is for sale, but only in certain outlets or channels) may include an identifier for an equivalent alternative product that may be available (or are not restricted to particular outlets or channels). This uses the <ProductIdentifier> composite, and best practices outlined in Group P.2 apply. Alternative products are intended to be used where one publisher provides two geographically distinguished products, as well as when a publisher without rights provides details of another publisher’s products (in real-world use, the latter will likely be rare). Data providers should attempt to match alternative products to the territories in which they are available – there is little benefit in listing alternatives that are themselves unavailable. However, data recipients should not assume anything about the availability of such alternatives, and should rely only on the full Product records for those products.

In typical circumstances, there would be a maximum of one repeat of the <SalesRights> composite for each value of <SalesRightsType>. However, it is possible that two repeats of the <SalesRights> composite carrying the same <SalesRightsType> might be necessary, either when a specified alternative product is known to be available in only some of the countries where the primary product is unavailable, or when a particular non-territorial sales restriction applies in only some of the countries where a product is for sale.

Territory composite

Each <SalesRights> composite must include a <Territory> composite to specify a geographical area, within which the particular sales rights apply. Every <Territory> must include either a <CountriesIncluded> or a <RegionsIncluded>, or both.

Geographical territories can be built up by including multiple countries or sub-national regions, and fine-tuned by excluding smaller regions from individual countries, or by excluding countries and smaller regions from the WORLD region. Areas that are not included should not be excluded (they would typically be included in a different <SalesRights> composite). For example, if the territory to be specified for one <SalesRights> composite is ‘North America’, then simply include the North American countries – the rest of the world should not be explicitly excluded (but the rights applicable to the rest of the world should be described in a separate <SalesRights> composite). Exclusions should be used to refine the included territory. For example, if the territory to be specified is ‘the 48 contiguous States of the USA’, then include USA using <CountriesIncluded> and exclude Hawaii and Alaska using <RegionsExcluded>. (You could alternatively include each of the 48 States individually, using <RegionsIncluded>, and the meaning of the <Territory> composite would be identical. Choosing which method to use may depend on the way in which territorial rights information is held in another IT system, but clearly the first method is simpler and preferable.)

In <Territory>, sub-national regions can be excluded from countries and from supra-national regions, and countries can be excluded from supra-national regions. But only certain combinations of inclusion and exclusion make sense. If CI means that <Territory> includes a <CountriesIncluded> element, RI means <RegionsIncluded>, CX and RX are exclusions, and – indicates an element is missing, only the following combinations can be used:

  • CI —— —— ——
  • CI —— —— RX     ¹
  • —— RI —— ——
  • —— RI —— RX     (only where RI = WORLD)
  • —— RI CX ——     (only where RI = WORLD)
  • —— RI CX RX     (only where RI = WORLD) ²
  • CI RI —— ——     (only where RI does not contain WORLD) ³
  • CI RI —— RX     (only where RI does not contain WORLD) ¹ ³

Other combinations do not make sense ⁴, and most will not validate.

¹ the regions excluded obviously have to be regions within the included countries
² the regions excluded must be outside the countries excluded (that is, countries and regions are separately excluded from WORLD)
³ the regions included must be outside the countries included
⁴ an exception to this applies in Group P.26, where a few other combinations are valid.

ONIX uses the ISO 3166-1 country codes in List 91. Since this list also includes autonomous and semi-autonomous parts of some countries, and overseas territories or dependencies of others, care should be taken to include these separately where appropriate, independent of the ‘parent’ country, as they are not automatically included in the larger country when interpreting ONIX List 91. So US overseas territories such as Guam or Samoa are not included as part of code US, since they have their own codes (GU and SA), and the Åland Islands are not included in code FI (Finland), since the islands have their own code (AX). Similar principles apply to French départements et territoires d’outre-mer (eg Réunion, Guadeloupe), the British Channel Islands (GG and JE) dependencies and overseas territories (BM etc) and so on. In addition, independent principalities and microstates such as San Marino (SM), Lichtenstein (LI) and Andorra (AD) are often overlooked.

When interpreting List 91, the subdivisions are not considered part of the larger country for sales rights, market or pricing purposes. In ONIX, the country code FR is considered to apply only to metropolitan France (including Corsica), and not to include the overseas departments and territories (codes BL, GF, GP etc) ¹. So if rights are held throughout the larger country, include both the main country code and the country code for the smaller subdivision.

Country ²Country subdivision with independent code in List 91
AustraliaAUCCCocos Islands
CXChristmas Island
NFNorfolk Island
HMHeard Island and McDonald Islands
ChinaCNHKHong Kong
MOMacao
TWTaiwan
DenmarkDKFOFaroe Islands
GLGreenland
FinlandFIAXÅland Islands
FranceFRBLSaint Barthélemy
GFFrench Guiana
GPGuadeloupe
MFSaint Martin
MQMartinique
NCNew Caledonia
PFFrench Polynesia
PMSaint Pierre and Miquelon
RERéunion
TFFrench Southern Territories
WFWallis and Futuna
YTMayotte
NetherlandsNLAWAruba
BQBonaire, Saba and Sint Eustatius
CWCuraçao
SXSint Maarten
New ZealandNZTKTokelau
NorwayNOBVBouvet Island
SJSvalbard and Jan Mayen
United KingdomGBBMBermuda
GSSouth Georgia
GGGuernsey
JEJersey
IMIsle of Man
KYCayman Islands
MSMontserrat
PNPitcairn Islands
SHSaint Helena, Ascension and Tristan da Cunha
VGVirgin Islands
United StatesUSASAmerican Samoa
GUGuam
MPNorthern Mariana Islands
PRPuerto Rico
UMUS Minor Outlying Islands
VIUS Virgin Islands

¹ note that this interpretation applies specifically to ONIX and List 91. The underlying ISO 3166-1 list may be interpreted in different ways in other standards

² this list is not necessarily exhaustive

Note that some of these subdivisions may also have codes in List 49 for use within <RegionsIncluded> and <RegionsExcluded> – for example region code GB-IOM is synonymous with country code IM. The country codes from List 91 should be used in preference, and equivalent codes in List 49 should not be used.

Sales restriction composite

This composite should be used only within <SalesRightsType> codes 01 and 02, and it specifies an additional restriction that applies within a particular territory – for example a product may be a retailer exclusive, or sales may be restricted to a specific channel such as to libraries or schools.

Prior to ONIX 3.0.2, <SalesRestriction> was used outside <SalesRights>, using <SalesRightsType> 07 or 08. This method is deprecated. The <SalesRestriction> composite should be included within the <SalesRights> composite to which it applies.

It is also possible to describe restrictions with the opposite effects – a product that is available to all except a specific retailer, or a product that is not available to the library sales channel.

It is possible to describe a product that is generally available to the trade in one territory, yet restricted to a specific channel or retailer in another. The general availability is described in one repeat of the <SalesRights> composite with <SalesRightsType> 01 (assuming exclusive rights are held), and the restricted availability is described in a second repeat of <SalesRights> with <SalesRightsType> 01 and a <SalesRestriction> composite. The restriction details supplied then only apply to the territory with which it is grouped.

SalesRestriction SalesRestrictionType SalesRestrictionType SalesOutlet SalesRestrictionNote SalesRestrictionNote StartDate EndDate SalesOutlet SalesOutletIdentifier SalesOutletIdentifier SalesOutletName SalesOutletName must not omit both SalesOutletIdentifier SalesOutletIDType SalesOutletIDType IDTypeName IDValue must include if ID is proprietary, otherwise omit
exclusive rights in Commonwealth and EEA plus Switzerland, no rights in North America, non-exclusive rights elsewhere – but within the EEA, the product is only sold as a retailer-exclusive in Waterstones
using Reference names (preferred method for ‘rest of world’)
<SalesRights>
    <SalesRightsType>01</SalesRightsType>
    <Territory>
        <CountriesIncluded>AG AU BB BD BN BS BW BZ CA CM DM GD GH GM GY IN FJ JM KE KI KN LC LK LS MU MV MW MY MZ NG NR NZ PG PK RW SB SC SG SL SZ TO TT TV TZ UG VC VU WS ZA ZM</CountriesIncluded>
    </Territory>
</SalesRights>
<SalesRights>
    <SalesRightsType>01</SalesRightsType>
    <Territory>
        <CountriesIncluded>AT BE BG CY CZ DE DK EE ES FI FR GB GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO</CountriesIncluded>
    </Territory>
    <SalesRestriction>
        <SalesRestrictionType>04</SalesRestrictionType>
        <SalesOutlet>
            <SalesOutletIdentifier>
                <SalesOutletIDType>03</SalesOutletIDType>
                <IDValue>WST</IDValue>
            </SalesOutletIdentifier>
            <SalesOutletName>Waterstones</SalesOutletName>
        </SalesOutlet>
    </SalesRestriction>
</SalesRights>
<SalesRights>
    <SalesRightsType>06</SalesRightsType>
    <Territory>
        <CountriesIncluded>CA MX US</CountriesIncluded>
    </Territory>
</SalesRights>
<SalesRights>
    <SalesRightsType>02</SalesRightsType>
    <Territory>
        <RegionsIncluded>WORLD</RegionsIncluded>
        <CountriesExcluded>AG AU BB BD BN BS BW BZ CA CM DM GD GH GM GY IN FJ JM KE KI KN LC LK LS MU MV MW MY MZ NG NR NZ PG PK RW SB SC SG SL SZ TO TT TV TZ UG VC VU WS ZA ZM AT BE BG CY CZ DE DK EE ES FI FR GB GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO CA MX US</CountriesExcluded>
    </Territory>
</SalesRights>
using Short tags (alternative method for ‘rest of world’)
<salesrights>
    <b089>01</b089>For unrestricted sale (exclusive)
    <territory>
        <x449>AG AU BB BD BN BS BW BZ CA CM DM GD GH GM GY IN FJ JM KE KI KN LC LK LS MU MV MW MY MZ NG NR NZ PG PK RW SB SC SG SL SZ TO TT TV TZ UG VC VU WS ZA ZM</x449>Commonwealth
    </territory>
</salesrights>
<salesrights>
    <b089>01</b089>For restricted sale (exclusive)
    <territory>
        <x449>AT BE BG CY CZ DE DK EE ES FI FR GB GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO</x449>EU and EFTA
    </territory>
    <salesrestriction>(in EU and EFTA)
        <b381>04</b381>Only via
        <salesoutlet>
            <salesoutletidentifier>
                <b393>03</b393>ONIX outlet list
                <b244>WST</b244>Waterstones
            </salesoutletidentifier>
            <b382>Waterstones</b382>
        </salesoutlet>
    </salesrestriction>
</salesrights>
<salesrights>
    <b089>06</b089>Not for sale (no rights)
    <territory>
        <x449>CA MX US</x449>
    </territory>
</salesrights>
<x456>02</x456>For sale (non-exclusive) elsewhere
‘Commonwealth’ is a large but dynamic list of countries, and the particular countries included may vary from product to product and from time to time.
The second <SalesRights> composite does not mean that the product can be sold throughout the European countries listed – it means it can be sold in those counties subject to the sales restriction. Prior to 3.0.2, the same information could be conveyed with <SalesRightsType> 08, but this code is now deprecated.
exclusive world rights but temporarily excluded for sale via a particular retailer
using Reference names
<SalesRights>
    <SalesRightsType>01</SalesRightsType>
    <Territory>
        <RegionsIncluded>WORLD</RegionsIncluded>
    <Territory>
    <SalesRestriction>
        <SalesRestrictionType>11</SalesRestrictionType>
        <SalesOutlet>
            <SalesOutletIdentifier>
                <SalesOutletIDType>03</SalesOutletIDType>
                <IDValue>ZZZ</IDValue>
            </SalesOutletIdentifier>
            <SalesOutletName>LoCostReadz</SalesOutletName>
        </SalesOutlet>
        <StartDate dateformat="00">20130621</StartDate>
        <EndDate dateformat="00">20140102</EndDate>
    </SalesRestriction>
</SalesRights>
<!-- no ROWSalesRightsType -->
using short tags
<salesrights>
    <b089>01</b089>For restricted sale (exclusive)
    <territory>
        <x450>WORLD</x450>
    <territory>
    <salesrestriction>
        <b381>11</b381>Except via
        <salesoutlet>
            <salesoutletidentifier>
                <b393>03</b393>ONIX outlet list
                <b244>ZZZ</b244>Other
            </salesoutletidentifier>
            <b382>LoCostReadz</b382>Fictitious retailer
        </salesoutlet>
        <b324 dateformat="00">20130621</b324>
        <b325 dateformat="00">20140102</b325>Until January 2014
    </salesrestriction>
</salesrights>
<!-- no x456 -->
exclusive world rights, but sold only through two specific retailers for a short time after publication
using Reference names
<SalesRights>
    <SalesRightsType>01</SalesRightsType>
    <Territory>
        <RegionsIncluded>WORLD</RegionsIncluded>
    </Territory>
    <SalesRestriction>
        <SalesRestrictionType>04</SalesRestrictionType>
        <SalesOutlet>
            <SalesOutletIdentifier>
                <SalesOutletIDType>03</SalesOutletIDType>
                <IDValue>KBO</IDValue>
            </SalesOutletIdentifier>
        </SalesOutlet>
        <SalesOutlet>
            <SalesOutletIdentifier>
                <SalesOutletIDType>03</SalesOutletIDType>
                <IDValue>APC</IDValue>
            </SalesOutletIdentifier>
        </SalesOutlet>
        <EndDate dateformat="00">20140621</EndDate>
    </SalesRestriction>
</SalesRights>
using Short tags
<salesrights>
    <b089>01</b089>For sale (exclusive)
    <territory>
        <x450>WORLD</x450>
    </territory>
    <salesrestriction>
        <b381>04</b381>Retailer exclusive
        <salesoutlet>
            <salesoutletidentifier>
                <b393>03</b393>ONIX outlet ID
                <b244>KBO</b244>Kobo and…
            </salesoutletidentifier>
        </salesoutlet>
        <salesoutlet>
            <salesoutletidentifier>
                <b393>03</b393>
                <b244>APC</b244>Apple
            </salesoutletidentifier>
        </salesoutlet>
        <b325 dateformat="00">20140621</b325>Restriction ends (and product is generally available after this date)
    </salesrestriction>
</salesrights>

Note that restrictions can be time-limited if necessary, by including <EndDate> (and possibly a <StartDate>). After a restriction expires, the <SalesRights> composite should be interpreted as if the restriction does not exist. The deprecated <SalesRightsType> code 07 should be treated as code 01 after expiry of any restrictions, and code 08 should be treated as code 02.

The expected expiry of a sales restriction provides an example where provision of ONIX metadata to retailers that are not able to sell the product is valuable – they may be able to sell the product in the future. And retailers who are affected by a restriction may still make use of the metadata, even prior to expiry, for customer service purposes (‘You cannot buy it from us yet’, ‘You cannot buy it from us, but we can offer you this alternative’, or even ‘You cannot buy it from us, but it may be available from this other retailer.’), and perhaps to facilitate the sales of used books. Best practice must therefore be to provide metadata, even when a retailer cannot sell the product.

But it is recognized that in some circumstances, there are commercial imperatives that weigh heavily against the provision of such metadata. Publishers may not wish to include retailer-exclusive products in an ONIX data feed that is sent to all retailers – especially prior to publication of that exclusive product – and retailers with exclusive arrangements may similarly not want their retail competitors informed in advance of the product appearing in-store. However, there is no reason to prevent dissemination of the metadata once the product is published, as competitor retailers may (legitimately) wish to facilitate used-book trading. The availability of metadata on products with sales restrictions (at least post-publication) is also important for the collection of aggregated sales data and market statistics.

P.21.10 Rest of World sales rights type code

In a technical sense, the <ROWSalesRightsType> element is optional. But the Specification defines it as ‘required in all cases where no sales rights type is associated with the region ‘WORLD’, and in all cases where a sales rights type is associated with ‘WORLD’ but with exclusions that are not themselves associated with a sales rights type’. It is defined that way to ensure that a sales rights type is associated unequivocally with every part of the world. And it is still required even if you believe you have listed all possible countries individually.

The <ROWSalesRightsType> element has two common uses. First, with code 00, it is used to make a positive statement about remaining areas of the world where rights are unknown or where the publisher does not wish to make a statement. In such cases, ONIX recipients should of course assume nothing about the rights that are applicable, and as a precaution should treat such territories as if the product were not for sale. Second, with codes 01–06, it is used to express rights statements such as ‘non-exclusive rights in the rest of the world’ or ‘not for sale in the rest of the world’ – this can often be more convenient than using a <SalesRights> composite that includes WORLD and excludes a wide range of countries, but this second use is not a best practice. Wherever practicable, an explicit <SalesRights> composite should be used instead.

Since this data element relies on preceding <SalesRights> composites to define the extent of ‘the rest of the world’, it should never appear unless it is accompanied by one or more <SalesRights> composites. And if the <SalesRights> composites unequivocally cover the whole world, then the <ROWSalesRightsType> element should be omitted.

Whether Group P.21 requires a <ROWSalesRightsType> element must be checked on a case-by-case basis:

  1. is the WORLD region associated with a sales rights type code?
    • if no, <ROWSalesRightsType> is required, even if you believe you have exhaustively listed all ISO country codes separately. It will act as a fallback if you have inadvertently omitted a country, or if a new country is created (eg South Sudan was created in 2011);
    • if yes, see question 2;
  2. within the <SalesRights> composite that includes WORLD, are there any <CountriesExcluded> or <RegionsExcluded> elements?
    • if no, <ROWSalesRightsType> should be omitted;
    • if yes, see Question 3;
  3. are all those excluded countries and regions included in other <SalesRights> composites, in accordance with best practice?
    • if no, <ROWSalesRightsType> is required. It may be used to specify the rights that apply in the remaining countries or regions, or specify that those rights are unknown or unstated;
    • if yes, <ROWSalesRightsType> should be omitted.
Code 00 from List 46, indicating that sales rights are unknown or unstated, may be used only with <ROWSalesRightsType>. It is not valid within the <SalesRights> composite. As a precaution, recipients should generally interpret code 00 as ‘not for sale’.

Block 5: Related material

Related material composite

The <RelatedMaterial> composite, with its enclosed <RelatedWork> and <RelatedProduct composites, is used to deliver information about related works and other products, and their relationship to the product being described. <RelatedWork> is used to describe a relationship between the product being described – the subject of the entire ONIX Product record – and an abstract ‘work’. <RelatedProduct> is used to describe a relationship between the product being described and another product (which may be another manifestation of the same work, or a manifestation of another work).

RelatedMaterial RelatedWork RelatedProduct must include at least one, unless product record is a partial or ‘block update’ (when <RelatedMaterial/> may be empty in order to ‘delete’ previously supplied data)

P.22 Related works

The <RelatedWork> composite is primarily intended to be used to specify the ISTC or a similar identifier for the (work manifested in the) product – a ‘work identifier’ that is shared by all products that contain the same significant text content, where each product will have a different ISBN, and where products may even be published by different publishers. Note that the ISTC identifier itself has been withdrawn, and may be re-specified in the future.

Importantly, it can also be used to specify the work’s relationship to other works (it may be a derivation of another work, or other works may be derived from it): a large measure of the value of ISTC (and similar work identifiers which incorporate work-to-work links) is that it creates ‘family trees’ of works, and allows publishers and retailers to create groupings of products based on the relationships between their ISTCs – collocating products manifesting a work alongside the manifestations of a grandparent work and child works. For example, a novel in translation can be linked to its grandparent work in the original language, and to an abridged, adapted or enhanced child work.

Work identifiers are immensely useful to retailers, who may – with certainty – link multiple versions of the same work, and delink other, seemingly-similar products. This ensures the retailer is able to offer all versions of the work – hardcover, softcover, various e-publications, the luxury leather-bound version – giving the customer greater choice of formats and prices, and enhancing the visibility of niche products. To some extent, retailers can accomplish this without work identifiers, but the accuracy of such efforts is variable (for example when the same work is re-published under a different title). Libraries can use work identifiers for collocation, or to prevent acquisition of duplicate versions of works. Reliable work identifiers can also be used to improve compliance with territorial rights.

RelatedWork WorkRelationCode WorkRelationCode WorkIdentifier WorkIdentifier WorkIDType IDTypeName IDValue must include if ID is proprietary, otherwise omit
this product is a manifestation of a particular work identified by an ISTC. The ‘parent’ ISTC is also specified
using Reference names
<RelatedWork>
    <WorkRelationCode>01</WorkRelationCode>
    <WorkIdentifier>
        <WorkIDType>11</WorkIDType>
        <IDValue>A02200900000A654</IDValue>
    </WorkIdentifier>
</RelatedWork>
<RelatedWork>
    <WorkRelationCode>02</WorkRelationCode>
    <WorkIdentifier>
        <WorkIDType>11</WorkIDType>
        <IDValue>A02200900000ECDE</IDValue>
    </WorkIdentifier>
</RelatedWork>
using Short tags
<relatedwork>
    <x454>01</x454>Is manifestation of
    <workidentifier>
        <b201>11</b201>ISTC
        <b244>A02200900000A654</b244>Of this work
    </workidentifier>
</relatedwork>
<relatedwork>
    <x454>02</x454>Is manifestation of work derived from
    <workidentifier>
        <b201>11</b201>ISTC
        <b244>A02200900000ECDE</b244>this grandparent work
    </workidentifier>
</relatedwork>
In this example, the grandparent ISTC (A02-2009-00000ECD-E) is an original work, and the product is a manifestation of a derived work (A02-2009-00000A65-4), in this case an abridged edition. Equally, the grandparent work could be the Sixth edition, and the product a manifestation of the Seventh edition, a derived work.
supplying multiple parent ISTCs for an omnibus edition
using Reference names
<RelatedWork>
    <WorkRelationCode>02</WorkRelationCode>
    <WorkIdentifier>
        <WorkIDType>11</WorkIDType>
        <IDValue>A022009000000951</IDValue>
    </WorkIdentifier>
</RelatedWork>
<RelatedWork>
    <WorkRelationCode>02</WorkRelationCode>
    <WorkIdentifier>
        <WorkIDType>11</WorkIDType>
        <IDValue>A022009000000964</IDValue>
    </WorkIdentifier>
</RelatedWork>
<RelatedWork>
    <WorkRelationCode>02</WorkRelationCode>
    <WorkIdentifier>
        <WorkIDType>11</WorkIDType>
        <IDValue>A0220090000009B3</IDValue>
    </WorkIdentifier>
</RelatedWork>
using Short tags
<relatedwork>
    <x454>02</x454>Is manifestation of work derived from
    <workidentifier>
        <b201>11</b201>ISTC
        <b244>A022009000000951</b244>Of Sense and Sensibility
    </workidentifier>
</relatedwork>
<relatedwork>
    <x454>02</x454>Is manifestation of work derived from
    <workidentifier>
        <b201>11</b201>ISTC
        <b244>A022009000000964</b244>Of Pride and Prejudice
    </workidentifier>
</relatedwork>
<relatedwork>
    <x454>02</x454>Is manifestation of work derived from
    <workidentifier>
        <b201>11</b201>ISTC
        <b244>A0220090000009B3</b244>Of Northanger Abbey
    </workidentifier>
</relatedwork>
The omnibus edition does not (yet) have an ISTC of its own (it could be registered as a work derived by compilation of the three grandparent works).
supplying an internal work identifier
using Reference names
<RelatedWork>
    <WorkRelationCode>01</WorkRelationCode>
    <WorkIdentifier>
        <WorkIDType>01</WorkIDType>
        <IDTypeName>KP-biblio-work-ID</IDTypeName>
        <IDValue>2283</IDValue>
    </WorkIdentifier>
</RelatedWork>
using Short tags
<relatedwork>
    <x454>01</x454>Manifestation of
    <workidentifier>
        <b201>01</b201>Proprietary
        <b233>KP-biblio-work-ID</b233>
        <b244>2283</b244>
    </workidentifier>
</relatedwork>
Proprietary internal identifiers such as this always require a ‘namespace’ – a likely-to-be-unique name for the identifier. Without such a namespace, many companies are likely to have works with the internal number 2283.
using the ISBN of the first-published version as a proprietary work identifier of last resort
using Reference names
<RelatedWork>
    <WorkRelationCode>01</WorkRelationCode>
    <WorkIdentifier>
        <WorkIDType>01</WorkIDType>
        <IDTypeName>CE-titoloID</IDTypeName>
        <IDValue>CET9780001234567</IDValue>
    </WorkIdentifier>
</RelatedWork>
using Short tags
<relatedwork>
    <x454>01</x454>Manifestation of
    <workidentifier>
        <b201>01</b201>Proprietary
        <b233>CE-titoloID</b233>
        <b244>CET9780001234567</b244>
    </workidentifier>
</relatedwork>

It is common for publishers with legacy IT systems to use an ISBN to identify ‘works’. Typically this is the ISBN of the first product that manifests the work – sometimes termed the ‘title ISBN’ or ‘head ISBN’ – and is often the hardback ISBN. There is an obvious potential for confusion.

When using an ISBN as a proprietary work ID, the publisher has prefixed the ISBN with ‘CET’. This is in addition to the provision of the ‘CE-titoloID’ name for the proprietary identifier, and greatly reduces the level of doubt when an ISBN is used to identify a work: the prefix makes it obvious that the identifier is not being used as an ISBN in this context and reduces the likelihood that a recipient will confuse the internal work ID with a product ID.

Related work composite

The strongly-preferred work identifier is the ISTC, and it is best practice to supply an ISTC that has been registered for the work manifested in the product, with a <WorkRelationCode> of 01 from List 164. Any parent or source works, or known child or derived works should also be specified, with <WorkRelationCode> codes 02 and 03 respectively – the supply of parent and child ISTCs greatly enhances the value of the data for collocation of multiple products.

The diagram illustrates the relationship between the product (which is the subject of the Product record) and various works, with the <WorkRelationCode> codes used with the ISTCs or proprietary work identifiers of those works:

Types of work relationship product grandparent work (02) parent work (01) child work (03) derived derived manifested manifested

Note that List 164 says nothing about the nature or method of derivation of derived works – whether by revision, abridgement, translation, adaptation, addition of ancillary non-textual content etc.

However, it is recognized that only a small number of publishers have so far started registering ISTCs. Where an ISTC has not been registered, reliable internal identifiers still have some utility. Internal identifiers will not have the valuable cross-publisher quality of ISTC, but may still help retailers create clusters of a single publisher’s products which contain the same textual content. Internal identifiers should normally use <WorkIDType> 01 (Proprietary), and should always have an <IDTypeName> to distinguish them from similar internal identifiers used by other publishers.

It’s worth noting that when proprietary work IDs are provided, the ‘rules’ governing what constitutes a single work are inevitably unknown to the ONIX data recipient. Are abridged editions or second editions the same work as the original, or different works? A publisher’s internal view of what constitutes a single work is sometimes much wider than the model inherent in the ISTC. Since the scope of the proprietary identifier is unknown, it is difficult to interpret relationships between works expressed with proprietary identifiers, whereas with ISTC these relationships are closely defined and are an important part of the value provided by an ISTC.

Ideally, the scope of a proprietary work identifier should be the same or similar to that of the ISTC. That is, it should identify the content of the product. Changes to the content – such as through significant addition or revision, abridgement, adaptation, translation etc – should necessitate a new work identifier. ‘Work’ identifiers with a broader scope (eg where the second edition has the same work identifier as the first, or where the abridged and unabridged versions have the same work identifier) are not recommended.

In the absence of a reliable internal work identifier, some companies use the ISBN of the first-published version of a work (sometimes called a ‘title ISBN’ or ‘head ISBN’) to collocate all versions of the same work. A similar practice arises when a publisher allocates an ISBN to an e‑book ‘master file’, from which several different products are derived: this is often (erroneously) termed an ‘e-ISBN’. However the individual products are identified – and best practice would be to allocate each of them a unique ISBN – the master file’s ISBN can be used to signify that they are all manifestations of the same content. It should be noted that the master file should generally not have its own ISBN and ONIX record, as it is usually not a product in its own right. But it is frequently given a ‘for internal purposes only’ ISBN that is used in ONIX records communicated between the publisher and a technical intermediary who may use the master file to create several products. In these cases, an ISBN is being used in place of a work identifier. As a last resort, this ISBN may be supplied as a proxy work identifier in ONIX records – but should never be included if there is any other work identifier available. It is best practice to identify this proxy as a proprietary work identifier (ie <WorkIDType> code 01), although it could theoretically be supplied with <WorkIDType> code 15. When used as an internal work identifier, the ISBN is being used ‘out of context’ and not as an ISBN (which by definition and when used correctly identifies a product). Given the ubiquity of ISBN as a product identifier and the ease of recognition of the ‘978’ and ‘979’ prefixes, it is strongly recommended that when an ISBN is used in a different context – as a proprietary identifier of something other than a product – then it should be modified in some way to ensure it cannot be interpreted as an ISBN. It could be modified by adding a prefix or suffix, or in any other way that ensures it looks unlike an ISBN.

Some companies use an e‑book ISBN to identify a master file that is also a product in its own right, perhaps an EPUB format file from which other e‑book file formats can be derived. This is like using a ‘title ISBN’ or ‘head ISBN’, and the same advice applies. Take great care, as it is easy to confuse ISBN as product identifier with the same ISBN being used as a work identifier.

P.23 Related products

The <RelatedProduct> composite is primarily intended to be used to specify the ISBNs of any similar or related products, though other identifiers may be used. Information about related products is invaluable to retailers, who can ensure the customer is aware of the full range of product options, and may be able to offer a customer alternatives if the desired product is unavailable for any reason.

There are a large number of ways two products may be related, and two individual products may have multiple relationships. For example, one ISBN may be an e‑book version of another (print) product, and <ProductRelationCode> codes 06 and 13 from List 51 may both apply. Or a product tied to release of a movie may include codes 03, 06 and 18 relating it to the earlier non-tie in version. The <ProductRelationCode> element is repeatable to accommodate these multiple relationships.

Where the product is related to many other products, then each related product is identified in a separate repeat of the <RelatedProduct> composite. Although <ProductIdentifier> is repeatable within <RelatedProduct>, each <RelatedProduct> composite lists just one related product – thought that one product may have multiple identifiers. The repeatability of <ProductIdentifier> is not used to list multiple products within a single <RelatedProduct> composite – instead, repeat the whole <RelatedProduct> composite for each related product.

RelatedProduct ProductRelationCode ProductRelationCode ProductIdentifier ProductForm ProductFormDetail ProductFormDetail
new product replaces a previous version (2011 edition replaces 2010 edition)
using Reference names
<RelatedProduct>
    <ProductRelationCode>03</ProductRelationCode>
    <ProductIdentifier>
        <ProductIDType>03</ProductIDType>
        <IDValue>9782849026335</IDValue>
    </ProductIdentifier>
    <ProductIdentifier>
        <ProductIDType>15</ProductIDType>
        <IDValue>9782849026335</IDValue>
    </ProductIdentifier>
</RelatedProduct>
using Short tags
<relatedproduct>
    <x455>03</x455>Replaces
    <productidentifier>
        <b221>03</b221>GTIN-13
        <b244>9782849026335</b244>(of 2010 edition)
    </productidentifier>
    <productidentifier>
        <b221>15</b221>ISBN
        <b244>9782849026335</b244>(of 2010 edition)
    </productidentifier>
</relatedproduct>
The sample is from the Product record for the 2011 edition. In the Product record for the 2011 edition, the ISBN of the 2010 edition is listed as a related product with the relationship ‘replaces’. In an updated Product record for the 2010 edition – which may show the 2010 edition as going out of print – the ISBN of the 2011 edition should be listed with the relationship ‘replaced by’ (code 05 from List 51).
linking an e-publication to other alternative formats of the same work
using Reference names
<RelatedProduct>
    <ProductRelationCode>13</ProductRelationCode>
    <ProductRelationCode>06</ProductRelationCode>
    <ProductIdentifier>
        <ProductIDType>03</ProductIDType>
        <IDValue>9780007120765</IDValue>
    </ProductIdentifier>
    <ProductIdentifier>
        <ProductIDType>15</ProductIDType>
        <IDValue>9780007120765</IDValue>
    </ProductIdentifier>
</RelatedProduct>
<RelatedProduct>
    <ProductRelationCode>06</ProductRelationCode>
    <ProductIdentifier>
        <ProductIDType>03</ProductIDType>
        <IDValue>9780007234387</IDValue>
    </ProductIdentifier>
    <ProductIdentifier>
        <ProductIDType>15</ProductIDType>
        <IDValue>9780007234387</IDValue>
    </ProductIdentifier>
</RelatedProduct>
using Short tags
<relatedproduct>
    <x455>13</x455>Epublication based on
    <x455>06</x455>Alternative format
    <productidentifier>
        <b221>03</b221>GTIN-13
        <b244>9780007120765</b244>(of paperback)
    </productidentifier>
    <productidentifier>
        <b221>15</b221>ISBN
        <b244>9780007120765</b244>(of paperback)
    </productidentifier>
</relatedproduct>
<relatedproduct>
    <x455>06</x455>Alternative format
    <productidentifier>
        <b221>03</b221>GTIN-13
        <b244>9780007234387</b244>(of hardcover)
    </productidentifier>
    <productidentifier>
        <b221>15</b221>ISBN
        <b244>9780007234387</b244>(of hardcover)
    </productidentifier>
</relatedproduct>
linking a print-on-demand facsimile product to its original
using Reference names
<RelatedProduct>
    <ProductRelationCode>24</ProductRelationCode>
    <ProductRelationCode>16</ProductRelationCode>
    <ProductIdentifier>
        <ProductIDType>03</ProductIDType>
        <IDValue>9780002130325</IDValue>
    </ProductIdentifier>
    <ProductIdentifier>
        <ProductIDType>15</ProductIDType>
        <IDValue>9780002130325</IDValue>
    </ProductIdentifier>
</RelatedProduct>
using Short tags
<relatedproduct>
    <x455>24</x455>Is facsimile of
    <x455>16</x455>POD replacement for
    <productidentifier>
        <b221>03</b221>GTIN-13
        <b244>9780002130325</b244>(of original)
    </productidentifier>
    <productidentifier>
        <b221>15</b221>ISBN
        <b244>9780002130325</b244>(of original)
    </productidentifier>
</relatedproduct>
linking a t-shirt to the book it promotes
using Reference names
<RelatedProduct>
    <ProductRelationCode>08</ProductRelationCode>
    <ProductIdentifier>
        <ProductIDType>03</ProductIDType>
        <IDValue>9780684833392</IDValue>
    </ProductIdentifier>
    <ProductIdentifier>
        <ProductIDType>15</ProductIDType>
        <IDValue>9780684833392</IDValue>
    </ProductIdentifier>
</RelatedProduct>
using Short tags
<relatedproduct>
    <x455>08</x455>The t-shirt is ancillary to the book
    <productidentifier>
        <b221>03</b221>GTIN-13
        <b244>9780684833392</b244>(of the book)
    </productidentifier>
    <productidentifier>
        <b221>15</b221>ISBN
        <b244>9780684833392</b244>(of the book)
    </productidentifier>
</relatedproduct>
The t-shirt is the product here – the separate record for the book could include the t-shirt as a related product, but with a different <ProductRelationCode> (code 07 instead of code 08).
Related product composite

The <RelatedProduct> includes the <ProductIdentifier> composite described in Group P.2, and similar best practice applies.

It’s true to say that <RelatedProduct> and <RelatedWork> can sometimes provide the same information: a product may be linked to several others via <ProductRelationCode> 06 (Alternative format), and all those products would be manifestations of the same ISTC, which could be specified in <RelatedWork>. However, it is good practice to include both <RelatedWork> and <RelatedProduct> composites whenever possible: not all ONIX recipients are able to make use of <RelatedWork>, and each composite adds different detail to the relationship between two products.

<RelatedProduct> might in principle also duplicate information provided in <ProductPart> in Group P.4, particularly when using the <ProductRelationCode> 02 (Product includes related product). It is good practice to include identifiers for multi-component and multi-item products in <ProductPart> and not to repeat them in <RelatedProduct>. ONIX recipients should make use of identifiers listed in <ProductPart> in addition to those in <RelatedProduct>.

The most important relationships from List 51 include:

code relation
06 <Product> is available in an alternative format as <RelatedProduct>
use to link hardback, paperback, e‑book versions, where the content is essentially identical. Linking two products implies they are the same work, and they may also be linked through sharing a single work identifier (that is, in <RelatedWork>, each product would specify that they are manifestations of the same work using <WorkRelationCode> 01)
01
02
<Product> includes <RelatedProduct>
<Product> is included within <RelatedProduct>
use for multi-component and multi-item products which include items that are themselves available individually, where the component or item identifiers cannot be included in <ProductPart> for any reason. Also use where the content from one product is included in another product – for example with an omnibus edition, or where a chapter of a book is also made available as an independent product. This latter relationship also implies that the two products may be linked through <RelatedWork> using codes 02 and 03 too (they are not manifestations of the same work, but one work may be derived from the other, for example by compilation)
41 <Product> includes some content shared with <RelatedProduct>
use where products share some content – but where that shared content does not form the whole of either product. Note the contrasts between codes 06, 01, 02 and 41: code 06 means the content is essentially identical (ie the shared content forms the whole of both products), codes 01 and 02 means the shared content forms the whole of one product but only part of the other, and code 41 means that each product also contains some content that is not shared with the other. None of these relationships imply anything about whether one or other product is the ‘primary’ source of the shared content
03
05
<Product> replaces <RelatedProduct>
<Product> is replaced by <RelatedProduct>
use to link new and previous editions, or whenever one product completely supersedes another. The two products would generally be manifestations of different works, but one work would often be derived from the other, and this implies they may also be linked using codes 02 and 03 in <RelatedProduct>. Do not use for ‘paperback replaces hardback’ – for that, use code 06 instead. Note that a particular Product record might well have related products with both codes 03 and 05 – a sixth edition replaces the fifth, and towards the end of its life is itself replaced by the seventh edition (and the sixth edition work would be derived from the fifth, and would in turn have the seventh derived from it)
18
19
<Product> is a special edition based on the basic version <RelatedProduct>
<Product> is also available as a special edition, as <RelatedProduct>
use to link normal with tie-in, gift, illustrated or similar types of ‘special’ editions (generally of the same work – though if extra content is included in the special edition, it may represent a derived work). Do not use for ordinal numbered editions (use codes 03 and 05 instead), or for facsimile editions (use codes 24 and 25 instead), or for enhanced e‑books (use 28 and 29);
30 <Product> is a member of a collection which also includes <RelatedProduct>
use to link together all products in a collection, particularly useful if there is no collection identifier supplied in Group P.5. The members of the collection would generally not have particular work relationships to each other
13
27
<Product> is an e‑book based on the print version <RelatedProduct>
<Product> is the print version on which <RelatedProduct> is based
use to link an e‑book and its previously-published paper equivalent (when paper and e‑book version are published contemporaneously, then the e‑book is just another format and should be related with code 06). This implies the paper and digital products are the same work, and may also be linked via a sharing a code 01 work identifier in <RelatedWork>
28
29
<Product> is an enhanced version of <RelatedProduct>
<Product> is a basic version of <RelatedProduct>
use to link basic and enhanced e‑books. The enhanced e‑book is a manifestation of a new work derived from the basic work (or possibly the other way around, if the basic version were created by removal of material from the enhanced version)
26 <Product> is a separate license that covers usage of <RelatedProduct>
use when <RelatedProduct> is digital, and available separately
07
08
<Product> has ancillary or supplementary <RelatedProduct>
<Product> is ancillary or supplementary to <RelatedProduct>
use for example to link a promotional poster to the product it is promoting, or where general merchandise (t-shirt, mug, tote-bag) is linked to a particular product
22
23
42
<Product> is by the same author as <RelatedProduct>
if you liked <RelatedProduct>, you’ll love <Product> (or vice versa)
<Product> is a later edition of first edition <RelatedProduct>
these relationships normally apply at work level. When relating products, ensure <Product> and <RelatedProduct> appeal to the same market – for example, both <Product> and <RelatedProduct> are mass market paperbacks, or both are audiobooks
Note that this table contains only some of the potential relationships from List 51. Note also the direction of these relationships. Many come in pairs: if one is used in a particular Product record, then the ‘opposite’ or inverse relationship is used in the ‘other’ Product record (the record for the related product). Others, including codes 06, 22, 30 and 41, are their own opposites. A few, like code 42, apply in only one direction – there is no opposite relationship in the ONIX list.
In cases where a relationship is paired with its inverse (for example, codes 03 and 05 in the table above), or when a relationship is its own inverse (eg code 06 or code 41) then a recipient may assume the inverse relationship exists even if not explicitly stated in the ONIX record for the ‘other’ product. Thus if the record for product Y states that it replaces product X, but the record for product X does not state that it has replaced Y, then such an inverse relationship can be assumed. However, data providers should be explicit in both records.

In the table above, for example with code 01, the phrase ‘<Product> includes <RelatedProduct>’ should be read as ‘the product which is the subject of the ONIX record as a whole includes the related product whose ISBN is listed in the <RelatedProduct> composite’. That is, code 01 should be used in the ONIX record for the larger product, and it should carry the ISBN (or another identifier) of the smaller product in the <RelatedProduct> composite . Conversely, code 02 should be used in the ONIX record for the smaller product, and list the ISBN for the larger product.

The diagram illustrates the way a fourth edition (in the example, ISBN 978-0-00-123457-4) replaces a third edition, and conversely the third edition (in the example, ISBN 978-0-00-123456-7) is replaced by the fourth, and how the relationships are specified in the two ONIX records.

Usage of RelatedProduct <Product> <ProductIdentifier> 9780001234567 <EditionNumber> 3 <RelatedProduct> <ProductRelationCode> 05 <ProductIdentifier> 9780001234574 </Product> ONIX record for third edition <Product> <ProductIdentifier> 9780001234574 <EditionNumber> 4 <RelatedProduct> <ProductRelationCode> 03 <ProductIdentifier> 9780001234567 </Product> ONIX record for fourth edition replaced by replaces

It is a common error to get the direction of the relationship wrong. For example, an ONIX Product record that describes a hardback or paperback book may list an e‑book as a related product. That relationship must use code 27, not code 13. Conversely, the Product record describing the e‑book should list the print book as a related product, using the inverse relationship code (ie must use code 13, not 27). Code 13 should never occur in an ONIX record describing a print book, and code 27 should never occur in an ONIX record for an e-publication.

In all cases, there is no requirement that <RelatedProduct> identifies a product published by the same publisher, nor does it imply anything about the status or availability of the related product. Further metadata for the related product should be obtained from the full Product record for that product.

P.23.5, P.23.6 Related product form and form detail

The <RelatedProduct> composite may include limited information about the product form of a related product. This is strongly discouraged, except in circumstances where the ONIX recipient specifically requests this information.

Normal ONIX practice is that all metadata for related products should be derived from the full Product record of the related product – only identifiers should be included within a <RelatedProduct> composite. The <ProductForm> and <ProductFormDetail> data elements are provided in <RelatedProduct> specifically for use in cases where the data recipient does not receive (and does not want to receive) full Product records for the related products – as for example might be the case where ONIX metadata is provided to a specialist e‑book retailer and that retailer does not wish to receive full records about related print products.

Block 6: Product supply

Product supply composite

The <ProductSupply> composite is intended to carry supply chain information – where a product may be ordered from, how much it will cost, when it will be available and so on. But this information is market-specific, and separate repeats of the <ProductSupply> composite should be used to specify different information that applies to different markets.

Note that <ProductSupply> is the only block-level composite in a Product record that is repeatable, once for each market the product is available in. Block 6 of a Product record in principle consists of all the <ProductSupply> composites in the record.

ONIX 3.0 uses a four-level structure to describe the geographical supply arrangements for a product:

  • First, there are the territorial sales rights in Group P.21, which lists all the territories where a publisher wishes to sell the product (including territories where the publisher has exclusive or non-exclusive rights);
  • these territories may be a single market, or may be divided into two or more independent markets, each of which is represented by a <ProductSupply> composite. If there are multiple markets, there are – at least in principle – multiple <ProductSupply> composites;
  • within a market, there may be one or multiple suppliers (distributors, wholesalers and so on), each represented by a <SupplyDetail> composite;
  • each supplier may set multiple prices, and each price might only be valid in a single country, or may be valid in multiple countries.
Of course, not every market need be listed in a particular ONIX record. It may be that the sender of the ONIX message specifies details of only the market within which the message is distributed, omitting irrelevant information about other markets. So the market territories listed may be a subset of the sales rights territories, and other market(s) exist by implication only.
Where a specific list of countries or regions is not included, the assumption must be that the list is inherited from the next ‘higher’ level – so a price without an attached list of countries must be valid throughout the market, and a <ProductSupply> composite that does not include a list of countries or regions must be assumed to mean that the market is the totality of the <SalesRights> area.
This structure in ONIX 3.0 is significantly different from ONIX 2.1. In 3.0, suppliers operate within markets, whereas in 2.1, suppliers have supply-to countries – the order of the hierarchy is modified. And in 3.0, geographical information about sales rights, market extent and price validity consistently use the same XML composite – <Territory>. In 2.1, sales rights, supply-to countries and prices all use quite different XML structures.

So what is a ‘market’? In general, where a product is distributed from a single source – say from one exclusive distributor – then there is a single market. Multiple markets are characterized by there being:

  • more than one exclusive distributor, each having an exclusive geographical territory or an exclusive sales channel;
    • in this case, the sales rights that the publisher is exploiting (see Group P.21) are divided up into narrower and disjunct sets of distribution rights that are granted by the publisher to different distributors. It’s clear that the distribution territories must ‘fit within’ the overall sales rights territories;
    • it is of course possible that distribution territories or channels overlap, but at least part of a market must be exclusive, otherwise it is not a distinct market;
  • significant differences in publication date (or more specifically, in initial market availability date) or other dates and statuses.

Varying prices across different countries or regions, or having multiple non-exclusive distributors or wholesalers do not in themselves indicate that there are multiple markets.

<ProductSupply> describes the product supply chain in a particular market. The <ProductSupply> composite itself has a three part structure:

  • the <Market> composite, Group P.24 describes the geographical (or channel-based) extent of the market;
    • <Market> may be omitted when the product is available in only a single market, since the market would be identical to the <SalesRights> included in Group P.21;
  • the <MarketPublishingDetail> composite, Group P.25 specifies the status and availability of the product in the market;
    • <MarketPublishingDetail> may also be omitted in some circumstances, when the product is available in only a single market;
  • the mandatory <SupplyDetail> composite, Group P.26 carries supplier and pricing details for the product in the market. There can be multiple suppliers, each represented by a repeat of the <SupplyDetail> composite, and a supplier may maintain multiple prices each applicable in a variety of territories.

Note that there is no particular requirement that a Product record contains information on all markets that a product is available in. It is possible for a publisher to provide information on just a single market, even when the product is available more widely, if for example an ONIX data feed is tailored to a specific retailer recipient and that retailer’s operations are clearly within the confines of that market. Or a wholesaler may provide an ONIX feed containing only the details of the market within which it operates, while the data recipient may be a global retailer operating across many markets. (Of course in these cases, <Market> and perhaps <MarketPublishingDetail> should not be omitted). Because of this, great care needs to be taken by recipients who receive ONIX records describing a specific product from multiple sources (a retailer might receive an ONIX record for a particular product from the publisher, from a data aggregator, and from one or more wholesalers). A newly-supplied Block 6 should not replace all data in the recipient’s internal system, but should in most cases only replace data previously received from that particular data supplier.

ProductSupply Market MarketPublishingDetail MarketPublishingDetail SupplyDetail

Additional guidance on the description of markets in ONIX 3.0 will be found in a separate document ONIX for Books Product Information Message: How to Specify Markets and Suppliers in ONIX 3.

P.24 Market

Group P.24 describes the extent of a market – usually in geographical terms, but it may also be limited by sales channel (eg to schools only) and may even be limited to a single customer. It defines the extent of the market within which the following <MarketPublishingDetail> and <SupplyDetail> data applies.

It is obviously important that any specification of the extent of a market does not extend beyond the bounds of the geographical area where the product is for sale as specified in Group P.21, or beyond any sales restriction that applies – any market which includes countries or regions where the product that is not for sale, or which fails to specify sales restrictions that match those in P.21, sets up an internal inconsistency that cannot be resolved by the data recipient. The sum of all markets must be a subset of, or identical to, the publisher’s sales rights. If P.24 is omitted, then the market is understood to be identical to the extent of the publisher’s sales rights.

<Market> should never be omitted when a product is available in multiple markets, even if the particular Product record contains details of only one of those markets.

Market Territory SalesRestriction
market where publisher holds and exploits world rights via one supply chain, but where a separate exclusive distributor has been appointed for Africa (excepting the Maghreb countries, Egypt and some island states)
using Reference names
<Market>
    <Territory>
        <RegionsIncluded>WORLD</RegionsIncluded>
        <CountriesExcluded>AO BJ BW BF BI CM CF TD KM CD CG CI DJ GQ ER ET GA GM GH GN GW KE LS LR LY MG MW ML MZ NA NE NG RW SN SL SO ZA SD SZ TZ TG UG ZM ZW​</CountriesExcluded>
    </Territory>
</Market>
using Short tags
<market>
    <territory>
        <x450>WORLD</x450>World
        <x451>AO BJ BW BF BI CM CF TD KM CD CG CI DJ GQ ER ET GA GM GH GN GW KE LS LR LY MG MW ML MZ NA NE NG RW SN SL SO ZA SD SZ TZ TG UG ZM ZW​</x451>Excluding most of Africa
    </territory>
</market>
The market for the African distributor in a second repeat of the <ProductSupply> composite would simply include all the countries excluded here.
markets where the publisher holds and exploits rights throughout world except the ‘US market’ (which in this case includes Canada, Mexico and the Philippines). The product will be published with a strict sales embargo date in the UK, but with a later pub date and no embargo in the remainder of the world
using Reference names
<ProductSupply>
    <Market>
        <Territory>
            <CountriesIncluded>GB</CountriesIncluded>
        </Territory>
    </Market>
    <!-- <MarketPublishingDetail>, <SupplyDetail> omitted for brevity -->
</ProductSupply>
<ProductSupply>
    <Market>
        <Territory>
            <RegionsIncluded>WORLD</RegionsIncluded>
            <CountriesExcluded>AS CA GB GU MP MX PH PR UM US VI​</CountriesExcluded>
        </Territory>
    </Market>
    <!-- <MarketPublishingDetail>, <SupplyDetail> omitted for brevity -->
</ProductSupply>
using Short tags
<productsupply>First market – UK
    <market>
        <territory>
            <x449>GB</x449>
        </territory>
    </market>
    <!-- <marketpublishingdetail>, <supplydetail> omitted for brevity --><MarketPublishingDetail> carries details of UK pub date, embargo etc (which are identical to the ‘global’ details in Group P.20). <SupplyDetail> carries details of supplier(s) in UK market
</productsupply>
<productsupply>Second market – rest of world
    <market>
        <territory>
            <x450>WORLD</x450>
            <x451>AS CA GB GU MP MX PH PR UM US VI​</x451>(excluding GB and the US market)
        </territory>
    </market>
    <!-- <marketpublishingdetail>, <supplydetail> omitted for brevity --><MarketPublishingDetail> carries detail of the ROW availability date (which is later than the pub date in P.20)
</productsupply>
market where publisher holds rights only in the schools market in Europe (in this case ‘Europe’ is the EU and EFTA)
using Reference names
<Market>
    <Territory>
        <CountriesIncluded>AT BE BG CY CZ DE DK EE ES FI FR GB GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO​</CountriesIncluded>
    </Territory>
    <SalesRestriction>
        <SalesRestrictionType>07</SalesRestrictionType>
    </SalesRestriction>
</Market>
using Short tags
<market>
    <territory>
        <x449>AT BE BG CY CZ DE DK EE ES FI FR GB GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO​</x449>31 countries in the EU and EFTA
    </territory>
    <salesrestriction>
        <b381>07</b381>Schools only
    </salesrestriction>
</market>
In this case, the sales restriction applies to all countries in the market, since it is nested within the only <Market> composite. If it applied only to some of the market, then two repeats of the <Market> composite could be used as in the example below (remember – the market is the sum of the various repeats of <Market>). cf the use of different <SalesRightsType> codes in Group P.21 to indicate whether any sales restrictions apply.
market where a publisher exploits world rights, but has agreed a temporary retailer exclusive in Spain. The product is for general trade sale outside Spain
using Reference names
<Market>
    <Territory>
        <RegionsIncluded>WORLD</RegionsIncluded>
        <CountriesExcluded>ES</CountriesExcluded>
    </Territory>
</Market>
<Market>
    <Territory>
        <CountriesIncluded>ES</CountriesIncluded>
    </Territory>
    <SalesRestriction>
        <SalesRestrictionType>04</SalesRestrictionType>
        <SalesOutlet>
            <SalesOutletName>Casa del Libro​</SalesOutletName>
        </SalesOutlet>
        <EndDate dateformat="00">20110828</EndDate>
    </SalesRestriction>
</Market>
using Short tags
<market>First part of market
    <territory>
        <x450>WORLD</x450>Everywhere…
        <x451>ES</x451>Except Spain
    </territory>
</market>
<market>Second part of market
    <territory>
        <x449>ES</x449>
    </territory>
    <salesrestriction>
        <b381>04</b381>Retailer exclusive in Spain
        <salesoutlet>
            <b382>Casa del Libro​</b382>
        </salesoutlet>
        <b325 dateformat="00">20110828</b325>Until 28 Aug 2011
    </salesrestriction>
</market>
In a slight variation of this case, Casa del Libro’s exclusivity might extend throughout Europe – and if so, it would be better to exclude all EU and EFTA countries from the first part of the market and include them in the second part of the market, to make it clear the product is not for sale through Spanish language bookshops in south-west France or elsewhere in Europe.
‘windowed’ sales restrictions in the North American market
using Reference names
<Market>
    <Territory>
        <CountriesIncluded>CA MX US</CountriesIncluded>
    </Territory>
    <SalesRestriction>
        <SalesRestrictionType>09</SalesRestrictionType>
        <EndDate>20150423</EndDate>
    </SalesRestriction>
    <SalesRestriction>
        <SalesRestrictionType>12</SalesRestrictionType>
        <EndDate>20150625</EndDate>
    </SalesRestriction>
</Market>
using short tags
<market>
    <territory>
        <x449>CA MX US</x449>
    </territory>
    <salesrestriction>
        <b381>09</b381>not for sale to libraries
        <b325>20150423</b325>…until 24 April
    </salesrestriction>
    <salesrestriction>
        <b381>12</b381>not for sale to subscription services
        <b325>20150625</b325>…until 26 June
    </salesrestriction>
</market>
The product is for sale throughout North America, but cannot be sold to libraries until late April, and cannot be sold to ‘subscription’ services until late June. Note that the end date attached to each restriction is ‘inclusive’, so the restriction still holds on that date.
‘Subscription’ services in this case are those that provide readers with ‘all you can eat’ access to a library of e‑books for a fixed monthly fee, and where those e‑books that are read by consumers are purchased by the service from the publisher or distributor. They are usually purchased ‘on demand’, with the purchase triggered by a consumer beginning to read, or when a consumer reads beyond a preset ‘free preview’ limit that may be set using <EpubUsageConstraint>.
Market composite

The <Market> composite is repeatable, and in some cases – particularly where a market restriction applies in only part of a market – multiple repeats may be necessary. The extent of the ‘market’ is the sum of all the repeats of <Market>. It is obvious good practice to minimize the number of repeats, consistent with correct description of the extent of the market itself.

Territory and Sales restriction composites

The <Territory> and <SalesRestriction> composites are identical to those in Group P.21, and similar best practices apply.

However, there is no ‘rest of world’ option within <Market> analogous to <ROWSalesRightsType> within <SalesRights>, and ROW is not a valid option for a region (ROW on List 49 is not used in ONIX 3).

P.25 Market publishing detail

Group P.25 – the <MarketPublishingDetail> composite – comprises three largely separate types of information, all of which are specific to a particular market:

  • in <PublisherRepresentative>, details of any local publisher or agent acting on behalf of the publisher that makes the product available in the market;
  • a market-specific publishing status and relevant dates, analogous to those provided globally by the publisher in Group P.20;
  • selected details of any promotional campaign, copies printed or sold, and other miscellaneous information.
Market publishing detail composite

<MarketPublishingDetail> should not normally be omitted when a product is available in multiple markets, even if the particular Product record contains details of only one of those markets. At minimum, it serves to confirm the publishing status in the specific market. And note that when market-specific details are provided in P.25, it is still best practice to include ‘global’ details in P.20 (even though it is not essential). Doing so makes clear the difference between a product that is available in only one market, and a Product record that contains details of only one market, and expresses nuanced differences between ‘publication date’ and ‘publication or availability date in this market’.

MarketPublishingDetail PublisherRepresentative PublisherRepresentative ProductContact MarketPublishingStatus MarketPublishingStatus MarketPublishingStatusNote MarketPublishingStatusNote MarketDate PromotionCampaign PromotionCampaign PromotionContact PromotionContact InitialPrintRun ReprintDetail CopiesSold BookClubAdoption BookClubAdoption
product from UK publisher available through Australian local publisher
using Reference names
<MarketPublishingDetail>
    <PublisherRepresentative>
        <AgentRole>07</AgentRole>
        <AgentName>HarperCollins Publishers</AgentName>
        <Website>
            <WebsiteRole>18</WebsiteRole>
            <WebsiteLink>https://www.​harpercollins.​com.​au​</WebsiteLink>
        </Website>
    </PublisherRepresentative>
    <MarketPublishingStatus>02</MarketPublishingStatus>
    <MarketDate>
        <MarketDateRole>01</MarketDateRole>
        <Date dateformat="00">20110707</Date>
    </MarketDate>
</MarketPublishingDetail>
using Short tags
<marketpublishingdetail>
    <publisherrepresentative>
        <j402>07</j402>Local publisher
        <j401>HarperCollins Publishers</j401>
        <website>
            <b367>18</b367>Publisher’s consumer website
            <b295>https://www.​harpercollins.​com.​au​</b295>
        </website>
    </publisherrepresentative>
    <j407>02</j407>Forthcoming
    <marketdate>
        <j408>01</j408>Local publication date
        <b306 dateformat="00">20110707</b306>
    </marketdate>
</marketpublishingdetail>
Any publication date provided in P.20 may be the same as or earlier than the local publication date in P.25 – but for obvious reasons should never be later than the P.25 date. ONIX recipients should use the dates and status provided in P.25, unless specifically concerned with the global position.
Publisher representative composite
PublisherRepresentative AgentRole AgentIdentifier AgentName TelephoneNumber TelephoneNumber FaxNumber EmailAddress Website AgentIdentifier AgentIDType IDTypeName IDValue must not omit both must include if ID is proprietary, otherwise omit

A publisher’s representative may be a ‘local publisher’ or a sales agent responsible for a market, but is always an organization, not a person. A local publisher undertakes responsibility for the product in the market – certainly including promotion and distribution, possibly including manufacturing copies of the product, and potentially including legal liabilities that normally lie with the publisher. A local publisher may or may not be named on the product itself: they may be in effect a co-publisher, or simply acting as a distribution agent. In contrast, a sales agent takes on fewer responsibilities – likely limited to promotion and distribution.

What distinguishes a publisher’s representative from a normal importer, distributor, wholesaler or retailer? A representative would be associated with a distinct market, and takes on at least part of the publisher’s role, for example controlling the publication or availability date, within that market. The original publisher would have no direct role in that market, except via the representative.

This composite is – in most respects – the local market equivalent of the <Publisher> composite in Group P.19, and similar best practices apply. Although almost every part of the <PublisherRepresentative> composite is optional, it is best practice to include – at minimum – the mandatory <AgentRole> element and the optional <AgentName>, with any identifiers and the organization’s website if available.

‘Agent’ here does not imply the use of the ‘Agency model’.
Product contact

This composite is analogous to the <ProductContact> composite in Group P.19, although in this case it may carry contact details provided by the publisher’s representative in the market.

This composite replaces the use of the <PromotionContact> date element, plus <TelephoneNumber>, <FaxNumber> and <EmailAddress> within <PublisherRepresentative>, which have been deprecated.
P.25.12 Market publishing status

This data element is directly analogous to <PublishingStatus> in Group P.20, and similar best practices apply. Note however that it uses a different codelist (List 68). When it is provided, a market-specific publishing status or date supersedes any ‘global’ status or date provided in P.20 for the specific market only.

Similarly, some statuses require associated dates in <MarketDate>.

MarketDate MarketDateRole DateFormat Date use dateformat attribute on <Date> element instead
specifying the product is ‘out of print in this market’
using Reference names
<MarketPublishingStatus>07</MarketPublishingStatus>
<MarketDate>
    <MarketDateRole>13</MarketDateRole
    <Date dateformat="00">20091022</Date>
</MarketDate>
using Short tags
<j407>07</j407>
<marketdate>
    <j408>13</j408
    <b306 dateformat="00">20091022</b306>
</marketdate>
The implication here – because it is not ‘globally’ out of print – is that the product is still in print in another market. Only the local publisher or publisher’s representative has declared it out of print.
P.25.17 to P.25.22 Promotion details

These data elements relate to promotional activity in a particular market.

The most likely to be used is the <PromotionalCampaign> data element: this should be used to specify market-specific advertising and promotion plans prior to publication or reissue – the planned use of print or broadcast advertising, for example, any author tour or other media tie-ins. There is some overlap here with information that can be provided in Group P.16, which can include links to press releases or an author tour itinerary. However, details in P.25 are market-specific, and are clearly intended for trade use only.

If <PromotionalCampaign> details are provided, it is good practice to also supply a contact name in <PromotionContact> for queries about the promotional activity. This would normally be the person responsible for advertising and promotion of the product in this particular market – a person in the publisher’s or publisher’s representative’s publicity department for example.

The <InitialPrintRun> data element might be used to provide details of limited and numbered editions (see <EditionType> codes NUM, SPE in Group P.9), but best practice would be to provide this information in an <EditionStatement> element. Use <InitialPrintRun> only when the size of the print run is to be treated as ‘promotional’ – for example, to express the confidence the publisher has in the product.

P.26 Supply detail

Group P.26 is the <SupplyDetail> composite, and it is the most complex of the Groups in the ONIX for Books Specification. However, large parts of the Group are optional and used only rarely: the commonly-used parts of the <SupplyDetail> composite are limited to two composites – <Supplier> and <Price>, plus a handful of data elements specifying the availability of the product from the supplier.

In the case of physical products, a ‘supplier’ is normally a distributor or wholesaler from whom a retailer can obtain the product for resale. For digital products, the ‘supplier’ is normally a ‘retail platform’, which may be operated for or by a single retail entity, or by a platform owner offering technical fulfillment services to a range of retailers.

Supply detail composite

Within any specific market – as represented by the whole <ProductSupply> composite – there must be at least one, and may be many suppliers: each supplier is represented by a <SupplyDetail> composite.

Each supplier would normally, but need not be willing (or even able to) supply the product to every part of the market. Setting prices that are valid for specific territories indicates an offer to supply to those territories. The price need not be set in the currency of the country involved. So a Spanish publisher could set export prices in Euro valid for various countries which do not themselves use the Euro internally.

But note that price territories must be a subset of or identical to the market territories, which are either specified in Group P.24 or are understood to be identical to the publisher’s sales rights specified in Group P.21 if P.24 is omitted.

Additional guidance on the description of suppliers and price territories in ONIX 3.0 will be found in a separate document ONIX for Books Product Information Message: How to Specify Markets and Suppliers in ONIX 3.

SupplyDetail Supplier SupplyContact SupplyContact SupplierOwnCoding SupplierOwnCoding ReturnsConditions ReturnsConditions ProductAvailability ProductAvailability SupplyDate OrderTime NewSupplier Stock PackQuantity PalletQuantity OrderQuantityMinimum OrderQuantityMinimum OrderQuantityMinimum OrderQuantityMinimum OrderQuantityMultiple OrderQuantityMultiple UnpricedItemType UnpricedItemType Price Reissue
supplier of forthcoming product is publisher/distributor of physical book
using Reference names
<SupplyDetail>
    <Supplier>
        <SupplierRole>01</SupplierRole>
        <SupplierIdentifier>
            <SupplierIDType>06</SupplierIDType>
            <IDValue>8001234567897</IDValue>
        </SupplierIdentifier>
        <SupplierName>Campione Editore</SupplierName>
        <TelephoneNumber>+39 0123 45678901</TelephoneNumber>
        <EmailAddress>vendite@campioneeditore.com</EmailAddress>
    </Supplier>
    <ReturnsConditions>
        <ReturnsCodeType>04</ReturnsCodeType>
        <ReturnsCode>03</ReturnsCode>
    </ReturnsConditions>
    <ProductAvailability datestamp="20110517">10</ProductAvailability>
    <SupplyDate>
        <SupplyDateRole>08</SupplyDateRole>
        <Date dateformat="00">20110621</Date>
    </SupplyDate>
    <PackQuantity>8</PackQuantity>
    <Price>
        <PriceType>02</PriceType>
        <Discount>
            <DiscountPercent>37.5</DiscountPercent>
        </Discount>
        <PriceStatus>02</PriceStatus>
        <PriceAmount>7.95</PriceAmount>
        <Tax>
            <TaxType>01</TaxType>
            <TaxRateCode>P</TaxRateCode>
            <TaxRatePercent>4<TaxRatePercent>
            <TaxableAmount>7.64</TaxableAmount>
            <TaxAmount>0.31</TaxAmount>
        </Tax>
        <CurrencyCode>EUR</CurrencyCode>
        <Territory>
            <CountriesIncluded>IT</CountriesIncluded>
        </Territory>
        <PrintedOnProduct>02</PrintedOnProduct>
        <PositionOnProduct>00</PositionOnProduct>
    </Price>
    <!-- Price composites for other countries omitted -->
</SupplyDetail>
using Short tags
<supplydetail>
    <supplier>
        <j292>01</j292>Publisher supplies retailers
        <supplieridentifier>
            <j345>06</j345>GLN
            <b244>8001234567897</b244>
        </supplieridentifier>
        <j137>Campione Editore</j137>
        <j270>+39 0123 45678901</j270>
        <j272>vendite@campioneeditore.com</j272>
    </supplier>
    <returnsconditions>
        <j268>04</j268>ONIX returns code
        <j269>03</j269>Sale or return
    </returnsconditions>
    <j396 datestamp="20110517">10</j396>Not yet published
    <supplydate>
        <x461>08</x461>Expected availability
        <b306 dateformat="00">20110621</b306>YYYYMMDD format
    </supplydate>
    <j145>8</j145>Packed 8 per carton
    <price>
        <x462>02</x462>RRP including tax
        <discount>
            <j267>37.5</j267>
        </discount>
        <j266>02</j266>Firm
        <j151>7.95</j151>
        <tax>
            <x470>01</x470>VAT
            <x471>P</x471>Tax paid at source
            <x472>4<x472>%
            <x473>7.64</x473>
            <x474>0.31</x474>
        </tax>
        <j152>EUR</j152>
        <territory>
            <x449>IT</x449>Price valid only in Italy
        </territory>
        <x301>02</x301>Price is printed on product
        <x313>00</x313>Position is unspecified
    </price>
    <!-- prices for other countries omitted -->
</supplydetail>
Special tax rules in Italy allow VAT to be prepaid at source by the publisher. Books are subject to VAT at the 4% rate.
supplier is distributor of POD product
using Reference names
<SalesRights>
    <SalesRightsType>01</SalesRightsType>
    <Territory>
        <RegionsIncluded>WORLD<RegionsIncluded>
        <CountriesExcluded>CA US VI GU AS PR PH UM MX</CountriesExcluded>
    </Territory>
</SalesRights>
<SalesRights>
    <SalesRightsType>06</SalesRightsType>
    <Territory>
        <CountriesIncluded>CA US VI GU AS PR PH UM MX<CountriesIncluded>
    </Territory>
</SalesRights>
<!-- no ROW sales rights type needed -->
. . .
<SupplyDetail>
    <Supplier>
        <SupplierRole>0</SupplierRole>
        <SupplierIdentifier>
            <SupplierIDType>06</SupplierIDType>
            <IDValue>5030670160471</IDValue>
        </SupplierIdentifier>
        <SupplierName>Lightning Source</SupplierName>
        <EmailAddress>info@lightningsource.com</EmailAddress>
    </Supplier>
    <ReturnsConditions>
        <ReturnsCodeType>04</ReturnsCodeType>
        <ReturnsCode>02</ReturnsCode>
    </ReturnsConditions>
    <ProductAvailability datestamp="20120324">23</ProductAvailability>
    <OrderTime>1</OrderTime>
    <Price>
        <PriceType>02</PriceType>
        <DiscountCoded>
            <DiscountCodeType>01</DiscountCodeType>
            <DiscountCode>AKOGA095</DiscountCode>
        </DiscountCoded>
        <PriceStatus>02</PriceStatus>
        <PriceAmount>29.95</PriceAmount>
        <Tax>
            <TaxType>01</TaxType>
            <TaxRateCode>Z</TaxRateCode>
            <TaxRatePercent>0</TaxRatePercent>
            <TaxableAmount>29.95</TaxableAmount>
            <TaxAmount>0.00</TaxAmount>
        </Tax>
        <CurrencyCode>GBP</CurrencyCode>
        <Territory>
            <CountriesIncluded>GB</CountriesIncluded>
        </Territory>
        <PrintedOnProduct>02</PrintedOnProduct>
        <PositionOnProduct>01</PositionOnProduct>
    </Price>
    <Price>
        <PriceType>01</PriceType>
        <DiscountCoded>
            <DiscountCodeType>01</DiscountCodeType>
            <DiscountCode>AKOGA096</DiscountCode>
        </DiscountCoded>
        <PriceStatus>02</PriceStatus>
        <PriceAmount>29.95</PriceAmount>
        <!-- no tax composite -->
        <CurrencyCode>GBP</CurrencyCode>
        <Territory>
            <RegionsIncluded>WORLD</RegionsIncluded>
            <CountriesExcluded>GB CA US VI GU AS PR PH UM MX</CountriesExcluded>
        </Territory>
        <PrintedOnProduct>01</PrintedOnProduct>
    </Price>
</SupplyDetail>
using Short tags
<salesrights>
    <b089>01</b089>
    <territory>
        <x450>WORLD<x450>For sale everywhere
        <x451>CA US VI GU AS PR PH UM MX</x451>…except US, CA, MX market
    </territory>
</salesrights>
<salesrights>
    <b089>06</b089>Not for sale, as publisher
    <territory>…has no rights in
        <x449>CA US VI GU AS PR PH UM MX<x449>…US, CA, MX market
    </territory>
</salesrights>
<!-- no ROW sales rights type needed -->Because all exceptions to world rights are explicitly associated with type 06
. . .
<supplydetail>
    <supplier>
        <j292>0</j292>
        <supplieridentifier>
            <j345>06</j345>GLN
            <b244>5030670160471</b244>
        </supplieridentifier>
        <j137>Lightning Source</j137>
        <j272>info@lightningsource.com</j272>
    </supplier>
    <returnsconditions>
        <j268>04</j268>ONIX returns codes
        <j269>02</j269>Firm sale
    </returnsconditions>
    <j396 datestamp="20120324">23</j396>Available POD
    <j144>1</j144>One day turnaround
    <price>
        <x462>02</x462>Price inc tax
        <discountcoded>
            <j363>01</j363>BIC discount code scheme
            <j364>AKOGA095</j364>
        </discountcoded>
        <j266>02</j266>Firm price
        <j151>29.95</j151>
        <tax>
            <x470>01</x470>VAT
            <x471>Z</x471>…is zero-rated
            <x472>0</x472>
            <x473>29.95</x473>
            <x474>0.00</x474>
        </tax>
        <j152>GBP</j152>Pounds Sterling
        <territory>
            <x449>GB</x449>Price applicable in GB only
        </territory>
        <x301>02</x301>Price printed
        <x313>01</x313>…on back cover
    </price>
    <price>
        <x462>01</x462>Price ex tax
        <discountcoded>
            <j363>01</j363>BIC discount code scheme
            <j364>AKOGA096</j364>
        </discountcoded>
        <j266>02</j266>Firm price
        <j151>29.95</j151>
        <!-- no tax composite -->…as price is ex-tax
        <j152>GBP</j152>Pounds Sterling
        <territory>
            <x450>WORLD</x450>Price applicable everywhere
            <x451>GB CA US VI GU AS PR PH UM MX</x451>…except GB (where other price is applicable) and US, CA, MX market (where the product is not for sale)
        </territory>
        <x301>01</x301>This price not printed on product
    </price>
</supplydetail>
Recommended retail price in UK is £29.95 including tax. Recommended retail price elsewhere is £29.95 plus any local taxes.
supplier is exclusive retail platform for e‑book, on agency terms, for US and Canadian market
using Reference names
<ProductSupply>
    <!-- Group P.24 -->
    <Market>
        <Territory>
            <CountriesIncluded>CA US VI GU AS PR PH UM​</CountriesIncluded>
        </Territory>
    </Market>
    <!-- Group P.25 -->
    <MarketPublishingDetail>
        <MarketPublishingStatus>02</MarketPublishingStatus>
        <MarketDate>
            <!-- nominal publication date -->
            <MarketDateRole>01</MarketDateRole>
            <Date dateformat="00">20110816</Date>
        </MarketDate>
        <MarketDate>
            <MarketDateRole>02</MarketDateRole>
            <Date dateformat="00">20110809</Date>
        </MarketDate>
    </MarketPublishingDetail>
    <!-- Group P.26 -->
    <SupplyDetail>
        <Supplier>
            <SupplierRole>10</SupplierRole>
            <SupplierName>e‑books4U</SupplierName>
            <TelephoneNumber>+1 212 555 0123</TelephoneNumber>
            <EmailAddress>info@ebooks4u.com</EmailAddress>
        </Supplier>
        <ProductAvailability datestamp="20110621">10</ProductAvailability>
        <SupplyDate>
            <SupplyDateRole>02</SupplyDateRole>
            <Date dateformat="00">20110809</Date>
        </SupplyDate>
        <Price>
            <PriceType>41</PriceType>
            <DiscountCoded>
                <DiscountCodeType>05</DiscountCodeType>
                <DiscountCodeTypeName>MyBooks Agency Type​</DiscountCodeTypeName>
                <DiscountCode>B</DiscountCode>
            </DiscountCoded>
            <PriceStatus>02</PriceStatus>
            <PriceAmount>7.99</PriceAmount>
            <CurrencyCode>USD</CurrencyCode>
            <Territory>
                <CountriesIncluded>US VI GU AS PR PH UM​</CountriesIncluded>
            </Territory>
        </Price>
        <Price>
            <PriceType>41</PriceType>
            <DiscountCoded>
                <DiscountCodeType>05</DiscountCodeType>
                <DiscountCodeTypeName>MyBooks Agency Type​</DiscountCodeTypeName>
                <DiscountCode>B</DiscountCode>
            </DiscountCoded>
            <PriceStatus>02</PriceStatus>
            <PriceAmount>7.49</PriceAmount>
            <CurrencyCode>CAD</CurrencyCode>
            <Territory>
                <CountriesIncluded>CA</CountriesIncluded>
            </Territory>
        </Price>
    </SupplyDetail>
</ProductSupply>
using Short tags
<productsupply>
    <!-- Group P.24 -->
    <market>
        <territory>
            <x449>CA US VI GU AS PR PH UM​</x449>
        </territory>
    </market>
    <!-- Group P.25 -->
    <marketpublishingdetail>
        <j407>02</j407>
        <marketdate>
            <MarketDateRole>01</MarketDateRole>Nominal publication date
            <Date dateformat="00">20110816</Date>
        </marketdate>
        <marketdate>
            <j408>02</j408>Embargo (strict on-sale) date
            <b306 dateformat="00">20110809</b306>
        </marketdate>
    </marketpublishingdetail>
    <!-- Group P.26 -->
    <supplydetail>
        <supplier>
            <j292>10</j292>Exclusive distributor to end customers
            <j137>e‑books4U</j137>
            <j270>+1 212 555 0123</j270>
            <j272>info@ebooks4u.com</j272>
        </supplier>
        <j396 datestamp="20110621">10</j396>Not yet available
        <supplydate>
            <x461>02</x461>Embargo date
            <b306 dateformat="00">20110809</b306>
        </supplydate>
        <price>
            <x462>41</x462>‘Agency’ price, exc-tax
            <discountcoded>
                <j363>05</j363>Proprietary commission terms code
                <j378>MyBooks Agency Type​</j378>
                <j364>B</j364>
            </discountcoded>
            <j266>02</j266>Firm price
            <j151>7.99</j151>
            <j152>USD</j152>US$ price
            <territory>
                <x449>US VI GU AS PR PH UM​</x449>for US market
            </territory>
        </price>
        <price>
            <x462>41</x462>‘Agency’ price, exc-tax
            <discountcoded>
                <j363>05</j363>Proprietary commission terms code
                <j378>MyBooks Agency Type​</j378>
                <j364>A</j364>
            </discountcoded>
            <j266>02</j266>
            <j151>7.49</j151>
            <j152>CAD</j152>CA$ price
            <territory>
                <x449>CA</x449>for Canada only
            </territory>
        </price>
    </supplydetail>
</productsupply>
The retail platform (the supplier) can sell exclusively to the US market and Canada, in either US$ or CA$, but retail price is fixed by the publisher (the ‘agency’ model). The publisher maintains a code indicating to the reseller what commission % it will receive on each sale. If the publisher has rights beyond the US market and Canada, a second <ProductSupply> composite could carry the wider market and supply details.
future increase in recommended retail price
using Reference names
<Price>
    <PriceType>01</PriceType>
    <DiscountCoded>
        <DiscountCodeType>01</DiscountCodeType>
        <DiscountCode>ATAFR005</DiscountCode>
    </DiscountCoded>
    <PriceStatus>02</PriceStatus>
    <PriceAmount>7.99</PriceAmount>
    <CurrencyCode>EUR</CurrencyCode>
    <Territory>
        <CountriesIncluded>AT BE CY FI FR DE ES GR IE IT LU MT NL PT SI SK AD MC ME SM VA</CountriesIncluded>
    </Territory>
    <PriceDate>
        <PriceDateRole>15</PriceDateRole>
        <Date>20120429</Date>
    </PriceDate>
</Price>
<Price>
    <PriceType>01</PriceType>
    <DiscountCoded>
        <DiscountCodeType>01</DiscountCodeType>
        <DiscountCode>ATAFR005</DiscountCode>
    </DiscountCoded>
    <PriceStatus>02</PriceStatus>
    <PriceAmount>8.99</PriceAmount>
    <CurrencyCode>EUR</CurrencyCode>
    <Territory>
        <CountriesIncluded>AT BE CY FI FR DE ES GR IE IT LU MT NL PT SI SK AD MC ME SM VA</CountriesIncluded>
    </Territory>
    <PriceDate>
        <PriceDateRole>14</PriceDateRole>
        <Date>20120430</Date>
    </PriceDate>
</Price>
using Short tags
<price>
    <x462>01</x462>RRP exc-tax
    <discountcoded>
        <j363>01</j363>BIC discount code
        <j364>ATAFR005</j364>
    </discountcoded>
    <j266>02</j266>Price is firm
    <j151>7.99</j151>
    <j152>EUR</j152>
    <territory>
        <x449>AT BE CY FI FR DE ES GR IE IT LU MT NL PT SI SK AD MC ME SM VA</x449>
    </territory>
    <pricedate>
        <x476>15</x476>Price valid until
        <b306>20120429</b306>29th April
    </pricedate>
</price>
<price>
    <x462>01</x462>RRP exc-VAT
    <discountcoded>
        <j363>01</j363>
        <j364>ATAFR005</j364>
    </discountcoded>
    <j266>02</j266>
    <j151>8.99</j151>Increased price
    <j152>EUR</j152>
    <territory>
        <x449>AT BE CY FI FR DE ES GR IE IT LU MT NL PT SI SK AD MC ME SM VA</x449>
    </territory>
    <pricedate>
        <x476>14</x476>New price valid from
        <b306>20120430</b306>30th April
    </pricedate>
</price>
Valid from and Valid to dates are inclusive. That is, the end date for one price should be the day before the start date of the next price. Prices are assumed to switch outside business hours between the two trading days, or at midnight, unless specific time and timezone details are included.
temporary special offer pricing (two price method)
using Reference names
<Price>
    <PriceType>07</PriceType>Wholesale price inc-tax
    <PriceTypeQualifier>00</PriceTypeQualifier>‘Normal’ unqualified price
    <Discount>
        <Quantity>10</Quantity>
        <DiscountPercent>6.5</DiscountPercent>
    </Discount>
    <PriceAmount>49.00</PriceAmount>
    <Tax>
        <TaxType>01</TaxType>VAT
        <TaxRateCode>R</TaxRateCode>at Reduced rate
        <TaxRatePercent>6</TaxRatePercent>of 6%
        <TaxableAmount>46.25</TaxableAmount>Ex-VAT price
        <TaxAmount>2.75</TaxAmount>Tax payable
    </Tax>
    <CurrencyCode>SEK</CurrencyCode>
    <Territory>
        <CountriesIncluded>SE</CountriesIncluded>
    </Territory>
</Price>
<Price>
    <PriceType>07</PriceType>Wholesale price inc-tax
    <PriceTypeQualifier>08</PriceTypeQualifier>‘Special offer’
    <PriceAmount>39.00</PriceAmount>Reduced by SEK10.00
    <Tax>
        <TaxType>01</TaxType>VAT
        <TaxRateCode>R</TaxRateCode>at Reduced rate
        <TaxRatePercent>6</TaxRatePercent>of 6%
        <TaxableAmount>36.75</TaxableAmount>Ex-VAT price
        <TaxAmount>2.25</TaxAmount>Tax payable
    </Tax>
    <CurrencyCode>SEK</CurrencyCode>
    <Territory>
        <CountriesIncluded>SE</CountriesIncluded>
    </Territory>
    <PriceDate>
        <PriceDateRole>24</PriceDateRole>
        <Date dateformat="12">Swedish Book Promotion Week</Date>This lower price only valid for a short period (normally, exact start and end dates are provided. In this case, exact dates unknown – should be supplied in later update message)
    </PriceDate>
</Price>
using Short tags, prices provided ex-VAT (and therefore without the <Tax> composite)
<price>
    <x462>05</x462>Wholesale price exc-tax
    <j261>00</j261>‘Normal’ unqualified price
    <discount>
        <x320>10</x320>Additional volume discount
        <j267>6.5</j267>below wholesale price
    </discount>
    <j151>46.25</j151>
    <j152>SEK</j152>Swedish Krona
    <territory>
        <x449>SE</x449>Price valid in Sweden only
    </territory>
</price>
<price>
    <x462>07</x462>Wholesale price
    <j261>08</j261>‘Special offer’
    <j151>36.75</j151>
    <j152>SEK</j152>Swedish Krona
    <territory>
        <x449>SE</x449>Price valid in Sweden only
    </territory>
    <pricedate>
        <x476>24</x476>Price valid during
        <b306 dateformat="12">Swedish Book Promotion Week</b306>Exact dates of period unknown
    </pricedate>
</price>
The product is available on wholesale terms to the Swedish book trade, at SEK49 including 6% Swedish VAT (or SEK46.25 ex VAT in the short tags example). A discount of 6.5% below the normal wholesale price applies for orders of 10 copies or more. The product is planned to be available on ‘special offer’ for a reduced wholesale price of SEK39 (or SEK36.75 ex VAT in the short tags example) for a short promotional period, though no volume discount will apply to orders at the promotional price. The dates of the promotional period are as yet uncertain: this is a rare use of dateformat code 12 from List 55 for a complex, approximate or uncertain date, and the details should be updated as soon as the exact dates of Book Promotion Week are known, with something like <b306 dateformat="06">2012013120120213</b306> (ie 31st Jan to 13th Feb 2012). See the closed-end price promotion example in discussion of the Price date composite
Supplier composite

The <Supplier> composite is mandatory, and should contain enough information to clearly identify a supplier for the product. This might be as little as the name of the supplier organization, but ideally would include multiple contact options too – telephone, e‑mail, fax (still somewhat useful for international orders) and an identifier that might be used in any electronic ordering system. The identifier would typically be a SAN or GLN, whichever is in most common use within the supplier’s market. Ideally, a personal or department contact name, and relevant phone and fax numbers should be provided – these are best delivered in the following <SupplyContact> composite, and the phone and fax numbers should whenever possible be full international numbers – +1 212 555 0123 rather than (212) 555‑0123.

Supplier SupplierRole SupplierIdentifier SupplierName TelephoneNumber TelephoneNumber FaxNumber EmailAddress Website SupplierIdentifier SupplierIDType IDTypeName IDValue must not omit both must include if ID is proprietary, otherwise omit

Within the <Supplier> composite, a ‘role’ is mandatory. This data element describes the position of the supplier in the supply chain, in relation to the original publisher and the end purchaser or consumer, and lets recipients of the data (other than the supplier) know where an order can be directed. In most physical supply chains, the key parties are publishers, distributors (also sometimes called ‘vendors of record’), wholesalers and retailers or library suppliers. Some publishers act also as distributors, whereas others appoint distributors to act on their behalf, and ‘publishers’ may in some cases be market-specific representatives of the originating publisher. The supply chain for digitally-delivered products is more varied, with intermediaries offering a variety of services that ultimately connect publisher to consumer.

For physically-delivered products, the ‘supplier’ is an organization to which an order for a product might be directed by a downstream customer. So a distributor is a supplier (for wholesalers and usually also for retailers). A retailer is a supplier too, though it is perhaps less clear at whom a message containing a <Supplier> composite that describes a retail offering might be aimed (the retailer’s website is one possibility).

For digitally-delivered products, the supplier is also the organization to which orders should be directed. So for example, a publisher offering direct fulfillment of e-publications to consumers might name itself as the supplier. In contrast, a publisher of products that are unique to a specific ‘retail platforms’ should name that platform as the supplier. And ONIX data sent from a publisher that contracts with a digital services intermediary might name the intermediary as the ‘supplier’, since it is to the intermediary that a retailer might apply prior to retailing that publisher’s catalog. Individual consumer orders handled by the retailer would be forwarded to the digital services intermediary, from whom the consumer would download the file.

For all these various scenarios, the supplier’s position within the supply chain must be specified using the <SupplierRole> data element and a code from List 93.

Certain countries operate identification schemes for companies and/or locations. These are often vital enablers for e-commerce systems that allow ONIX recipients to place orders with particular suppliers. In territories where a particular identification system is used, the identifiers should be included in a <SupplierIdentifier> composite – and in particular, suppliers should ensure that all identifiers used within any e-commerce system in which the supplier participates are included. The preferred identifier for international usage is the GLN.

Supply contact composite

The <SupplyContact> composite is intended to allow specification of multiple contact details at the supplier organization. There may be one contact – including a personal or departmental name, phone and e‑mail addresses – for ordinary enquiries, for sales orders, credit control, returns authorization etc, each with a distinct <SupplyContactRole>.

SupplyContact SupplyContactRole SupplyContactRole SupplyContactIdentifier SupplyContactIdentifier SupplyContactName SupplyContactName ContactName EmailAddress SupplyContactIdentifier SupplyContactIDType SupplyContactIDType IDTypeName IDValue must not omit both must include if ID is proprietary, otherwise omit
Distributor’s return authorization contact
using Reference names
<SupplyContact>
    <SupplyContactRole>07</SupplyContactRole>
    <SupplyContactIdentifier>
        <SupplyContactIDType>07</SupplyContactIDType>
        <IDValue>0155144</IDValue>
    </SupplyContactIdentifier>
    <SupplyContactName>Turpin Distribution</SupplyContactName>
    <EmailAddress>turpinna@turpin-distribution.com</EmailAddress>
</SupplyContact>
using Short tags, with additional contact detail for ordinary enquiries
<supplycontact>
    <x537>07</x537>Return authorizations
    <supplycontactidentifier>
        <x538>07</x538>
        <b244>0155144</b244>
    </supplycontactidentifier>
    <x539>Turpin Distribution</x539>
    <j272>turpinna@turpin-distribution.com</j272>
</supplycontact>
<supplycontact>
    <x537>99</x537>Customer services
    <supplycontactidentifier>
        <x538>07</x538>
        <b244>0155144</b244>
    </supplycontactidentifier>
    <x539>Turpin Distribution</x539>
    <x299>Customer services, +44 1767 604800<x299>
    <j272>custserv@turpin-distribution.com</j272>
</supplycontact>
By convention, any phone number is included within the <ContactName> element.
Supplier own coding composite
SupplierOwnCoding SupplierCodeType SupplierCodeType SupplierCodeTypeName SupplierCodeTypeName SupplierCodeValue SupplierCodeValue should include to clarify code type
Publisher’s sales guidance
using Reference names
<SupplierOwnCoding>
    <SupplierCodeType>03</SupplierCodeType>
    <SupplierCodeTypeName>Collins Sales Guide</SupplierCodeTypeName>
    <SupplierCodeValue>B+</SupplierCodeValue>
</SupplierOwnCoding>
using Short tags
<supplierowncoding>
    <x458>03</x458>
    <x513>Collins Sales Guide</x513>
    <x459>B+</x459>indicates level of expected sales
</supplierowncoding>
Indication of backlist / frontlist status
using Reference names
<SupplierOwnCoding>
    <SupplierCodeType>04</SupplierCodeType>
    <SupplierCodeTypeName>Apple Price Agreement</SupplierCodeTypeName>
    <SupplierCodeValue>F</SupplierCodeValue>
</SupplierOwnCoding>
using Short tags
<supplierowncoding>
    <x458>04</x458>
    <x513>Apple Price Agreement</x513>
    <x459>F</x459>indicates Frontlist (so price agreement applies)
</supplierowncoding>
Supplier own coding should only be used when the information is supplier-specific. All codes are necessarily proprietary, and although <SupplierCodeTypeName> is not mandatory (for compatibility with versions earlier than 3.0.2), it is best practice for suppliers to agree – and use – consistent naming for each type of code.

The <SupplierOwnCoding> composite is used to carry supplier-specific information from publisher to supplier, or from supplier to retailer. The examples above show publisher-to-supplier information – a guide to expected sales, which the supplier might use to gauge how many copies to order prior to publication, a code indicating the backlist / frontlist status of the product, which may be used to control contractual limits on pricing (eg in this case via Apple), and a yes/no indication of whether the product can be included in a ‘subscription’ collection.

Returns conditions composite

Since in many countries, most but not all products in the physical book supply chain are offered on a sale-or-return basis, it is vital that all such products should specify their returnability.

ReturnsConditions ReturnsCodeType ReturnsCodeType ReturnsCodeTypeName ReturnsCodeTypeName ReturnsCode ReturnsNote must include if type is proprietary, otherwise omit

The simplest way to specify returnability is to make use of the ONIX Returns Conditions codes in List 204, which can indicate whether the goods are on consignment, firm sale, or ‘sale or return’. An alternative for North American use is the BISAC Returns codes in List 66, which specifies a basic set of four codes – returnable, not returnable, conditional (ie contact the supplier) and strippable (ie returnable, but only the cover need be sent back). However, some countries maintain other code lists, and it is best practice to include the relevant codes from lists in widespread use across the territories where the supplier operates. Where a standard returns code is not appropriate, a proprietary returns coding scheme can be used.

Where the coded returns conditions require further instructions or elaboration, text in <ReturnsNote> element should give further details.

Returns conditions can be a key data element when products switch from normal stock availability to print-on-demand, or to out of print. POD products are often not returnable, and the change in Returns conditions plus the Product availability and Order time may be the only three data elements that are modified when this switch happens. Ideally, a supplier would provide some notice of the latest date on which returns will be accepted, using the <SupplyDate> composite.

In principle, electronically-delivered products such as e‑books are subject to returns too – a consumer might return a product for technical reasons, for example – but such returns are normally dealt with by the retailer as a customer service issue and an adjustment made to the sales reports: there is nothing physical to return. The <ReturnsConditions> composite should not usually be included for electronically-delivered products.

P.26.17 Product availability

The <ProductAvailability> data element is mandatory within the <SupplyDetail> composite.

This data element is very simple for most products: a product advances from Not yet available (code 10) to In stock (code 21), possibly with a short period where the availability is Awaiting stock (ie it has been published, but stock is still not available, code 11). During its life, there may be short periods where the product is Out of stock (code 31). Towards the end of the product’s life, it advances from In stock to Not available, and the publisher indicates it is Out of print (code 51). Although List 65 contains many other availability codes, most are minor modifications on these few.

It is good practice to add a datestamp attribute to the <ProductAvailability> data element, particularly where the ‘age’ of the availability data is different from the overall age of the message derived from <SentDateTime> in the message header.

Supply date composite

Some values of <ProductAvailability>, from List 65, should also be accompanied by a <SupplyDate> composite, for example giving an expected availability date (from the supplier in question) or latest date that returns will be accepted (by the supplier in question). The Expected availability date is often called the Release date, the date on which stock is released from the supplier’s warehouse to wholesalers and retailers.

Sales embargo dates should not normally be included here (or at least, not only here): it is best practice to supply these in either Group P.20 (for globally-administered embargoes) or Group P.25 (for embargoes applied in a specific market). Very occasionally, it might be appropriate to add an embargo in Supply date, where it differs from the market or global embargo: in this case, the embargo applies only to copies sourced from the supplier in question, and a different embargo applies to copies sourced elsewhere.

SupplyDate SupplyDateRole DateFormat Date use dateformat attribute on <Date> element instead

Note that different suppliers may report different availabilities at the same time – a product may be out of stock at one wholesaler for example, while being available from stock at another. <ProductAvailability> is unique to a supplier, and need not even reflect the publisher’s <PublishingStatus> supplied in Group P.20: the publisher may declare a product out of print, while a supplier retains stock. At that point, and depending on the original terms of trade, a supplier may have the opportunity to return unsold stock, or retain the stock for continued retail fulfillment.

For products that are not normally available from stock – particularly those that are available print-on-demand or only-to-order (ie <ProductAvailability> codes 22 and 23), it is best practice to include the <OrderTime> data element, so an ONIX recipient may judge the expected delay in fulfilling an order. An <OrderTime> of zero means a same-day service, but typical values are more likely to be 1–3 days for print-on-demand and longer for only-to-order.

For digital products, availability is usually much simpler than for physical items: only a subset of the codes in List 65 are likely to be appropriate.

Availability codes from List 65 (for digital products)
product availability from supplier code
Canceled01
Not yet available ³10
Available20
Temporarily unavailable ³30
Temporarily withdrawn ³34
Not available40
Not available, replaced by new product41
Not available, other format available42
No longer supplied by us43
Withdrawn from sale46
Not available, publisher indicates OP ¹51
Not available, publisher no longer sells product in this market ²52

¹ ie the publisher no longer sells product in any market
² eg for rights reasons
³ a <SupplyDate> composite should also be provided. Note that this status implies the product can be ‘pre-ordered’ (subject to any pre-order embargo listed in <PublishingDate>)

Stock quantity composite

ONIX data suppliers may or may not wish to provide details of stock quantities held at their distribution locations. Such information can be commercially sensitive – but can also be valuable to retailers as it helps avoid large orders being placed when only small numbers of copies are in stock. Stock quantities can be either accurate numbers of copies, or can be deliberately obfuscated to reduce their sensitivity – the optional <Proximity> element is used to indicate the likely accuracy of the stock figure.

It can also be useful for distributors and wholesalers to provide an estimate of the rate of sale of existing stock, known as stock velocity, as an indicator of likely future exhaustion of stock (and this can also be subject to an optional proximity value). When combined with stock figures, velocity information reduces the likelihood of orders that can only be part fulfilled, or of a backorder

The entire <Stock> composite is repeatable if the supplier has multiple locations from which stock might be fulfilled, and in this case, a <LocationName> (or perhaps a location identifier) should be included. If the supplier has only a single location, then neither the location name nor an identifier is necessary.

<Stock> is not relevant with POD, OTO or digital products.

Stock LocationIdentifier LocationIdentifier LocationName StockQuantityCoded StockQuantityCoded OnHand Proximity Reserved Proximity OnOrder Proximity CBO Proximity OnOrderDetail Velocity should not omit both if <Stock> is repeated
OnOrderDetail OnOrder Proximity ExpectedDate Velocity VelocityMetric Rate Proximity
providing an approximate stock quantity
using Reference names
<Stock>
    <LocationName>Carlisle</LocationName>
    <OnHand datestamp="20100921">1400</OnHand>
    <Proxmimity>06</Proximity>
    <Velocity>
        <VelocityMetric>01</VelocityMetric>
        <Rate>125</Rate>
        <Proximity>05</Proximity>
    </Velocity>
</Stock>
using Short tags
<stock>
    <j349>Carlisle</j349>Warehouse location
    <j350 datestamp="20100921">1400</j350>Copies (on 21st Sept)
    <x502>06</x502>Not less than
    <velocity>
        <x504>01</x504>Mean daily sale (measured over last month)
        <x505>125</x505>Copies
        <x502>05</x502>About (within factor of two)
    </velocity>
</stock>
In this case, a retailer could be confident of rapid delivery of an sizeable order if placed with the supplier immediately, since there are at least 1400 copies in stock, and stock is unlikely to be exhausted within a week or so. However, more than a few days delay in placing an order could result in part-fulfillment or a backorder (mean stock depletion lies between 63 and 250 copies per day).
For time-sensitive data elements or composites such as <Stock> the datestamp attribute can be valuable, particularly if there is any significant difference between the ‘age’ of the stock report and the overall age of the message derived from <SentDateTime> in the message header.

Note that <OnHand> is defined as the number of copies available to fulfill orders – it does not include in-stock copies that have already been committed to fulfilling an order. Some distributors and wholesalers term this their ‘free stock’. It is possible for free stock – and thus <OnHand> – to go negative if order commitments exceed the number of copies in stock and no further copies are on order. Committed orders could be fulfilled using returned copies, or the orders may remain unfulfilled and subsequently be canceled. But if further new copies are on order to cover those order commitments, then any particular commitment should be counted either as negative free stock or as a (positive) <CBO> quantity. Of the two, <CBO> is strongly preferred (ie <OnHand> should only be negative if there are no copies on order, or if the number of outstanding backorders exceeds the number on order). In either case, ensure outstanding orders are not counted twice. Let’s assume a wholesaler has 100 copies physically in stock, but has 200 unfulfilled orders. This should result in a <Reserved> quantity of 100 and an <OnHand> quantity of −100, as below. How might the stock change?

OnHand Reserved OnOrder CBO
Wholesaler’s initial stock position −100 100 0 0
– place order for 500 copies with distributor 0 100 500 100
– fulfill backorders until stock is exhausted 0 0 500 100
– accept order for 50 copies from retailer 0 0 500 150
– 500 copies delivered from distributor 350 150 0 0
– fulfill outstanding backorders 350 0 0 0
– place order for 50 copies with distributor 350 0 50 0
– accept 10 saleable copies back as returns 360 0 50 0
– accept order for 425 copies from retail chain −15 360 50 40

Of the four data elements <OnHand>, <Reserved>, <OnOrder> and <CBO>, only <OnHand> may be negative. Within the <Velocity> composite, <Rate> can also be negative in some rare circumstances, where returns more than offset orders.

Finally, if required, the expected delivery timing of any stock on order can be included in the <OnOrderDetail> composite. This includes the quantity in a shipment, and the expected shipment date. (This should be interpreted not as the expected arrival date of the shipment at the supplier’s location, but the supplier’s expected goods-out date of copies in that shipment if they are used to fulfill backorders.) Note there can be multiple shipments ‘in flight’ at any one time, and that there may be additional unspecified shipments for which no date is yet available.

The stock reporting functionality provided in ONIX 3.0 is essentially identical to that provided by the EDItX Stock Report message format, and is similar to that in earlier, equivalent X.12, EDIFACT or Tradacoms EDI messages.

P.26.41 Pack or carton quantity

It is good practice to include a <PackQuantity> data element where possible, though it is recognized that this information is not always available.

This information is provided for the convenience of recipients who wish to order in carton quantities. A pack or carton quantity does not imply that orders must be for an exact multiple of the carton quantity: a pack quantity of (for example) 8 does not mean that orders for 1, 5 or 15 copies will not be accepted. It means only that orders for 8, 16 or 24 copies are likely to be fulfilled using whole cartons rather than ‘loose’ copies. If arbitrary numbers of copies are not available from the supplier – if only multiples of the pack quantity may be ordered – then the carton should be treated as a multi-item trade pack (<ProductComposition> code 30), or specific quantities should be stated using <OrderQuantityMinumum> and <OrderQuantityMultiple>.

P.26.41a to P.26.41c Minimum order quantities

The quantities specified here are – in contrast to the pack or carton quantity – definite limits on the size of orders that will be accepted by the supplier. For example, if the product value is very low, the supplier may only accept orders for at least a certain number of copies. A minimum order quantity of (for example) 8 means that orders for 1 or 7 copies will not be accepted by the supplier, though an order for 8, 9 or 15 would be accepted. The minimum number may or may not be the same as the pack quantity.

The provision of a separate <OrderQuantityMultiple> specifies that orders larger than the minimum must exceed the minimum by a multiple of the specified number of copies. Note that there is no requirement for the order quantity multiple to be linked to the pack quantity or the minimum order quantity (though for reasons of convenience it often will be).

Acceptable order sizes
Order minimumOrder multipleAcceptable order sizes
6not specified6, 7, 8…
636, 9, 12…
646, 10, 14…
666, 12, 18…

Note that the minimum order sizes apply to a single order line (ie a number of copies of a single product). It is not a minimum order size for the complete order consisting of multiple order lines for different products.

minimum order of 6 copies
using Reference names
<SupplyDetail>
    . . .
    <PackQuantity>3</PackQuantity>
    <OrderQuantityMinimum>6</OrderQuantityMinimum>
    <OrderQuantityMultiple>3</OrderQuantityMultiple>
    . . .
</SupplyDetail>
using Short tags
<supplydetail>
    . . .
    <j145>3</j145>It is likely (but not guaranteed) that an order for 6 copies will be packed as two cartons
    <x532>6</x532>
    <x533>3</x533>Orders for 6, 9, 12 etc will be accepted
    . . .
</supplydetail>

Occasionally, a supplier may specify a different minimum order size for initial orders (often prior to publication) and subsequent replenishment orders. In this case a second repeat of <OrderQuantityMinimum> applies to the initial order, and the first <OrderQuantityMinimum> applies to all subsequent orders. The order multiple applies to both initial and subsequent orders.

P.26.42 Unpriced item type

Unpriced item type should be used to describe products that are free of charge, products where a price has not yet been announced, or products where no price is applicable – for example, where a product is not retailed separately or where the product is available on revenue-share terms. In particular, for free of charge products, <UnpricedItemType> 01 (see List 57) should always be used in place of a <Price> composite where the Price amount is zero. Similarly, an <UnpricedItemType> should be used as a placeholder in a Product record sent prior to setting a price, using code 02 – though it is good practice to announce a price as soon as possible, even if it is unconfirmed and uses <PriceStatus> code 01.

Note however, that <UnpricedItemType> may also be used within the <Price> composite (see P.26.70a). Use here, outside of <Price>, means the product is as yet completely unpriced, or is free of charge in all circumstances (at least within this particular market). That is, <UnpricedItemType> is used instead of one or more <Price> composites. Use within <Price> means the product is as yet unpriced, or free of charge, in some particular circumstance, but has a conventional price set for other circumstances – for example where the product is priced in one country and either free of charge or no price has been fixed yet for other countries within the market.

free of charge POS item
using Reference names
<SupplyDetail>
    <Supplier>
        . . . 
    </Supplier>
    <ProductAvailability>21<ProductAvailability>
    <UnpricedItemType>01</UnpricedItemType>
</SupplyDetail>
using Short tags
<supplydetail>
    <Supplier>
        . . . 
    </Supplier>
    <j396>21</j396>In stock
    <j192>01</j192>FOC
</supplydetail>
unpriced in one market, priced in another
using Reference names
<ProductSupply>
    <Market>
        <Territory>
            <CountriesIncluded>US CA</CountriesIncluded>
        </Territory>
        <SalesRestriction>
            <SalesRestrictionType>13<SalesRestrictionType>
        </SalesRestriction>
    </Market>
    <SupplyDetail>
        <Supplier>
            . . . 
        </Supplier>
        <ProductAvailability>10</ProductAvailability>
        <UnpricedItemType>06</UnpricedItemType>
    </SupplyDetail>
</ProductSupply>
<ProductSupply>
    <Market>
        <Territory>
            <CountriesIncluded>US CA</CountriesIncluded>
        </Territory>
        <SalesRestriction>
            <SalesRestrictionType>12</SalesRestrictionType>
        </SalesRestriction>
    </Market>
    <Market>
        <Territory>
            <RegionsIncluded>WORLD</RegionsIncluded>
            <CountriesExcluded>US CA</CountriesExcluded>
        </Territory>
    </Market>
    <SupplyDetail>
        <Supplier>
            . . . 
        </Supplier>
        <ProductAvailability>10</ProductAvailability>
        <Price>
            . . . 
        </Price>
    </SupplyDetail>
</ProductSupply>
using Short tags
<productsupply>Market #1
    <market>
        <territory>
            <x449>US CA</x449>Market is US and Canada
        </territory>
        <salesrestriction>But restricted to
            <b381>13<b381>…subscription services only
        </salesrestriction>
    </market>
    <supplydetail>
        <supplier>
            . . . 
        </supplier>
        <j396>10</j396>Awaiting
        <j192>06</j192>Available on revenue share terms
    </supplydetail>
</productsupply>
<productsupply>Market #2
    <market>
        <territory>
            <x450>WORLD</x450>Market is everywhere
            <x451>US CA</x451>…except US and Canada
        </territory>
    </market>
    <market>Plus…
        <territory>
            <x449>US CA</x449>US and Canada
        </territory>
        <salesrestriction>
            <b381>12</b381>…except subscription services
        </salesrestriction>
    </market>
    <supplydetail>
        <supplier>
            . . . 
        </supplier>
        <j396>10</j396>Awaiting
        <price>
            . . . Price details
        </price>
    </supplydetail>
</productsupply>
Market #2 is a rare example where the <Market> composite has to be repeated, because the restriction (to everyone except subscription services) applies in one part of the geographical range of the market but not across the whole geographical range.
Price composite

The <Price> composite is optional within the <SupplyDetail> composite, but in practice, there must always be either an <UnpricedItemType> element or at least one <Price> composite for each supplier – and often, there’s more than one price. And obviously, <UnpricedItemType> and <Price> should never occur in the same <SupplyDetail> composite (though <UnpricedItemType> may occur within a <Price> composite).

Price PriceIdentifier PriceType PriceQualifier EpubTechnicalProtection EpubTechnicalProtection PriceConstraint PriceConstraint EpubLicense EpubLicense PriceTypeDescription PriceTypeDescription PricePer PriceCondition MinimumOrderQuantity MinimumOrderQuantity BatchBonus DiscountCoded Discount PriceStatus Continued in Price part 2 Not usually used together

The <Price> composite is repeatable within an instance of the <SupplyDetail> composite – a single supplier may maintain several prices at the same time. However, each individual repeat of the <Price> composite should contain a unique combination of <PriceType>, <PriceQualifier>, <PriceConstraint>, <PriceCondition>, <PricePer>, <Currency>, <Territory> and validity dates in the <PriceDate> composite – it should always be possible for a customer to select the single price that applies unequivocally. And although <PriceType> is optional where a default price type is supplied in the message header, it should be considered effectively mandatory since it is not good practice to supply a default price type.

Price Continued from part 1 PriceAmount PriceCoded UnpricedItemType UnpricedItemType Tax TaxExempt CurrencyCode Territory CurrencyZone ComparisonProductPrice ComparisonProductPrice PriceDate PrintedOnProduct PrintedOnProduct PositionOnProduct PositionOnProduct
A <PriceAmount> of zero should never be used to indicate a product is free of charge – use <UnpricedItemType> instead.
<Tax> should only be used with Price types that include tax.
The <TaxExempt/> empty element should only be used with Price types that exclude tax. Note that Tax exempt status is rare and should only be used to indicate statutory tax exemptions in those few countries that have them. Tax exempt is distinct from the case where tax details are not specified (as is the case with most North American Prices) and also distinct from the case where tax is levied at zero percent (as is the case for physical books in the UK, for example). For the former, omit both <Tax> and <TaxExempt>. For the latter, specify a rate and tax amount of zero in <Tax>.
A supplier may mark the product as unpriced throughout the whole market using <UnpricedItemType> as an alternative to an entire set of <Price> composites (see P.26.42), or may mark it as unpriced in a territory representing only part of the market using <UnpricedItemType> as an alternative to <PriceAmount> (where there may be other, conventional, prices that apply in other parts of the market).
Price identifier composite

Where a product is available at a number of different price points – to different customer groups (via <PriceType> and <PriceQualifier>), or with different price conditions, or in different combinations of currency and territory – it may make accurate and granular revenue reporting impossible. Simple aggregated revenue or an average selling price may not be enough to meet the needs of the publisher or an intermediary supplier for royalty or tax purposes. In this case, each price point may be given an arbitrary identifier using <PriceIdentifier>.

It is important to understand that the price identifier does not describe the price: it serves only to differentiate different prices. It should never be used alone, but only alongside the relevant <PriceType>, <PriceQualifier>, <PriceConstraint> and other elements that describe the price. Then later, the product identifier and price identifier can be quoted in revenue reports, without having to repeat all the other details.

The <PriceIdentifier> composite can carry an identifier that is:

  • unique for each price point (ie two unrelated products both priced at €4.95 would carry the same identifier, irrespective of the price types);
  • unique for each price type (ie two unrelated products sold with the same combination of price type and qualifier, constraints, conditions, territory etc – but not necessarily at the same actual amount – would carry the same identifier);
  • unique for each combination of price point and type (but two unrelated products may still carry the same price identifier if all details of their prices are identical);
  • unique for each product and price point (ie a single product sold at the same price amount and currency under two different price types would carry the same identifier, but different products would always carry different identifiers, even when sold at the same price point);
  • unique for each product and price type (ie a single product sold with the same price type but at different price points (eg at different times) would carry the same identifier, but different products would carry different identifiers even when sold with the same price type);
  • unique across products, price points and types (an identifier would change if either the price point or price type for a single product was changed, and different products would always carry different identifiers).

It can be useful to the data recipient if the price identifier type is listed as one of the above options using <PriceIDType> codes 02–07, instead of simply as ‘proprietary’ (code 01).

Whether the ID identifies the price amount, the price type or some combination of both will depend on the choice made by the publisher or supplier. But the price identifier can be included in revenue reporting – in combination with the product identifier – to ensure that the publisher or intermediary supplier receiving the report can associate revenue with a particular product sold under particular terms and conditions.

PriceIdentifier PriceIDType IDTypeName IDValue must include if ID is proprietary, otherwise omit

There is no standardized scheme for price identifiers, and the only values on List 217 for <PriceIDType> are ‘Proprietary’ (which in turn means that <IDTypeName> is effectively mandatory). A UUID (Universally Unique Identifier) constructed in accordance with RFC 4122 (types 1 or 4) would make a good price identifier, since they can be ‘minted’ automatically on demand, each time a price is created or modified.

P.26.43, P.26.44 Price type code and Price type qualifier

Since prices may be quoted excluding or including tax, may be recommended or fixed retail prices, may be quoted based on different business models (eg wholesale or agency terms), and may have other limitations or conditions (eg only valid pre-publication, or only valid for particular classes of customer, or relate to a three-day rental rather than a purchase), the <PriceType> code should always be included – and if necessary it should be accompanied by the <PriceQualifier> data element and (more rarely) the <PriceConstraint> and <PriceCondition> composites.

In general, the Price type code identifies the business model or terms of sale on offer, and Price qualifier limits the applicability of the price to specific customers or circumstances. Price conditions enable expression of rental rather than purchase prices. Prices without a <PriceQualifier> should be assumed to apply to all classes of customer, or – if there are other prices with qualifiers – to all customers to whom another, qualified price does not apply. However, mixing qualified and unqualified prices opens up some ambiguity, so is not recommended – it is best practice to ensure that wherever possible, if any price has a qualification, then all prices within that <SupplyDetail> composite should be qualified. So for example, an institutional price with <PriceQualifier> 06 should not be listed alongside an unqualified ‘consumer’ price: use <PriceQualifier> 05 on the consumer price to make it clear this does not apply to institutional customers. Where necessary, <PriceQualifier> 00 from List 59 can be used to provide a price for all customers to whom other qualifiers do not apply.

Further limitations on the applicability of a price are specified by currency, territory and date. In addition to this, many Price type codes occur in pairs, allowing prices to be quoted excluding tax and including tax. However, the same price should never be quoted using both Price type codes from a single pair: that is, a supplier should never include two <Price> composites that vary only in Price type code, where the two price types are the exc-tax and inc-tax variants of the same pair. So for example, a recommended retail price for sales to consumers in a particular country should be specified with either code 01 or code 02 from List 58, but not both.

Choosing whether to specify prices including or excluding tax depends on the territory:

  • In North America and other markets where tax rates vary from state to state and province to province, it is normal practice to quote prices excluding sales tax;
    • Prices are ‘advertised’ exc-tax, and sales taxes added only at the checkout, so a particular price point chosen for marketing reasons – for example, $10.95 – must be an exc-tax price. If an inc-tax price of $10.95 were provided, that would mean an undesirable advertised price of $10.07 in a particular jurisdiction with 8.75% sales tax. Furthermore, the advertised price would have to be different in each tax jurisdiction (and there are several hundred different sales tax jurisdictions within the USA);
    • It is almost impossible for retailers – particularly online retailers – to make use of tax-inclusive prices supplied for territories where sales tax varies according to local jurisdiction;
    • Where exc-tax prices are provided, it can be useful to provide a <ProductClassification> composite (see Group P.3) using the Harmonized System or a national product classification, so that recipients can estimate the applicable tax in their particular jurisdiction, prior to receipt of the goods (eg for advance orders);
  • In Europe, where VAT is applied on a largely national basis, it is normal to quote consumer prices including tax – at least for countries in which the supplier is based or where a tax-inclusive recommended retail price is printed on the product. However, export prices and educational, institutional or corporate (business-to-business) prices are often quoted excluding tax, even within the EU, as some EU countries maintain special regional tax regimes (for example, the Canary Islands have a special local sales tax), and schools or other organizations often prefer exc-VAT pricing;
  • Where prices are quoted inc-tax, a breakdown of the tax details should be provided in the <Tax> composite. Since tax rates are country-specific, this means that all inc-tax prices apply to a single country only;
    • There is an exception, but it is rare. Occasionally a publisher may set a single inc-tax RRP for multiple countries, understanding that this inevitably implies that the underlying exc-tax price varies from country to country. In this case, no <Tax> composite should be included, since even though the inc-tax price is the same, the percentage rate and absolute amount of tax varies across the various countries;
  • Conversely, where prices are quoted exc-tax, no <Tax> composite should be provided.
including two different qualified prices, with price identifiers
using Reference names
<Price>
    <PriceIdentifier>
        <PriceIDType>05</PriceIDType>
        <IDTypeName>PRH PUID</IDTypeName>
        <IDValue>ff8a5521-fcad-4a3b-89b0-34f2ed131016</IDValue>
    </PriceIdentifier>
    <PriceType>02</PriceType>
    <PriceQualifier>05</PriceQualifier>
    <!-- details of consumer price inc-tax -->
</Price>
<Price>
    <PriceIdentifier>
        <PriceIDType>05</PriceIDType>
        <IDTypeName>PRH PUID</IDTypeName>
        <IDValue>3e304b73-50f6-432d-8e82-2865198dad73</IDValue>
    </PriceIdentifier>
    <PriceType>01</PriceType>
    <PriceQualifier>06</PriceQualifier>
    <!-- details of institutional price exc-tax -->
</Price>
using Short tags
<price>
    <priceidentifier>
        <x506>05</x506>Proprietary ID
        <b233>PRH PUID</b233>for revenue reporting
        <b244>ff8a5521-fcad-4a3b-89b0-34f2ed131016</b244>UUID
    </priceidentifier>
    <x462>02</x462>Including tax
    <j261>05</j261>Price to consumers
    <!-- details of consumer price inc-tax -->
</price>
<price>
    <priceidentifier>
        <x506>05</x506>
        <b233>PRH PUID</b233>
        <b244>3e304b73-50f6-432d-8e82-2865198dad73</b244>
    </priceidentifier>
    <x462>01</x462>Excluding tax
    <j261>06</j261>Institutional price
    <!-- details of institutional price exc-tax -->
</price>
In addition to the different Price qualifiers on the two prices above, one is quoted inc-tax, the other exc-tax. This is quite usual, for example in European VAT jurisdictions, where consumer sales are priced including tax, and business-to-business sales are typically priced exclusive of tax.

In general, the Price type code identifies the business model or terms of sale on offer, and Price type qualifier limits the applicability of the price to specific customers:

Price type values from List 58
Trade sales (normal reseller terms) exc-tax ⁵ inc-tax ⁵
Recommended retail price (RRP)0102
Fixed retail price0304
Wholesale price ⁴0507
Alternative wholesale price ¹ ⁴0809
Freight-pass-through RRP ²31
Freight-pass-through billing price ²32
Pre-publication trade sales (reseller terms), where post-publication prices will differ exc-tax inc-tax
Pre-publication recommended retail price ³2122
Pre-publication fixed retail price ³2324
Pre-publication wholesale price ³ ⁴2527
Trade sales (agency terms) exc-tax inc-tax
Publisher’s retail price4142
Special sales (generally non-returnable, often retailer-specific) ⁶ exc-tax inc-tax
Recommended retail price1112
Fixed retail price1314
Wholesale price ⁴1517
Price type qualifiers from List 59
Unqualified price (applies when no other qualified price applies) ⁷00
Member/subscriber price01
Export price (not recommended – use <Territory> instead)02
Reduced price when purchased as part of a collection03
Voucher/coupon promotion price04
Consumer price05
Library/corporate/institutional price06
Reservation order07
Promotional offer (temporary ‘special offer’ price reduction) ⁶08
Library only price10
Education only price11
Corporate only price12

¹ used where two wholesale prices are required for different customer categories
² US-only
³ use where reduced prices are applicable for orders placed pre-publication (‘subscription orders’)
⁴ if accompanied by discount information, eg based on ordering a minimum number of copies, this is treated as a discount below the wholesale price
⁵ choice between inc- and exc-tax prices is market- and sometimes sector-specific. Supply one or other, not both
⁶ it is a common error to confuse ‘special sales’ where the terms and conditions vary from the norm, and ‘special offers’ where the price is lowered for a temporary promotional period
⁷ use as necessary as the complement of any price qualifiers that have no obvious complement (for example, to qualify a non-member price, or a price without a coupon). But omit if there is no price other than the ‘normal’ unqualified price

P.26.44a Digital product technical protection (Price)

The <EpubTechnicalProtection> element is only used within <Price> when the product is available at different prices under differing terms and conditions, to provide information about whether the various constraints on usage of the product relating to a particular commercial offer are enforced by DRM. The usage is similar to <EpubTechnicalProtection> in Group P.3, but applies only to a particular commercial offer for the product (where the DRM information in Group P.3 applies to the product ‘globally’).

Price constraint composite

The <PriceConstraint> composite is used in circumstances where the product is available at different prices under different combinations of contractual terms and conditions. This could for example be used to distinguish between prices for single and multi-user versions of the same product – where the two versions are identical apart from the price charged, and the limits on concurrent users are purely contractual, ie there is a single product identifier, the difference between single and multi-user is not enforced by any technical protection, and the user experience is not affected. Note that where there are separate identifiers, or where the technical protection or reader experience differs between versions, then separate Product records are required.

The composite can also be used to express rental prices – time-limited licenses – for e-publications. Prices without constraints on the license period are purchase prices (or perpetual licenses).

PriceConstraint PriceConstraintType PriceConstraintType PriceConstraintStatus PriceConstraintStatus PriceConstraintLimit PriceConstraintLimit PriceConstraintLimit Quantity PriceConstraintUnit PriceConstraintUnit

Great care should be taken when using <PriceConstraint>. It has many similarities with the <EpubUsageConstraint> composite in Group P.3. <EpubUsageConstraint> should be used when constraints apply to the product as a whole, and <PriceConstraint> should be used only where additional constraints are applied that depend on the price paid for the product.

For e-publications, the ‘product’ is the license rather than the file. So where the major terms of the license vary between two ‘versions’, they are distinct products, and should have distinct product identifiers (eg different ISBNs). The license for an e-publication can be linked using the <EpubLicense> composite, at ‘product level’.

Where a particular constraint is applied in both <EpubUsageConstraint> and in <PriceConstraint>, the Price constraint overrides the <EpubUsageConstraint> for that price only.

library lending
using Reference names
<PriceConstraint>
    <PriceConstraintType>06</PriceConstraintType>
    <PriceConstraintStatus>02</PriceConstraintStatus>
    <PriceConstraintLimit>
        <Quantity>24</Quantity>
        <PriceConstraintUnit>10</PriceConstraintUnit>
    </PriceConstraintLimit>
    <PriceConstraintLimit>
        <Quantity>0</Quantity>
        <PriceConstraintUnit>07</PriceConstraintUnit>
    </PriceConstraintLimit>
    <PriceConstraintLimit>
        <Quantity>14</Quantity>
        <PriceConstraintUnit>09</PriceConstraintUnit>
    </PriceConstraintLimit>
</PriceConstraint>
<PriceTypeDescription>24x loan option</PriceTypeDescription>
using Short tags
<priceconstraint>
    <x529>06</x529>Lending
    <x530>02</x530>Is limited
    <priceconstraintlimit>
        <x320>24</x320>On twenty four
        <x531>10</x531>Occasions
    </priceconstraintlimit>
    <priceconstraintlimit>
        <x320>0</x320>No limit on
        <x531>07</x531>Concurrent users
    </priceconstraintlimit>
    <priceconstraintlimit>
        <x320>14</x320>For fourteen
        <x531>09</x531>Days
    </priceconstraintlimit>
</priceconstraint>
<j262>24x loan option</j262>
This price constraint for library e‑lending shows the purchaser (the library) may lend the e‑book to a library patron a maximum of 24 times. Each loan is for a maximum of 24 days, and the loans can be concurrent (ie the library could loan the e‑book to 24 different patrons at the same time, for the same two week period). Alternatively, since there is no limit on loan renewal, a single borrower could renew their loan repeatedly, and the total period of the extended loan would be 48 weeks.
Note the special case use of zero for the limit on concurrent users. Zero can be used to indicate explicitly that there are no limits, where no limits might otherwise be merely implicit if a constraint limit is composite omitted.
multi-user educational software
using Reference names
<PriceConstraint>
    <PriceConstraintType>09</PriceConstraintType>
    <PriceConstraintStatus>02</PriceConstraintStatus>
    <PriceConstraintLimit>
        <Quantity>30</Quantity>
        <PriceConstraintUnit>07</PriceConstraintUnit>
    </PriceConstraintLimit>
</PriceConstraint>
<PriceTypeDescription>Multi-user option</PriceTypeDescription>
using Short tags
<priceconstraint>
    <x529>09</x529>Multi-user
    <x530>02</x530>Is limited
    <priceconstraintlimit>
        <x320>30</x320>One class of 30
        <x531>07</x531>Concurrent users
    </priceconstraintlimit>
</priceconstraint>
<j262>Multi-user option</j262>
This price constraint for a multi-user product shows the purchaser (the school) may give access to the product to each of a class of 30 pupils. There is no limit on the number or times a particular class may use the software, nor on use of the product by multiple classes – so long as no more than 30 pupils use the product at the same time.

It is strongly suggested that the details of the price constraints are also described in <PriceTypeDescription>.

With purchases and rentals of e-publications, the ‘product’ sold is in fact a license. Purchases are ‘perpetual licenses’, where the term (duration) of the license is unlimited. Rentals are ‘time-limited licenses’. Some publishers take the view that different rental durations are different licenses, and thus require different product identifiers. In this case, a complete Product record is required for each license variation, and the duration of the rental may be specified in <EpubUsageConstraint> (see Group P.3). No <PriceConstraint> is necessary.

Alternatively, a single product – one single product identifier, and thus one single Product record – may be available both as a purchase (a perpetual license) and for one or more rental durations (a range of time-limited license options), and so there may be a lengthy list of prices for the same product, where the only difference is the length of time that the product is licensed for. There are two common models:

  • the price for each rental period is a simple percentage of the retail price, so for example 30% of retail for a 3-day rental, 50% for a one week rental, 70% for one month and so on. The exact percentages may be set by the retailer, or may be subject to a broad agreement between publisher and retailer – but they are set ‘globally’, not on a product by product basis. This needs no particular treatment in ONIX, though the final prices can be confirmed or communicated to a third party as below);
  • the price for each rental period is managed individually by the publisher, and needs to be communicated to the retailer on a product-by-product and duration-by-duration basis. In this case, the price for each possible rental duration may be carried in a single repeat of the <Price> composite within an overall Product record.

However, these methods do not provide a unique product identifier or SKU against which to report rental revenues in a granular fashion – if a unique product identifier is required, for example to ensure that revenues can be reported separately for each rental duration (without any changes to existing reporting and applications), then a complete ONIX Product record per rental duration is required. The alternative – which does require changes in reporting – it to make use of a proprietary <PriceIdentifier> within the <Price> composite.

The intention of <PriceConstraint> is to support a product catalog like this, where each price can be managed individually by the data supplier. Note that the ‘3-day rental’ option is not a fixed proportion of the ‘buy’ price:

Product 1ISBN 1buy as PDF£17.95
rent for 3 days£5.95
rent for one week£8.95
rent for one month£11.95
Product 2ISBN 2buy as EPUB£19.95
rent for 3 days£9.95
rent for one week£12.95
rent for one month£15.95

This two-product catalog with various purchase and rental options would require two Product records, each with (at least) four repeats of <Price>. Further repeats of <Price> could be used to specify other rental periods and further extension and conversion options, and rental prices in other currencies, other territories etc. Note that within a single <Price>, the <PriceConstraint> composite specifies the rental duration the price applies to, and a <PriceCondition> specifies the prior rental requirements for rental extension and conversion options.

specifying perpetual license (purchase) and time-limited license (rental) prices
using Reference names
<Price>
    <PriceIdentifier>
        <PriceIDType>01</PriceIDType>
        <IDTypeName>Ivy and Oak Price ID</IDTypeName>
        <IDValue>f6de9a49-533f-4cd9-8a1f-b060442ccdb6</IDValue>
    </PriceIdentifier>
    <PriceType>01</PriceType>
    <EpubTechnicalProtection>02</EpubTechnicalProtection>
    <PriceConstraint>
        <PriceConstraintType>00</PriceConstraintType>
    </PriceConstraint>
    <PriceTypeDescription>Perpetual license option</PriceTypeDescription>
    <PriceAmount>27.95</PriceAmount>
    <CurrencyCode>EUR</CurrencyCode>
    <Territory>
        <CountriesIncluded>AT BE CY EE FI FR DE ES GR IE IT LU MT NL PT SI SK AD MC SM VA ME</CountriesIncluded>
    </Territory>
</Price>
<Price>
    <PriceIdentifier>
        <PriceIDType>01</PriceIDType>
        <IDTypeName>Ivy and Oak Price ID</IDTypeName>
        <IDValue>6f67e214-541b-4169-89e1-05f4940e07a5</IDValue>
    </PriceIdentifier>
    <x462>01</x462>
    <PriceType>01</PriceType>
    <EpubTechnicalProtection>06</EpubTechnicalProtection>
    <PriceConstraint>
        <PriceConstraintType>07</PriceConstraintType>
        <PriceConstraintStatus>02</PriceConstraintStatus>
        <PriceConstraintLimit>
            <Quantity>3</Quantity>
            <PriceConstraintUnit>14</PriceConstraintUnit>
        </PriceContraintLimit>
    </PriceConstraint>
    <PriceTypeDescription>Three month rental option</PriceTypeDescription>
    <PriceAmount>9.95</PriceAmount>
    <CurrencyCode>EUR</CurrencyCode>
    <Territory>
        <CountriesIncluded>BE DE LU NL</CountriesIncluded>
    </Territory>
</Price>
<!-- further repeats of <Price> can specify other rental periods -->
using Short tags
<price>Price #1 – a purchase or ‘perpetual license’
    <priceidentifier>
        <x506>01</x506>
        <b233>Ivy and Oak Price ID</b233>
        <b244>f6de9a49-533f-4cd9-8a1f-b060442ccdb6</b244>UUID of price #1
    </priceidentifier>
    <x462>01</x462>Exc-tax price
    <x317>02</x317>Digital watermarking
    <priceconstraint>
        <x529>00</x529>No constraints (for confirmation)
    </priceconstraint>
    <j262>Perpetual license option</j262>
    <j151>27.95</j151>
    <j152>EUR</j152>
    <territory>
        <x449>AT BE CY EE FI FR DE ES GR IE IT LU MT NL PT SI SK AD MC SM VA ME</x449>Valid in 17 Euro-using EU countries and five other European countries which use the Euro
    </territory>
</price>
<price>Price #2 – with time-limitation (a rental)
    <priceidentifier>
        <x506>01</x506>
        <b233>Ivy and Oak Price ID</b233>
        <b244>6f67e214-541b-4169-89e1-05f4940e07a5</b244>UUID of price #2
    </priceidentifier>
    <x462>01</x462>
    <x317>06</x317>Readium LCP DRM
    <priceconstraint>
        <x529>07</x529>Time-limited license
        <x530>02</x530>
        <priceconstraintlimit>
            <x320>3</x320>Three
            <x531>14</x531>months
        </priceconstraintlimit>
    </priceconstraint>
    <j262>Three month rental option</j262>
    <j151>9.95</j151>
    <j152>EUR</j152>
    <territory>
        <x449>BE DE LU NL</x449>Note the rental price is valid in Benelux and Germany only (the supplier may not rent out the product in the other countries)
    </territory>
</price>
<!-- further repeats of <price> can specify other rental periods -->
Digital product license composite (Price)

This composite can be used to deliver details of the license terms for a digital product, where those license terms vary across multiple commercial offers. In use it is similar to <EpubLicense in Group P.3, but applies only to a particular set of terms and conditions, and <UsageConstraint> composites (where Group P.3 is used where a license applies to the product however it is purchased).

P.26.46 Unit of pricing

The <PricePer> element is normally omitted, as it has a default value that indicates the price refers to a single copy of the product.

This means that where the product is a quantity pack, filled dumpbin or other product that contains multiple items intended to be separated and retailed individually, the price is the price of the multi-pack, not the price of each of the individual retail products. The price of each individual retail item is usually detailed in a separate product record. The product record of the multi-pack should describe only the multi-pack, and should use <ProductPart> to list the identifiers (for example, the ISBN) of the individual retail items.

If <PricePer> is included, and is not equal to 1, then it indicates the price is the price for multiple items – for example, a bulk price for 25 individual copies of a book. And if the product it itself a quantity pack of some sort, then the price is for 25 quantity packs (which is likely to be more than a hundred individual copies of a book).

Price condition composite

The <PriceCondition> composite is primarily used to indicate rental price extensions – time period extensions for pre-existing time-limited licenses – for e-publications.

The intention of <PriceCondition> is to support a product catalog like this, where each price can be managed individually by the data supplier. Note that the ‘3-day rental’ option is not a fixed proportion of the ‘buy’ price:

Product 1ISBN 1buy as PDF £17.95
rent for 3 days£5.95
rent for one week£8.95
rent for one month£11.95
extend rental from 3 days to one week£4.95
extend rental from one week to one month£3.95
convert one month rental to purchase£6.95
Product 2ISBN 2buy as EPUB£19.95
rent for 3 days£9.95
rent for one week£12.95
rent for one month£15.95
extend rental from 3 days to one week£3.95
extend rental from one week to one month£4.95
convert one month rental to purchase£7.95

This two-product catalog with various purchase and rental options would require two Product records, each with (at least) seven repeats of <Price>. Further repeats of <Price> could be used to specify other rental periods, further extension and conversion options, rental prices in other currencies for other territories etc. Within a single <Price>, the <PriceConstraint> composite specifies the rental duration the price applies to, and for rental extension and conversion options, <PriceCondition> specifies the prior rental requirements.

<PriceCondition> also supports linked prices. For linked prices, the ‘other’ product – on which validity of this price depends – can be identified with <ProductIdentifier>. This composite should follow the best practices set out in Group P.2.

If there are multiple conditions placed on a price (eg for this linked price, you must own or purchase two other products), each condition could be listed in a separate repeat of <PriceCondition>. Alternatively, a single constraint requiring purchase of two linked products can be constructed. This same construction can also describe a price when purchased along with several other products from a larger range (eg BOGOF or 3-for-the-price-of-2 from this range of 10, and similar offers). If one of multiple conditions must be met (eg for this linked price, you must own or purchase either one of two other products), these should be treated as two separate prices, each with a single simple condition, in two repeats of <Price>.

PriceCondition PriceConditionType PriceConditionType PriceConditionQuantity PriceConditionQuantity ProductIdentifier PriceConditionQuantity PriceConditionQuantityType PriceConditionQuantityType Quantity QuantityUnit
specifying rental, rental extension, rental to purchase upgrade and purchase prices
using Reference names
<Price>
    <!-- price identifiers omitted for brevity -->
    <PriceType>01</PriceType>
    <PriceConstraint>
        <PriceConstraintType>07</PriceConstraintType>
        <PriceConstraintStatus>02</PriceConstraintStatus>
        <PriceConstraintLimit>
            <Quantity>3</Quantity>
            <PriceConstraintUnit>14</PriceConstraintUnit>
        </PriceConstraintLimit>
    </PriceConstraint>
    <PriceTypeDescription>Three month rental option</PriceTypeDescription>
    <PriceAmount>19.95</PriceAmount>
    <CurrencyCode>USD</CurrencyCode>
    <!-- Territories omitted for brevity -->
</Price>
<Price>
    <PriceType>01</PriceType>
    <PriceConstraint>
        <PriceConstraintType>07</PriceConstraintType>
        <PriceConstraintStatus>02</PriceConstraintStatus>
        <PriceConstraintLimit>
            <Quantity>12</Quantity>
            <PriceConstraintUnit>14</PriceConstraintUnit>
        </PriceConstraintLimit>
    </PriceConstraint>
    <PriceTypeDescription>Twelve month rental option</PriceTypeDescription>
    <PriceAmount>34.95</PriceAmount>
    <CurrencyCode>USD</CurrencyCode>
</Price>
<Price>
    <PriceType>01</PriceType>
    <PriceConstraint>
        <PriceConstraintType>07</PriceConstraintType>
        <PriceConstraintStatus>02</PriceConstraintStatus>
        <PriceConstraintLimit>
            <Quantity>12</Quantity>
            <PriceConstraintUnit>14</PriceConstraintUnit>
        </PriceConstraintLimit>
    </PriceConstraint>
    <PriceTypeDescription>Upgrade from three to twelve month rental option</PriceTypeDescription>
    <PriceCondition>
        <PriceConditionType>12</PriceConditionType>
        <PriceConditionQuantity>
            <PriceConditionQuantityType>01</PriceConditionQuantityType>
            <Quantity>3</Quantity>
            <QuantityUnit>09</QuantityUnit>
        </PriceConditionQuantity>
    </PriceCondition>
    <PriceAmount>19.95</PriceAmount>
    <CurrencyCode>USD</CurrencyCode>
</Price>
<Price>
    <PriceType>01</PriceType>
    <!-- no rental period constraint -->
    <PriceTypeDescription>Upgrade from three month rental to perpetual license option</PriceTypeDescription>
    <PriceCondition>
        <PriceConditionType>11</PriceConditionType>
        <PriceConditionQuantity>
            <PriceConditionQuantityType>01</PriceConditionQuantityType>
            <Quantity>3</Quantity>
            <QuantityUnit>09</QuantityUnit>
        </PriceConditionQuantity>
    </PriceCondition>
    <PriceAmount>34.95</PriceAmount>
    <CurrencyCode>USD</CurrencyCode>
</Price>
<Price>
    <PriceType>01</PriceType>
    <!-- no rental period constraint -->
    <PriceTypeDescription>Upgrade from twelve month rental to perpetual license option</PriceTypeDescription>
    <PriceCondition>
        <PriceConditionType>11</PriceConditionType>
        <PriceConditionQuantity>
            <PriceConditionQuantityType>01</PriceConditionQuantityType>
            <Quantity>12</Quantity>
            <QuantityUnit>09</QuantityUnit>
        </PriceConditionQuantity>
    </PriceCondition>
    <PriceAmount>19.95</PriceAmount>
    <CurrencyCode>USD</CurrencyCode>
</Price>
<Price>
    <PriceType>01</PriceType>
    <!-- no rental period constraint -->
    <PriceTypeDescription>Perpetual license option</PriceTypeDescription>
    <PriceCondition>
        <PriceConditionType>00</PriceConditionType>
    </PriceCondition>
    <PriceAmount>49.95</PriceAmount>
    <CurrencyCode>USD</CurrencyCode>
</Price>
using Short tags, with alternative positive statement of perpetual license
<price>Price #1 – Rental
    <!-- price identifiers omitted for brevity -->
    <x462>01</x462>Exc-tax price
    <priceconstraint>
        <x529>07</x529>Time limited license
        <x530>02</x530>
        <priceconstraintlimit>
            <x320>3</x320>Three months
            <x531>14</x531>
        </priceconstraintlimit>
    </priceconstraint>
    <j262>Three month rental option</j262>
    <j151>19.95</j151>
    <j152>USD</j152>
    <!-- territories omitted for brevity -->
</price>
<price>Price #2 – Rental
    <x462>01</x462>Exc-tax price
    <priceconstraint>
        <x529>07</x529>Time limited license
        <x530>02</x530>
        <priceconstraintlimit>
            <x320>12</x320>Twelve months
            <x531>14</x531>
        </priceconstraintlimit>
    </priceconstraint>
    <j262>Twelve month rental option</j262>
    <j151>34.95</j151>
    <j152>USD</j152>
</price>
<price>Price #3 – Rental extension, upgrade from three to twelve months
    <x462>01</x462>
    <priceconstraint>
        <x529>07</x529>Time limited license
        <x530>02</x530>
        <priceconstraintlimit>
            <x320>12</x320>Twelve months
            <x531>14</x531>
        </priceconstraintlimit>
    </priceconstraint>
    <j262>Upgrade from three to twelve month rental option</j262>
    <pricecondition>
        <x463>12</x463>As upgrade from
        <priceconditionquantity>
            <x464>01</x464>
            <x320>3</x320>Three months
            <x466>09</x466>
        </priceconditionquantity>
    </pricecondition>
    <j151>19.95</j151>
    <j152>USD</j152>
</price>
<price>Price #4 – Rental to purchase conversion, upgrade from three months rental to perpetual license
    <x462>01</x462>
    <priceconstraint>
        <x529>07</x529>Perpetual license
        <x530>01</x530>
    </priceconstraint>
    <pricecondition>
        <x463>11</x463>Rental to purchase, as upgrade from
        <priceconditionquantity>
            <x464>01</x464>
            <x320>3</x320>Three months
            <x466>09</x466>
        </priceconditionquantity>
    </pricecondition>
    <j151>34.95</j151>
    <j152>USD</j152>
</price>
<price>Price #5 – Rental to purchase conversion, upgrade from twelve months rental to perpetual license
    <x462>01</x462>
    <priceconstraint>
        <x529>07</x529>Perpetual license
        <x530>01</x530>
    </priceconstraint>
    <pricecondition>
        <x463>11</x463>Rental to purchase, as upgrade from
        <priceconditionquantity>
            <x464>01</x464>
            <x320>12</x320>Twelve months
            <x466>09</x466>
        </priceconditionquantity>
    </pricecondition>
    <j151>19.95</j151>
    <j152>USD</j152>
</price>
<price>Price #6 – No conditions – purchase
    <x462>01</x462>Exc-tax price
    <priceconstraint>
        <x529>07</x529>Perpetual license
        <x530>01</x530>
    </priceconstraint>
    <pricecondition>
        <x463>00</x463>No conditions
    </pricecondition>
    <j151>49.95</j151>
    <j152>USD</j152>
</price>
The above lists six prices arranged so that an outright purchase is $50, renting for one period of three or twelve months then converting to a purchase totals $55, and renting, extending the rental, then converting to a purchase totals $60.
For rental extensions, <PriceConditionType> code 10 is used to specify the new total duration of the rental, not the duration of the extension (ie extension from 3 to 12 months means the extended rental expires 12 months after the original 3 month rental began, not 15 months).
The short tags example shows a more positive method of specifying there are no time limitations, which may be useful when other priced do have time limits.
specifying a linked price (price of an e‑book is dependent on purchase or ownership of the equivalent print book)
using Reference names
<Price>
    <PriceType>01</PriceType>
    <PriceCondition>
        <PriceConditionType>00</PriceConditionType>
    </PriceCondition>
    <PriceAmount>7.95</PriceAmount>
    <CurrencyCode>CAD</CurrencyCode>
    <!-- Territory omitted for brevity -->
</Price>
<Price>
    <PriceType>01</PriceType>
    <PriceCondition>
        <PriceConditionType>05</PriceConditionType>
        <ProductIdentifier>
            <ProductIDType>03</ProductIDType>
            <IDValue>9780007120765</IDValue>
        </ProductIdentifier>
        <ProductIdentifier>
            <ProductIDType>15</ProductIDType>
            <IDValue>9780007120765</IDValue>
        </ProductIdentifier>
    </PriceCondition>
    <PriceAmount>2.95</PriceAmount>
    <CurrencyCode>CAD</CurrencyCode>
    <!-- Territory omitted for brevity -->
</Price>
using Short tags
<price>Normal price
    <x462>01</x462>Ex-tax
    <pricecondition>
        <x463>00</x463>No conditions
    </pricecondition>
    <j151>7.95</j151>
    <j152>CAD</j152>
    <!-- territory omitted for brevity -->
</price>
<price>Linked price
    <x462>01</x462>Ex-tax
    <pricecondition>
        <x463>05</x463>Price conditional on prior purchase or ownership of…
        <productidentifier>
            <b221>03</b221>GTIN-13
            <b244>9780007120765</b244>
        </productidentifier>
        <productidentifier>
            <b221>15</b221>And ISBN
            <b244>9780007120765</b244>of linked product
        </productidentifier>
    </pricecondition>
    <j151>2.95</j151>
    <j152>CAD</j152>
    <!-- territory omitted for brevity -->
</price>
Where some prices within a <SupplyDetail> composite include price conditions, it is good practice to include <PriceCondition> on every price, using <PriceConditionType> 00 from List 167 where necessary to provide positive indication that there are no conditions.
Three-for-the-price-of-two (buy three from a range of five products and the least expensive is free of charge)
using Reference names
<Price>
    <PriceCondition>
        <PriceConditionType>00</PriceConditionType>
    </PriceCondition>
    <PriceAmount>8.00</PriceAmount>
    <!-- other details of price omitted for brevity -->
</Price>
<Price>
    <PriceCondition>
        <PriceConditionType>06</PriceConditionType>
        <PriceConditionQuantity>
            <PriceConditionQuantityType>03</PriceConditionQuantityType>
            <Quantity>2</Quantity>
            <QuantityUnit>00</QuantityUnit>
        </PriceConditionQuantity>
        <ProductIdentifier>
            <!-- identifier for second $8 product -->
        </ProductIdentifier>
        <ProductIdentifier>
            <!-- identifier for $9 product -->
        </ProductIdentifier>
        <ProductIdentifier>
            <!-- identifier for $10 product -->
        </ProductIdentifier>
    </PriceCondition>
    <UnpricedItemType>01</UnpricedItemType>
    <!-- other details of price omitted for brevity -->
</Price>
using Short tags
<price>Normal price
    <pricecondition>
        <x463>00</x463>No conditions
    </pricecondition>
    <j151>8.00</j151>
    <!-- other details of price omitted for brevity -->
</price>
<price>Linked price
    <pricecondition>
        <x463>06</x463>Price conditional on simultaneous purchase of other products
        <priceconditionquantity>
            <x464>03</x464>Specifically, two other products
            <x320>2<x320>
            <x466>00<x466>
        </priceconditionquantity>
        <productidentifier>From range of three
            <!-- identifier for second $8 product -->
        </productidentifier>
        <productidentifier>
            <!-- identifier for $9 product -->
        </productidentifier>
        <productidentifier>
            <!-- identifier for $10 product -->
        </productidentifier>
    </pricecondition>
    <j192>01</j192>Free of charge
    <!-- other details of price omitted for brevity -->
</price>
Here there is a group of five products in the offer, priced normally at $7, $8, $8, $9 and $10, and the price above represent a ‘three for two’ offer for the first $8 product. That is, if purchased at the same time as two of the more expensive items, the product is free of charge.
Discount code and Discount composites

The physical book supply chain in some countries is unusual in that products are supplied from distributors and wholesalers to retailers based on a discount from a fixed or recommended retail price, rather than the more common explicit wholesale price to which retailers add their markup. <PriceType> allows prices of either type to be quoted.

In cases where business-to-business prices are based on retail price minus a discount, it is common for publishers, distributors and wholesalers to specify discounts given against the retail price in a coded manner rather than as explicit percentages. This is either because discount terms vary from customer to customer (ie from retailer to retailer), as well as from product to product, or because they are commercially sensitive for some other reason. So if on Product A, retailer X gets a 37.5% discount and retailer Y gets 41%, this can be communicated in a single ONIX message without tailoring each message to a specific retailer, and without revealing commercially-sensitive discounts to other retailers. The publisher, distributor or wholesaler establishes a set of ‘discount groups’ and allocates each product to a group. Each retailer then uses a private, retailer-specific lookup table – agreed in advance with the supplier – to relate the discount group for the product to the actual discount percentage they would receive. So Product A might be in Discount Group 3, and according to their individual lookup tables, retailer X receives 37% discount on all products in Group 3 and retailer Y receives 41%. Rather than changing the Discount Group relating to each product, it is the lookup table that is the subject of negotiation between the supplier and retailer.

Where such a scheme is operated, the Discount Code (termed a ‘Discount Group number’ in the example above) should be included for all products supplied on normal business-to-business terms, within a <DiscountCoded> composite. Typically, the <DiscountCodeType> within the composite is 02 from List 100 (a proprietary code), and the actual Discount Code (‘3’ in the example described above) is specified in <DiscountCode>. In common with all proprietary codes and code lists, a distinctive name for the code scheme should be included in <DiscountCodeTypeName>.

In some countries, a consistent naming scheme for Discount Codes is maintained by a central agency – for example by BIC in the UK: these schemes have their own entries in List 100 and do not need a <DiscountCodeTypeName>.

The BIC discount code format comprises five letters assigned to a supplier by BIC, and one to three alphanumeric characters assigned by the supplier to each discount group. These three characters are usually digits (eg ABCDE247, meaning the supplier’s group 247). If only one or two characters are assigned by the supplier, the code should be padded out with trailing spaces to a total length of eight characters when used in fixed-length fields and EDI messages (eg ABCDE23#, where # is a space, for group 23). Trailing spaces are not recommended in ONIX. Omit any padding (ie use just ABCDE23).
DiscountCoded DiscountCodeType DiscountCodeType DiscountCodeTypeName DiscountCodeTypeName DiscountCode Discount DiscountType Quantity ToQuantity DiscountPercent DiscountAmount must not omit both must include if type is proprietary, otherwise omit
supplying a proprietary discount code
using Reference names
<DiscountCoded>
    <DiscountCodeType>02</DiscountCodeType>
    <DiscountCodeTypeName>Acorn Press DG</DiscountCodeTypeName>
    <DiscountCode>DG31</DiscountCode>
</DiscountCoded>
using Short tags
<discountcoded>
    <j363>02</j363>Proprietary discount code scheme
    <j378>Acorn Press DG</j378>Distinctive name for code scheme
    <j364>DG31</j364>Individual retailers can work out what ‘DG31’ means in percentage terms
</discountcoded>

Where discounts are not commercially sensitive, and do not vary from retailer to retailer – or where an ONIX message is exchanged solely in the context of a specific trading relationship – they can be expressed as plain percentages, and should be carried in a <Discount> composite instead, within the simple <DiscountPercent> data element. Repeated <Discount> composites can also be used to specify rising discounts based on order quantities.

rising discount based on order quantity
using Reference names
<Discount>
    <DiscountPercent>36.5</DiscountPercent>
</Discount>
<Discount>
    <Quantity>10</Quantity>
    <DiscountPercent>41</DiscountPercent>
</Discount>
using Short tags
<discount>
    <j267>36.5</j267>No minimum order for 36.5% discount
</discount>
<discount>
    <x320>10</x320>
    <j267>41</j267>Additional 4.5% for orders of 10 copies or more
</discount>
An order for 15 copies qualifies for the higher discount. If the list price of the book is €10, the retailer will pay €88.50 (10 × 15 – 41%).
progressive discount based on order quantity
using Reference names
<Discount>
    <DiscountType>03</DiscountType>
    <Quantity>1</Quantity>
    <ToQuantity>10</ToQuantity>
    <DiscountPercent>36.5</DiscountPercent>
</Discount>
<Discount>
    <DiscountType>03</DiscountType>
    <Quantity>11</Quantity>
    <ToQuantity>0</ToQuantity>
    <DiscountPercent>41</DiscountPercent>
</Discount>
using Short tags
<discount>
    <x467>03</x467>Progressive discount
    <x320>1</x320>Effectively, no minimum order for 36.5% discount
    <x514>10</x514>but 36.5% applies only to the first 10 copies
    <j267>36.5</j267>
</discount>
<discount>
    <x467>03</x467>
    <x320>11</x320>From the 11th copy, 41% discount
    <x514>0</x514>with no upper limit
    <j267>41</j267>
</discount>
Part of an order for 15 copies qualifies for the higher discount. If the list price of the book is €10, the retailer will pay €93.00 ( (10 × 10 – 36.5%) + (10 × 5 – 41%) ).

For products – particularly in the e‑book supply chain – that are traded under the Agency model (ie where the <PriceType> is 41 or 42), the <Discount> composite should be interpreted as the ‘commission composite’. A percentage specified in <DiscountPercent> indicates the commission that the agent earns for the sale. This percentage is usually fixed, but might vary from product to product. If the commission (on a particular product) varies between agents or is commercially sensitive for any other reason, the <DiscountCoded> composite may be used to specify the commission indirectly (using Discount code type 05 or 06).

Of course, if the price quoted in the enclosing <Price> composite is a wholesale price (a business-to-business price, <PriceType> codes 05, 07, etc) rather than one based on a retail price less a discount, then neither <DiscountCoded> nor <Discount> would normally be included at all. However, wholesale prices may sometimes be accompanied by additional discounts for volume purchases (ie by a <Discount> composite containing a <Quantity> data element as well as the percentage).

P.26.61 Price status

A product announced in an ONIX record several months before publication might go through the following stages prior to publication:

  1. product announced, <UnpricedItemType> code 02 (price to be announced), no <Price> composite
  2. price announced, <PriceStatus> code 01 (provisional)
  3. price announced, <PriceStatus> code 02 (firm)
Firm here does not imply ‘firm-sale’ (as contrasted with ‘sale or return’), but suggests that orders placed at that price will be honored, even if the price is revised prior to fulfillment of the order. Orders placed against a provisional price may be subject to price changes. Firm sales (in the sense of ‘not sale or return’) should be indicated using a Special Sales Price type.
P.26.62 Price amount

A price should be included for all products except those that are explicitly unpriced or free of charge (so a zero price should never be used). The price can be supplied either as an amount in a specified currency using <PriceAmount> or, in exceptional circumstances, as a price tier or code using <PriceCoded> (and again, a currency should be specified, unless the coding scheme makes it explicit that a tier relates to multiple prices in different currencies). The tier/code option should only be used when the product is retailer or at least retail platform-specific, and is only relevant when that retailer or platform sets a fixed set of price tiers for the products in its store. Each <Price> composite should contain only one price.

It is best practice to always provide the Price amount as a real number with the conventional number of explicit decimal digits, even when the digits are trailing zeros – so a price should typically be given as 3.00, not 3 or 3.0. Prices and other real numbers in ONIX must always use the period character ‘.’ as the decimal separator, not a comma or mid-dot, though recipients may display prices using the conventional decimal separator for the locale (for example, a price of 7.95 in the ONIX data, with a period, would be displayed in France with a comma, as ‘€7,95’ or ‘7,95€’ – even occasionally as ‘7€95’). And for very large numbers, there should be no ‘thousands separator’ in the ONIX data, even though the price might be displayed with a group separator (ie a price of 1275.00 with currency code MXN in the ONIX would be displayed as ‘$1,275.00’ in Mexico, with the Peso symbol, a comma as the group separator and a period as the decimal separator).

List 96 indicates the conventional number of decimal places for each currency, taken from ISO 4217 and the Unicode Common Locale Data Repository. For most currencies, convention suggests two decimal places (eg 100 cents = 1 US Dollar). A handful of currencies use three decimal places (eg 1000 fils = 1 Jordanian Dinar), and List 96 indicates this. About 50 currencies are conventionally quoted as integers without any decimal places (eg Japanese Yen, Korean Won). For these currencies, either there are no subunits, or the previous subunits (eg the sen and jeon for the Yen and Won) are no longer in practical use, and this is also indicated in the codelist. However, while it is best practice to quote prices with the conventional number of decimal places, it is not an error – merely poor practice – to omit trailing zeros.
A zero Price amount is not valid. This limitation has always been implicit in ONIX, but recent versions of the ONIX XSD and RNG schemas have explicitly disallowed a zero Price amount. The restriction was tightened because it is a common software error to confuse zero (free of charge) with blank (price is not yet set) or null (price is unknown), and this could lead to products being mistakenly advertised as free of charge.
Price coded composite

This composite is used only for supplying prices which are specified as tiers in a price list, rather than as absolute amounts. Some tiering systems use a single tier that translates into multiple prices in various currencies (so Tier 7 could mean $6.95, €4.95 and £4.45), and others use independent tiers for each currency or work in only a single currency. In either case, the currency is implicit within the tier definition, so <PriceCoded> should be used without <Tax>, <CurrencyCode> and usually without <Territory>. In contrast, <PriceCoded> does not prelude the use of <PriceDate> (eg to notify future changes in tier), <Discount> or <DiscountCoded> (for business-to-business discounts or agency commission rates), or other type- and status-related elements (eg <PriceType>, <PriceCondition> and <PriceStatus>).

PriceCoded PriceCodeType PriceCodeTypeName PriceCodeTypeName PriceCode must include if type is proprietary, otherwise omit

Normal use would include a <PriceCodeTypeName> as the tier structure and the relationship of each tier to an actual price amount would most likely be unique to a particular retailer (for example, the Apple iBooks store).

Tax composite

For Price types that include tax (ie <PriceType> codes 02, 04, 07, 42 etc from List 58), a <Tax> composite should be included, to detail the tax included in the price. Note that where tax details are supplied, they are specific to a single country or tax jurisdiction, so the <Territory> composite should also be included to specify the geographical validity of the specific price and tax combination. Separate repeats of the <Price> composite should be used for areas of the market that have different taxes.

  • See the notes on inc-tax and exc-tax Price types in P.26.43.

The <Tax> composite should not be used with exc-tax Price types (ie <PriceType> codes 01, 03, 05, 41…), though of course additional business-to-business taxes may apply, and sales taxes may be applied by the retailer ‘at the cash register’ – the exc-tax Price type simply indicates that these taxes are not included in the specified price.

Although every element is optional, it is best practice to supply all elements of the <Tax> composite, so the recipient can choose which elements to use or display. In all cases, whether they are stated explicitly or need to be calculated, the <TaxableAmount> plus the <TaxAmount> must equal the <PriceAmount>.

The composite is limited to specifying a single tax rate. Where a multi-component product is subject to tax at more than one rate, then multiple repeats of the composite should be used. The sum of the multiple Taxable amounts plus the multiple Tax amounts must equal the <PriceAmount>.

Tax ProductIdentifier PricePartDescription PricePartDescription TaxType TaxRateCode TaxRatePercent TaxableAmount TaxAmount must not omit both must not omit if <Tax> is repeated
book price stated without tax
using Reference names
<Price>
    <PriceType>01</PriceType>
    <PriceAmount>7.99</PriceAmount>
    <!-- NO Tax composite -->
    <CurrencyCode>USD</CurrencyCode>
    <Territory>
        <CountriesIncluded>US</CountriesIncluded>
    </Territory>
</Price>
using Short tags
<price>
    <x462>01</x462>Exc-tax price
    <j151>7.99</j151>RRP 7.99
    <!-- NO tax composite -->
    <j152>USD</j152>US $
    <territory>
        <x449>US</x449>Price valid in US only
    </territory>
</price>
In principle, where only an exc-tax price is supplied, the tax that should be applied in a particular tax regime could be indicated by the <ProductClassification> (see Group P.3). Partly-taxable products can be dealt with using different commodity codes and using the <Percent> data element within <ProductClassification> to indicate what proportion of the overall exc-tax price is represented by each commodity code.
simple zero rated book
using Reference names
<Price>
    <PriceType>02</PriceType>
    <PriceAmount>7.99</PriceAmount>
    <Tax>
        <TaxType>01</TaxType>
        <TaxRateCode>Z</TaxRateCode>
        <TaxRatePercent>0</TaxRatePercent>
        <TaxableAmount>7.99</TaxableAmount>
        <TaxAmount>0.00</TaxAmount>
    </Tax>
    <CurrencyCode>GBP</CurrencyCode>
    <Territory>
        <CountriesIncluded>GB</CountriesIncluded>
    </Territory>
</Price>
using Short tags
<price>
    <x462>02</x462>Inc-tax price
    <j151>7.99</j151>RRP 7.99
    <tax>
        <x470>01</x470>VAT
        <x471>Z</x471>Zero rate
        <x472>0</x472>Percent
        <x473>7.99</x473>Ex-VAT price
        <x474>0.00</x474>VAT
    </tax>
    <j152>GBP</j152>UK £
    <territory>
        <x449>GB</x449>Price valid in UK only
    </territory>
</price>
In the UK, physical books are subject to VAT at a rate of zero percent (ie they are subject to tax, but the amount of tax is always zero). However, book-like items like stationery and diaries, audiobooks and e‑books are not eligible for the zero rate, and are taxed at the standard rate of 20%.
part of multi-component product taxed at zero rate, part at standard rate
using Reference names
<Price>
    <PriceType>02</PriceType>
    . . .
    <PriceAmount>9.95</PriceAmount>
    <Tax>
        <TaxType>01</TaxType>
        <TaxRateCode>S</TaxRateCode>
        <TaxRatePercent>20</TaxRatePercent>
        <TaxableAmount>5.85</TaxableAmount>
        <TaxAmount>1.17</TaxAmount>
    </Tax>
    <Tax>
        <TaxType>01</TaxType>
        <TaxRateCode>Z</TaxRateCode>
        <TaxRatePercent>0</TaxRatePercent>
        <TaxableAmount>2.93</TaxableAmount>
        <TaxAmount>0.00</TaxAmount>
    </Tax>
    <CurrencyCode>GBP</CurrencyCode>
    <Territory>
        <CountriesIncluded>GB</CountriesIncluded>
    </Territory>
    <PrintedOnProduct>01</PrintedOnProduct>
</Price>
using Short tags
<price>
    <x462>02</x462>Inc-tax price
    . . .
    <j151>9.95</j151>RRP 9.95
    <tax>
        <x470>01</x470>VAT
        <x471>S</x471>Standard rate
        <x472>20</x472>Percent (note not 0.20)
        <x473>5.85</x473>Ex-VAT price (of this portion)
        <x474>1.17</x474>VAT (on this portion)
    </tax>
    <tax>
        <x470>01</x470>VAT
        <x471>Z</x471>Zero rate
        <x472>0</x472>Percent
        <x473>2.93</x473>Ex-VAT price (of this portion)
        <x474>0.00</x474>VAT (on this portion)
    </tax>
    <j152>GBP</j152>UK £
    <territory>
        <x449>GB</x449>Price valid in UK only
    </territory>
    <x301>01</x301>Not printed on product
</price>
Ex-VAT price is £8.78 (ie 5.85 + 2.93). Two-thirds of the value of the product (ie £5.85) is taxable at standard 20% UK VAT rate, resulting in tax of £1.17. One third (ie £2.93) is zero-rated (taxable, but with a rate of zero percent), resulting in tax of £0.00. Total inc-VAT price is £9.95 (ie £5.85 + £1.17 + £2.93 + £0.00)
Note that when a product is wholly zero-rated for VAT, an inc-tax Price type should still be used, the <TaxableAmount> is equal to the <PriceAmount> and the <TaxAmount> is zero).
part of multi-component product taxed at reduced rate, part at standard rate
using Reference names
<ProductPart>
    <PrimaryPart/>
    <ProductIdentifier>
        <ProductIDType>15</ProductIDType>
        <IDValue>9780001234567</IDValue>
    </ProductIdentifier>
    <ProductForm>ED</ProductForm>
</ProductPart>
<ProductPart>
    <ProductIdentifier>
        <ProductIDType>01</ProductIDType>
        <IDTypeName>Mein Verlag UUID</IDTypeName>
        <IDValue>a2e76e92-3749-4ad1-8d4a-b68ecf48e8b1</IDValue>
    </ProductIdentifier>
    <ProductForm>BF</ProductForm>
</ProductPart>
. . . 
<Price>
    <PriceType>04</PriceType>
    . . .
    <PriceAmount>9.95</PriceAmount>
    <Tax>
        <ProductIdentifier>
            <ProductIDType>15</ProductIDType>
            <IDValue>9780001234567</IDValue>
        </ProductIdentifier>
        <TaxType>01</TaxType>
        <TaxRateCode>S</TaxRateCode>
        <TaxRatePercent>19</TaxRatePercent>
        <TaxableAmount>6.20</TaxableAmount>
        <TaxAmount>1.18</TaxAmount>
    </Tax>
    <Tax>
        <ProductIdentifier>
            <ProductIDType>01</ProductIDType>
            <IDTypeName>Mein Verlag UUID</IDTypeName>
            <IDValue>a2e76e92-3749-4ad1-8d4a-b68ecf48e8b1</IDValue>
        </ProductIdentifier>
        <TaxType>01</TaxType>
        <TaxRateCode>R</TaxRateCode>
        <TaxRatePercent>7</TaxRatePercent>
        <TaxableAmount>2.40</TaxableAmount>
        <TaxAmount>0.17</TaxAmount>
    </Tax>
    <CurrencyCode>EUR</CurrencyCode>
    <Territory>
        <CountriesIncluded>DE</CountriesIncluded>
    </Territory>
    <PrintedOnProduct>02</PrintedOnProduct>
    <PositionOnProduct>11</PositionOnProduct>
</Price>
using Short tags
<productpart>e‑book component
    <x457/>
    <productidentifier>
        <b221>15</b221>
        <b244>9780001234567</b244>
    </productidentifier>
    <b012>ED</b012>
</productpart>
<productpart>Pamphlet component
    <productidentifier>
        <b221>01</b221>
        <b233>Mein Verlag UUID</b233>
        <b244>a2e76e92-3749-4ad1-8d4a-b68ecf48e8b1</b244>
    </productidentifier>
    <b012>BF</b012>
</productpart>
. . . 
<price>
    <x462>04</x462>Fixed retail price inc-tax
    . . .
    <j151>9.95</j151>
    <tax>
        <productidentifier>For use in Germany, identifier
            <b221>15</b221>links this element of tax
            <b244>9780001234567</b244>to a specific product part
        </productidentifier>
        <x470>01</x470>MwSt
        <x471>S</x471>Standard rated
        <x472>19</x472>Percent
        <x473>6.20</x473>Ex-MwSt price (of this component)
        <x474>1.18</x474>MwSt (on this component)
    </tax>
    <tax>
        <productidentifier>
            <b221>01</b221>Proprietary identifier used
            <b233>Mein Verlag UUID</b233>for a product part that is not
            <b244>a2e76e92-3749-4ad1-8d4a-b68ecf48e8b1</b244>itself also a separately-available product
        </productidentifier>
        <x470>01</x470>MwSt
        <x471>R</x471>Reduced rate
        <x472>7</x472>Percent
        <x473>2.40</x473>Ex-MwSt price (of this component)
        <x474>0.17</x474>MwSt (on this component)
    </tax>
    <j152>EUR</j152>Euro
    <territory>
        <x449>DE</x449>Price valid in Germany only
    </territory>
    <x301>02</x301>Printed on product
    <x313>11</x313>On removable outer wrap
</price>
The recommended retail price is €9.95, made up of two portions. The first portion is €6.20 plus 19% MwSt (German VAT) and the second portion is €2.40 plus 7% MwSt. Total tax is €1.35 (€1.18 plus €0.17).
In Germany, <ProductIdentifier> should be used so that individual elements of tax specified in a series of <Tax> composites can be linked clearly to specific components of the product listed in <ProductPart>. In the example, €1.18 is the tax on the component with ISBN 978‑0‑00‑123456‑7 and 17¢ is the tax on the component with proprietary identifier a2e76e92‑3749‑4ad1‑8d4a‑b68ecf48e8b1. <ProductIdentifier> is not used in this way in other countries, and should be omitted.
French price with electronic waste levy (eg on an e‑book reader device)
Using Reference names
<Price>
    <PriceType>02</PriceType>
    . . .
    <PriceAmount>179.95<PriceAmount>
    <Tax>
        <TaxType>01</TaxType>
        <TaxRateCode>S</TaxRateCode>
        <TaxRatePercent>20<TaxRatePercent>
        <TaxableAmount>149.12</TaxableAmount>
        <TaxAmount>29.82</TaxAmount>
    </Tax>
    <Tax>
        <PricePartDescription>DEEE</PricePartDescription>
        <TaxType>01</TaxType>
        <TaxRateCode>S</TaxRateCode>
        <TaxRatePercent>20<TaxRatePercent>
        <TaxableAmount>0.84</TaxableAmount>
        <TaxAmount>0.17</TaxAmount>
    </Tax>
    <CurrencyCode>EUR</CurrencyCode>
    <Territory>
        <CountriesIncluded>FR</CountriesIncluded>
    </Territory>
    <PrintedOnProduct>01</PrintedOnProduct>
</Price>
using Short tags
<price>
    <x462>02</x462>Recommended retail price inc-tax
    . . .
    <j151>179.95<j151>
    <tax>
        <x470>01</x470>TVA
        <x471>S</x471>Standard rate
        <x472>20<x472>Percent
        <x473>149.12</x473>Ex-TVA base price
        <x474>29.82</x474>Base price exc-TVA
    </tax>
    <tax>
    <x535>DEEE</x535>Éco-participation
        <TaxType>01</TaxType>TVA
        <x471>S</x471>Standard rate
        <x472>20<x472>Percent
        <x473>0.84</x473>For tablet with screen size > 7in
        <x474>0.17</x474>TVA on éco-participation
    </tax>
    <j152>EUR</j152>
    <territory>
        <x449>FR</x449>Price valid in France only
    </territory>
    <x301>01</x301>Not printed on product
</price>
In France, it is a requirement for retailers to show the éco-participation amount (in this case, €1.01 – 84¢ plus 17¢ TVA) explicitly, as well as the total price of the product. The VAT rate on the eco-levy is not necessarily the same as the VAT rate on the base price of the product itself (though in the example, both carry standard rate TVA).

It is always good practice to ensure that money amounts are rounded to an appropriate precision, and not presented as a real number with more than 2 (or perhaps 3) decimal places. The expected precisions are indicated for each currency in List 96 (the default is 2 decimal places).

P.26.70a Unpriced item type

The <UnpricedItemType> element may be used in either of two places in ONIX 3.0: first, see P.26.42, for products that are entirely unpriced, and second here, for products that are unpriced in some circumstances but priced in others. Used here, within <Price>, the product is unpriced according to the various price type, qualifier, territory and date parameters, but should have a price when different parameters apply. Essentially, for <UnpricedItemType> to make sense inside <Price>, there must be at least one other, more conventional <Price> composite too.

One common use for this is where a product is free of charge to certain customers, but priced to others. Another may be when a product is priced until a certain date and free of charge thereafter.

Priced until a particular date, free of charge thereafter
using Reference names
<Price>
    <PriceType>01</PriceType>
    . . .
    <PriceAmount>4.95</PriceAmount>
    <CurrencyCode>USD</CurrencyCode>
    . . .
    <PriceDate>
        <PriceDateRole>15</PriceDateRole>
        <Date>20161202</Date>
    </PriceDate>
    <PrintedOnProduct>01</PrintedOnProduct>
</Price>
<Price>
    <PriceType>01</PriceType>
    . . .
    <UnpricedItemType>01</UnpricedItemType>
    . . .
    <PriceDate>
        <PriceDateRole>14</PriceDateRole>
        <Date>20161203</Date>
    </PriceDate>
</Price>
using Short tags
<price>
    <x462>01</x462>RRP excl. tax
    . . .Price qualifiers, discounts etc omitted
    <j151>4.95</j151>$4.95
    <j152>USD</j152>
    . . .Territory omitted for brevity
    <pricedate>
        <x476>15</x476>Until…
        <b306>20161202</b306>
    </pricedate>
    <x301>01</x301>Price not printed on product
</price>
<price>
    <x462>01</x462>RRP excl. tax
    . . .Price qualifers etc to match above
    <j192>01</j192>Free of charge
    . . .Territory to match above
    <pricedate>
        <x476>14</x476>From…
        <b306>20161203</b306>
    </pricedate>
</price>
A similar structure with two <Price> composites, one of which is unpriced, could be used to specify the date until which a price is valid, and a date from which a price is uncertain or has not yet been set.
P.26.71 Currency code

All prices should include a specific <CurrencyCode> data element. It is best practice to avoid providing a default for currency in the message header.

One special case – prices quoted using <PriceCoded> which specify a price tier should omit <CurrencyCode>, and any default currency provided in the message header should also be ignored.
Territory composite

The <Territory> composite is essentially identical to that in Group P.24, and similar best practices apply. <Territory> in P.24 describes the geographical extent of the market, whereas in P.26, it describes the geographical validity of a particular price within that market. Where a tax-inclusive price (<PriceType>, 02, 04, 07, 42 etc) is specified, <Territory> also specifies the geographical applicability of the tax.

Note that there is no requirement that currency and territory be aligned: prices for export territories are often set in the currency of the country where the supplier is based, or in some widely traded currency, rather than in the currency of the country into which the product is being sold, and a price in a particular currency need not apply in all countries using that currency.

Because the supra-national region ECZ (the Eurozone) may be used in <RegionsIncluded> and <RegionsExcluded> within Group P.26, the allowed combinations of <CountriesIncluded>, <RegionsIncluded>, <CountriesExcluded> and <RegionsExcluded> are more complex than those in Block 4 or Group P.24. However, use of the ECZ region is strongly discouraged – use <CountriesIncluded> with ‘AT BE CY EE FI FR DE ES GR IE IT LU LV MT NL PT SI SK’ (the 18 Eurozone countries), plus possibly ‘AD MC SM VA ME’ (other non-EU countries in continental Europe using the Euro as their official currency) in preference.

Typically, the market that the supplier operates within spans multiple countries. A supplier may choose a single price, in a single currency, for supplies to all those countries. Or they may set different prices, in multiple currencies, specifically for each country in the market. Clearly, no price should appear to be valid outside the market – that is, the <Territory> for a price should always be a subset of (or the same as) the <Territory> for the market, just as the market <Territory> should be a subset of (or the same as) the territory covered by Sales rights types 01 and 02. However, not all suppliers are necessarily willing supply to all countries within the market, and thus, the various prices listed for that supplier may not cover all the countries in the market. A price without a <Territory> composite must be interpreted as applying throughout the market, but if the territories attached to various prices do not add up to cover the whole market, it simply means that the supplier does not supply to the remaining countries within the market. Other suppliers operating within the same market may list prices for those remaining countries.

Price date composite

The function of the price date composite is to provide limits on the validity of a price. For example, it enables planned future prices to be notified to data aggregators, wholesalers and retailers in advance.

Dates should specified as the last date on which a current price will be effective, or the first date on which a future price will be effective. Current prices do not need a start date, and planned future prices do not need an end date. The end date for the current price should be the day immediately prior to the start date of the future price, and neither need necessarily be a business day. An end date should not be provided without an indication of the subsequent price (ie a start date for another price), except as an indication that orders for the product will not be accepted after that date.

Closed-end price promotions (temporary reductions in price) should be specified through provision of either two or three prices – the current price (with an end date, if three prices are specified), the temporary price (with both start and end dates), and optionally the price the product will revert to at the end of the promotion (with a start date). An example of the three price method is shown below, and the two price method is shown at the beginning of Group P.26. So why use one rather than the other?

  • the two price method is more concise, and is generally preferred. The <PriceQualifier> code 08 specifies the special price is temporary, and that it will revert to the ‘normal’ price at the end of the promotion;
  • the three price method (which does not need to use price qualifiers) allows the post-offer price to be different from the pre-offer price.
PriceDate PriceDateRole DateFormat Date use dateformat attribute on <Date> element instead
closed-end price promotion, 8th–22nd May (three price method)
using Reference names
<Price>
    <PriceType>05</PriceType>
    . . .
    <PriceAmount>7.99</PriceAmount>
    . . .
    <PriceDate>
        <PriceDateRole>15</PriceDateRole>
        <Date dateformat="00">20110507</Date>
    </PriceDate>
    . . .
</Price>
<Price>
    <PriceType>05</PriceType>
    . . .
    <PriceAmount>5.99</PriceAmount>
    . . .
    <PriceDate>
        <PriceDateRole>14</PriceDateRole>
        <Date dateformat="00">20110508</Date>
    </PriceDate>
    <PriceDate>
        <PriceDateRole>15</PriceDateRole>
        <Date dateformat="00">20110522</Date>
    </PriceDate>
    . . .
</Price>
<Price>
    <PriceType>05</PriceType>
    . . .
    <PriceAmount>7.99</PriceAmount>
    . . .
    <PriceDate>
        <PriceDateRole>14</PriceDateRole>
        <Date dateformat="00">20110523</Date>
    </PriceDate>
    . . .
</Price>
using Short tags, with shortened From … until date format
<price>
    <x462>05</x462>Wholesale price type
    . . .
    <j151>7.99</j151>Normal price
    . . .
    <pricedate>
        <x476>15</x476>Until
        <b306 dateformat="00">20110507</b306>7th May
    </pricedate>
    . . .
</price>
<price>
    <x462>05</x462>
    . . .
    <j151>5.99</j151>Promotional price
    . . .
    <pricedate>
        <x476>24</x476>From … until
        <b306 dateformat="06">2011050820110522</b306>8th–22nd May
    </pricedate>
    . . .
</price>
<price>
    <x462>05</x462>
    . . .
    <j151>7.99</j151>Normal price
    . . .
    <pricedate>
        <x476>14</x476>From
        <b306 dateformat="00">20110523</b306>23rd May
    </pricedate>
    . . .
</price>
Dates are inclusive. That is, the end date for one price should be the day before the start date of the next price. In the absence of time and timezone information, it should be assumed that price changes happen outside business hours between the two dates specified, or at midnight, at the location of the supplier. However, if the exact timing of the price change is critical, precise time and timezone information can be supplied using dateformat code 13. Where timezone details are included for both a From date and a To date, ensure you use the same timezone for each.
Where there are paired start and end dates, possibly with timezone information, it is very strongly recommended that the same date format and timezone is used for both.
product is free of charge for one day (two price method)
using Reference names
<Price>
    <PriceType>41<PriceType>
    . . .
    <PriceAmount>4.95</PriceAmount>
    <CurrencyCode>USD</CurrencyCode>
    . . .
</Price>
<Price>
    <PriceType>41<PriceType>
    . . .
    <UnpricedItemType>01</UnpricedItemType>
    . . .
    <PriceDate>
        <PriceDateRole>14</PriceDateRole>
        <Date dateformat="00">20150525</Date>
    </PriceDate>
    <PriceDate>
        <PriceDateRole>15</PriceDateRole>
        <Date dateformat="00">20150525</Date>
    </PriceDate>
</Price>
using Short tags, and shortened From … until date
<price>
    <x462>41<x462>Agency price type
    . . .
    <j151>4.95</j151>Normal price
    <j152>USD</j152>
    . . .
</price>
<price>
    <x462>41<x462>
    . . .
    <j192>01</j192>Free of charge
    . . .
    <pricedate>
        <x476>24</x476>From … to
        <b306 dateformat="06">2015052520150525</b306>25th May
    </pricedate>
</price>
For a single-day promotion, the start and end dates for the promotional price are the same date.
P.26.86, P.26.87 Price on product

It is helpful for retailers to know in advance whether a price is printed on the product itself, particularly since trade practice on this varies greatly, and the retailer may need to plan in advance for stickering physical stock. It is good practice to supply this information where it is available, via <PrintedOnProduct> (and possibly also the <PositionOnProduct> data element). Note that <PositionOnProduct> is required when <PrintedOnProduct> indicates the price is on the product (ie code 02), and must otherwise be omitted (code 01, or when <PrintedOnProduct> is absent).

Where a product has many prices – in different currencies, or linked to different price types and qualifiers, or with different conditions and constraints – some of those prices may be printed on the product and others not.

Note that for multi-item trade packs, <PrintedOnProduct> indicates whether the multi-item pack is visibly priced – it implies nothing about the inner product that is sold at retail (which would usually have its own separate Product record).

Reissue composite

A ‘reissue’ occurs when a publisher makes an existing product available (again) with revised collateral material, a redesigned cover etc, but without significant changes to the content of the product and without any change in the product identifiers. This might occur regularly with perennial backlist products where the product receives a regular ‘refresh’ or ‘relaunch’. The old and new versions are not available concurrently (since that would require them to be treated as two separate products, with separate identifiers), and there may or may not be an intervening period during which neither version of the product is available.

The issue that faces metadata suppliers and recipients is to achieve an orderly switchover from using the old collateral material to using the new, revised material – and timing this switchover so that a consumer ordering the product on the basis of seeing, say, a cover image on a retailer’s website, gets the product bound with the cover they expect.

The intent of the <Reissue> composite is – or was – to provide a way for suppliers to deliver information about a planned reissue of an existing product. However, all information that might be carried in the composite can also be carried in other, more appropriate parts of the message, and use of the <Reissue> composite is deprecated. For convenience, best practices associated with reissues are described here, and these recommended practices avoid the <Reissue> composite altogether.

Reissues can be actioned at either a ‘global’ or market level. However, since reissues mostly involve updating of descriptive text and supporting resources specified in Block 2 of an ONIX Product record – and all Block 2 metadata applies to the product globally – there is no support within these best practices for reissues that happen in only one market (where another market may continue to be supplied with older versions of the same product). In this regard, the use of the <Reissue> composite may have been advantageous, but the significant simplification gained by avoiding it is felt to be worthwhile.

There are two distinct reissue scenarios. The first is when there is a period preceding the reissue when the product is unavailable. The second is when availability of the older version continues right up to the reissue, and availability is essentially uninterrupted.

If there is a distinct gap between last availability of the ‘old’ version and introduction of the reissued version of the product, then the treatment in ONIX is relatively simple: replacement of the metadata and resources describing the old version of the product with revised metadata and resources while the product is out of stock:

  • the Publishing status in Group P.20 or Market publishing status in Group P.25 remains Active throughout (ie <PublishingStatus> or <MarketPublishingStatus> code 04 from List 64 or List 68), because there is no time during the reissue process when orders for the product cannot be placed;
  • at the point of announcement of the planned reissue, add the date of the next reissue in <PublishingDate> in Group P.20, with <PublishingDateRole> code 21 from List 163 (or the equivalent in <MarketDate> in Group P.25);
    • after the reissue, that date becomes the Last reissue date, code 16;
  • in Group P.26, <ProductAvailability> should change from In stock (code 21 from List 65) to Out of stock (code 31) when the old version runs out, to Awaiting reissue (code 33) when the reissue is announced, to In stock again when the new stock becomes available;
    • there may not be an intervening period when Out of stock is used, if the reissue is announced immediately the old version going out of stock;
    • Awaiting reissue should be accompanied by an Expected ship date indicating when reissued copies will ship from the supplier (use <SupplyDateRole> with code 08 from List 166). Just as the Expected ship date for a new product is likely to be a few days prior to a nominal publication date, the expected ship date for a reissue is likely to be a few days prior to the nominal reissue date;
  • collateral material such as a revised cover image or updated descriptive text for new version can be included as normal in Block 2 as soon as the reissue is announced (or when stock of the old version is exhausted), since the old collateral no longer has any value;
    • where the collateral material must be downloaded by the retailer (eg when it is a supporting resource such as a cover image), include a <ContentDate> composite with <ContentDateRole> code 17 from List 155 to indicate the resource has been updated. This indicates the data recipient should re-download the resource and replace the old version with the updated version, even if the file name or URI for the resource is unchanged;
  • for the avoidance of any doubt, put a note indicating ‘pending reissue’ in <PublishingStatusNote> or <MarketPublishingStatusNote>, and remove it when the reissue is complete.

If there is no significant gap between availability of the ‘old’ version and introduction of the reissued version of the product, then in all probability the publisher and retailer will not wish to publicize the upcoming reissue in advance (since to do so might inhibit final sales of the old version and leave excess stock). So the aim is to announce the reissue to the supply chain a little in advance and supply revised metadata and supporting resources (eg a new cover image) in the ONIX data feed, allowing the recipient ample time for any necessary processing. At the same time, the aim is to inhibit the use of revised metadata and resources in consumer-facing contexts until the planned date of reissue. The sequence of metadata changes is slightly different:

  • the Publishing status in Group P.20 or Market publishing status in Group P.25 remains Active throughout (ie <PublishingStatus> or <MarketPublishingStatus> code 04 from List 64 or List 68);
  • at the point of announcement of the planned reissue, add the date of the next reissue in <PublishingDate> in Group P.20, with <PublishingDateRole> code 21 from List 163 (or the equivalent in <MarketDate> in Group P.25);
    • after the reissue, that date becomes the Last reissue date, code 16;
  • in Group P.26, <ProductAvailability> remains as In stock (code 21 from List 65) throughout (though the nature of that stock is changed at some point);
  • collateral material such as any revised descriptive text or supporting resources for the new version should be included in Block 2 along with a date controlling the introduction of the new collateral material (and replacement of the old);
    • temporarily, the new collateral should be included in parallel with the old;
    • use the <ContentDate> composite with <ContentDateRole> code 14 from List 155 to specify the first date on which the reissue can be publicized with the new collateral material;
    • use <ContentDate> composite with <ContentDateRole> code 15 to specify the last date on which the previous material may be used. Do not simply remove the old material from the data feed as its status would remain unclear – remove it only after the last date on which it is valid;
    • these dates might indicate ‘immediately’, but are more likely to indicate ‘continue using the old material until the date of the reissue, then switch to the replacement material’.

Appendix

A.1 Glossary of terms

A0, A4 etc
See A series paper sizes. A0 is 1m² in area (1189 × 841mm), A1 is half that, A2 is half again and so on. All sizes have width and height in the ratio 1:√2. A4 is 116m², and 297 × 210mm.
AA
Author’s alterations, corrections made on proofs by the author or publisher. cf printer’s errors or literals, which are errors made by the typesetter.
AAC
Advanced Audio Coding. Improved codec for audio files to reduce file size or download time. Used to compress audio files in the iTunes store, but not unique to Apple. For a given amount of compression, AAC generally sacrifices a little less quality than MP3.
AACR2
Anglo-American Cataloging Rules, second edition, widely used English language library cataloging rules. cf RDA. See also MARC21, the primary format in which library catalog metadata is transmitted (and often stored).
AB
Abandoned, previously planned publication later canceled without ever having been published. cf NYP.
Abridged
Content shortened by removal of text and minimal re-writing, occasionally termed ‘condensed’ (the latter implies a greater degree of re-writing).
Abstract
Short summary of the contents of (for example) an academic paper, article or chapter. Journal publishers often provide free online access to abstracts, while access to the full text remains dependent upon subscription to the journal.
Abstract model
Generalized conceptual model of a real-world system, developed as a guide or aid to understanding the principles of that system. Often expressed as a series of generic entities (‘things’ – books, people, places, dates and so on), the potential relationships between them, and perhaps the events that may change those entities and relationships. See <indecs>, FRBR.
AC
Author’s corrections, see AA.
Accent
See diacritical mark.
Accessibility
A book can be accessible by print-impaired people (eg blind, partially sighted or dyslexic readers, or readers with a physical disability). For print books, special accessible editions are often required. For e‑books, accessibility is not a special edition or feature, but a best practice for mainstream editions. Accessibility is also a consideration for the remainder of the supply chain, including retailer websites, library catalogs and e-reading devices.
Accessible edition
Large print, Braille or specially-formatted audiobook (DTB) that can be used by print-impaired people who cannot use a conventional physical book.
Accession number
A unique identifier added to each item acquired by a library or archive, assigned as part of the acquisition process. The accession number is a proprietary item identifier, and two items with the same ISBN (ie two instances of the same manifestation) would have distinct accession numbers.
Acid-free paper
Higher quality paper with low lignin content, and treated so it is chemically neutral (pH 7.0) or slightly alkaline to avoid yellowing and deteriorating as quickly as normal paper. For the maximum longevity, the highest archival-quality paper contains about 2% calcium or magnesium carbonate as a chemical buffer to guard against future development of acid within the paper as it ages.
Acquisition
Beginning of the publishing process – the publisher agrees the contract with the creator and purchases the rights to publish a work.
The process of selecting, ordering, and receiving books and resources for a library or archive. See also accession number.
The purchase of rights to a product, range of products or (often) an entire imprint from one publisher by another. This usually include transfer of any existing stock of the affected products. cf divestment of a product, range or imprint by the selling publisher.
Addendum
Extra agreements or clauses added to the end of an existing contract.
Addition made to a book in a later printing or subsequent edition – for example a list of corrections (corrigenda), appendices or coda added to any section of a book.
Adhesive binding
Typical paperback (‘limp’) book binding using hot-melt adhesive applied to the roughened or notched spine of the book block to hold the pages or signatures and cover together. Also termed ‘Perfect binding’, ‘unsewn binding’.
Adobe RGB
Extended RGB colorspace, allowing a much wider range or gamut of colors on screen than standard sRGB. It is intended to cover – in RGB – almost all of the colors that can be printed using CMYK. See also DCI-P3, color profile.
Adoption
Decision by a school or college, or by a consortium or educational authority, that a specific textbook will be included on a reading list or used to teach a course of study.
Advance
Sum paid by a publisher to an author (or other contributor) prior to publication. Often paid in parts, upon acquisition (agreement of the publishing contract), upon delivery of manuscript, and upon publication. The advance is paid against future royalty earnings, so the author does not receive any further royalty payments from the publisher until the advance has been ‘earned out’ (or ‘recouped’) at the agreed per-copy-sold royalty rate.
See ARC.
A format
UK term for a paperback around 178 × 111mm in size, roughly equivalent to a US rack-sized mass-market paperback. See also B format, pocket book.
Agency model
Business model based on the idea that a publisher sells to the consumer and is wholly responsible for setting the price. The retailer acts as an intermediary or agent to facilitate the sale and takes a fixed commission from the publisher; cf the more common wholesale or reseller model. Under the agency model, the publisher can directly control the ‘street price’ or Actual selling price of a book, whereas under the reseller model, street prices are usually at the discretion of the retailer – the retailer can even choose to sell the book at a loss to attract footfall – unless the legal framework provides for Fixed rather than Recommended retail prices. Reseller models where retail prices are not fixed thus encourage retailers to compete on price (possibly to the exclusion of other areas such as customer service) and put great pressure on margins. However, agency models are more complex for the publisher, and may be viewed as anti-competitive.
Aggregator
In metadata, an organization that collects metadata from many sources (mostly publishers), and re-distributes a combined feed to other metadata recipients. This service may enable or be provided alongside other services such as identifier registration, maintenance of a national bibliography or Books-in-Print database, retail sales reporting and so on.
AI
Artificial intelligence, machine intelligence – broad term for the application of software to analyse data and make decisions based on that data aimed at achieving some predefined goal. Encompasses natural language processing, knowledge representation, reasoning, machine learning etc. In publishing and metadata, AI techniques might for example be applied to automated entity extraction (recognising names, places, concepts and so on) from the text of a book to create keyword lists or links to other books about the same entities, to sales prediction, or to abstracting and summarization.
See AIS.
A&I
Abstracting and indexing. cf AIS, AI.
Airside edition
Book only for sale in bookshops in the duty-free (or ‘airside’) area of an airport (cf ‘groundside’). Occasionally, special editions are produced specifically for airside retail outlets (though they are not editions in the proper sense used for P.9 Edition). At other times, airside retail outlets may sell products normally limited to export.
AIS
Advance Information Sheet, colloquially just ‘AI’, also called a Title sheet, a printed page of metadata about a book produced in advance of publication for sales and marketing purposes, including details of the title, author, ISBN, pub date, format, price, a description of the contents and marketing information. In effect, an ONIX Product record can be the digital equivalent of an AIS or title sheet.
Ampersand
The & character, meaning ‘and’ when used in text (typographically, it is related to the Latin et). In XML data, it must be replaced by ‘&amp;’.
Answer code
Distributor or wholesaler’s brief response to an order or stock enquiry, for example indicating the product is NYP or OP. In ONIX, codes in List 65 (used in the <ProductAvailability> date element) are equivalent to answer codes.
A&P
Advertising and promotion, often the major concern of the marketing department. Not to be confused with P&A, price and availability.
APC
Article processing charge, a fee charged to the author by an open access publisher to cover the cost of editorial work, production and distribution of a work. More common for articles published in open access academic journals, but a similar business model is also used by some publishers for monographs.
API
Application programming interface: a set of protocols, functions or services that one piece of software offers to another, used to share data in ‘real time’ – more or less instantly – between applications on a computer or between computer systems on a network. There are two common styles of network API protocol – SOAP and REST – which differ in the manner they encapsulate data in the request and response messages, and the messages are often passed over HTTP. See also web service.
Approval copy
Finished copies of a book sent to an educational institution or library for evaluation purposes, with a view to purchase or adoption. Approval copies may be sent speculatively or on request, and may be free of charge, or charged if not returned (ie on SOR terms). Also termed an Inspection copy, Desk copy or Evaluation copy.
ARC
Advance Reading Copy (pl often just Advances), sometimes also known as a review copy: early finished copies of a book, usually arriving before publication and used for publicity purposes, reviews, and occasionally for evaluation (eg for potential adoption – see approval copies) etc. Book proofs (which are bound but usually editorially unfinished) are also sometimes used in the same way.
ASCII
American Standard Code for Information Interchange. Simple character set comprising 0–9, A–Z and a–z, plus a few basic symbols and punctuation characters. An ‘Ascii’ text file is one that contains plain text (‘words and spaces’) using only characters from this set. There’s no control over fonts, no formatting or styling (eg different point sizes, justification, bold or italic), and no accented characters, specialized symbols or fancy punctuation – ASCII does not even allow for proper curly quotation marks “ … ” or currency symbols like £ and €. Plain text. cf Latin‑1, Windows‑1252, Unicode.
A series
ISO standard cut sheet paper sizes, used almost everywhere except North America. A0 is 1189 × 841 mm – 1 square metre in area, with sides in the ratio of 1:√2. A1 is half that area (but the same shape), A2 is half again, and so on. 2A0 is twice the area of A0. A4 is 297 × 210 mm (116th of a square metre). RA and SRA raw paper sizes are roughly 5% or 15% larger in area than A series sizes, to allow for bleed and final trimming, so SRA4 is 320 × 225 mm. B series sheets are intermediate between the A series sizes (B1 is between A0 and A1). These ISO 216 A and B series paper sizes are not used in the USA and Canada, where Letter sized paper is more common than A4 for office use. Letter is 11 × 8½ inches (or about 279 × 216 mm), similar in area but ‘squarer’ in shape than A4. US Legal size is 13½ × 8½ inches (about 343 × 216 mm), significantly taller than A4.
ASIN
Amazon Standard Identification Number, a proprietary identifier for products used internally within Amazon.
ASN
Advance Shipping Notification, message sent by printer, distributor etc, usually via EDI, to confirm imminent dispatch of books to the customer (ie to the distributor, wholesaler or retailer).
ASP
See RRP.
Aspect ratio
Ratio of width to height of an image, screen etc, for example 16:9 for a modern TV screen. See also portrait, landscape.
ASR
Automatic Stock Replenishment, business method whereby new copies of a physical book are automatically manufactured when warehouse stocks fall below a pre-set trigger level – the publisher does not need to generate an order each time. Often combined with short-run printing in a ‘little and often’ stock maintenance process.
Assistive technology
Software and devices such as text-to-speech (TTS) screen readers or Braille displays that make e‑books more accessible to print-impaired readers.
Asterisk
Typographical mark, a small star (‘ * ’), used in text to indicate the presence of an annotation, as a list item marker (instead of a • symbol), to indicate multiplication (instead of the proper × symbol), etc.
Asterism
Typographical mark, usually of three stars or asterisks (‘ ⁂ ’) but often approximated by a row of three spaced asterisks, indicating a break in the flow of text.
Attribute
In XML documents such as an ONIX message, text, numeric or other data contained within an opening markup tag (eg the dateformat attribute within <Date>). XML attributes usually carry information about how to interpret the data content of a data element. More generally, can be synonymous with ‘property’, ‘characteristic’, ‘data element’ or ‘data field’.
Authentication
Verification of the identity of a person (eg via a login), product or process. cf authorization.
Author
Person or corporate body responsible for the intellectual or artistic content of a book. Often specific to the writer of the textual content – a broader and more inclusive term is contributor.
Author’s copies
Free copies of a book given to the author (or other primary contributor) upon publication, as (usually) stipulated in the author’s contract. cf voucher copies.
Authority file
In library cataloging and bibliographic data, a central list of, for example, contributor names. Used to ensure that contributors can be identified unambiguously and to highlight the single preferred form of a name that might have various forms or spellings. Any particular name may appear in different forms on different books, eg with or without Dr., with ü, ue or u, yet the shared contributor number from the authority file would make it clear that the names identify the same contributor. Authority files also help differentiate different contributors who share a name, and optionally can be used to resolve the real people behind pseudonyms. See also ISNI, VIAF. More generally, an authority file forms a type of controlled vocabulary.
Authorization
Verification of the permissions associated with a person or process, for example to access or change some information. cf authentication, on which authorization depends.
AVC
Advanced Video Coding, a format for compressed video data, also termed H.264 or MPEG‑4 part 10. Has superseded earlier and less technically sophisticated video compression schemes such as H.261, H.263, and is likely to be replaced by H.265 (HEVC).
B2B
Business-to-business – commercial transactions between businesses, such as between a wholesaler and a retailer, or between a publisher and a wholesaler. cf B2C.
B2C
Business-to-consumer – commercial transactions between a business and an end user (usually but not always an individual consumer). Also termed D2C (direct-to-consumer). cf B2B.
Backlist
Backlist products are those that have been on sale for (typically) a year or more and are still available. In contrast, Frontlist titles are conventionally those less than a year old (and usually including forthcoming publications).
Back matter
Pages following the main content of a book, including appendices, bibliography, index, other notes and – possibly – any sample or ‘teaser’ material from other books, advertising pages and blank pages added to make up a convenient signature size. Back matter is also termed End matter and occasionally ‘postlims’. cf front matter.
Backorders
See dues.
Back-to-back
Two books in one, bound back-to-back, with the text of one upside down with respect to the other, so that it reads from the ‘back’ of the book. The two share a single spine. Sometimes termed a ‘turn-around book’, ‘tête-bêche’ or a flip book (but cf Flick book). cf Dos-à-dos binding, where two books are bound back to back without turning one upside down, so the foredge of one meets the spine of the other.
Bandwidth
In data communications, the amount of data that can be carried over a particular channel, usually measured in bits per second (or megabits per second – Mbit/s or Mbps). Transmitting a 10 megabyte file over a 1Mbit/s link should take around 80–100 seconds.
Barcode
Machine-readable data printed as a series of black and white stripes on a product or on packaging. A conventional Bookland barcode on a book uses the EAN-13 barcode symbology and has the ISBN printed above the stripes, with the equivalent GTIN-13 at the bottom. The stripes represent the GTIN-13, not the ISBN (though for modern books, the two are the same number). Other types of barcode (different ‘symbologies’, with differing sizes and arrangements of bars) can appear on products, on cartons containing multiple products, on pallets, shipping labels etc, for example GTIN-12 (formerly known as UPC-A barcodes, but obsolete in the book trade since 2005), GTIN-14 and GS1-128 (SSCC barcodes). Barcode readers mostly use red light, so printing barcodes in color requires care to preserve adequate contrast.
Basis weight
See paper weight.
Berne Convention
International copyright agreement concluded between various European countries in 1886, since revised and extended to most countries. It provides for copyright protection of textual works from the moment of creation, and for the life of the author plus at least 50 years (many countries have a longer term), but also allows for some limited copyright exceptions. The 1967 revision of the Convention introduced the ‘three step test’ for judging exceptions – any exception must be limited and narrow in scope, must not conflict with normal exploitation of the work and must not unreasonably prejudice the interests of the author.
B format
UK term for a paperback around 197 × 130 mm in size, roughly equivalent to a US trade paperback. See also A format.
BIBFRAME
A relatively new abstract model and RDF-based data format for library bibliographic data, intended to replace MARC but at the same time also breaking with FRBR data modeling practice. Where FRBR offers work, expression, manifestation and item entities, BIBFRAME originally contained only work and instance – work conflated FRBR’s work and expression, and instance conflated manifestation and item. BIBFRAME version 2 introduces an item entity, making it much closer to the <indecs> work, manifestation and item structure (though a BIBFRAME work may be more abstract than an <indecs> work>). BIBFRAME data is expressed in RDF using linked data principles.
BIC
Book Industry Communication, a UK-based trade organization.
In the ONIX and metadata context, the subject categorization scheme developed by BIC and used mostly in the UK, though close variants of the BIC scheme are used in some other European countries, for example CCE (Classificazione commerciale editoriale) in Italy. cf BISAC, CLIL, WGS, see also Thema. Schemes like BIC, BISAC, CLIL, WGS and Thema are intended for use in the book trade, and have little in common with library-focused subject classification or categorization schemes like Dewey Decimal, UDC or LCSH (Library of Congress Subject Headings).
BIC Basic
A bare-bones set of metadata elements enumerated by BIC, and forming part of the requirements for its data quality accreditation scheme. The elements may be communicated using ONIX, a flat file (eg CSV, tab-separated file), or another method.
Binder’s pack
See carton.
BIP
See Books in print.
BISAC
A subject categorization scheme developed originally by BISAC (Book Industry Systems Advisory Committee), now administered by BISG and used mostly in North America. In the past, BISAC has also been known as BASIC. cf BIC, see also Thema.
BISG
US-based trade organization Book Industry Study Group.
Bit
In computing, a binary digit – a single unit of information, either 0 or 1. Eight bits are usually combined into a byte. A byte of data might represent a single (integer) number between 0 and 255 (for mathematical convenience, a byte representing an integer between −128 and +127 is also common). But equally, a byte of binary data could represent a single text character (eg in the Latin‑1 character set), or a particular color for a pixel in an image (eg brightness of red in an RGB image), or any other type of information – including a programming instruction for the computer itself. This document comprises more than 3.3 megabytes (million bytes) of data.
Blad
Sample pages of a book, produced in the form of a booklet for promotional purposes.
Bleed
Print or printable area that extends beyond the trimmed page edge. Headline text or images can extend into the bleed area to avoid an unsightly edge when the book block is slightly mis-trimmed.
Blocking
Metallic foil (often gold or silver colored) often used to ‘print’ the title, logo or decorative pattern on the spine or boards of a hardback book, or added for visual impact on a cover. It is applied with a heated stamping die.
Block update
See Organization of data delivery.
Blu-ray disc
Optical disc developed to supersede the DVD, holding up to 25GB of compressed and DRM-protected high-definition video or other data. Dual and multi-layer variations can hold much more data, including ultra-high definition or 3D video.
Blurb
Short descriptive text usually written by the publisher and used to promote the book. The blurb may be used in a catalog or on the back cover or jacket flaps of the book, and may include short quotations from favorable reviews or endorsements.
Board
Stiff card (paperboard, fibreboard) used for the rigid covers of a hardback, or for the leaves of a ‘board book’. Generally more than 400gsm and 500µm (or 20 mils) in bulk.
BOGOF
Buy One, Get One Free, promotional offer where a retail customer receives one product free of charge when paying full price for a second (usually the cheaper of the two is free, if they are priced differently, and usually it’s any two selected from a range of books on offer). BOGOF is equivalent to a maximum 50% price reduction where both products have the same RRP, a little less if the products vary in price. 3-for-2 (equivalent to a maximum 33.3% price reduction) or buy one, get one half price (maximum 25% reduction) are more common.
Boilerplate
Template of standard clauses used to create contracts, for example between authors and publishers.
Book
ONIX does not define what a ‘book’ is. Some legal systems set a minimum number of pages, below which a low-extent publication is a ‘pamphlet’ or similar, but within the ONIX framework this distinction is left to the data provider.
Book block
Part-bound book, with all the signatures gathered, bound and trimmed, but before the cover is added.
Bookland
GTIN-13s are normally allocated nationally, with the first two or three digits indicating the country. Bookland is the fictional country to which the 978 and 979 prefixes used for ISBNs are assigned. In this way, the range of ISBNs becomes a small subset of the larger GTIN numbering scheme.
Book proof
Paginated and bound proof copy, usually without the final cover and with text that still requires final corrections. Used for marketing and (sometimes) review purposes, as well as final proofreading and correction. See also advance reading copy, page proof.
Books-in-print
Reference catalog or service providing aggregated metadata – both bibliographic and commercial – aiming to cover all books available in the market (in print or at least in commerce). Often compiled on a national basis, and used by book retailers, libraries etc. BIP services can usually provide information on OP and out of commerce titles too.
Boolean
In databases, a data value that can be either True or False. (A third possible value – null or ‘unknown’ – is usually also an option.)
Bound proof
See book proof, advance reading copy.
Brackets, Braces, Parentheses
Paired typographic symbols – brackets ‘[ … ]’, braces ‘{ … }’, parentheses ‘( … )’. In text, brackets are often used to surround sections of quotations that are not verbatim. and parentheses for subsidiary phrases or clarification. Parentheses are often called ‘round brackets’ in UK.
Bulk
Thickness of a sheet of paper, usually measured in microns (µm, thousandths of a millimetre). Typical book paper is around 90–120µm. In the US, often termed Caliper, and measured in mils (thousandths of an inch). See also paper weight. Strictly, the relationship between a paper’s weight and bulk is the density (mass per unit volume), and higher quality papers generally have higher density, but confusingly, a paper’s ‘density’ is often used as a synonym of the paper’s weight or grammage (ie mass per unit area) without regard to bulk or caliper.
Byte
See bit.
Byte order mark
In the UTF‑16 encoding of Unicode characters, each character is represented by two or more bytes of information. But these bytes might be in either order – something like saying either ‘seventy three’ or ‘three and seventy’. The latter could easily be misinterpreted as 37. A special character, a byte order mark, may be included as the first character in a Unicode file to make it clear which way around the rest of the file is. However, the strong recommendation in ONIX is to omit byte order marks, and to declare either UTF‑16BE (‘big endian’, like seventy three) or UTF‑16LE (‘little endian’, like three and seventy) explicitly in the first line of the XML file. A byte order mark is valid in UTF‑8 too, but it has no real meaning, and again should be omitted.
Caliper
See bulk.
Cancel
Abandon plans for publication before a book is published, see AB.
Removal and replacement of a page from a book, or the reprinted sheets for replacing canceled pages.
Cardinality
In XML, data modeling and database design, whether a data element or composite is optional or mandatory, and whether nor not it is repeatable, within a particular DTD or schema. In the ONIX documentation, a cardinality of 0…1 means the element is optional, 1 means mandatory, 0…n means optional and repeatable, and 1…n means mandatory and repeatable. Cardinality is often a simplification of the full requirements of a schema or data model, since the requirements can be contextual – they depend on other data values. In ONIX, <ROWSalesRightsType> is 0…1 (ie optional), but in many circumstances is actually mandatory (it is dependent on the data provided in various <SalesRights> composites). Such contextual requirements cannot be expressed in the XML DTD or schema.
Carton
Box made of paperboard or corrugated fibreboard, and used by manufacturers to pack multiple copies of a book ready for distribution. Bulk shipments of books are packed in cartons and then stacked on pallets. A carton might hold anything between four and 100 or more copies, depending on the size of the book and carton. Retailers can order in multiples of this carton quantity (occasionally, case quantity) for convenience, though in general, orders for any number of copies are accepted. Sometimes called a binder’s pack.
Case
Some scripts (eg Latin, Cyrillic, Greek) include distinct upper case and lower case variations of each alphabetic character, with lower case used for the majority of text and upper case used for initial characters in each sentence, on nouns, etc. Upper case (or capital, or majuscule) letters are so called because when moveable type consisted of small cast blocks of metal, the capitals were kept in a wooden case on the top shelf, and lower case (minuscule) letters were kept in a case on the lower shelf. Typographically, majuscule letters are all more or less the same height, whereas minuscule letters have variable height with ascenders and descenders. Other alphabetic and logographic scripts (eg Arabic, Devanagari, Hebrew, Hanzi and Kanji) do not maintain distinct cases.
The cover and spine boards of a case-bound book. cf slip-case.
Occasionally, a synonym for carton, as in the phrase ‘case quantity’.
Case-bound
Book bound with rigid board covers – a hardback. Not to be confused with a slip-case, a separate board ‘sleeve’ the book slides into. cf limp-bound, a paperback.
Cast off
Calculation of the likely number of typeset lines or pages from the number of characters or words in text and the line width, page height and type size.
CC
See Creative Commons.
CCE
See BIC.
CD, Compact disc
Optical disc holding digital data – often digital audio data – developed by Philips and Sony, based originally on the CD Digital Audio ‘Red Book’ standard for high-quality audio (44.1KHz sampling rate, 16 bits per sample, two channel stereo), or 1411Kbits per second (cf compressed MP3 or AAC audio files at perhaps 128Kbits/s which sacrifice a little fidelity for much lower file size). Other CD standards allow up to about 700MB of ordinary data files to be stored on a disc. See also DVD.
CDF
Consumer direct fulfillment, see Drop shipment.
CE
In dates, Common Era of the Gregorian calendar, secular equivalent to AD (anno domini). cf BCE, Before Common Era.
In product certification, the CE logo on a product is a declaration by the manufacturer that indicates it conforms to European Union legislation and directives, for example on product and materials safety.
In font names, CE usually indicates the font includes a repertoire of characters suitable for Central European languages such as Polish or Czech. These fonts often support the Latin-2 character set and encoding.
C format
Less common UK term for a paperback in a size more typically used for trade hardbacks – sometimes around 216 × 135mm in size (Demy), but equally often 234 × 153mm (Royal) or another size. More typically just termed a trade paperback.
Chapbook
Originally a small book or pamphlet of popular, sensational, juvenile, moral or educational content once sold by street merchants or peddlers known as ‘chapmen’. In modern use, may be almost any short booklet, often a children’s book. Occasionally (and probably wrongly) termed a ‘chapter book’.
Character encoding
See character set.
 
Character entity
Method of encoding non-ASCII characters in HTML, for example ‘&hellip;’ for an ellipsis, now largely unnecessary with widespread use of Unicode characters. While character entities were used with earlier versions of ONIX, they are not valid in ONIX 3.0.
Character set
A defined list or repertoire of characters. A Character encoding then defines how this repertoire is represented by a computer. For example, ASCII lists a repertoire of 95 printable characters including space – plus a selection of non-printable ‘control characters’ including tab, new line and so on – and encodes them using the numbers 0–127 (or 00000000 to 01111111 in binary). Latin‑1 lists 191 characters, and encodes them using the numbers 0–255. Windows‑1252 is a different encoding of around 215 characters also using the numbers 0–255 – and obviously this means that if some text is encoded using Windows‑1252 and then displayed as if it were Latin‑1, some characters will be displayed wrongly or not at all. See also Unicode, a character set of more than 130,000 characters.
Check digit
Many identifiers include a numerical check digit, calculated arithmetically from the other digits. For an ISBN, for example, calculating what the check digit should be based on the first twelve digits, then comparing it with the actual check digit indicates whether the ISBN is likely to be correct, or whether an error has been introduced – a mistyped digit, two digits transposed etc. Different identifiers use different mathematical procedures (or ‘algorithms’) for calculating the check digit.
Chicago Manual of Style
Widely used guide for spelling, punctuation, grammar and typographic style in American English, derived originally from guidelines set by Chicago University Press. cf Hart’s Rules.
CIE
Commission Internationale de l’Eclairage, the body responsible for colorimetry standards, against which colorspaces such as Adobe RGB, sRGB or device-specific color profiles are characterized.
CIP
Cataloging in Publication, limited bibliographic information produced by national libraries prior to publication of a book, based on information supplied in advance by publishers. The CIP information is often printed within the book itself on the title verso page.
CIP4
International Cooperation for the Integration of Processes in Prepress, Press, and Postpress Organization, a standards organization focusing on process automation and improved workflow in the print industry. CIP4’s key technical standard is JDF (Job Definition Format), an XML messaging system used in print production.
CLC
Chinese Library Classification, library subject classification scheme used in China. See also UDC, DDC, LCC.
CLIL
Commission de Liaison Interprofessionnelle du Livre, a French book trade organization.
In the context of ONIX and metadata, Classification CLIL is the subject classification developed by the Commission and used widely in the French book trade. See also Thema.
Cloth
Term for a hardback/hardcover book, generally only used in a bookbinding or specialist publishing context (‘…in cloth’). Also the textile or faux material used to cover the boards of a hardback.
Cloth book
See rag book.
CMS
Content management system, system used to manage the creation and editing of material destined for publication (in a book, or on a website).
CMYK
Cyan, magenta, yellow, key (or black), basic subtractive color model used to simulate (at least in theory) the full range (or gamut) of visible colors in color printing with just four colored inks (and halftoning). In practice the range of printable colors is more limited than the full visible range. See also RGB.
Codec
Coder–decoder. Loosely, the compressed file format used to store a files containing image, audio or video data. Since such files can often be very large, the data is compressed mathematically. JPEG is a lossy format for image data, whereas TIFF is lossless. AAC and MP3 are two different lossy formats for audio data. These are referred to as ‘different codecs’. More strictly, the codec is the software used to compress or decompress the data in a particular format.
Codelist
Term used in ONIX documentation for a controlled vocabulary or authority file. In addition, codelists define a language-independent notation – the code – for each term or concept in the vocabulary. Only the code appears in ONIX data. Some codelists have an implied hierarchy (for example list 150, where BA is clearly a broader term than BB or BC), making some lists taxonomies rather than simple vocabularies. An interactive codelist browser is available at ns.editeur.org/onix. See also SKOS, keyword.
Codex
A book – printed or manuscript content arranged in discrete pages, bound down one edge (the spine), or occasionally folded accordion-style. cf scroll.
Co-edition
See co-publication.
Collation
Process of sorting, the sort order or procedure used, or the process of checking items have been sorted correctly.
Collection
Fixed or indefinite number of products that share some collective identity such as a collective title. Members of the collection usually also have other attributes in common, such as product form or a branding or design style. A set or a series is a collection, but a collection could also comprise a less formal selection of products.
Colophon
Logo of publisher or imprint on the spine or title page of a book.
A statement about production details such as typeface, paper grade and binding printed on the title verso or at the end of the book.
Color gamut
The range of colors available within a particular colorspace (for example, within sRGB) or on a particular display or printed page (see CMYK), often measured against the full range of visible colors (or ‘chromaticities’) as defined by the CIE.
Color profile
Extra metadata embedded inside an image file that specifies what colorspace the image in ‘in’ (JPEG, TIFF, PNG images can carry ICC color profiles – but not all image formats support the inclusion of profiles). The profile relates real-world colors to digital color values, and an ‘input profile’ is a characteristic of the camera, scanner etc used (or of the software used to generate or manipulate the image). The color profile defines a device-specific ‘colorspace’. A second profile – an ‘output profile’ – belonging to the printing system or display device can be combined with the digital image and its embedded input profile to compensate for less than ideal color accuracy in both input and output and thus present the final printed or on-screen image as close as possible to the original real-world color. Profiles can also be used to convert between device-specific colorspaces and idealised standard colorspaces like sRGB, Adobe RGB or CMYK. See also CIE.
Component
A part of a product – a single volume of a multi-volume set (when sold as a single product), a single CD in a multi-disc audiobook, a book in a book plus toy bundle. cf item, though note that a component of a multi-component trade pack can become a product or item in its own right when sold at retail.
Composite
Informal term used in ONIX documentation to refer to an XML markup structure that consists of an XML element or tag that contains only other data elements (and contains no data of its own). A composite acts as a wrapper around a set of closely-related data elements, largely to enable them to be repeated in a neatly structured way. eg the repeatable <ProductIdentifier> composite contains three data elements, <ProductIDType>, <IDTypeName>, and <IDValue>.
Compression
Data compression is the mathematical process of reducing the size of a file, for example by eliminating repetition and redundancy. Different compression methods are either lossy or lossless. Lossless compressed files can be expanded back to reconstitute the exact original data, but lossy compression – often used with image, video or audio files – discards less important sounds or image detail to make the compressed file even smaller, so the re-expanded file is only approximately the same as the original. In practice, the difference may be invisible or inaudible, but lossy compression is obviously unsuitable for use with text or numerical data. AAC and MP3 are lossy audio codecs, JPEG is a lossy image codec and AVC is a lossy video codec. TIFF is (almost always) a lossless image file format, WAV is lossless audio, and Zip losslessly compresses any file (but worth knowing that zipping a file that is already compressed – like zipping a JPEG, for example – does not usually make it any smaller…). See also codec.
Consignment
See sale or return.
Condensed
In typography, a typeface design that is tall and narrow, or narrower than usual for a particular family of typefaces, so more characters fit on a single line of text.
See Abridged.
Contributor
Person or organization – more generally, the party – responsible for creating the intellectual or artistic content of the product. ONIX is usually only concerned with contributors named on the product itself, and then only with their outward-facing public identity or persona. The publisher acquires rights to exploit the intellectual or artistic content created by the contributor, in return for fees or a royalty.
Controlled vocabulary
An exhaustive list of terms that can be used in a particular context or data element. Each term in the vocabulary should have an unambiguous definition or explanation, and may include both preferred terms and less-preferred synonyms. Controlled vocabularies may be a ‘flat’ list of terms, or the terms may be arranged hierarchically – in which case the vocabulary is sometimes called a taxonomy. See also codelist, authority file.
Co-op
Co-operative marketing, arrangement whereby the publisher subsidizes or pays for advertising and promotional activities (A&P) carried out by a retailer.
Co-publication
When two publishers co-operate to publish a book, they may create and sell a single product (a co-publication), or may create a shared ‘base’ from which two different products are derived and sold (these are Co-editions). A co-publication may carry the branding for both publishers, and may even carry two separate ISBNs (one from each publisher), but it is a single product. In contrast, co-editions have separate identities (including separate ISBNs for each publisher’s version), even though they might sometimes differ by no more that the branding and the publisher details. More often, the shared base for a co-edition may consist only of the color images, to which each publisher adds entirely separate text – this type of co-edition is very common in multi-language illustrated books, as it offers significant savings in shared production costs.
Copyleft
A play on conventional copyright: a licensing arrangement whereby a work (most often computer software) may be copied, used, re-distributed, adapted or modified, free of any restrictions, on condition that anything derived from it is also free of the same restrictions and bound by the same condition. Some Creative Commons licenses are copyleft licenses.
The exclusive legal rights to perform, display, reproduce, sell, modify, adapt or otherwise use original work or other intellectual property that is expressed in text, images, sound – a right enshrined in the ‘Berne Convention’, originally agreed in 1886 but revised and updated several times since – most recently by the Marrakesh Treaty. The copyright in a work is held by the author or creator, and can subsequently be passed on (eg to the author’s estate), or licensed or assigned to publishers (and others) in a contract. In most jurisdictions, copyright (which is essentially a commercial right) is accompanied by inalienable Moral rights such as the right to be identified as the author, and protection for the integrity of the work. Unlike rights over other intellectual property such as a patent or a trademark, copyright is automatic – you don’t need to register your work to gain legal protection, though in some countries, registration can be beneficial and in others, the Moral rights must be explicitly asserted (for example, within the work itself). Copyright in a new textual work usually persists for 70 years after the death of the original creator (occasionally slightly more), and limits exploitation of the work by those other than the copyright holder, licensees or assignees (collectively, rightsholders). The term of copyright has varied significantly across different countries during the last century, so 70 years after death is not always correct for older works. In some countries, Moral rights expire alongside the commercial copyright. In others, they are perpetual. After expiry of the commercial rights, the work passes into the public domain. Certain groups, eg print-impaired readers, may hold a legal copyright exception and can make copies for personal use without obtaining permission from the rightsholders. Other uses of copyright material may also be allowed without explicit permission (eg for purposes of education, research, parody, for review and criticism, for digital backups etc) under ‘fair use’ or ‘fair dealing’ provisions of national law, but the scope and detail of these exceptions vary from country to country (see also the ‘three step test’).
Copyright exception
See copyright.
 
Copyright page
Also termed the Imprint page. In a printed book, the title verso on which the copyright notice, publisher and imprint details, the ISBN and impression number, CIP and other details about the publication of the book usually appear. In a e-publication, this is often added at the end of the book.
CRC
Camera-ready copy, largely obsolete term for typeset or graphical material ready for photographic transfer to a printing plate.
Cyclic redundancy check, a number calculated according to some mathematical algorithm and appended to digital data as it is stored or transmitted, to enable later detection of errors. On receipt or retrieval of the data, the algorithm is recalculated and compared – any difference indicates an error. The concept is similar to a check digit within an identifier.
Creative Commons
Organization that develops copyright licenses that permit and encourage free sharing of creative works. Some CC licenses are copyleft (in particular the SA ‘Sharealike’ variants), whereas others reserve some rights to the creator (eg CC-By reserves the right to be credited as the author). The related CC0 (‘CC Zero’) waiver waives all possible rights (including the right to place – or prevent placement of – licensing restrictions on derived works). However, CC Zero cannot waive certain inalienable moral rights. See also Open Access, Public Domain.
CRM
Customer relationship management, integrated management of an organization’s customer and product support and other interaction with its customers and potential customers across multiple channels (eg via phone, website, e‑mail, social media, and advertising and marketing activities), and more narrowly, the IT systems to support and analyse those business processes.
CSR
Corporate social responsibility, ethical principles, policies and actions of an organization that promote social or environmental good, going beyond legal requirements, via corporate philanthropy, responsible and sustainable business and supply chain practices, cause-related and social marketing, etc.
CSS
Cascading Style Sheets, W3C standard for markup used alongside HTML to control the appearance of web pages (where the HTML markup largely defines the structure). CSS is also used in EPUB, which is also HTML-based.
CSV
A Comma-Separated Value data file consists of tabluar data (rows and columns) with each value stored as ordinary text, columns separated by commas and rows by line breaks. If a value itself includes a comma, then the value is enclosed in quote marks (in some files, all values are enclosed in quotes). CSV files are often a last-resort data exchange format: they are easy to read and write with a spreadsheet application (eg Microsoft’s Excel), but it’s not always clear whether a value might consist of multiple lines of text, how quote marks themselves might be encoded, whether the table includes column headers (field names), and what character set or encoding should be used. See also tab-separated file.
D2C
See B2C.
DAD
Digital Asset Distributor, organization that facilitates distribution of digital assets such as e‑books to online retailers and libraries on behalf of the publisher. The service may encompass a managed asset repository, file format conversion services, metadata and e‑book distribution, and aggregation of sales statistics.
Dagger
Typographic symbol ‘ † ’ sometimes used to indicate footnotes in text. Also comes in double dagger (‘ ‡ ’) flavor.
DAISY Consortium
Digital Accessible Information System, a consortium of organizations working to promote ‘inclusive publishing’ and the availability of accessible editions of books to all, including print-disabled readers. See also DTB, EPUB.
DAM
A Digital Asset Management system manages the ingestion and storage of digital assets, their cataloging and metadata, search and retrieval, and sometimes distribution. DAMs can be structured like a library aimed at simplifying the reuse of assets, or as a workflow tool forming part of a production system.
Dashes
Common typographic dashes come in different lengths, -, – and —. Hyphens (the shortest) are used to connect compound words or split words at the end of a line in justified text. En dashes (the middle size) can be used for parenthetical phrases – usually like this, with spacing – or unspaced to indicate a range such as A–Z or 1–9. Em-dashes are used for parenthetical phrases—usually like this, without spacing—or to indicate an abrupt halt or discontinuity in a sentence. An em dash is about one em long. In some languages and typographic styles, em dashes or a slightly longer ‘quotation dash’ are commonly used for dialogue, in place of opening quotation marks. And in maths, the subtraction sign ‘−’ is about the size of an en dash, but is often matched to the widths of the digits.
Database
An organized collection of data. Modern databases are normally electronic, often with tables of data arranged in columns and row, and relationships between tables (see relational database). The data is organized to model aspects of the real world, and to support various business processes through manipulating that data.
Data element
In XML documents such as an ONIX message, a single XML tag and its content – text, numeric or other data contained between a pair of markup tags. Sometimes loosely termed a ‘data field’. cf attribute, composite.
‘Day and date’
Movie industry term for simultaneous release of linked media properties, as when releasing a tie-in book carefully timed to publish on the same day as the film opens in cinemas. Such releases are usually embargoed to prevent early sales from bookshops. cf windowing.
DC
Distribution center, a distributor or wholesaler’s warehouse.
In metadata contexts, see Dublin core.
DCI-P3
Extended RGB colorspace, allowing a much wider range or gamut of colors on screen than standard sRGB. Allows more detail in red colors, but not as much in green as Adobe RGB. See also color profile.
DDA
Demand-driven acquisition, also termed PDA, patron-driven acquisition, where libraries have instant access to a complete catalog of e‑books, without having to purchase them up-front. Purchase or licensing of a particular e‑book is triggered automatically when actual usage of the book exceeds an agreed threshold (eg a library patron reading more than a certain number of pages).
DDC
Dewey Decimal Classification, common subject classification system used in libraries, named for its creator Melville Dewey. See also UDC, LCC, CLC.
Deckle edge
Page edges of a book block left rough and untrimmed, or more likely, carefully trimmed to make them look rough and untrimmed. Also termed a Rough front.
Delimiter
Character or character sequence used in data files to separate one discrete data element from the next. CSV files use commas as delimiters. XML uses angle brackets (< and >) as separators between data and markup. Within a few ONIX data elements such as <CountriesIncluded>, a space is used as a delimiter in a list of country codes. There is a clear problem whenever a delimiter character occurs within the data itself – this is why XML data must use &lt; to represent the < symbol within the data.
Delta update
See Organization of data delivery.
Demy, Demi
Common hardback book size in the UK, typically around 216 × 135mm. Pronounced as in ‘deny’. See also Royal, trade paperback.
Density
See bulk.
Deprecate
Deprecated data elements or codes are not recommended for use, and in general are strongly discouraged. In most cases, another element or code is recommended instead. Deprecation implies obsolescence, but the element or code does remain technically valid.
Derived work
See work.
Desk copy
See Approval copy.
Dewey
See DDC.
Diacritical mark, diacritic
Small decoration or accent added to a letter in Latin and other scripts, which modifies the pronunciation of the letter. Diacritics can also indicate the presence of unwritten vowels (eg in Arabic script), or indicate tones (eg in Chinese pinyin) or prosody. Common Latin accents include acute, grave, circumflex, háček, ring, tilde, cedilla etc, but there are many other types in other writing systems and languages. The effect of diacritics on alphabetic sorting varies by language – some (eg French) ignore accents for sorting purposes, others (eg Swedish) treat accented characters as whole new letters at the end of the alphabet.
Dieresis, diaeresis
Diacritical mark indicating (in English pronunciation) a vowel that is pronounced separately from the adjacent vowel in what would otherwise be a diphthong (two vowel characters indicating a single vowel sound). For example, a dieresis is used in ‘naïve’. A dieresis has roughly the opposite effect from a vowel ligature (which indicates they are pronounced as a single sound), but both have fallen out of common typographical use. The same ‘two dots’ symbol is more commonly used in Germanic languages for an umlaut, which has a different effect on pronunciation, for example ,schon / schön‘.
Digital asset distributor
See DAD.
 
Discount
Also Retailer discount, Trade discount. In some countries, books have established wholesale or business-to-business prices. In others, business-to-business transactions are based on a discount from the fixed or recommended retail price agreed by the parties. The discount given by a distributor or wholesaler varies from retailer to retailer (bigger retailers sometimes get more discount) and from book to book (discounts are often greater on mass market fiction than on specialist non-fiction). Assuming the books are sold to end customers at their normal retail price, the trade discount represents the retailer’s gross margin (sales revenue minus cost of goods sold). See also reseller model.
More loosely, Discount can also refer to books sold at retail for less than their recommended retail price (which reduces the retailer’s margin).
Distribution rights
Rights to make a product available in a particular market, a commercial right derived from the publisher’s publishing rights and conferred contractually on the publisher’s distributors, wholesalers and retailers. See Sales rights.
Distributor
Organization that holds the primary stock of books and is responsible for fulfillment (of trade orders) in a particular territory or market on behalf of the publisher. Wholesalers and retailers may act as intermediaries between the distributor and the end customer. Many large publishers own or operate their own distributor, and hold stocks themselves. Other publishers appoint a single, exclusive distributor per market or territory (and this exclusive distributor is sometimes termed the Vendor of record). Some publishers prefer to appoint multiple non-exclusive distributors.
DNS
See IP address.
DocBook
XML markup for structured book texts and documentation. The text of the book contains markup that divides it up into parts, chapters, paragraphs, tables, lists, footnotes and so on. The markup is structural and semantic, rather than defining the typographic presentation or page layout, and the DocBook data can be processed automatically to create e‑books, large print, conventional print, synthetic audio versions of the book. See also TEI, JATS.
DOI
Digital Object Identifier – a digital identifier for a document or other object, generally one accessible via the Internet. Objects with DOIs can be the target of clickable links in other documents (eg a scholarly article may cite another article via its DOI), or the link may provide information about the object. In contrast to the superficially similar URL link, DOIs are managed (by the owner of the target object) so that third-party links to the object do not break when the target document is moved. In contrast with many other identifiers, DOIs are always associated with some kind of domain-specific service, and are actionable (clickable) to gain access to that service. The most common application of DOIs in publishing is CrossRef’s registration and resolution service for online scholarly material, which provides citation services, but DOIs are also used within the DataCite service for citation of and access to research datasets, and the Entertainment Identifier Registry (EIDR) identifier scheme for movie and TV assets. Like ISBN and ISNI, DOI is an ISO identifier, and is managed by the International DOI Foundation (IDF).
DPI
Dots per inch, the number of data points or pixels per inch (PPI) of resolution in an image. Note that the DPI of an image is variable – if the image is displayed at twice the size, the DPI halves. To print an image as a halftone, the DPI of the image should ideally be twice the halftone LPI (so at least 350dpi at the size the image will be required for optimum-quality results with a 175lpi halftone screen. More pixels are unnecessary, fewer means a lower-quality halftone).
DRM
Digital Rights Management, usually refers to technical protection measures (eg content encryption systems and other access control technologies, and also watermarking) that are used to enforce or monitor compliance with constraints on usage of digital content within e-publications. DRM can for example limit copying and redistribution of the digital content, printing, cutting and pasting of text, sharing and lending, and can also place a time limit on the use of the content to enable rentals. DRM seeks to protect intellectual property from copyright infringement, but can also (often inadvertently) prevent usages that are specifically allowed by copyright exceptions.
Drop shipment
Also termed Consumer direct fulfillment (CDF). In order to avoid retailers holding stock, while at the same time minimizing fulfillment time, distributors and wholesalers sometimes ‘drop ship’ goods direct to the retail customer. The retailer placing the order must pass the customer delivery address to the wholesaler or distributor. This is most common with POD copies of books.
DST
See DTO.
DTB
Digital Talking Book, standard specification for an e‑book format accessible to blind or otherwise print-impaired readers (and also for the associated reading systems). Developed by the DAISY Consortium, and therefore also known as the DAISY standard (versions 2 and 3). Content of a DTB can range from text with XML markup (to be read using text-to-speech software), through combined text plus pre-recorded audio, to audio-only files with additional navigation functionality. DTB has been largely superseded by the EPUB 3 standard, which incorporates many features to make EPUB content more accessible.
DTD
Document Type Definition. Specifies the set of markup tags and the structure – in terms of mandatory and optional markup tags, their order and nesting – that may be used in a particular type of XML or SGML. document. So the ONIX for Books DTD defines how tags like <Contributor> or <x448> may be used. See also schema.
DTO
Download To Own, also termed DST, EST, Digital or Electronic Sell-Through. Business model whereby e‑book files or other digital goods are downloaded with a perpetual license. cf DTR, rental.
DTR
Download To Rent. Business model whereby e‑book files are downloaded with a time-limited license. See also rental. cf DTO.
Dublin Core
Set of key metadata elements (including Title, Creator, Publisher, Date and so on) intended to standardize bibliographic description and facilitate access to documents and resources on the internet. There were originally (in 1998) just 15 elements in the Dublin Core Metadata Element Set (DCMES), with a further 40 terms (DCTerms) added later, but the imprecision of the term definitions and lack of a common data exchange format mean DC is used either very loosely, or with application-specific ‘profiles’ that prevent broad interoperability.
Dues, Backorders
Business-to-business orders taken by a publisher, distributor or wholesaler prior to publication or during a temporary period of unavailability (when they are more frequently termed backorders), for delivery when the book becomes available. Subscription orders are recorded as dues. cf pre-orders, which are consumer orders placed with a retailer.
Dummy
Usually handmade mock-up of a book, folded together or bound from unprinted pages to demonstrate the physical nature of a planned product.
Dumpbin
Temporary, free-standing decorative box, usually of cardboard, produced by the publisher to display copies of books in a retail environment. See POS.
DVD, Digital Versatile Disc or Digital Video Disc
Optical disc developed by Philips and Sony, originally for digital video. Similar to a CD, but able to hold much more data – up to 4.7GB – usually compressed and DRM-protected standard-definition digital video, but occasionally digital audio, software (eg video games) or other data. Much rarer double-sided and multi-layer variations of DVD can hold up to 17GB. See also Blu-ray.
EAN
Formerly European Article Number. See GTIN.
Edge decoration
Colored, marbled or gilded edges of the book block.
EDI
Electronic Document Interchange: system for highly-automated exchange of strictly-formatted business documents such as invoices, orders or P&A updates. Common document formatting standards include X.12 (used in North America), Tradacoms (in UK) and EDIFACT (the underlying ISO 9735 standard, common across much of the rest of the world). These are not XML-based standards, but XML equivalents do exist under the EDItX banner.
EDItEUR
Not-for-profit membership-supported organization that develops and maintains, inter alia, the ONIX and EDItX families of message standards and the Thema subject categorization scheme. EDItEUR also manages the ISNI International Agency and until recently managed the International ISBN Agency.
Edition
See P.9 Edition. Historically and in book collecting, ‘edition’ carries the same meaning as impression (eg a limited edition, or a ‘first edition’ of Charles Darwin’s On the origin of species by means of natural selection), but in other contexts, does not imply that all copies are manufactured together, only that they are identical or very nearly so in content (ie there can be several impressions of a Third Edition in paperback, and a separate hardback of the same Third Edition). Significant revisions or changes to the content imply a new edition, and in <indecs> and ISTC terms, a new (derived) work. Other ONIX edition types specified in P.9 – facsimile, large print or Braille, for example – and loose terms such as airside edition used elsewhere are not classed as new works (though they are new manifestations).
EDItX
Family of XML-based ‘transactional’ e-commerce messages developed by EDItEUR, intended as potential replacements for common EDIFACT, X.12 and Tradacoms EDI trading messages. The family also includes sales/revenue/sales tax report messages intended to simplify retail platform-to-publisher sales reporting of e‑books, and an inventory report covering both physical stockholdings (eg for reporting stock on consignment) and digital inventory (for reporting the on-sale status of e‑books).
EDUPUB
Standardized e‑book file format aimed particularly at education material. EDUPUB, now more often termed ‘EPUB for Education’, is a specialized profile of EPUB 3.
EEA
European Economic Area, a free-trade area made up of the European Union countries plus three of the four EFTA countries, Iceland, Lichtenstein and Norway. The EEA agreement provides a ‘uniform internal market’ with freedom of movement for people, goods, services and capital, and great uniformity in regulations relating to trade, social policy, consumer protection, the environment and company law across 31 countries. In territorial rights contexts, ‘Europe’ often means the EEA – but at other times Europe implies the continent, which would additionally include Switzerland, the Balkans, Ukraine, Belarus, Russia and (possibly) Turkey and the trans-Caucasus (Georgia etc).
EFTA
European Free Trade Association, comprising Iceland, Lichtenstein, Norway and Switzerland (though several other countries were previously members and are now members of the European Union). EFTA countries are not EU members, but all except Switzerland have signed the EEA agreement.
EIDR
Entertainment ID Registry, and the DOI-based identifier used by the registry for the film, TV and video sectors. See also ISAN.
E-ISBN
There is no special type of ISBN for e‑books. See ISBN.
Element
See Data element.
Ellipsis
Typographic mark consisting of three dots (‘ … ’) indicating an omission, elision or continuation.
ELT
English language teaching.
Em
Measurement equal to the point size of text – so for 12pt text, one em is 12pts. An ‘en’ is half an em. See also dashes.
Embargo
Proscription of sales, or sometimes of publication of reviews, of a book prior to a particular date. See Sales embargo date.
EMEA
Europe, Middle East and Africa.
Encoding
All text is encoded in some way in order to store and process it digitally: each character is stored as a number, and the relationship between the characters and the numbers is the encoding. ‘A’ might be stored as the number 65, or more likely as the binary equivalent 01000001. B is 66, C is 67 and so on. There are many different standardized encodings, though for historical reasons, most actually do use 65 for A (because ASCII is the basis of many later, more complex encodings). However, encodings vary greatly for characters that are not present on an English typewriter keyboard – é might be stored as 233 (11101001 in binary), or as two numbers 195 then 169 (11000011 and 10101001), or in another way. And most encodings have a very limited repertoire of characters (their character set), so there are many characters that cannot be encoded at all. See Unicode, UTF-8, Latin-1, Windows-1252.
Endband
Headband or tailband at top and bottom of a book spine – originally protective reinforcement of the binding of the book block, and thus implying a high-quality binding, but these days usually a purely decorative cord or strip of woven material sewn or glued to the spine of the book block.
End matter
See back matter.
Endnote
See footnote.
End paper
Strong paper sheet used to affix the case of a hardback to the book block.
Entity
A thing, something that has a distinct and independent existence, and may carry various descriptive properties. Entities may be concrete or abstract, actual or potential, and their properties may often also be considered to be entities. ONIX allows description of various types of entities and the relationships between them – products, contributors, locations etc. See also abstract model, relational database.
EPICS
EDItEUR Product Information Communication Standard – a data dictionary that inspired many of the data element definitions of ONIX.
EPOS
Electronic Point Of Sale, a retailer till or checkout system often also used for sales data and stock control.
EPUB
Standard e‑book file format developed and maintained by the IDPF and more recently by the W3C. The latest EPUB 3 version of the format builds on HTML5 and CSS, incorporates both reflowable and fixed-format variants, and includes features to help publishers optimize the accessibility of the content (obviating the need for specialized accessible editions). Note that ONIX has a number of data elements named <Epub… (for example <EpubTechnicalProtection>) which are intended for use with all types of e-publication. They are not exclusively for publications in the EPUB file format.
ERP
Enterprise resource planning, the integrated managment of multiple high-level business processes, including inter alia purchasing and production, order-to-cash, customer service or CRM, financials including budgeting and accounting, perhaps even HR. Also commonly, the IT systems that support this integrated approach.
Errata
Corrections to the content of a book, sometimes corrigenda printed on a separate sheet and inserted into finished copies as an addendum.
EST
See DTO.
EU
European Union, political and economic union of 28 member European states (Austria, Belgium, Bulgaria, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, United Kingdom).
EULA
End user license agreement, the license granted by the publisher or rightsholder to the final purchaser or reader of an e‑book.
Europe
See EEA.
Evaluation copy
See Approval copy.
Exclusive rights
See Sales rights composite in Group P.21, though exclusivity can apply not only to publishing rights but also to other types of right (for example exclusive distribution rights).
Exhaustion (of rights)
See First sale principle.
 
Export edition
Product intended to be sold outside the country of publication.
Expression
See FRBR.
Extent
Page count, the number of pages in a book (or occasionally, the number of words or the running time). See Group P.11 for different methods of measuring the extent.
Faceted search
Technique for searching a collection of information based on applying multiple filters, successively refining the search results until the item is found. Faceted searching is often used after an initial direct text search, to narrow down a large number of search results.
Fair use, Fair dealing
Limited exceptions to copyright, for example allowing usage of short excerpts or quotations from a copyrighted work for particular purposes such as review, criticism or private study without formal permission or payment. In some jurisdictions, the limits on fair use are clearly and legally defined. In others, fair dealing is defined in a more flexible and pragmatic way.
Field
See data element. May also refer to a column in a database table, or a pre-defined data entry area in a form.
Fingerprint
Procedure to capture the underlying characteristics of, for example, an image or a chunk of audio or video, irrespective of how it is encoded as data. Fingerprint algorithms are designed to be resistant to change – for example, a cropped or lightly retouched image should have a fingerprint very similar to the uncropped original. In contrast to a mathematical hash function, a song would have the same fingerprint when encoded as MP3 or AAC. Digital fingerprints are used to recognize similarity, where hashes are used to detect differences. See also identifier – though note that fingerprints can only be used to identify a resource by comparing the fingerprint with a large database of fingerprints of known resources.
Firm sale
See sale or return.
First sale principle
Under US copyright law, retail book purchasers are allowed to re-sell, trade, rent, lend, or dispose of the previously purchased item without the prior consent of the copyright holder. In other jurisdictions, some of the copyright holder’s rights are ‘exhausted’ at the time of first (retail) sale, to similar effect. The first sale doctrine and exhaustion of IP rights is often now interpreted internationally – that is, the retail sale may happen anywhere, and the retail purchaser may re-sell, trade, rent etc anywhere, including from another country back into the country of origin. However, first sale and exhaustion do not apply to e‑books because they are licensed rather than sold, so libraries and consumers do not usually have the automatic right to lend, rent or re-sell e‑books without the publisher’s permission.
Fixed retail price
Often just FRP, occasionally also Fixed book price or FBP. In certain countries, for example France or Germany, there are legal restrictions that prevent retailers selling books significantly below the list price set by the publisher (or occasionally, the importer). The IPA publishes a report on the use of fixed book pricing across many countries. See also recommended retail price.
Flash card
Small card bearing a letter, word, phrase, number or symbol, displayed quickly to learners to improve recognition skills and recall. Often used in teaching very basic literacy and numeracy.
Flick book
Book containing a sequence of illustrations on the pages, designed to give an animated effect when the pages are flicked through. Not to be confused with ‘flip book’.
Flip book
A two-in-one volume, two books bound together, see back-to-back.
Folio
Historical term for a page number, or for a single sheet (leaf) of paper, or occasionally, for a single sheet folded once to form four pages of a book.
Folly
Cartographer’s folly, a fictitious feature, ‘trap street’ or ‘paper town’ inserted into a published map to help detect plagiarism and copyright violation. Similarly fictitious entries in dictionaries, encyclopedias etc are occasionally called ‘mountweazels’. See also watermark.
Font
Set of characters of the same typeface and size, for example 18pt Helvetica or 10pt Garamond.
Footnote
Additional information, explanation or cross-reference printed at the bottom of a page, and referenced in the main text by a symbol such as an asterisk or dagger, or by a superscripted footnote number. cf endnote, which is similar but placed at the end of a chapter, section or the end of the body of the book.
Foredge
Outer edge of a book page, opposite the bound edge or spine. Occasionally ‘fore-edge’.
Four-color
See CMYK process color.
FRBR
IFLA’s Functional Requirements for Bibliographic Records is a conceptual model, the approximate library-centric equivalent of the <indecs> framework. The most significant contrast in terminology for ONIX implementors is that, while <indecs> and FRBR describe effectively identical manifestation and item or instance concepts, a work in <indecs>, ONIX and ISTC terms is roughly equivalent to an expression within the FRBR model. See also RDA, BIBFRAME.
Frontlist
See backlist.
Front matter
Pages preceding to the main content of a book, including title and imprint pages, tables of contents and of illustrations, and any foreword, preface and introduction text. Also termed Prelims (preliminary pages), and usually numbered with Roman numerals. cf Back matter.
FRP
See Fixed retail price.
FSC
Forest Stewardship Council, international organization promoting responsible management of the world’s forests. It provides accreditation and certification standards for forest management and forest products such as pulp and paper. See also PEFC, the somewhat similar Programme for the Endorsement of Forest Certification.
FTP
File Transfer Protocol, a standard method of transferring files across the internet. cf HTTP.
Full-bound
Binding in which the spine and covers are fully bound in cloth, leather or other material. cf Half-bound, Quarter-bound.
Full update
See Organization of data delivery.
Galley, galley proof
Unpaginated proof copy for checking and correction of the text. The text is in a single long column, without specific page breaks). cf page proof.
Genre
Books of a particular style, form or subject matter – for example romance, crime, science fiction.
GEPIR
See GLN.
GIF
Low-quality raster image file, suitable only for use on the web. See TIFF and JPEG for higher quality image file formats.
GLN
Global Location Number, an international standard identifier for a physical trading location or (loosely) for an organization at that location. Well established within e-commerce and physical logistics, and not in any way specific to the publishing industry. cf SAN. Although the GLN system is administered by GS1, there is only limited central coordination of GLN assignment, and a single location may have more than one GLN. Note that GLNs are 13-digit numbers, and must be distinguished from GTIN-13s by context. Details about a particular GLN can be looked up in the Global Electronic Party Information Registry (GEPIR) – though the results are imperfect.
Gloss
Short explanation, interpretation or annotation of an unfamiliar word or phrase, added between the lines of text (an ‘interlinear’ gloss), in the margin or in a separate glossary. See also ruby.
Glossary
Alphabetically arranged list of terms and their definitions or explanations, essentially a topic-specific dictionary. See also controlled vocabulary, taxonomy. cf index.
‘Gold’ OA
See open access.
Governance
Policy, decision-making and oversight arrangements for a standard such as ONIX, or for an identifier registry like that operated by national ISBN agencies. Well-founded, inclusive and consistent governance engenders trust and builds credibility in the standard, allowing confident adoption and use of the standard by stakeholders.
Granularity
The extent to which metadata is divided into appropriate data fields – for example the way that a contributor name can be divided into <NamesBeforeKey>, <PrefixToKey>, <KeyNames> etc. Highly-granular metadata makes it easier to re-use the same metadata in different and possibly even unforeseen ways.
‘Green’ OA
See open access.
GS1
International standards organization responsible for a wide range of supply-chain standards, including the SSCC, GLN and GTIN identifier schemes.
GSM, grammage
Grams per square metre, see paper weight.
GST
See VAT.
GTIN
Global Trade Item Number, a numbering scheme for tradeable items and consumer products of all types in the supply chain. The GTIN identifier scheme is administered by GS1. Common GTINs have 12, 13 and 14 digits. GTIN-12s were formerly known as UPCs (Universal Product Codes), and are used almost exclusively used in North America. Their use on books has been deprecated since 2005. GTIN-13s were formerly known as EANs (European Article Numbers), and they are used to identify a wide range of retail items. The barcode symbology used to represent GTIN-13s is still referred to as ‘EAN-13’. Thirteen digit ISBNs are a small subset of the GTIN-13 number scheme (see Bookland). GTIN-14s are used to identify trade packs of items (from cartons to pallets).
GTIN-13
See GTIN.
GUID
Globally Unique Identifier. See UUID.
Guillemets
Arrow-shaped quotation marks ( « and » ) used in French and other languages.
Gutter
The portion of a bound page closest to the spine, the ‘back’ or ‘inside’ margin (cf the ‘outside’ margin nearest the foredge).
Gzip
See zip.
H.264
See AVC.
H.265
See HEVC.
Half-bound
High-quality binding in which the spine and corners of the covers (only) are bound in leather (or other fine and durable material). cf Quarter-bound, Full-bound.
Half-title
See title page.
Halftone
Printing technique or the resulting printed image in which shades of grey (or for color images, shades or tints of the CMYK process colors) are simulated by small and regularly spaced ink dots of varying sizes – this is termed AM or ‘amplitude modulation’ screening. The regular spacing of the halftone dots is measured in lines per inch (LPI), or per centimetre. 150 LPI (60 lines per centimetre) is common in books and magazines, and high quality color printing may be halftoned at up to 200 LPI (80 lines per centimetre). Occasionally, halftoning uses very small dots but varies their spacing rather than their size – so-called ‘stochastic’ or FM (‘frequency modulation’) screening. cf line art, which uses only ‘solid’ areas and lines of ink and does not use halftoning to simulate shading.
Handle system
The name resolution system that underlies the DOI. The Handle system turns an identifier or ‘handle’ for a resource – something like 10.4400/zuim – either directly into an IP address, or into a DNS name which can itself be resolved to an IP address. The resulting IP address can then be used to locate the identified resource, or its metadata, on the Internet.
Hart’s Rules
Reference book listing rules of (British) English spelling, punctuation, grammar, usage and typographic style. Derived originally from guidelines for Oxford University Press, but is now the basis of ‘house style’ at many UK publishers. cf Chicago Manual of Style.
Hash
Typographic symbol ‘ # ’ indicating ‘number’ or (in North America) ‘pound avoirdupois’. Not to be confused with the Pound Sterling sign (‘ £ ’) or the musical sharp sign (‘ ♯ ’).
Short, unique numerical pattern based on the digital content of a large block of data. If the underlying data changes in any way, the hash (sometimes loosely but wrongly termed a fingerprint) inevitably changes, so comparison of the expected and actual hash values is a way of detecting changes to the data. There are many different procedures (‘functions’ or ‘algorithms’) for generating hashes, for example MD5 or SHA-256. Hashes are used to detect differences, where digital fingerprints are used to recognize similarity. See also identifier, the key difference is that the hashes and fingerprints are generated from the data via a particular hash or fingerprint function, whereas identifiers are assigned to the data.
HEIC
High Efficiency Image Coding, a subset of HEVC intended for compression and storage of still images. Not yet in widespread use.
HEVC
High Efficiency Video Coding, a format for compressed video data, also termed H.265 or MPEG‑H Part 2. Improved compression enables higher-quality video to be stored in smaller files. Not yet in widespread use, but is likely to supersede existing formats such as AVC.
Hexadecimal
Numbers in base 16. Hexadecimal notation is convenient for numbers that are actually stored by a computer as binary (base 2) numbers. 49 in ‘hex’ is 01001001 in binary (and 73 in ordinary base 10). Hexadecimal uses the digits 0–9 and a–f, so after 49, you get 4a (01001010), 4b–4f (01001011–01001111), then 50 (01010000).
H&J
See hyphenation and justification.
HTML
Hypertext Markup Language, the markup system used for simple web pages. Sometimes refers specifically to HTML version 4, standardized by the W3C in 1997, but in other contexts encompasses HTML5 too. It uses simple XML-like tags to add structure to plain text, for example by surrounding third-level headings with <h3> tags and by marking paragraphs with <p> tags. But although XML-like, it does not fully conform to XML syntax, as certain HTML end tags are optional (eg </p>, </li> or the / in <br />) and tags may be upper or lower case. See also XHTML. Along with CSS and JavaScript, it forms the core of the ‘open web platform’, the suite of royalty-free standards and technologies that underlie the World Wide Web.
HTML5
The latest version of HTML. Some old HTML tags have been removed or redefined, some new tags have been added, the specification itself (technically a W3C ‘Recommendation’) is more rigorous, but it retains much of the familiarity of HTML version 4. Less formally, ‘HTML5’ may also encompass related standards used in modern web browsers. See also CSS.
HTTP
HyperText Transfer Protocol, a standard method used for transferring files or data across the internet. HTTP is used to transfer normal web pages (at their most basic, these are just files that use HTML markup) from web server to browser – but HTTP can be used to transfer other types of information too. cf FTP, HTTPS.
HTTPS
Version of HTTP in which the data transferred is securely encrypted while in transit across the network. Use of HTTPS is vital for network authentication, and for maintaining the privacy and integrity of data. The EDItEUR website https://www.editeur.org uses HTTPS.
Hyphenation and justification
Usually just H&J, typesetting procedures to align line endings so that both left and right margins are straight rather than ragged. Both the spacing of letters and between words can be varied so that each line of justified text is the same length. In some scripts (eg Arabic), joining strokes between individual letters can also be elongated. Words can be hyphenated to reduce the need for excessive variations in spacing, and to improve the look and readability of the text. Justified text may still need further adjustment to eliminate widows and orphans.
IANA
Internet Assigned Numbers Authority, group that coordinates a central registry for DNS, protocols and MIME types for use on the internet.
Identifier
Effectively, a persistent ‘name’ or ‘label’ for some entity like a product, a work, a location – or indeed a name – where the label is unique within a given context. Identifiers are often (but not always) in a tightly-controlled alphanumeric format, and sometimes contain a check digit to help error detection. Standardized identifiers (for example the ISBN or ISNI) generally provide global uniqueness, there is often a minimum set of metadata associated with the identifier, and the identifier and metadata are sometimes managed in a centralized registry. Other identifiers use decentralized registries. A well-managed registry engenders trust in the identifier and its likely future persistence. Although many identifiers are constructed using a ‘recipe’ (something like ‘four digits for the year, three for the publisher, then five more digits and a check digit’), it is best to treat them as dumb labels without internal meaning, intelligence or affordance. For standardized identifiers, the nature or scope of the identified entity is well defined and understood, so they enable unambiguous communication between organizations within the supply chain. Proprietary identifiers such as the ASIN may only be unique within a particular organization, and the exact nature of the entity identified is often not understood beyond the organization.
IDF
International DOI Foundation, see DOI.
IDPF
International Digital Publishing Forum, the standards body that devised and maintained the EPUB file format for e‑books, now absorbed into the W3C.
IETF
Internet Engineering Task Force, group providing technical standards (documented in ‘RFCs’ – Requests for Comment) and guidance (documented in ‘BCPs’ – Best Current Practices) for many aspects of the internet. cf the W3C, which provides standards and best practices specifically for the World Wide Web.
IFC, IBC
Inside front cover (cover 2), Inside back cover (cover 3).
ILS
See LMS.
Imposition
The arrangement of a set of pages printed on a single sheet, so that the pages appear in the correct order when the sheet is folded and trimmed to form a signature. Page 2 will be printed on the reverse of the sheet where page 1 is printed. Page 3 will not be imposed side-by-side with page 2 (except in a 4-page imposition with a single fold), but will appear adjacent after folding. Pages 2 and 3 are a ‘reader’s pair’ or spread in the finished book, but pages 2 and 15 could be a ‘printer’s pair’ (they will be adjacent in a 16-page, three fold imposition).
Impression
A single print run or batch of copies of a book. All copies in an impression are manufactured at the same time and are functionally identical. Subsequent impressions of the same product (reprints) may incorporate minor corrections to the content but may not include significant changes (significant changes to the content would imply it is a new edition, which is considered a new product, albeit a product that is closely linked to the earlier one). The impression number is usually noted on the copyright page.
Imprint
A brand name or marque used on the product by the publisher. On a book, the imprint is usually named on the title page with further details on the title verso. The imprint name is often (but not always) different from the name of the publisher, and larger publishers often make use of multiple imprints across a variety of products. cf list.
Imprint page
See copyright page.
Inalienable rights
See moral rights.
Indecs
The <indecs> (Interoperability of Data in E-commerce Systems) project and resulting <indecs> metadata framework provide the conceptual model and many of the principles that underpin the ONIX metadata framework. For example, the concepts of work and manifestation used in the ONIX framework (and the item concept which is largely unused in ONIX) are drawn directly from <indecs>. cf FRBR. <indecs> also underlies DOI, DDEX and EIDR for the recorded music and filmed entertainment sectors.
Index
Storing metadata in a database, in way that makes it quick to search. Online bookstores index some but not all data fields, so a search for ‘Wellington’ may find appropriate books where the word occurs in the title or name as subject fields, but not those books where the word occurs in an unindexed field like review copy. Different stores index a different selection of data fields.
Alphabetic list of keywords from the content of the book, with references to where they occur, often included at the back of a book. cf glossary.
In print
Active, available, commonly abbreviated to IP (though see also IP). Status implying the product has been published and is orderable from the publisher or publisher’s primary distributor. Note that this does not imply the product is immediately available – it may be temporarily unavailable (cf in stock/out of stock). Conversely, out of print does not mean the product is necessarily unavailable – there may still be stock available within the supply chain. Out of print means only that the publisher or the publisher’s distributor will no longer accept further orders for the product. Out of commerce is sometimes used to indicate ‘out of print and unavailable’.
Insert
See plate section. See also tip-in for a single-leaf insert.
Inspection copy
See Approval copy.
Instance
A single copy of a book, usually synonymous with item – a single retail product. In both the FRBR and <indecs> frameworks, a single ‘instantiation’ of a particular manifestation, more or less interchangeable with all other instances of the same manifestation.
Integer
Whole number, a number without any fractional component, −1, 0, 1, 2 etc. cf real number.
Integrated book
Book with text and illustrations combined on the same pages, rather than with any illustrations isolated in a plate section.
Internet
‘The much-feared best advertisement for books, and their perfect complement: one being a high-tech place where you can go to be connected and somehow feel alone, the other a low-tech thing where you can go to be alone and somehow feel connected.’ Steve Macone, New York Times blog, 25 Nov 2013. See also World Wide Web, one of the systems built on top of the internet. E‑mail, FTP and numerous other services also use the internet.
Interoperability
The ability of multiple systems, using different hardware or software platforms and data structures, to exchange or share data using a common interface.
IP, IPR
Intellectual Property Rights are legally-recognized property rights over ‘intellectual property’ – tangible expressions of creations of the mind such as literary, musical and other artistic works, designs, inventions and discoveries. Intellectual property is (or can be) protected by copyright, patent, trademark and design registration. See Rights. Only copyright is automatic – patents, trademarks and designs must be registered with national Intellectual Property Offices in order to acquire legal protection.
Internet Protocol, the mechanism for data exchange across the Internet. Each computer attached to the internet has a unique IP address.
For IP, see also In print.
IPA
International Publishers Association, the federation of regional, national and specialist publishers' associations which represents publishers worldwide.
IP address
Internet Protocol address, unique numerical address of a computer attached to the Internet. Some IP addresses are also associated with DNS (Domain Name System) names, which are easier to remember – 70.32.68.89 is (currently) linked to www.editeur.org. Computers use the IP address to communicate with other computers, but whenever necessary, they use a DNS service to convert (or resolve) any names entered by a human into the matching IP address.
IRI
Industry returns initiative – in the UK, an agreed set of industry-wide norms and processes for handling returns that enables much of the returns process to be automated. Many (but not all) UK distributors and wholesalers have adopted the IRI methodology for returns.
ISAN
International Standard Audiovisual Number, a unique identifier for audiovisual material in the film, TV and video sectors. ISAN is an ISO standard, administered by the ISAN International agency (ISAN‑IA).The identifier itself consists of 16 hexadecimal digits, a check character, plus eight further hex digits and another check character. See also EIDR.
ISBN
International Standard Book Number, unique and internationally-recognized identifier for a ‘monographic publication’ – a book, e‑book, audiobook or book-like product – which according to ISBN rules must be available to the public. See also barcode. ISBNs are a subset of GTIN-13s beginning with 978 or 9791–9799 (9790 numbers are ISMNs). ISBNs consist of 13 digits (eg 9780001234567), though they are often displayed with extra spaces or hyphens (eg 978‑0‑00‑123456‑7 or 978 0 00 123456 7). But the hyphens or spaces are really just a convenience – they are not a significant part of the identifier. [The positions of the hyphens or spaces within the ISBN highlight the different ‘parts’ of the ISBN – for example separating the ‘registrant element’, sometimes called the ‘publisher prefix’ (00 in the example), from the ‘publication element’ (123456) and the final check digit (7). Note that the middle two of the four spaces or hyphens do not always appear in the same positions – their correct positioning depends on the length of the ‘registration group element’ (0 in the example, but can be up to five digits) and the registrant element (00, but can be up to seven digits). A longer registration group or registrant element implies a shorter publication element. Note also that – even though it is often termed the ‘publisher prefix’ – the registrant element is not a reliable guide to the identity of the publisher.] Also termed ISBN-13 when it is important to differentiate from legacy ISBN-10s. ISBN is an ISO standard. The ISBN system as a whole is administered on behalf of the ISO by the International ISBN Agency – which acts as registration authority – and around 150 mostly national ISBN registration agencies.
ISBN-10
Prior to 2007, ISBNs contained only 10 digits (occasionally including the digit X, used to represent 10 in the last digit, the check digit, which was calculated using base 11 arithmetic). Any former 10-digit ISBN can be converted into the equivalent 13-digit ISBN by prefixing it with ‘978’ and recalculating the check digit. (There are several online converters which will do this. The algorithm for 13-digit ISBNs is different from that used for ISBN-10.) Any 978… ISBN-13 can be converted back into an ISBN-10, but 979… ISBN-13s do not have an ISBN-10 equivalent. Continued use of ISBN-10s is strongly deprecated.
ISBN-13
See ISBN.
ISBN-A
Actionable ISBN, a special type of DOI that incorporates an ISBN as part of its syntax. The equivalent ISBN-A for the ISBN 978-0-00-123456-7 would be 10.978.000/1234567. Note that registration of an ISBN-A is separate from the registration of the ISBN – it is not an automatic part of the ISBN registration process.
ISLI
International Standard Link Identifier. An embryonic international standard identifier that can be attached to a relationship between two entities, when it is important to identify and manage the link itself, not just assert the fact that it exists. The ISLI could find potential application in rights management, where in a relationship such as ‘A licenses B’, it would be important to attach an identifier and other metadata to the ‘licenses’ relationship.
ISMN
International Standard Music Number, an identifier similar to the ISBN, but used for manuscript (notated) music and digital equivalents. Prior to 2008, ISMNs were ten characters (the letter M plus nine digits), but are now 13 digits, with 9790 replacing the ‘M’. A mathematical quirk – or admirable foresight – means the check digit does not need to be recalculated.
ISNI
International Standard Name Identifier, a standard identifier for public identities or personas of parties (people, organizations) involved in creative activities. It can also be applied to brand names (imprints) and to fictional characters. An ISNI can provide an unambiguous way of identifying contributors, imprints and publishing companies. An ISNI consists of 15 decimal digits plus a final check digit which may be 0–9 or X. ISNI is an ISO standard, and the ISNI system is managed on behalf of the ISO by the ISNI International Agency (ISNI‑IA) registration authority and a range of ISNI registration agencies. See also ORCID, VIAF.
ISO
International Organization for Standardization, the non-governmental global standards setting body of which many national standards bodies are members. ISO Technical Committee 46 Subcommittee 9 (ISO/TC46/SC9) is ultimately responsible for many standardized publishing identifiers including the ISBN, ISTC and ISNI, but ISO sets standards for many other aspects of the publishing industry too.
ISRC
International Standard Recording Code, standard twelve character identifier for audio recordings (often music). The twelve characters comprise a two-letter country code, a three-character code identifying the registrant, two digits for the year the code was assigned, and five digits to specify the particular recording.
ISSN
International Standard Serial Number, a standard eight-digit identifier for serial publications such as academic journals, magazines and periodicals, and ongoing series of books. As with the ISBN-10, the last digit may be ‘X’. Note that the ISSN identifies the journal (eg ISSN 0028-0836 is the print version of Nature), magazine or series, not a particular issue of the journal or magazine, nor a particular book within the series. The ISSN-L (Linking ISSN) is an ISSN shared between versions of a journal available in different formats (eg online and printed). ISSNs can be expanded to GTIN-13 form and expressed in a barcode using the prefix 977 and a recalculated check digit.
ISTC
Former International Standard Text Code, unique identifier for textual works. An ISTC consists of 16 hexadecimal digits, comprising a three-digit code for the registration agency, a year of registration, eight digits to specify the individual work and a final hexadecimal check digit. A work identified by an ISTC may be exploited in several products, which would be identified by ISBNs. ISTCs are cross-publisher, and may also be related to each other where one work is derived from another (via translation, abridgement, compilation and so on). Like ONIX, ISTC draws upon the theoretical model provided by <indecs>. Note that the standard has been withdrawn, and the registration system is no longer active.
ISWC
International Standard Musical Work Code, unique identifier for musical works, independent of any particular performance or recording (for which an ISRC would be used). An ISWC consists of 11 characters – a T followed by nine digits and a check digit.
Item
A single (copy of a) product. Note that an item can comprise multiple components, which are sold together, and that a single trade-only product may be composed of multiple items which can be resold at retail as products in their own right. See also instance.
Jacket, dust jacket
Loose paper cover wrapped around the boards of a cased book, also known as a dust cover, dust wrapper etc. The imagery printed on the jacket (the ‘cover image’), and any blurb on the back or folded-in flaps, are key marketing tools.
JATS
Journal Article Tag Suite, a set of standardized XML markup tags for tagging journal articles during the preparation, publishing and archiving processes. See also TEI, DocBook.
JavaScript
Programming language, used primarily to add functionality to web pages. JavaScript programs are embedded in web pages along with HTML content and CSS styling, and the programs are executed with a web browser.
Jobber
See library supplier.
JPEG
Joint Photographic Experts Group. More commonly, an efficiently compressed image file format standardized by that group. JPEG image files are much smaller and nearly as high in quality as the original image (as little as 10% of the size with little perceptible decrease in quality). Greater compression reduces the image quality (JPEG is ‘lossy’), and highly-compressed JPEG images often show characteristic ‘quilted’ patterns (called ‘macroblock artifacts’). cf TIFF.
JSON
JavaScript Object Notation, a basic data syntax for data extended from JavaScript but now used in many contexts to communicate data consisting of a list of name-value pairs. JSON‑LD is JSON used to carry Linked data.
Justification
See hyphenation and justification.
Kerning
Adjustment of the spacing between particular pairs of letters to improve their fit and look. For example, in the word ‘WAVE’, the A fits nicely between the W and the V, so the three letters can be closed up a little. cf ‘tracking’ or letterspacing, which adjusts the spacing between all letters equally to adjust the length of a line (see justification).
Key title
See lead title.
Keyword
Word or phrase chosen to describe or associate with the content or theme of a book. Keywords do not conform to a controlled vocabulary, but may be any natural language word or phrase, such as names of characters in a novel, locations, narrative themes, terms of art etc – any relevant word that is likely to be the target of a search.
Lamination
Thin plastic film applied to a printed sheet, for protection or to improve the appearance. The film can be glossy or matte. Most often used on covers and jackets.
Landscape
A page or image in landscape format is wider than it is tall. cf portrait, where the height is greater than the width. See also aspect ratio.
Latin‑1
Also known as ISO 8859‑1. One of a range of standard 8‑bit encoded character sets intended for use with various European languages – Latin‑1 is designed for a wide range of west European languages, and includes the common characters A–Z, a–z, 0–9 and basic punctuation, plus some fancy symbols (eg §, ¶, ¿, × and ÷ symbols) and extra and ‘accented’ characters like ð, ø, ß, and á, ç, ê, ñ, ü. It omits curly quotes, en- and em-dashes and some other fancy punctuation (see Windows‑1252), and many Latin characters and diacritics used only by central and east European languages. It is a superset of ASCII, and a subset of Unicode. Related character sets Latin‑2 to Latin‑10 are optimized for other Latin-script languages: Latin‑2 contains the necessary characters for most central European languages, Latin‑5 is for Turkish, Latin‑8 is for Celtic languages such as Welsh, Gaelic and Breton, and Latin‑9 (also termed ISO 8859‑15) is an improved version of Latin‑1 that additionally includes the Euro sign (€) and a handful of letters (Œ, Š, Ž plus their lower case equivalents, and Ÿ) while omitting common fractions and the international currency symbol ¤. Further ISO 8859 character sets combine basic Latin characters and symbols with Cyrillic, with monotonic Greek, with Hebrew and with basic Arabic characters.
Latin‑9
See Latin‑1.
Laydown
See Sales embargo date. In printing, is occasionally used to mean Imposition.
LC
US Library of Congress.
LCC
Library of Congress Classification, book subject classification used in some libraries. See also DDC, UDC, CLC, LCSH.
Linked Content Coalition, a consortium of standards bodies and identifier registries that aims to – over time – increase interoperability between metadata, rights information and identifier standards across multiple media sectors.
LCSH
Library of Congress Subject Headings, book subject classification used in some libraries, and distinct from LCC.
Lead time
Expected time taken from order to delivery, for example of a POD product.
Lead title, Key title
Publisher’s frontlist titles for any particular month or season that are expected to sell the most copies or become bestsellers, which are given significant advertising and promotion support (A&P). cf midlist.
Leaf
Single thickness of paper, forming two pages of a book (one verso, one recto).
Learning object
See LOM.
Legal deposit
Legal requirement and administrative process whereby publishers lodge a copy – sometimes multiple copies – of every publication with a national library or with other repositories. Exact requirements vary from country to country, and increasingly apply to digital as well as physical publications.
Leveling
Measurement or assessment of the complexity of text, or the reading ability required for comprehension.
Libel
Publication of a defamatory or untrue statement about a person, organization etc that will harm their reputation, or tend to make them the target of ridicule, scorn, dislike or contempt. cf slander, which is the oral equivalent.
Library supplier
Wholesaler which specializes in supplying library and sometimes school customers. Library suppliers (jobbers, in North America) usually provide selection or bundling of suitable products and cataloging services and in addition to normal wholesale fulfillment, and even offer services such as rebinding.
License
Legal permission to make use of some intellectual property. A rightsholder may license another party (a licensee) to do something that would – without the license – be an infringement of copyright. With the license, the licensee is also a rightsholder (though most likely with narrower rights), and may in some cases be able to sub-license rights to a third party.
Ligature
In typesetting, special precomposed glyph representing two (occasionally, three) letters. In Latin-based typesetting, the combinations æ, ff, fi, fl, ij and a handful of others are common (depending on the fonts available, the difference between ff and ff may not be apparent, but the former is a single Unicode glyph, not a pair of characters). In Arabic typesetting, there are many common ligatures, as characters change shape according to the surrounding letters and their position in a word.
Limp-bound
See case-bound.
Line art
See halftone.
Linked data
Approach that expresses structured data as collections of subject–predicate–object ‘triples’. So for example ISNI:0000000121479135—‘is author of’—ISBN:9780007232833 is a triple. Additionally, linked data identifies the subject entities, predicates and many object entities using URIs – so http://isni.org/isni/0000000121479135 xould be used as the subject of a linked data triple. Linked data triples can be expressed in RDF. Linked open data (LOD) is linked data published under an ‘open’ license, and the Semantic web is a collection of highly interlinked machine-readable Linked open data resources on the internet that allows data to be shared and widely reused.
List
Informally, the books a publisher or imprint has available in print, or are soon to be published. Within a large publisher, there are usually separate lists for different types of book. See also backlist and frontlist. cf imprint.
List price
The retail price for the product set by the publisher. See RRP, FRP.
Litho, offset litho
Traditional high-volume lithographic printing technology using oil-based inks and oleophobic printing plates with oleophilic patterns to pick up the ink and transfer it to the paper. cf POD.
LMS
Library Management System, integrated software application to support the functioning of a library, including acquisition, cataloging and access. Also ILS, Integrated Library System.
Learning Management System, integrated application to support administration, delivery, tracking and reporting of digital educational resources or of complete courses. See also VLE.
Locale
The set of location or culturally-specific patterns and conventions used for display of numbers, prices, time and date formats, etc, sometimes also encompassing language and script preferences, and sort order. ONIX generally aims to ensure data (other than textual descriptions) is communicated in a locale-independent way, leaving the details of locale-specific use or display of the data to the eventual recipient. The Common Local Data Repository (CLDR) is a useful central source of information about specific locales.
LOD
Linked Open Data, see Linked data, Semantic web
LOM
Learning Object Metadata, a metadata scheme for describing educational resources, used within most LMSs. Learning objects are self-contained collections of instructional or explanatory content, together with practice activities and assessment. The LOM model describes the subject, educational objective, interaction model, any prerequisites and the technology requirements of a learning object.
Loose leaf
Publication which is supplied unbound, as individual sheets or leaves. These are usually punched to fit in a binder (often the type with openable metal rings) which makes replacing updated (or ‘canceled’) pages simple.
Lossy, lossless
See compression.
Lower case
See case.
LPI
See halftone.
Manifestation
The physical or digital embodiment of a particular work. The related hardback, paperback and e‑book products are different manifestations of the same work. All contain essentially identical content. Note that a manifestation encompasses multiple individual copies (or instances) of a book, which are identical (or very nearly so). Manifestations may be identified with ISBNs. See <indecs> and FRBR.
MARC
Machine Readable Cataloging, a family of metadata formats used in library cataloging. MARC21, the latest version in use in North America and the UK, is closely tied to the AACR2 cataloging rules. UNIMARC and many minor national variations are common elsewhere. MARC has been in use for nearly 50 years, and has been updated many times to cope with developments in cataloging practices (see AACR2 and RDA), but it is likely to be replaced by more modern data formats over the next decade.
Market
A geographical area within which commercial arrangements for distributing and selling a product are consistent – usually with a single exclusive distributor and single availability date across the market.
Markup
Labels, delimiters or tags within a document that define its structure or meaning. In XML and HTML, markup tags are placed between < and > symbols. Tags are often paired to indicate the beginning and end of a particular data element within the document, so top-level heading text in HTML is contained between <H1> and </H1> tags. Markup can be described as semantic or presentational, but in practice is usually a mixture of both.
Marrakesh Treaty
International agreement signed in 2013 providing for an exception to copyright to facilitate the creation of accessible versions of books and other copyrighted works for print-impaired readers. It also allows for cross-border supply of these accessible versions via trusted intermediaries, independent of the territorial rights arrangements for the works.
Mass market
General non-specialist (adult) consumer market. Also, a paperback product aimed at this broad-based market, often a rack-size or A-format size.
Measure
In typesetting, the width of a column of type.
Media type
Formerly MIME type, the descriptor for file formats used in many internet applications. For example, an HTML file may have the media type ‘text/html’ and a zipped ONIX file should be ‘application/xml+zip’.
Message
See ONIX message.
Metadata
Strictly, data about other data. More usefully in the context of the book and e‑book supply chain, metadata can be thought of as all the data used to describe and trade products through the supply chain. This encompasses both simple, structured and factual information like titles, author names, distribution arrangements and prices, and richer, more complex descriptive data, classifications of various types and even parts of the book itself (a table of contents can be seen also as valuable descriptive metadata). ONIX messages are simply a method of communicating highly structured and standardized metadata from one party to another within the supply chain.
Midlist
Frontlist titles not expected to become bestsellers, and thus not attracting the marketing and promotional effort that publishers afford to lead titles.
MIME type
Multipurpose Internet Mail Extension type. See media type.
Mono, monochrome
Printed using a single ink (usually black). Note this can include halftone images, not just text and line illustrations.
Monograph
Publication that’s complete in one part or volume (or occasionally, in a small number of separate volumes). Individual stand-alone books – or occasionally, sets of books – are monographs. Sometimes also implies a detailed and scholarly work. cf a serial publication such as an academic journal or magazine.
Moral rights
See copyright.
MP3
MPEG Audio Layer-III, standard for compressed audio files. cf AAC. See also codec.
MS
Manuscript, the author’s original version of the text. Occasionally ‘TS’ for Typescript.
Multi-component, multi-item
A single product may contain multiple parts – components – that are intended to be sold together, for example a book bundled with a toy or a slipcase containing three volumes. In contrast, a multi-item product contains several other products and is intended to be split before resale. Multi-item products such as a box containing a dozen copies of an individual book are often available only to the trade.
Namespace
A naming system, or collection of all the possible unique names or identifiers for a particular type of entity. For example, the ISBN namespace consists of all possible 13-digit numbers between 9780000000000 and 9799999999999 (minus those numbers that begin 9790, and those which the check digit indicates are invalid). The ONIX namespace is the complete list of XML tags that could be used in an ONIX message. In XML, namespaces are themselves often given URI-style names, so http://ns.editeur.org/onix/3.0/reference is the name of the ONIX 3.0 reference namespace. Note that there is no web page at that address – it is simply an unambiguous way of naming the namespace.
NBN
National Bibliography Number, an identifier assigned to a book or other document by a national library. Unlike the ISBN, there is no international standard – every library uses its own proprietary format, and NBNs are rarely used outside the library context.
Neighboring rights
See Publishing rights.
 
Net Book Agreement
Former agreement administered by the UK Publishers Association which prevented sale of books at below the publisher’s list price. The NBA was abandoned in 1995, allowing retailers to compete by selling below the list or recommended retail price. But there are laws and similar agreements in other countries that fix the retail price or limit retailers’ ability to sell at a discount, eg the Lang Law in France. See FRP.
Net price
Generally, a price after tax, trade discounts and other adjustments are made – in effect, a business-to-business or wholesale price. See RRP.
NFC
Near-field communication, a set of communication protocols used to communicate over very short distances (a few centimetres) with mobile phones, ‘contactless’ payment cards, biometric passports etc, and closely related to older RFID standards.
In Unicode, see Normalization.
NIP
New in Paperback – a paperback version of a book previously published in hardback.
In binding, to catch paper between rollers to sharpen a fold, or to expel air between sheets.
Non-exclusive rights
See Sales rights composite in Group P.21, though non-exclusivity could apply to other types of rights, for example distribution rights.
Normalization
In a relational database, the strategy of designing data tables and relationships between tables to ensure each chunk of data is stored only once, so that it can be managed efficiently and consistently. However, database designs can sometimes be judiciously denormalized to improve performance, if data management is not such a priority.
In Unicode, the normalization form (NFC, NFD, NFKC or NFKD) concerns whether composite characters like é or the ff ligature are decomposed into two separate characters, the e and ´ (acute accent) or f plus f, or kept as a single precomposed character.
In XML and HTML, ‘whitespace normalization’ means that combinations of multiple space, tab, return and newline characters are treated as if they were a single space character.
NYP
Not yet published: publication is forthcoming. cf AB.
OA
See open access.
OCLC
Online Computer Library Center, US-based global library cooperative offering services such as cooperative cataloging, technology services and research.
OFC, OBC
Outside front cover (cover 1), Outside back cover (cover 4).
Offset fee
Fee paid by one publisher to another for use of typesetting, film or printing plates and occasionally of data files, in the manufacture of a book, entirely separate from any licensing or rights to the intellectual property content.
ONIX for Books
Online Information eXchange, a standardized framework for communication of rich bibliographic and product metadata between computer systems within the book and e‑book supply chains. Originated under the aegis of the Association of American Publishers in 1999 and first published in January 2000, the standard is now managed, developed and supported by EDItEUR.
ONIX_implement
e‑mail mailing list and support forum for general questions about ONIX.
ONIX message
A complete ONIX data file, generally one in a series of messages passed between a data provider and a data recipient. A single message may contain one or many Product records.
On-sale date
See strict on-sale date.
Ontology
In information science, a formally-defined set of entities and their properties and relationships needed to model a domain or area of interest. See taxonomy.
OP
See out of print.
OPAC
Online Public Access Catalog, bibliographic database of a library’s holdings, accessible either online or via terminals within the library.
OPDS
Open Publication Distribution System, a simple data format for distributing catalogs of electronic publications, and usually containing only basic Dublin Core metadata.
Open access
Licensed on ‘open’ terms, for example under a Creative Commons license, which typically mean that a work or published product can be read, used and re-distributed freely – free of charge, and free of at least some of the usual copyright restrictions. The particular license chosen may still require attribution, prevent the distribution of derivative works, or impose other restrictions. More often associated with serials such as academic journals, but some academic publishers produce open access monographs (ie books). Open access material is usually made available via a digital archive maintained by the publisher (so-called ‘Gold’ OA), or an an archive maintained by the author, the research institution or an independent ‘open access repository’ (collectively, ‘Green’ OA). Gold OA material is almost always made available under a highly permissive license, whereas Green OA may be free of charge but remain subject to many or even all the usual copyright restrictions.
Open access publisher
Publisher which specializes in making its products available on open access terms. The publisher charges the author a fee – often termed an APC (article processing charge) or BPC (book processing charge) – to cover the cost of editorial work, peer review, production and distribution, and these fees are usually paid from the author’s research grants. Note that although the product is free of charge to the reader, reputable open access publishers impose the same editorial controls, academic review processes and quality standards as conventional publishers.
Open source (software)
Computer software whose source code is available under an ‘open’ license allowing anyone to use, modify and distribute the code without most of the usual copyright restrictions. See for example Apache v2 licenses.
Open standard
Broadly, standards that are publicly available and often implementable without charge, and which are developed and maintained through a transparent decision-making process open to a broad range of stakeholders.
OPS
Out of print, Substitute. An answer code meaning the product is OP, but the publisher suggests another equivalent or updated product (eg a second edition may be marked as OPS when the third edition becomes available).
ORCID
Open Researcher and Contributor ID, a unique identifier used for academic and scholarly contributors somewhat similar to ISNI, but requiring only self-registration instead of assignment through an ISNI registration agency.
Order-to-cash
High-level business process, or the IT system (often an ERP) responsible for the processes of accepting orders, dispatching goods, generating invoices, and receiving payments. Sometimes OTC, O2C, Purchase-to-pay, PTP or P2P.
Orphan
In typesetting, a single word or excessively short line that appears at the end of a paragraph. Alternatively, a section heading or the first line of a paragraph, or a partial or short line of text (eg the last line of a paragraph), which occurs at the bottom of a column or page. Typesetters and designers try to avoid all three types of orphan. See also widow.
Orphan work
A work protected by copyright or other rights, but where the presumed rightsholders are unknown or cannot be contacted (perhaps because the work is out of commerce). Such orphans are problematic, because uncertainty about the rightsholders and the expiry of their rights means they cannot be exploited.
Out of commerce
Out of print and no new stock is available in the supply chain (though used copies may be available). May apply to a particular product (which implies that other manifestations of the same work may still be in commerce), or may be applied to a work (which implies no manifestations of the work are in commerce).
Out of copyright
Work on which copyright (and other IP rights) have expired. After expiry, the work passes into the public domain.
Out of print
A publisher may declare a product out of print (or OP) to indicate it (or its primary distributor) will no longer accept orders. This usually also means copies sold to retailers on a sale or return basis are no longer returnable (or may be returnable only for a short period after the product is declared OP). However, out of print does not mean ‘unavailable’, as there may still be many copies in the supply chain. See also in print, out of commerce. Out of print can also be applied to a work rather than an individual product, which implies all manifestations of a work are out of print.
OWP
Open Web Platform, term used to describe the combination of HTML, CSS and JavaScript used to create web pages and web-based applications, and EPUB e‑books.
Packager
Agency contracted by the publisher to produce a book, usually including text creation, editing, design and illustration but not manufacturing of the final product.
P&A
Price and availability. Not to be confused with A&P, advertising and promotion.
Page count
See extent.
Page proof
Paginated but unbound proof copy for final checking, indexing etc prior to printing and publication. cf galley proof, bound proof.
Pagination
The process or result of dividing the text into individual pages. See also extent.
Pallet
Wooden packing base on which books (or more typically, cartons of books) or other goods are stacked, stored and transported in bulk. A pallet or skid is typically around 1 × 1.2m, is designed to be handled using a pallet-jack or forklift truck, and can carry up to about 1500 typical hardback novels or 3000 paperbacks (depending on their extent), or a tonne or more of paper sheets.
Pamphlet
Small booklet with few pages, often self-covered (no separate cover), and usually bound with a simple wire stitch.
Pantone
The Pantone Matching System (PMS) is a proprietary colorspace used to specify colors of print and ink, paint, plastic, dye and fabric. Only a subset of named Pantone colors can be printed accurately using CMYK four-color printing. Other Pantone colors are printed using special inks.
Paper weight
The weight (or more strictly, the mass) of a particular grade of paper, usually measured in gsm (grams per square metre of a single sheet). Handily, an A0 sheet is 1 square metre, and so are 16 sheets of A4. Typical book paper lies in the range of 60–100gsm. In North America, paper weight may instead be expressed in terms of the Basis weight, the weight in pounds of a Ream (500 sheets) sized 25 × 38 inches. Typical book paper lies in the range of 40–70lb basis weight (approximately equivalent to 60–100gsm). For some types of paper and board, a different basis size is used – eg 20 × 26 inches for cover board, so 230gsm cover board is 85lb basis weight (and this is sometimes written 85#). See https://www.papersizes.org/us-international-weights.htm for basis weight to gsm conversion tables. See also bulk.
Partwork
Publication released in several weekly or monthly installments, which may be bound together to form a complete book.
Party
Generalized term for a person or organization involved in a creative activity. See also persona.
PDA
See DDA.
PDF
Portable Document Format, standard file format for electronic documents (including e‑books), originally devised by Adobe as a simplification of PostScript, but now an ISO standard. A PDF file can encapsulate almost every aspect of the document – the text, fonts, all vector and raster graphics and even limited interactivity. In general, a PDF fixes the visual aspects of the document exactly and PDF is often used to transfer publisher files to the printer for manufacturing, but reflowing PDFs are possible. Unfortunately, PDF does not retain structural or semantic markup, which reduces its accessibility.
PEFC
See FSC.
Perfect binding
See Adhesive binding.
Period
Punctuation mark (‘ . ’) also called a full stop, used at the end of a a sentence, as a decimal point in a real number, or after an abbreviation. Not to be confused with a mid-dot (‘ · ’) or comma (‘ , ’) which can also be used as decimal points in different locales. XML data uses only the period as a decimal point within real numbers, even if that data is then displayed using the appropriate separator for the locale.
Permissions
Authorization from the copyright or other rightsholder to incorporate one work, or more often a part of a work, within another – for example the permission to include a copyright image or to quote a passage of text from one book in another. See also rights.
Persona
The public-facing outward identity of a party – usually of a person, though a persona may be pseudonymic, or otherwise distinct from the private identity of a real-world person. See also ISNI, contributor.
Pilcrow
Typographic symbol ‘ ¶ ’ usually indicating ‘paragraph’ (or sometimes in technical contexts, the Return character at the end of a paragraph).
Pinakes
The first recorded bibliographic database, developed by Callimachus to catalog the papyri holdings of the Library of Alexandria around 245 BCE.
Pixel
See raster image.
Plate section
Pages bound into a book containing primarily halftoned illustrations (often photographs), usually printed on higher quality paper than the remainder of the book block. Plate sections – sometimes also termed Inserts – usually lack page numbers. cf integrated book.
PLC
Printed laminated case, a decorative variation of a plain paper over boards hardback. The printed design on the cover boards is usually varnished or laminated, as PLCs often lack a separate jacket.
PLR
Public lending right, the right of an author to be compensated for the loan of books from libraries – and in the UK, the system used to provide the related payments.
PNG
Portable network graphics, a losslessly-compressed raster image file format. While mostly intended as an improvement over GIF (a relatively low-quality image format) for online use, PNG can carry high-quality RGB images, including transparency, color profiles etc – but it does not support CMYK. As a result, its use in publishing workflows is limited. See also TIFF, JPEG.
Pocket book
Small book, usually a paperback. Just how small varies from publisher to publisher and country to country. (In the UK, a pocketbook is a small blank notebook, often spiral bound, and the term ‘pocket book’ is not used – it is roughly synonymous with A-format paperback.)
POD
Print on demand, the manufacture of a single copy – often using xerographic (dry, toner-based) or ink-jet printing – in response to a customer order. POD copies may be drop-shipped to the retail customer, or fulfilled via a retailer. POD has a largely undeserved reputation for inferior print quality and binding: current POD technology rivals the quality of conventional litho manufacturing. cf Short-run printing. See also ASR.
Point
Traditional primarily American and British typographic unit of size, abbreviated as pt. Historically, slightly less than 172nd of an inch (or about 0.3515mm). The use of points in PostScript has made exactly 172 (0.3527mm) the de facto standard, and spread the use of points to other typographic traditions. The main text in a printed document is usually around 9–12pt. See also em. cf Didot, similar measurement unit widespread in European typography at least until the 1980s, around 0.375mm (ie about 7% larger than a traditional point).
Portrait
See landscape.
POS
Point of Sale, or Point of Service – ultimately, the retailer’s till or checkout. In the US, Point of Purchase.
Promotional material such as posters, dumpbins, bookmarks placed at or for sale at the retailer’s till or checkout.
Post-coordination
See pre-coordination.
 
PostScript
Computer programming language devised by Adobe, used by early laser printers and by typesetting machines to describe page images, now mostly superseded by PDF.
PPI
Pixels per inch, an unsatisfactory measure of resolution of a digital image. It relates the number of pixels in a digital image to the physical size of the image when printed or displayed.
Pre-coordination
Method of classification where multiple concepts are combined to form single subject headings or codes carrying a complex meaning. All allowed combinations are enumerated in advance. The opposite is Post-coordination, where multiple simple subject headings are used, and the complex combined meaning emerges from the combination of subject headings or codes. Post-coordination allows creative combination of the subject headings. As an example, BISAC is pre-coordinated: a children’s sports story featuring baseball would be classified as JUV032010. In contrast, Thema is at least in part post-coordinated: the same book would be classified as YFR (Children’s sporting stories) plus YNWD3 (baseball), and the full meaning emerges from the combination of the two codes.
Prelims
See front matter.
Pre-order
Consumer order placed with a retailer in advance of actual availability of the product, for delivery on (or at least close to) the publication date.
Presentational markup
See semantic markup.
 
Print-impaired readers
Readers with visual, physical or cognitive impairments who cannot use conventional printed or on-screen books, for example blind, partially-sighted or dyslexic readers, or readers with a physical disability. Print-impairment is a range of issues rather than a single problem, but print-impaired readers can often make use of various types of assistive technology and accessible editions. In many countries – in particular, those that have ratified the Marrakesh Treaty – print-impaired readers have a copyright exception that allows copying and modification of copyright material to make it accessible for personal use.
Print run
Number of copies printed in a single impression. Historically, this was an edition, and this sense is still used in book collecting (‘a valuable first edition’).
Process color
Color printing in which CMYK inks and halftoning are used to simulate the full range of color. Note that cyan, magenta, yellow and black is not the only possible combination of process colors – though rare, a six-color process with additional orange and green inks can widen the range of colors that can be simulated faithfully (the color gamut). cf mono, spot color.
Product
A particular manifestation of a work that is available for sale to the public (or to an organization, on a business-to-business basis). Although ONIX is often characterized as describing products, it can be used to describe parts of a product that are not individually available, or components that are used during creation of products. However, such parts and components should not be identified using an ISBN, unless they are also products in their own right.
Product record
The complete collection of metadata relating to a single product, provided within an ONIX message. A Product record is contained between <Product> and </Product> XML tags.
Provenance
In metadata, the origin of an assertion or metadata property – for example, who says that the book is about motorcycle maintenance? The provenance is important when metadata sources conflict.
Publication date
The date on which the product is nominally ‘published’, though not necessarily the date on which it first becomes available at retail. See Publishing date composite in Group P.20.
Public domain
Works in which all copyright, neighboring and related rights have expired, or those where such rights never pertained. Note that works covered by Creative Commons and similar open access licenses are not public domain, though for particular ‘licenses’ such as the CC0 (‘CC Zero’) waiver, the net effect may be somewhat similar.
Publisher
The organization responsible for making the product available, and generally the one taking the financial risk. cf distributor, contributor and imprint. The publisher is a legal entity, whereas the imprint is merely a brand name.
Publishing rights
The rights to publish or commercially exploit a work in various ways, obtained by the publisher from the author, creator or other rightsholder. The publishing rights obtained by a publisher may be exclusive, global and perpetual, or non-exclusive, limited geographically or for a limited period, and may cover all languages or a specific language. In the English-language publishing market, it is common for a British-based publisher to obtain exclusive world (or world English language) rights from an author, but then sublicense exclusive North American rights to a US-based publisher (or vice versa). Such a sublicense may include additional non-exclusive rights to countries where both UK and US publishers compete to sell their own separate versions of the work. Alternatively, the author may license the North American and remaining rights separately to two different publishers, or a single publisher may obtain the rights to publish globally. A publisher may also sublicense subsidiary and neighboring rights (translation, abridgement, serialization, audio etc) it does not wish to exploit directly. cf sales rights.
Pulping
Destruction of unsold copies of a book to remove them from the supply chain. This ultimately involves shredding and recycling of the paper mass to make new paper, but there may be stages prior to recycling that involve defacing or otherwise making copies of the book unsaleable.
QR code
Quick Response code, a type of 2D barcode comprising a grid of black and white squares. When scanned (eg with a smartphone), QR codes can trigger actions (go to a URL, send an SMS text message, add contact details to an address book, display text), and some actions have attendant security risks. There is no standard use within the book trade, but they are often used in consumer advertising to avoid the need to type long URIs.
Qualifier
Subject code used within schemes such as BIC and Thema that can only be used to refine the meaning of another code.
Quarter-bound
High-quality binding in which the spine (only) is bound in leather (or other fine and durable material). cf half-bound, full-bound.
Quotation marks
Typographic symbols (eg ‘ ’ or “ ”) used in pairs around quotations, reported speech or to highlight a word or phrase. Different languages use different quotation marks, even within the same writing system, and conventions for single or double quotes vary too (eg English uses ‘…’, German uses „…‟, French uses « … », Japanese uses 「…」).
Rack size
Size of mass-market paperback common in the US, 6¾ × 4¼ inches (or 171mm × 108mm), occasionally slightly taller. A ‘tall rack size’ is around 7½ × 4¼ ins. See also A-format.
Rag book
Children’s book in which the cover and every leaf are fabric rather than paper, card or board. Also termed a ‘Cloth book’.
RAM
Random Access Memory, the working memory of a computer, usually in the range of 1 gigabyte (roughly a billion bytes, in a smartphone) to 64 gigabytes (in a server). The contents of RAM are usually lost when the computer is switched off. Contrast with the more or less permanent storage attached to a computer, which is also measured in gigabytes.
Raster image
A digital image represented as rows and columns of colored dots (pixels – picture elements). TIFFs and JPEGs are raster image formats. Raster images cannot be scaled without losing visual clarity – if displayed too large, curves become jagged and the image pixels become individually visible. cf vector image.
RDA
Resource Description and Access. Modern set of library cataloging rules – increasingly widely used and gradually supplanting AACR2 in most English language library applications. RDA rules are also applicable to cataloguing in other languages.
RDBMS
See Relational database.
RDF
Resource Description Framework, a set of W3C specifications (‘Recommendations’) for representation of metadata about resources (typically web resources) as sets of ‘triples’, three-part statements expressing relationships between entities. RDF triple data can be expressed as XML, or in a variety of other data formats (eg Turtle or JSON‑LD, and is the foundation of the ‘semantic web’. RDFa is a data format for embedding RDF-style structured data within the markup of HTML web pages, and is one of the data formats used by schema.org.
Reading age
Measure of a child’s reading proficiency or the proficiency required to read a text, expressed as the age of a child of average reading ability.
Real number
Number that contains both a whole number part and a fractional part, representing a quantity that can vary continuously rather than in discrete increments. Can be expressed as a vulgar or mixed fraction (eg 54 or 1¼) or as a decimal (1.25), though only the latter can be used in an XML data element. (More strictly, in mathematics, these are rational numbers. Real numbers also include irrational numbers, which cannot be represented exactly by fractions.) cf integer.
Recommended retail price
Often just RRP, or occasionally termed a Suggested retail price, or SRP. Price chosen and recommended by the publisher for sales to the consumer. The retailer does not have to use this price, and may choose to sell the product for a lower (or higher) price – the Actual selling price or ASP. But royalties paid to the contributors of the book are often based on a percentage of the RRP, even though the Actual selling price is different. In some countries, retail prices set by publishers are fixed: by law, retailers may not reduce (or increase) the Fixed retail price, or may do so only within a fairly narrow band or only after a certain time has elapsed since publication. In countries where RRPs are the norm, the Agency model may also allow publishers to exert direct control over consumer prices.
Recto
The side of a single leaf in a book that is read first – usually the right hand page in a book, which is given an odd page number. (Conceptually at least, a recto page is a left page in Arabic, Hebrew, or in traditional Chinese and Japanese, where page progression is right-to-left.) The opposite is a Verso page, the second side of a leaf, or left hand page (in most languages and writing systems), with an even page number.
Red Book
The standard covering the physical, optical and electronic nature of all Compact Discs, and for recording high-quality (44.1kHz, stereo, 16‑bit linear PCM) digital audio on such discs. cf Yellow Book.
Registration agency
See Registration authority.
 
Registration authority
Organization ultimately responsible for managing an identifier standard, its governance, and registrations or assignments, for example the International ISBN Agency which is responsible for the ISBN system on a global basis. A registration authority may delegate the process of registration or assignment to multiple Registration agencies, perhaps on a geographical or sectoral basis. For example, Nielsen in the UK and Bowker in the US operate national ISBN registration agencies. (This terminology mostly applies to ISO identifier standards.)
Reissue
As for reprint, but with refreshed marketing collateral, a new cover etc. Reissue sometimes implies renewed availability after a period where the product has been unavailable. Reissues continue to carry the same ISBN as earlier impressions (using a new ISBN is simply a new product, not a reissue of the original, even if it carries identical content and has an identical product form etc).
Relational database
Metadata is often managed using a relational database, in which the data is stored in one or more tables. Each table has rows representing entities such as products or contributors, and the table columns are the properties of each entity. Tables are related to each other, usually through sharing a single column in common, and the relationships usually mirror the real-world relationships between the entities. The tables are usually normalized (designed to minimize redundancy) – so an author who has written a dozen books has their name stored once, forming a row in a Contributor table, and data in that row can be linked to the many rows in the Books table as required. Most relational database management systems (RDBMSs) or applications have library software for importing and exporting XML. See also SQL.
Release date
See Expected availability date in Group P.20.
Remainders
Excess stock of books disposed of by the publisher or distributor at a low price to a specialist bookseller (who cannot return them). An alternative to destruction of excess unsold copies, for example by pulping.
Rental
In e‑books, a limited-term (temporary) license, where a ‘purchase’ is a perpetual license. cf Subscription.
Repertoire
In text encoding, the range of characters used in a document, or present in a particular character set.
In rights, may refer to the works of a particular creator or rightsholder, or those offered by a righsholder for licensing under particular terms.
Reprint
[Print] a new impression, usually manufactured to replenish stock. Copies are essentially identical to the previous batch or impression, though may incorporate minor changes to correct errors, and they carry the same ISBN as previous impressions. Note that if the changes represent significant alterations to the content, then the new copies are a distinct edition – in ONIX terms a new product (and indeed a new work) which would also have a new ISBN (and a new ISTC).
Reseller model
Business model based on the idea that the publisher sells to an intermediary (typically a distributor, wholesaler or retailer) based on an established retail price (RRP or FRP) minus a trade discount (the discount may vary from intermediary to intermediary), or via an established business-to-business or wholesale price. The intermediary can subsequently sell on the book to the consumer at whatever price they choose. Alternatively, in some legal frameworks, the retailer must sell to the consumer at the fixed retail price. In either case, it is the wholesaler or retailer that is the publisher’s direct customer, and not the consumer. This is the most common business model in the book trade; cf the alternative agency model.
Resolution
The process of resolving an identifier to retrieve its underlying metadata, or to find the entity itself. For some ‘actionable’ identifiers such as the ISBN-A, this resolution process can be via the internet, in the same way a DNS name may be resolved to an IP address.
The degree of detail captured in an image (or more generally, degree of precision in a measurement). Image resolution is usually expressed in dots per inch (DPI) or per centimetre (occasionally it’s pixels per inch, PPI). Note that resolution applies to an image in the physical world, not to the underlying pixel data which can be reproduced at any size (see notes on image resolution in Group P.16).
Return
See returns.
Carriage return, character typed to indicate a new paragraph or confirm entry of data.
Returns
Books sold to retailers on ‘sale or return’ terms, that fail to sell at retail and are subsequently returned to the wholesaler or distributor for credit. Returned copies can be re-sold, or may be pulped. Some publishers allow low-value books to be destroyed by the retailer rather than physically returned (eg by stripping off the cover, which is then returned as proof of destruction).
Reversion
Return to the creator of rights previously licensed by the creator to a publisher, for example at the end of a contractually-set term or under other agreed circumstances. Reversions are often requested if a publisher fails to keep a work in print. Similarly, sublicensed rights can revert to the licensor.
Review copy
Copy sent (free of charge) to the press or other media for the purposes of review. See ARC.
See approval copy.
RFID
Radio frequency identification, technology used to communicate with tiny electronic tags that can be attached to physical items such as books. The tags contain identification and other information for the item, which can be read at a short distance to track the item and automate many logistics processes. For example RFID tags can be used to automate library lending processes.
RGB
Red, Green, Blue – basic additive color model used (eg) on a computer screen to generate (or at least simulate) the full range (or gamut) of visible colors. See sRGB, Adobe RGB, CMYK, color profile.
Rights
General term covering copyright, moral rights and other intellectual property rights, plus contractual rights such as the right to distribute or sell products. So-called ‘Volume rights’ give the publisher the right to publish and sell products based on (manifestations of) a copyright work, and are sometimes divided by language and geographical territory (eg ‘the publisher holds Commonwealth English language rights’). Subsidiary rights or ‘sub-rights’ – usually attached to the volume rights, but often sublicensed by the volume rights holder to another publisher – include the right to create and publish serializations for newspapers or magazines, abridgements, adaptations as a play or movie, and (assuming the underlying volume rights are not limited by language) translations. Distribution rights are contractual rights conferred by the publisher on a distributor, enabling the distributor to trade a product in a particular market. See also permissions, publishing rights, sales rights.
Rightsholder
Party which holds copyright or some related rights in a work.
RNG
RELAX NG schema language. See schema.
Rough front
See deckle edge.
Royal
Common UK hardback book size typically around 234 × 153mm. See also demy, trade paperback.
Royalties
Payments made by the publisher to authors or other contributors, in return for the right to publish and sell the book. Royalties are usually calculated based on the number of copies sold and a percentage of the list price of the book – though sums are often paid in advance, and minor contributors may only receive a fixed fee.
RRP
See Recommended retail price.
Ruby
Small gloss or annotation added to characters in non-alphabetic scripts such as Japanese Kanji or Chinese Hànzì, used to guide pronunciation of unfamiliar characters or provide phonetic information for sorting purposes. Ruby glosses are written using phonetic characters such as Pinyin for Chinese or Hiragana for Japanese. See Person name in Group P.7.9, though ruby glosses can be incorporated into any textual data element in ONIX. In HTML, the <ruby> tag can be used to specify glosses. Ruby glosses are so named in English because they were supposedly typeset in Ruby size (5½pt) type.
Sale or return
Transaction terms where goods are sold (eg from a distributor or wholesaler to a retailer) and the purchaser retains the right to return them for full credit if not sold at retail. Sometimes called ‘see-safe’ terms. The purchaser’s right to return unsold copies may expire when – or a fixed period after – a book is declared out of print by the publisher. In some cases, goods need not be physically returned to claim a credit – the cover can be torn off and returned instead (such books are ‘strippable’ and carry a triangular indicator containing a letter S adjacent to the barcode), or the products can be defaced or destroyed in some trusted process to prevent resale. In contrast, ‘Firm sale’ terms mean the product is sold and is not returnable for credit at all, and ‘Consignment’ terms mean the product is still owned by the upstream distributor or wholesaler even though it is physically stocked by the retailer (the retailer ‘buys’ it only after selling it on to a consumer).
Occasionally, sale or return terms (more strictly, consignment terms) are applied to products supplied to end-purchasers, and the purchaser pays only after deciding to keep the goods. See Approval copy.
Sales embargo date
See Publishing date composite in Group P.20.
 
Sales rights
The commercial rights derived from the publisher’s publishing rights that a publisher confers on its distributors, wholesalers and retailers, allowing them to trade in and make the product available to customers. Note the contrast with publishing rights: publishing rights concern where a publisher has the right to publish and sell a product. The sales rights are where the publisher chooses to make the product available (ie chooses to exercise those publishing rights). Clearly the sales rights must be a subset of (or the same as) the publishing rights. In ONIX, only the sales rights are described in detail, and the publishing rights themselves are not made explicit (at least in part because the publishing rights pertain to the work, not the product). In ONIX, the <SalesRights> composites list the set of countries and regions where the publisher is exercising its rights to make a product available. A <ProductSupply> composite and its enclosed <Market> composites can detail the subset of countries and regions where those rights are conferred upon a particular set of distributors, wholesalers and retailers. Another market might have a different subset of the sales rights conferred upon a different group of suppliers. When broken down by market, these are often termed Distribution rights.
Sales tax
Tax levied as a percentage of retail sales to the consumer or end user. cf VAT, which is levied incrementally at all points in the supply chain. Sales taxes are levied by most US states and some Canadian provinces, with rates varying typically in the 0–7.5% range, and additional sales taxes may be levied by city and local government. Since the total retail price – inclusive of tax – varies according to the exact location of the retail sale, advertised prices in those countries do not include the sales tax element, and tax is added at the checkout.
SAN
Standard Address Number, American national standard identifier for a trading location within the supply chain. The SAN registry is administered by Bowker. In Germany, the Börsenverein administers the similar Verkehrsnummer. In contrast to the GLN, the SAN is unique to the publishing industry, but is well established in book-related e-commerce in North America and parts of Europe to identify distribution locations, customer delivery addresses etc.
Schema
Like a DTD, an XML schema formally defines the set of markup tags that may be used in a particular type of XML document, whether each tag is mandatory or optional, and their order and nesting. But unlike a DTD, a schema also constrains the data types and values that may be used within the data elements in the document. It can require that a particular tag contains an integer, or a date, or set a limit on the length of text. And an XML schema can define lists of allowed values (‘enumerations’, controlled vocabularies, or in ONIX terminology, codelists) that can be used in a particular data element. Two primary ‘flavors’ of ONIX for Books schemas are available, using the XSD and RNG schema languages, both of which are themselves XML documents. (Technically, the DTD is a very simple kind of schema too, though DTDs are not themselves XML documents and they cannot define required data types or enumerations.) The normal or ‘classic’ ONIX XSD is based around XSD 1.0. A ‘strict’ XSD 1.1 is also available, which checks a further range of data types, business rules and other requirements, although it not compatible with all XML validation scenarios. A further schema language flavor, Schematron, can be used independently or in conjunction with an XSD schema. A range of Schematron-based rules are embedded within the ONIX ‘strict’ XSD to provide optional warnings covering the use of deprecated data elements and codes.
A database schema is a formal definition of the structure of a database, specifying the nature of the columns, tables, relationships and so on in the database.
Schema.org
Initiative by the major search engines – specifically by Google, Bing, Yahoo and Yandex – that encourages addition of structured metadata into HTML web page markup using a JSON‑LD, Microdata or RDFa vocabulary, largely for SEO purposes.
Schematron
An alternative type of XML schema language. Schematron is rule-based, and is able to test conformance with a wider range of document constraints and business rules than XSD or RNG schemas. Over and above the pass/fail capability of validation with an XSD 1.1, Schematron validation can also deliver warnings about the data.
Script
A writing system of conventional symbols representing the elements of language. A script can be alphabetic, like Latin or Cyrillic, or logographic like Kanji or Hanzi. Scripts can be linked to particular languages (eg Hangul to Korean), or used for a variety of languages (eg Latin to a host of European languages, and also to Chinese via phonetic Hanyu pinyin). A handful of languages are commonly written in more than one script (eg Serbian in either Cyrillic or Latin), or have changed their script at some point in recent history (eg Turkish, Vietnamese are written using Latin script).
Scroll
Printed or manuscript content arranged as a continuous document, not divided into discrete pages. cf codex.
Section mark
Typographic symbol ‘ § ’ usually indicating a section or clause in a document.
Self-publisher
Person combining the roles of contributor and publisher.
Sell-in
Sales to retailers – the number of copies entering the sales channel. In the book trade, most of these copies are typically sold on sale or return terms, so sell-in is not a final sales total. cf sell through.
Sell-through
Sales to consumers. In principle, over the long term, sell-through = sell-in minus returns – though over a shorter period, this can be masked by changes in the number of copies held in stock by retailers. Sell-through is sometimes expressed as a percentage of sell-in (eg a sell-through of 85% implies a 15% return rate). See also EST.
Semantic markup
Markup tags that define or at least highlight the meaning or nature of the tagged text, rather than simply specifying how it should be presented. In contrast, presentational markup defines only how the text should be displayed on page or screen. As a simple example, HTML includes <i>, a purely presentational tag that indicates text should be displayed in italics. In contrast, the <em> and <cite> tags have the same typographic effect on the appearance, but have extra semantic value – they indicate why the text should be italicized (for emphasis, or because it is a title citation).
Semantic web
See Linked data.
SEO
Search engine optimization, the process of enhancing the visibility of your web pages in organic search results, by adding cross-links, keywords and structured metadata about the web page within the web page itself (see schema.org and RDFa), or using terms in the content that are frequently searched for.
Serial
Ongoing publication issued under the same title in a succession of discrete parts, often at regular intervals, such as a magazine, academic journal, newspaper or regularly-issued directory or annual report. Issues are usually dated or numbered sequentially, and are usually purchased via a subscription rather than by purchase of individual issues. Just as monographic publications are identified with an ISBN, serial publications are identified with an ISSN.
Series
Continuing and indefinite sequence of monographic products published separately over a period of time, with a shared identity such as a ‘series title’. The products are usually of similar product form, and share a distinctive branding or design style. A series is not available for purchase as a single product. In ONIX, a series is a type of collection. cf set.
Set
Finite number of products published simultaneously or over a definite period of time, with a shared identity such as a ‘set title’. The products are usually of similar product form, and share a distinctive branding or design style. The products in the set may be available individually, or the set may be a single product, or both. In ONIX, a set is a type of collection. cf series.
SGML
Standard Generalized Markup Language. Highly complex technical standard for markup. Effectively the predecessor of XML, but rarely used because of its complexity.
Short-run printing
Uses similar technology to POD to manufacture small numbers of copies (a print run of perhaps 10 up to 200 copies) in response to a publisher order. These copies are then warehoused and distributed in a conventional manner (though warehousing for such small numbers of copies may be at the printer, rather than at a dedicated distributor’s or wholesaler’s warehouse). See also ASR.
Shrinkwrap
Thin plastic film used for packaging, which contracts tight around the packed goods when exposed to heat.
Signature
A number of pages (usually a multiple of eight) printed on a single sheet and then folded and trimmed to form a section of a book. Signatures are gathered in the correct order and bound to form the book block. See also imposition.
Skid
See pallet.
SKOS
Simple Knowledge Organization System, a way of structuring and representing controlled vocabularies such as ONIX codelists, subject classification and categorization schemes, taxonomies, etc. Using SKOS, each concept (such as a single entry in an ONIX codelist or a single Thema subject) has an optional (language-independent) notation, a preferred label (per language), alternative labels (per language) and a variety of notes (per language), and can be related in various ways to other concepts (eg semantically broader than, narrower than, related to).
SKU
Stock Keeping Unit. In logistics, a unique (and often proprietary) identifier for each product available. In the book trade, the ISBN is sometimes used as an SKU. But often – for example where a single ISBN is reprinted or reissued – an internal stock control process needs to use more granular identification than is provided by the external product identifier (the ISBN). A book distributor might supplement the ISBN with an impression, lot or batch number to ensure older stock is sold before newer.
SLA
Service Level Agreement, the agreed quality of service (often quoted in terms of time to react, time to complete a task, acceptable technical standards etc) to be provided by a service department or an external partner.
Slip-case
Sleeve constructed of rigid board into which the book slides, leaving the spine exposed.
Social DRM
See watermarking, DRM.
Solus
Alone, apart from others of its type. So a ‘solus review’ which concentrates on a single book, or a solus advertisement, placed away from other adverts (or at least away from others offering similar products, cf classified advertising).
SOR
See sale or return.
Sort
Arrange into alphabetical or numerical order.
In typesetting, a special symbol (as opposed to a normal alphabetic or numeric character), a ‘dingbat’.
Special sale
Business-to-business sale where the terms and conditions of sale differ from the norm – for example, for a product where sale-or-return terms are normal, a firm sale (non-returnable) is a special sale. The buyer usually pays a lower price, of course.
Spine
Bound edge or ‘back’ of a bound book, squared off or slightly rounded.
Spot color
Specific colored ink used for printing, in contrast to simulating that color using process color inks and halftoning.
Spread
Pair of facing pages in a book.
SQL
Structured Query Language, a programming language for querying a relational database.
sRGB
Standard RGB, the colorspace that Windows uses by default for RGB images. See also Adobe RGB, DCI-P3.
SRP
See RRP.
SSCC
Serial Shipping Container Code, an 18-digit number used to identify logistics units such as containers, pallets and shipping cartons (parcels) in the supply chain. The SSCC is often printed as a GS1-128 barcode.
STEM
Science, Technology, Engineering and Mathematics curriculum topics and publishing sectors.
Stemming
Reducing inflected or derived words to their word stem, base or root form. Search engines use stemming to improve the search results, ensuring that searches for ‘fishes’, ‘fishing’, ‘fished’, ‘fisher’, and possibly ‘fisherman’, all match ‘fish’. Occasionally termed ‘lemmatization’.
STM, STML
Scientific, Technical, Medical (and Legal) publishing sectors.
Stock
Number of copies of books in a warehouse, or held at a retailer, available for distribution or for sale (eg ‘free stock’). Can also refer to the grade or type of paper or card used for printing (eg ‘cover stock’).
Strict on-sale date
Also known as a sales embargo date (this is the preferred term within ONIX), ‘on-sale date’ or ‘laydown date’ – see the <PublishingDate> composite in Group P.20, and note that ONIX does not distinguish between a strict on-sale date backed by legal force (eg an affidavit) and one that is not (eg backed only by an industry code of conduct). Where the publisher wishes to exercise close control over the earliest retail availability of a product, this is the earliest date that a consumer may obtain a copy of a product – though advance orders (pre-orders) may be placed prior to the embargo date, and advance orders fulfilled by mail-order may be dispatched one day prior to expiry of the embargo. cf publication date.
Stream, streaming
Download and play or display audio, video or e‑book data in real time, without the recipient storing the data permanently as a file.
Strippable
See sale or return.
Sub-rights
Subsidiary rights, or a sublicensed fraction of the volume rights.
Subscript
See inferior.
Subscription
Prepayment against future delivery of multiple issues of a serial publication such as an academic journal over a fixed period of time (eg an annual subscription for twelve monthly issues). Journal issues already received are retained by the subscriber even if the subscription is canceled.
Prepayment of a regular (eg monthly or annual) fee for access to an online resource such as a journal, journal collection or an online library of e‑books for a specific period. Access to the journal or e‑book library ends if the subscription is canceled (in principle at least – some e-journal subscriptions can include limited ‘post-cancellation access’). Note that some so-called B2C ‘subscription’ models are structured more like ordinary B2B sales between publisher or distributor and the subscription library operator, but operate as subscriptions between the subscription library operator and the consumer. For books, subscription has features in common with rental, but subscription usually applies to a library of many e‑books, whereas rental usually applies to a single book, and subscription is open-ended whereas rental tends to be for a fixed period.
Subscription orders
Retailer orders placed with a wholesaler or distributor several weeks prior to publication date – see also dues.
Subsidiary rights
See rights.
Superior, Inferior
Also termed superscript, subscript. Characters printed smaller and higher or lower than normal characters on a line.
Superscript
See superior.
Supply chain
A network – not necessarily a linear chain – of organizations and processes involved in creating and delivering a product or service from the initial producer to the end user. In principle, the supply chain begins with the author and ends with the reader, via publishers, typesetters, printers, distributors, wholesalers and retailers etc. The supply chain encompasses the flow of both goods such as physical or digital books, and information such as metadata, orders and invoices, between the supply chain partner organizations. This is a operational management concept that encourages focus on process optimization, logistics and customer satisfaction, cf value chain, a closely-related business management term.
SVG
Scalable Vector Graphics, a vector image format incorporated within HTML5. The diagrams in this document use SVG.
Tab-separated value file, TSV
Tab-separated value data file. Tabular data file like a CSV file, but with tab characters used as separators between values instead of commas, removing the need to use quote marks when the data contains commas.
Tag, tagging
Can refer to either the markup elements of HTML, XML or ONIX (eg ‘the <ProductForm> tag’, or ‘using <ruby> tags in XHTML’), or to keywords associated with some content that are used to classify the content (eg ‘blog posts tagged with “ONIX”’, or ‘a tag cloud’). It is common to confuse these two very distinct meanings, particularly as classification tags can sometimes be embedded within markup tags….
Taxonomy
A classification scheme, where controlled vocabulary terms or concepts are arranged in a hierarchy of classes and sub-classes. Strictly, a particular entity can only be attached to a single class or term within the taxonomy, though this is not always rigorously applied (for example with many ‘subject classification’ schemes – these are really subject category schemes, where entities can be assigned to multiple categories). Where the vocabulary terms are related not just hierarchically (ie broader and narrower terms) by also by non-hierarchical links of association (‘related to’) and equivalence (‘same as’), and terms are accompanied by a richer range of usage notes, the scheme is often called a thesaurus. A formal representation of the concepts and the relationships is an ontology. Taxonomic hierarchies can be simple or ‘polyhierarchical’, where a sub-class has multiple parent classes – though polyhierarchies can be confusing to use. See also SKOS.
TC46/SC9
See ISO.
Technical protection
See Digital rights management.
 
TEI
Text Encoding Initiative, organization that develops the TEI standard and guidelines for XML semantic markup of structured text. TEI standard markup is used most often in XML workflows for academic work in the humanities, social sciences and linguistics, and particularly for text preservation.
Teleordering
E-commerce system handling electronic orders for books, routing EDI messages between booksellers and their suppliers.
Territorial rights
Loose term referring to rights that vary by location. See Rights, publishing rights, distribution rights, sales rights.
Thema
A new(ish) subject categorization scheme developed in part from the legacy BIC scheme, but updated, internationalized and significantly extended to create a multi-lingual scheme with global applicability. It differs from BIC in that it makes greater use of post-coordination, and has a mechanism for national extensions to qualifiers within the scheme. An interactive category browser is available at ns.editeur.org/thema. Like ONIX, Thema is managed by EDItEUR. Thema was introduced in late 2013, and is currently in the early stages of implementation in many countries. It is intended to be used in parallel with existing nationally-focused schemes, but has the potential to eventually supplant them as a single global scheme. It has already been adopted widely across the book trade in a number of countries, including Germany, Spain, the UK, Norway and Sweden, and has become a key part of Amazon’s 'browse by subject’ scheme in its European stores.
Ti-hi
In physical logistics, the number of items per layer (tier) and number of layers high that goods are stacked on a pallet. In this context, the ‘items’ are usually cartons rather than individual books. Unless the cartons are cubic, there is usually a prescribed stacking pattern so that successive tiers are laid differently.
TIFF
Tagged Image File Format. Typically, TIFF is a high-quality (lossless) file format for raster images. TIFF files are usually compressed using an LZW or Deflate compression scheme, but are still usually much larger than the same image stored as a JPEG. (In fact, TIFF can contain lossy image data that is compressed using JPEG, or uncompressed images, but this is rare).
Tip-in
Extra leaf glued into a book after binding, often used for separately-printed illustrations or plates, errata sheets, gatefolds and other pages that are not the same size, or sometimes for pages intended to be removed.
Title page
Recto page at the beginning of a book that bears the title of the book, and also the names of contributors and the publisher and city of publication. This is often the third page of the book block. The Title verso (the reverse of the title page, often also called the Imprint page, often the fourth page of the book block) usually contains copyright details and any CIP information and colophon. The Half-title page is the recto page before the title page – and thus usually the first page of the book block – that carries just the title of the book (without other details).
Title sheet
See AIS.
Title verso
See title page.
TLS
Trimmed leaf size, more ordinarily TPS (trimmed page size) or just trim size. Dimensions of a book page or leaf after binding and trimming. For a typical paperback where the cover is cut flush to the pages, the TLS is also the size of the cover. For hardbacks where the cover boards extend beyond the trimmed pages, the cover is usually around 6–8mm larger in each dimension.
TOC
Table of Contents.
Tote
In logistics, a reusable plastic crate used to collect and convey items within a distribution center.
TPB
See Trade Paperback.
TPS
See TLS.
Trade
The book trade – the business and commerce of book publishing, manufacture, distribution and selling, in phrases like ‘trade-only’, ‘trade-pack’, ‘trade association’ etc.
A trade book – fiction and general interest non-fiction books primarily for adult consumers, sold through ordinary retail bookshops. See trade publishing, trade paperback.
Trade discount
See Discount.
Trade paperback
In the UK, a paperback produced in a size more typical of hardbacks (see demy, royal); in the US, a paperback that’s usually larger than rack-size mass-market paperbacks (but not as large as a typical hardcover book).
Trade publishing
Publishing of fiction and general interest non-fiction (‘trade’) books primarily for adult consumers, which are sold through ordinary retail bookshops. cf specialist sectors, including children’s publishing, academic and educational publishing, STM and legal publishing. Note that trade books are only a small part of the book trade.
Transliteration
Expressing the words of one language in an alphabet or writing system normally associated with a different language – so for example Russian language text can be transliterated into the Latin alphabet. cf Translation, where Russian can be translated into the English language.
Trim size
See TLS.
TRIPS
Agreement on Trade-Related Aspects of Intellectual Property Rights, international agreement administered by the World Trade Organization that defines minimum standards for legal protection and enforcement of intellectual property rights (IPR).
TSV
See Tab-separated value file.
TTS
Text to Speech. Synthesized speech sounds generated from text by specialized software, usually to improve text accessibility for print-impaired readers.
Typeface
A set of characters of a particular consistent design, for example Helvetica or Garamond. cf font.
UCC
Universal Copyright Convention, limited alternative to the Berne Convention, agreed in 1952 by countries which were not party to the Berne Convention (eg USA and later, USSR). Virtually all countries have now adopted the full Berne Convention on copyright.
UDC
Universal Decimal Classification, common and highly detailed systematic subject classification system used within many libraries and information services. It has a complex ‘grammar’ of punctuation symbols used to combine multiple subjects and facets to provide rich subject information. See also DDC, on which UDC was originally based, LCC, CLC.
Ultraviolet
Digital rights management system which implements an internet-accessible key locker, so DRM-protected content can be unlocked by any of the Ultraviolet account owner’s devices.
Umlaut
See dieresis.
Unicode
Comprehensive set of characters, hugely improved over ASCII and Latin‑1 to Latin‑10, which are focused on basic English text and a broad range of European scripts respectively. Unicode includes the characters required for all common written languages and writing systems, including non-European scripts like Arabic, Devanagari or Chinese, ancient and historical scripts, and a vast range of mathematical and other symbols. However, displaying these characters is font-dependent too – the data may be in Unicode, but if your font does not contain the right characters, you still can’t see it! This document is composed in Unicode, which allows it to include special characters like √ (square root symbol), д (Cyrillic letter de), ش (Arabic character sheen) or 房 (Chinese word fáng) – but you might not see them correctly if your web browser and operating system don’t support Unicode or the font does not include the relevant glyphs. Each character in Unicode has a 32‑bit number (cf ASCII, which uses 7 bits (binary digits), or Latin‑1, 8 bits per character, and are therefore limited a much smaller range of characters), so in principle Unicode files are four times the size of Ascii files for the same text content. However, UTF‑8 is a special encoded form of Unicode that reduces the file size to something more manageable.
UPC
See GTIN.
Upper case
See case.
URI
Uniform Resource Identifier – an identifier for a resource (usually, but not necessarily, a resource on the internet).
URL
Uniform Resource Locator – a variety of URI that identifies a resource based on where it can be found or ‘actioned’. For example, the familiar https://www.editeur.org URL is the identifier for a resource – the EDItEUR website.
URN
Uniform Resource Name – a variety of URI that identifies a resource based solely on a name, without any indication of where that resource can be found. For example, urn:isbn:9780007232833 identifies a book, but cannot (in general) be used to find a copy of that book on the internet – some libraries do operate ‘URN resolvers’ to link that URN to metadata about that book or to an electronic copy of the book, but such systems tend to be internal to the library.
UTC
Coordinated Universal Time, or ‘Zulu’ time, which is (for all practical purposes) the same as Greenwich Mean Time (GMT). It does not change with timezones or daylight saving. Local timezones use a specific offset from UTC, so EST is five hours behind UTC, and EDT is four hours behind.
UTF‑8
Practical encoding of the Unicode character set. Each Unicode character is represented by one to four bytes of data. Files containing English text are approximately the same size as if they were represented in ASCII, as the common English keyboard characters are all represented using a single byte in UTF‑8. Files containing equivalent text in other languages are larger, but usually comparable with encodings designed specifically for that language (eg Shift_JIS for Japanese text). UTF‑16 is another practical encoding of Unicode, but it comes in two flavors, UTF‑16LE and UTF‑16BE (little-endian and big-endian) and uses two or more bytes per character.
UUID
Universally Unique Identifier, a label or identifier that can be minted in accordance with RFC 4122. UUIDs are essentially random numbers, sufficiently large to practically ensure uniqueness without the need for centralized management (they contain 128 bits, or 32 hexadecimal digits). Some types of UUID include information about the time of creation of the ID, or about the machine that created the ID, instead of being wholly random. GUID Globally Unique Identifiers are UUIDs, but the GUID name is more common in some particular contexts (eg within Microsoft software).
Validation
The process of checking an XML document meets the requirements of a particular DTD or schema – for example the ONIX for Books DTD and XSD. Special XML software tools are required to validate an XML document.
Value chain
The various activities and processes involved in creating or adding value to a product or service, from the initial producer to the end consumer. In principle, the value chain (or more generally the ‘value system’) begins with the end consumer, and value is distributed ‘up’ the chain of retailers, wholesalers and distributors, to publishers and authors according to how well each organization adds value in excess of its costs. This is a business management concept that encourages a focus on strategic planning and building competitive advantage, cf supply chain, a closely-related operational management term.
Vanity publisher
Publisher which charges (rather than pays) the author to publish the author’s book. In the US, a ‘subsidy publisher’. The term is largely obsolete because of the growth of self-publishing, and of open access publishing, both of which also involve publishing a work at the expense of the author but without the critical opprobrium attracted by vanity publishing.
Varnish
Transparent lacquer applied eg to covers and jackets after printing, to impart a glossy finish. Applied as a liquid, and often dried or cured using ultraviolet light. cf lamination.
VAT
Value Added Tax, also known in some countries as GST (Goods and Services Tax). It is levied as a percentage of sales (both B2B and B2C sales), and paid by companies to the tax authority based on the difference between the tax value of their sales and the tax value of their purchases. Thus it is collected incrementally from all parts of the supply chain. cf sales tax. VAT/GST rates vary from country to country, typically in the range 5–20%, though there are exceptions, and in some countries books and other cultural goods attract a special low rate. In the UK, VAT on physical books is currently levied at 0%, though audio and e‑books carry standard rate (20%) VAT. In France, the low rate of TVA (Taxe sur la valeur ajoutée) applied to books is 5.5% and the standard rate for e‑books is 20%. In Germany, the rates of MwSt (Mehrwertsteuer) are 7% and 19%. The IPA produces a regular report containing detailed information on VAT on books.
Vector image
A digital image represented as lines and shapes, such as a map, diagram or graph. SVG is a vector image format. Vector images can be scaled without losing quality – curves remain smooth at any size. cf raster image.
Vendor of record
See distributor.
Verso
See recto.
VIAF
Virtual International Authority File, a name authority file service for libraries that combines name authority data from many libraries. VIAF IDs are created statistically, rather than being explicitly and permanently assigned. The service is operated by OCLC. See also ISNI, ORCID.
VLE
Virtual learning environment, IT system used in education to provide a platform for managing and delivering digital content to students. VLEs often include content creation, curriculum and student management, collaboration and assessment tools.
Volume rights
Loose term indicating the main rights to publish a book (or more generally, ‘exploit a work’), for example in hardback and paperback and possibly other formats. The rights may be limited to a particular language, a particular geographical territory, and might also be time-limited. See also rights.
Voucher copies
Free copies of a book given to secondary contributors. cf Author’s copies.
W3C
World Wide Web Consortium, the body that controls many of the standards that underlie the technical workings of the World Wide Web, including HTML and XML. cf the IETF, which provides underlying technical standards for the internet as a whole.
Warranty
A legal guarantee given in a contract. For example, an author usually warrants that they are the original author, that they have the legal power to license or assign the copyright to the publisher, and that they agree to indemnify the publisher against this not being the case.
Watermark
In digital rights management (DRM), a hidden or hard-to-remove pattern of unique data added to each individual copy of a product, so that the purchaser or licensee of each copy can be identified. Watermarking – sometimes called social DRM – does not enforce constraints on usage of digital content, but discourages breaking those constraints by making the responsible party identifiable.
In papermaking, a faint design visible in some types of paper, usually identifying the paper maker.
WAV
Audio file format most commonly used with Windows PCs, usually uncompressed. cf AAC, MP3 audio files.
Web service
Software system or API designed to support interoperable machine-to-machine interaction across the internet. This is usually in a ‘real-time’ context and via a SOAP- or REST-style API where messages are exchanged more or less instantly using HTTP, but can in principle also encompass batch mode message files passed via FTP.
Weight
Loosely, the physical mass of a product.
See also paper weight.
WGS
Warengruppen-Systematik neu, product category system used widely in the German book trade, combines subject coding with information about the product form. See also Thema, which is in use alongside and is replacing WGS within Germany.
Wholesale model
See reseller model.
Wholesaler
Supply chain organization that holds a secondary stock of books. A wholesaler obtains stocks from a primary distributor and supplies stocks to retailers or other business-to-business customers. Wholesalers are typically non-exclusive – there may be several wholesalers competing to supply the retailer. Some wholesalers (library suppliers or jobbers) specialize in supplying the libraries or schools markets rather than the retailer market.
Widow
In typesetting, a partial or short line of text (eg the last line of a paragraph) which occurs at the top of a column or page. Typesetters and designers try to avoid widows. See also orphan.
Windowing
Movie industry release strategy where a movie is published on different media at different times (eg first a theatrical release in cinemas, then on Bluray and DVD, then subscription TV and finally free-to-air TV). Trade book publishers often follow a similar strategy with hardback, trade paperback, mass-market releases. cf day and date releases.
Windows‑1252
An 8‑bit character encoding of a set of around 215 characters, a superset of ASCII and Latin‑1 character sets, with a few additions such as curly quotes, en- and em-dashes, †, ƒ, ž. Used with the Windows operating system, and sometimes called Code Page 1252. Different Windows Code Pages provide support Cyrillic, Arabic and other character sets. The near-equivalent character set on the Mac is called MacRoman, though the actual encoding of many characters is different.
WIP
Work in progress.
WIPO
World Intellectual Property Organization, specialized agency of the United Nations concerned with international copyright, patents and trademarks. It originated in an organization charged with administration of the Berne Convention.
Wire stitch
Staple. A wire stitch through the middle of a set of folded sheets forms a simple booklet.
Wire-O, wiro binding
Type of wire binding where the wire forms a series of double loops through holes punched in the pages. cf coil binding in which a spiral wire runs through the punched holes, and comb binding which uses a flexible plastic spine with curved teeth through punched holes.
Work
Distinct intellectual or artistic creation, from which several products (or manifestations in <indecs> terms) may be derived; roughly synonymous with ‘title’, where hardback, paperback and e‑book manifestations of that title are all versions of the same work. Textual works may be identified with an ISTC. Works are the subject of intellectual property rights. Modifications to a work, such as translation, abridgement or significant revision (eg to create a new edition) or addition of further material create a new ‘Derived’ work. As such, ONIX uses the <indecs> view of a work; cf FRBR, within which a work has a broader definition. A FRBR expression is the equivalent of an <indecs> work.
Workflow
In a publishing company, an organized pattern of business processes within editorial, design, production and other departments that creates the company’s intellectual property and products.
Work for hire
Normally, the creator of a creative work becomes the initial copyright holder. Work for hire (sometimes work made for hire) is an arrangement whereby the employer of the creator, or the party that commissions a work, becomes the copyright holder.
World Wide Web
Distributed hypermedia resource, built on top of the Internet, and which primarily uses the HTTP protocol to exchange data and documents created using HTML, CSS and JavaScript.
World Wide Web Consortium
See W3C.
 
Wrapper
See jacket.
X.12
See EDI.
XHTML
A slightly reformulated and stricter version of familiar HTML markup, differing in that it conforms to XML syntax. All tags must be properly closed and nested, and tags must be lower case.
XML
eXtensible Markup Language. Underlying technical standard for ONIX for Books syntax (see https://www.w3.org/TR/xml/), allows highly structured, granular documents, and makes data easily reusable. Often used to communicate data between databases. See also DTD and schema.
XML database
An alternative to a relational database, in which data is stored as a collection of XML documents, rather than being decomposed into individual tables, rows and columns. In some circumstances, can perform better than a relational model when there are very large numbers of dependent tables.
XPath
XML-related software technology for selecting particular composites or data elements (in XPath, nodes) within an XML document. An XPath lists the ancestor elements of the selection – the path /ONIXMessage/Header/Sender selects the Sender composite of an ONIX message.
XSD
W3C XML Schema Language. See schema.
XSL-FO
eXtensible Stylesheet Language – Formatting Objects, a language for specifying the visual formatting of an XML document. Not widely used, and increasingly superseded by use of CSS.
XSLT
eXtensible Stylesheet Language Transformations – language for defining how to process an XML document, for example to convert it from one DTD or schema to another, or into an XHTML format.
YA
Young Adult book or audience – intended to be read and enjoyed by adolescents (approximately 12–18 years old) – ‘teenagers’, more or less. But the term is also used to refer to books primarily intended for adults – perhaps those up to about 24 years old – which in some cases would be considered unsuitable for those younger teenagers. As a result of the varying intended meanings, ‘YA’ should be used with care and qualification. Similar terms (eg ‘new adult’) often suffer a similar lack of clarity.
Yapp binding
Soft cover that extends a few millimeters beyond the edge of the book block (like the boards of a hardback do). Binding style sometimes used for Bibles, soft-cover dictionaries, personal diaries. The edge of the cover is sometimes fitted with a zip fastener to keep the book closed.
Yellow Book
The standard covering the data format of CD-Rom discs – the standard builds upon the Red Book standard but allows the disc to store any kind of digital data: for example ‘MP3 CDs’ (CD-Rom discs containing .mp3 files).
Zip
Zipped and Gzipped data files are compressed to be smaller than the original data files, making them easier or quicker to send to a recipient. They can be decompressed (unzipped, gunzipped) by the recipient to recover the exact original data. The compression algorithm is the same, but Gzip is used for single files, whereas zip may be used on entire folders of files. Note that zipping or gzipping doesn’t greatly reduce the size of files that are already compressed, such as JPEGs or MP3s.

A.2 Checklist of ‘practical minimum set’ of data elements

It is common, with a standard as large and comprehensive as ONIX for Books, for implementors to ask what is the minimum set of metadata elements that it is necessary to support. This might seem to be a purely technical question – what is the minimum ONIX message you can construct that consists only of mandatory data elements?

Minimum useful ONIX message – confirmation of no changes since last message
using Reference names
<?xml version="1.0"?>
<ONIXMessage release="3.0">
    <Header>
        <Sender>
            <SenderName>Publishing Service Inc</SenderName>
        </Sender>
        <SentDateTime>20141209</SentDateTime>
    </Header>
    <NoProduct/>
</ONIXMessage>
using Short tags
<?xml version="1.0"?>
<ONIXmessage release="3.0">
    <header>
        <sender>message from
            <x298>Publishing Service Inc</x298>
        </sender>
        <x307>20141209</x307>sent on 9 Dec
    </header>
    <x507/>no product updates
</ONIXmessage>since previous message

Another very minimal ONIX message would contain a single <Product> record containing a Record reference, a Notification type 05 to request deletion of a record issued in error, an explanation of the error in <DeletionText>, and a single product identifier for confirmation. An example record like this is listed in Section P.1. Nothing else is mandatory.

However, beyond the special circumstance of a deletion, this technical minimum is almost useless – it conveys no information about the product other than a single ISBN (or some other identifier). On the other hand, no ONIX data sender or recipient uses every ONIX data element. To a large degree, the question of the minimum set of metadata elements has to be answered by considering the business requirements of both sender and recipient of the data. And the minimum set suitable for a typical trade publisher or retail bookstore will differ from the minimum set designed to meet the needs of an academic publisher or educational bookseller.

Another approach to the idea of a ‘minimum set’ is to limit which codes from each codelist are supported. Recipients who can only use a subset of codes from a particular codelist should ensure there are sensible fallbacks in place for unsupported codes – they should not restrict which codes can be used by senders, but should map unsupported codes used in the data they receive to the nearest supported equivalent (or in some cases, unsupported codes could be treated as exceptions that require manual intervention).

The table below summarizes a practical minimum set of data elements that a data sender should be able to support, at least to cover the typical data recipient’s requirements for the most common types of product. For the most part this duplicates the summaries in rounded boxes throughout this Implementation and Best Practice Guide, though a few of the more specialist data elements have been dropped.

Omission from this list does not imply that a particular data supplier or recipient should simply ignore the element in question – it means only that the element is unlikely to be required by typical recipients or for common types of product. For example, the list below does not cater for collections nested within other collections (it omits <PartNumber> within <Collection>). Neither does it cater for religious texts, for e‑book rentals, for the publication of conference proceedings, nor for the use of Block 3 to carry structured tables of contents, since these are not required in most implementations. Conversely, inclusion in this list does not imply a data supplier must implement a particular data element or composite – though data recipients should be wary where omitting support for one seemingly unimportant data element may change the interpretation of another important data element. For example, <ProductPart> and the whole of Group P.4 is unnecessary where multi-component products are not a consideration, and <SalesRestriction> is only required where products are retailer-exclusive. Ignoring <ProductPart> is largely benign, but ignoring <SalesRestriction> may change the interpretation of <SalesRights>. (Again, some unsupported data elements that do potentially change the interpretation of other data could be treated as exceptions requiring manual intervention.) The important point is that the minimum set of data elements for a particular implementation is highly dependent on the nature of the products the data supplier is describing, and on the purpose the description is intended for.

Some ONIX national groups have also defined expectations for the minimum set to be used within a particular country. Importantly, such sets are minimums, and do not prevent a data supplier delivering richer information – nor do they prevent recipients making use of this richer data when it is supplied.

For an alternative ‘minimum’ set of data elements focused on a specific business requirement, see ONIX for ISBN Registration, a subset or ‘profile’ of ONIX for Books intended solely for communication between publishers and national ISBN Agencies, that carries only that metadata required for registration of ISBNs – omitting all details of collateral material, content details and product supply details since they are irrelevant to the process of ISBN registration, but making mandatory a few elements that are optional in ONIX for Books.

data element checklist ☑
# Reference name Short tag Notes
Message
 <?xml version="1.0"?><?xml version="1.0"?>☑ also include encoding
 <ONIXMessage release="3.0"><ONIXmessage>
Message header
 . <Header><header>
 . . <Sender><sender>
 . . . <SenderIdentifier><senderidentifier>☐ if available
 . . . <SenderName><x298>
 . . . <ContactName><x299>
 . . . <EmailAddress><j272>
 . . <Addressee><addressee>☐ if message is tailored
 . . . <AddresseeIdentifier><addresseeidentifier>
 . . . <AddresseeName><x300>
 . . <MessageNumber><m180>☐ if delta update
 . . <SentDateTime><x307>
Product record
 . <Product><product>
Group P.1
 . . <RecordReference><a001>
 . . <NotificationType><a002>
 . . <RecordSourceType><a194>☐ if aggregated data
 . . <RecordSourceName><a197>☐ if aggregated data
Group P.2
 . . <ProductIdentifier><productidentifier>
Block 1
 . . <DescriptiveDetail><descriptivedetail>
Group P.3
 . . . <ProductComposition><x314>
 . . . <ProductForm><b012>
 . . . <ProductFormDetail><b333>☐ if relevant
 . . . <ProductFormFeature><productformfeature>☐ especially for digital products, safety warnings, paper certifications etc
 . . . <ProductPackaging><b225>☐ if product is packaged
 . . . <PrimaryContentType><x416>☐ if not simply textual
 . . . <ProductContentType><b385>☐ if not simply textual
 . . . <Measure><measure>☐ if product is physical
 . . . <CountryOfManufacture><x316>☐ if product is physical
 . . . <EpubTechnicalProtection><x317>☐ if product is not physical
 . . . <EpubUsageConstraint><epubusageconstraint>☐ if product is not physical
 . . . <MapScale><b063>☐ if cartographic
Group P.4
 . . . <ProductPart><productpart>☐ if a multi-component product or multi-item pack
 . . . . <PrimaryPart/><x457/>
 . . . . <ProductIdentifier><productidentifier>
 . . . . <ProductForm><b012>
 . . . . <ProductFormDetail><b333>☐ if relevant
 . . . . <NumberOfItemsOfThisForm><x322>☐ or…
 . . . . <NumberOfCopies><x323>
 . . . . <CountryOfManufacture><x316>☐ if product part is physical
Group P.5
 . . . <Collection><collection>
 . . . . <CollectionType><x329>
 . . . . <CollectionIdentifier><collectionidentifier>☐ even if only proprietary
 . . . . <TitleDetail><titledetail>
 . . . . . <TitleType><x330>
 . . . . . <TitleElement><titleelement>
 . . . . . . <SequenceNumber><b034>☐ if title has many elements
 . . . . . . <TitleElementLevel><x409>
 . . . . . . <TitleText><b203>☐ if legacy data cannot differentiate titles with prefixes, but…
 . . . . . . <NoPrefix/><x501>☐ or…
 . . . . . . <TitlePrefix><b030>☐ plus…
 . . . . . . <TitleWithoutPrefix><b031>☐ is better
 . . . . . . <Subtitle><b029>
 . . . . . <TitleStatement><x478>☐ if simple concatenation is insufficient
 . . . <NoCollection/><x411/>
Group P.6
 . . . <TitleDetail><titledetail>
 . . . . <TitleType><x330>
 . . . . <TitleElement><titleelement>
 . . . . . <SequenceNumber><b034>☐ if title has many elements
 . . . . . <TitleElementLevel><x409>
 . . . . . <PartNumber><x410>
 . . . . . <YearOfAnnual><b020>
 . . . . . <TitleText><b203>☐ if legacy data cannot differentiate titles with prefixes, but…
 . . . . . <NoPrefix/><x501>☐ or…
 . . . . . <TitlePrefix><b030>☐ plus…
 . . . . . <TitleWithoutPrefix><b031>☐ is better
 . . . . . <Subtitle><b029>
 . . . . <TitleStatement><x478>☐ if simple concatenation is insufficient
Group P.7
 . . . <Contributor><contributor>
 . . . . <SequenceNumber><b034>
 . . . . <ContributorRole><b035>
 . . . . <NameIdentifier><nameidentifier>☐ even if only proprietary
 . . . . <PersonNameInverted><b037>☐ or…
 . . . . <TitlesBeforeNames><b038>☐ and…
 . . . . <NamesBeforeKey><b039>☐ and…
 . . . . <PrefixToKey><b247>☐ and…
 . . . . <KeyNames><b040>☑ and…
 . . . . <NamesAfterKey><b041>☐ (if any eastern-style names)
 . . . . <CorporateNameInverted><x443>
 . . . . <BiographicalNote><b044>
 . . . . <UnnamedPerson><b249>
 . . . <ContributorStatement><b049>
 . . . <NoContributor/><n339/>
Group P.9
 . . . <EditionType><x419>
 . . . <EditionNumber><b057>
 . . . <EditionStatement><b058>
 . . . <NoEdition/><n386/>
Group P.10
 . . . <Language><language>☐ of text, and ☐ of original if product is translated
Group P.11
 . . . <Extent><extent>
 . . . <AncillaryContent><ancillarycontent>
Group P.12
 . . . <Subject><subject>☐ subject schemes and ☐ keywords
 . . . <NameAsSubject><nameassubject>
Group P.13
 . . . <Audience><audience>☐ (and ☐ warnings)
 . . . <AudienceRange><audiencerange>☐ if children’s or education product
Block 2
 . . <CollateralDetail><collateraldetail>
Group P.14
 . . . <TextContent><textcontent>
 . . . . <TextType><x426>
 . . . . <ContentAudience><x427>
 . . . . <Text><d104>ideally with XHTML markup
 . . . . <TextAuthor><d107>if text is review or endorsement
 . . . . <ContentDate><contentdate>for embargoes, latest updates
Group P.15
 . . . <CitedContent><citedcontent>
 . . . . <CitedContentType><x430>
 . . . . <ContentAudience><x427>
 . . . . <SourceTitle><x428>
 . . . . <ResourceLink><x435>
 . . . . <ContentDate><contentdate>
Group P.16
 . . . <SupportingResource><supportingresource>
 . . . . <ResourceContentType><x436>
 . . . . <ContentAudience><x427>
 . . . . <ResourceMode><x437>
 . . . . <ResourceFeature><resourcefeature>for captions, credits etc
 . . . . <ResourceVersion><resourceversion>
 . . . . . <ResourceForm><x441>
 . . . . . <ResourceVersionFeature><resourceversionfeature>for file types, pixel sizes, running times etc
 . . . . . <ResourceLink><x435>
 . . . . . <ContentDate><contentdate>for embargoes, latest updates
Group P.17
 . . . <Prize><prize>
 . . . . <PrizeName><g126>
 . . . . <PrizeYear><g127>
 . . . . <PrizeCode><g129>
Block 4
 . . <PublishingDetail><publishingdetail>
Group P.19
 . . . <Imprint><imprint>
 . . . . <ImprintIdentifier><imprintidentifier>if available
 . . . . <ImprintName><b079>
 . . . <Publisher><publisher>
 . . . . <PublishingRole><b291>
 . . . . <PublisherIdentifier><publisheridentifier>if available
 . . . . <PublisherName><b081>
 . . . <CityOfPublication><b209>
 . . . <CountryOfPublication><b083>
Group P.20
 . . . <PublishingStatus><b394>
 . . . <PublishingDate><publishingdate>
Group P.21
 . . . <SalesRights><salesrights>
 . . . . <SalesRightsType><b089>
 . . . . <Territory><territory>
 . . . . <SalesRestriction><salesrestriction>if product is not for general distribution
 . . . <ROWSalesRightsType><x456>
Block 5
 . . <RelatedMaterial><relatedmaterial>
Group P.22
 . . . <RelatedWork><relatedwork>
 . . . . <WorkRelationCode><x454>
 . . . . <WorkIdentifier><workidentifier>even if only proprietary
Group P.23
 . . . <RelatedProduct><relatedproduct>
 . . . . <ProductRelationCode><x455>
 . . . . <ProductIdentifier><productidentifier>
Block 6
 . . <ProductSupply><productsupply>
Group P.24
 . . . <Market><market>unless only a single market
 . . . . <Territory><territory>
 . . . . <SalesRestriction><salesrestriction>
Group P.25
 . . . <MarketPublishingDetail><marketpublishingdetail>unless only a single market
 . . . . <PublisherRepresentative><publisherrepresentative>
 . . . . . <AgentRole><j402>
 . . . . . <AgentIdentifier><agentidentifier>
 . . . . . <AgentName><j401>
 . . . . <MarketPublishingStatus><j407>
 . . . . <MarketDate><marketdate>
Group P.26
 . . . <SupplyDetail><supplydetail>
 . . . . <Supplier><supplier>
 . . . . . <SupplierRole><j292>
 . . . . . <SupplierIdentifier><supplieridentifier>
 . . . . . <SupplierName><j137>
 . . . . . <TelephoneNumber><j270>
 . . . . . <EmailAddress><j272>
 . . . . <ReturnsConditions><returnsconditions>for physical products
 . . . . <ProductAvailability><j396>also include datestamp
 . . . . <SupplyDate><supplydate>
 . . . . <PackQuantity><j145>
 . . . . <UnpricedItemType><j192>or…
 . . . . <Price><price>multiple prices
 . . . . . <PriceType><x463>
 . . . . . <PriceQualifier><j261>if relevant
 . . . . . <DiscountCoded><discountcoded>or…
 . . . . . <Discount><discount>if discounts are relevant
 . . . . . <PriceAmount><j151>
 . . . . . <Tax><tax>if price includes tax
 . . . . . <CurrencyCode><j151>
 . . . . . <Territory><territory>
 . . . . . <PriceDate><pricedate>
 . . . . . <PrintedOnProduct><x301>for physical products

A.3 ONIX codelists and internationalization

Why does ONIX use codelists, where the codes embedded in data files are ‘BB’, ‘BC’, ‘01’, ‘02’ and the like, instead of apparently more understandable controlled vocabulary terms like ‘Hardback’, ‘Paperback’ and so on? ONIX is specifically intended to support a truly global book trade, and uses codes to provide a measure of explicit language-independence. Codelists consist of tables with three main columns:

Sample codelist
code label notes
BA Book  
BB  Hardback  Hardback or cased book.
BC Paperback  Paperback, softback or limp-bound book.
BD Loose-leaf  Loose-leaf book, individual sheets, optionally with updateable binder.
  • each row of the codelist is a concept;
  • the first column is the code or notation for each concept – and it’s this notation that is embedded in the ONIX message data;
  • the second column is a shortish preferred label for each concept – the label is often suitable for display, eg in an application menu or on a web page;
  • the third column is a longer definition or explanatory editorial note or scope note for each concept, in the event that the label is not enough to ensure the concept is defined adequately;
  • some codelists have an implied hierarchical structure, where where some terms are more general and others are more refined concepts – List 150 is a good example, where the code BA (Book) is broader and codes BB, BC, BE (Hardback, Paperback, Spiral bound) are narrower, more specialized terms and thus so could be viewed as ‘children’ or sub-concepts of the broader BA ‘parent’. This is not currently made explicit in ONIX codelists. While List 150 makes the implicit underlying taxonomy more or less visible in the codes, other lists do not.

The concept and its notation are language-independent. Conventionally, the label and notes columns are in English, simply because EDItEUR’s documentation is created in English – but occasionally, a few concepts are labelled in some other language in which they were first expressed (eg Dwarsligger, Sonderausgabe), usually with an English equivalent given in the notes (though in the absence of a clear English equivalent, these terms are sometimes just treated as loanwords). Conceptually at least, there could be many pairs of label and note columns, each pair for a different language. So ‘BB’ is linked to the label ‘Hardback’ in English, but could equally well be linked to ‚Gebundene ausgabe‘ in German or to ‘精装书’ in Chinese – so long as the concept is unchanged, the labelling and notes can be translated into any language. There might also be alternative labels and synonyms within the same language – ‘Hardcover’ is more common than ‘Hardback’ in North American usage, for example, although the words are largely interchangeable. In this way, a message sent from an American publisher to a German or Chinese retailer will contain the code ‘BB’, which specifies the concept expressed as ‘Hardcover’ to the publisher and the identical concept expressed as ‚Gebundene ausgabe‘ or ‘精装书’ to the retailer.

The codelists are published in English, but could be translated into any language, provided the concept expressed by each row is unchanged. Some ONIX National Groups may produce translations of the controlled vocabularies for languages other than English. But the use of the notation – the languge-independent code – in ONIX messages avoids the need to maintain a central public registry of all translations.

A particular IT system may use any labels that are familiar to the users of that system – in English, ‘hardback’, ‘hardcover’, and (in some contexts) ‘cased’ are synonyms, and any synonym could be used in place of the preferred label given in the codelists, providing once again that the concept expressed is unchanged.

As an aside, it’s also worth noting that the codes (the notations) in ONIX are all limited to the basic ASCII character set – as indeed are all other elements of the ONIX syntax such as tag and attribute names – because most other character sets and encodings contain ASCII as a subset and no special care is needed to include ASCII in XML files. This limitation doesn’t apply to the labels or the notes, as they never appear in a message.

Where the terms in lists have an implicit underlying hierarchy, the hierarchical semantic relationships may be made explicit in future.

The internationalization approach for ONIX codelists – and some of the terminology above – is equivalent to that in SKOS (Simple Knowledge Organization System, see https://www.w3.org/2004/02/skos/). The ONIX codelists may be published as a SKOS concept scheme in the future.

A.4 Development and support lifecycle

The status of a particular release of ONIX for Books – say of Release 3.0.2 – follows an orderly development and support lifecycle.

  1. Active development:
    • the schema is under active development, and will be extended or enhanced to deliver new functionality as new business requirements are identified, providing they can be met without introducing incompatibilities with existing implementations of the release;
    • new codes and new codelists will be introduced as necessary. Revisions of the codelists are generally published quarterly, and this is the primary means of adding new functionality to the release;
    • changes to schema and codelists will be discussed with ONIX National Groups, must be approved by the ONIX International Steering Committee – the primary governance body for the standard – and will be fully documented;
    • changes to the schema imply a new minor version or sub-version (also known as a revision), depending on the scope of the additional functionality. Release 3.1 would be a minor version increment after 3.0, whereas 3.0 revision 1 (also known as 3.0.1) is a sub-version increment from 3.0 (more specifically, from 3.0.0). A new minor version would aim to retain a very high degree of forwards and backwards compatibility, but might introduce limited incompatible changes – new mandatory elements or removal of deprecated elements – into the schema where necessary to support new functionality. A new sub-version would always retain full backwards and either full or a very high degree of forwards compatibility, and thus cannot introduce new mandatory elements into the schema or remove elements entirely (though they may be deprecated);
      • for a new sub-version, full backwards and full forwards compatibility means that no additional development work is required of either data suppliers or recipients, unless they wish to support any new optional data elements added to the schema (this forwards compatibility assumes recipients can correctly ignore unknown elements in messages from data suppliers who have implemented the new optional elements in a later sub-version);
      • full compatibility also implies that new sub-versions should not change the interpretation of existing data conforming to the older version, for example by ascribing meaning to the absence of new data elements). This is not always possible where earlier sub-versions are unclear in their specification, and sub-versions may on occasion clarify the interpretation of existing data;
      • new minor versions are not fully back- and forward-compatible, but any breaking changes should be extremely limited in scope;
      • another difference between a minor version and a sub-version is that sub-versions completely replace the equivalent earlier sub-version in all respects, whereas minor versions retain separate identities (ie a minor version is a separate development branch and thus has a separate development and support status). That is, for practical purposes, version 3.0.1 no longer exists after release of 3.0.2, whereas 3.1 (or the latest sub-version such as 3.1.1) would still be maintained after release of 3.2;
      • a new minor version would usually imply the old minor version is moved from ‘active development’ to ‘feature complete’;
    • major new functionality requirements that cannot be met without introducing significant incompatible changes imply a new release and an incremented major version number (ie some future release 4.0 would be a major version increment after 3.x);
  2. Feature complete:
    • the schema will not be extended, whether new requirements can be accommodated or not;
    • however, corrections, bugfixes and minor workarounds will still be developed as necessary;
    • new codes (but generally not new codelists) will be added as necessary. New codelists may be added where they are effectively ‘shared’ with later releases, and the effect of such changes will be taken into account during the development process;
    • the documentation is essentially frozen, but will remain easily available and will be updated to correct errors where necessary;
    • all users are encouraged to migrate to a more recent release;
  3. Legacy (extended use):
    • the schema is frozen, and corrections, bugfixes and minor workarounds will not be developed;
    • new codes and codelists will not be added – except possibly as result of developing later versions that use the same codelists (the effect of such developments on the extended use version will not be taken into particular account during the development process);
    • documentation and any online schemas will be archived, though they may remain available upon request;
    • all users are very strongly advised to migrate to a more recent release;
  4. Obsolete;
    • no support available.

Note that none of these stages are defined by reference to a ‘current’ version of ONIX. At the time of writing, both Release 2.1 and Release 3.0 are ‘current’ in that they are in widespread use, but 2.1 is in the ‘legacy’ phase of the lifecycle. Only ONIX 3.0 is recommended for new developments. No version of ONIX ‘stops working’ at any stage in this process, but the model guides the orderly reduction in EDItEUR support effort for superseded versions and allows implementors to plan and budget for future development.

The ONIX development and support lifecycle is based on the versioned staged maintenance model presented in Software maintenance and evolution: a roadmap, Bennett and Rajlich, Proceedings of the Conference on The Future of Software Engineering, ICSE ’00, (ACM, ISBN 1-58113-253-0, DOI: 10.1145/336512.336534).

A.5 Checklist for establishing a new data feed

Prior to the widespread use of ONIX messages, data suppliers often had to create unique data files – in different formats – for their various supply chain partners. Spreadsheet files, comma- or tab-separated files, with different columns, with the meaning of the data in those columns often ill-defined, and with unstated limitations on what each recipient might be able to use inevitably led to imperfect and costly-to-maintain data exchanges.

ONIX is intended to eliminate this variation (and thus reduce costs), by providing semantic consistency (standardising the nature and meaning of the data to be included in each ‘column’ – each data element) and a standardized syntax (the underlying XML structure). Data suppliers should in principle be able to create a single data output process to feed all their supply chain partners. The Product record for a particular product should not depend on whom that Product record is sent to.

But in real-world use, setting up a data feed with a new partner is not quite a matter of agreeing to use ONIX 3.0 and adding a new delivery address to a list of FTP sites. Partners need to:

  1. agree the selection criteria for records to be included in feed;
    • how far ahead should the scope extend for forthcoming products?
      • around six months is likely to be typical. It is best practice to ensure that all key data is available at least four months prior to publication;
    • should the feed include solely physical print products, should it be e‑book s only, or should it contain both?
      • a more all-encompassing data feed is recommended, as data senders can provide the same data to multiple recipients (thus improving consistency of data across the supply chain) and recipients can filter out unwanted products;
    • should products that the recipient cannot sell be included?
      • trade-only products such as multi-copy packs or point-of-sale material – a data recipient retailer might be able to purchase but not sell these items;
      • products that are exclusive to other retailers, other sales channels or other territories – the data recipient might not be able to purchase or sell these items. In many cases, the need for commercial confidentiality would preclude their inclusion prior to publication, but their inclusion post-publication enables better customer service (or used copy trading). Conversely, are products that are exclusive to the recipient included?
    • should already-obsolete (ie out of print) products be included?
      • for example, to facilitate used book trading or to improve customer service;
  2. agree the overall character set and encoding;
  3. check the method used to embed any markup within certain data elements (XHTML markup, or HTML with either CDATA or escaping);
  4. confirm whether Reference names or Short tags will be used;
  5. agree the file collection/delivery method, for example;
    • ‘push’ or ‘pull’ model (ie use of a server controlled by the recipient, or by the sender);
    • file transfer method (eg FTP, SFTP, FTPS, HTTP, HTTPS…);
    • server address details and account credentials;
    • whether the file will be compressed (‘zipped’) or not;
    • the file naming convention;
  6. agree the supply mode – full feed always, or initial full feed followed by delta files or block-level updates;
    • if delta or block-level updates, is an annual, biannual or quarterly full feed catch-up planned to correct any accumulated errors?
  7. agree the frequency of new messages – as needed, or on a regular intra-day, daily or weekly schedule – and the procedures to be followed when a message is missed or cannot be delivered;
  8. agree whether the ONIX Acknowledgement Message will be used, and whether it would be used simply to confirm message receipt or as part of a more comprehensive query and error reporting message choreography;
  9. agree whether supporting resources such as cover images and sample files will be downloaded by the recipient from a full URI delivered in the ONIX message, or whether a parallel feed of collateral files is required (with a relative URI delivered in the ONIX message). If using a relative URI, agree the base URI to which it is relative;
  10. agree whether ongoing post-publication updates of price and availability will be provided as part of the ONIX data feed, or whether separate price and availability updates will be delivered using another method (eg via an X.12 or EDIFACT PRICAT message);
  11. discuss which data elements will be used by the recipient, and how they will be presented in both internal and consumer-facing contexts (note that this does not imply that the content of the Product record needs to be configured for each recipient, as recipients should simply ignore elements they do not use);
  12. confirm the Codelist issue in use, and the expectations of both sender and recipient when future Codelist updates are issued by EDItEUR. Codelist updates occur typically three or four times per year;
  13. confirm the recipient can comply with Announcement, Embargo, Valid From/To dates, Content audience limitations, display of required credits and other similar limitations or requirements embedded in the ONIX;
  14. confirm whether the recipient imposes any non-standard requirements of their own. Recipients should strenuously avoid imposing any such non-standard limitations, since non-standard messages impose extra costs on the supply chain. But where they are unavoidable – for example because of legacy IT systems – they should be clearly documented, and ideally, a development roadmap or timetable established to eliminate them);
  15. agree whether the implied license to use supplied data is enough, or whether a formal license covering use of the data by the recipient is needed;
    • a formal license is recommended for modification and/or redistribution of the data by the recipient, or where third-party API access to the data is provided by the recipient;
  16. agree whether industry norms regarding timeliness of data delivery from sender, and speed of processing by recipient are enough, or whether a formal service level agreement is required;
    • organizations including BISG and BIC have produced guidelines for service levels within their specific markets which set out expectations for both senders and recipients;
  17. agree procedures for occasional emergency notification of required changes (eg in response to legal or product safety issues).

Beyond this checklist, using ONIX does not remove the need for end-to-end testing. However, the scope of that testing and the likelihood of serious errors is much reduced because – in most cases – the generation of the ONIX message data will not be new as it will have been in use by the sender with other recipients, and the parsing, insertion and update process will be established within the recipient organization because it too will have been in use with other senders.

A.6 Character sets and character encodings

The ONIX Specification lists the basic range of characters that can be incorporated into an ONIX message without any special care. This list comprises the printable ASCII characters – with the exception of the ‘&’ and ‘<’ characters, which must be encoded as ‘&amp;’ and ‘&lt;’ when included in data. (Of course, they are used un-encoded, as ‘&’ and ‘<’, as part of the XML markup.)

Any characters beyond this basic set can be incorporated in ONIX data one of two ways, using either Unicode numerical character references or a suitable message-wide character encoding. Either method enables any character in the full Unicode character set (a repertoire of more than 100,000 characters from all the major writing systems of the world) to be included in ONIX data. (Having said this, the ability to display any of these characters on screen is dependent on the fonts installed on a particular device. Modern operating systems provide broad but not entirely complete font support by default.)

It may be useful to think of a numerical character reference as a way of encoding any one of the Unicode characters beyond the basic set as plain text. The character can be included in ONIX data by encoding it as ‘&#xn;’ where n is the Unicode character number in hexadecimal (in base 16). Effectively, the single Unicode character is encoded into a series of plain text characters – ampersand, hash, the letter x, a series of digits and a semicolon. Alternatively, use ‘&#n;’ where n is the character number in ordinary decimal (base 10).

If numerical character references are a text encoding of Unicode character numbers, a message-wide character encoding is a binary encoding of the same character numbers. Fundamentally, all text is stored as a series of numbers. Each Unicode character has a 32-digit binary number, and the most basic encoding is simply to use that number. But this means that plain text files become very large, each character using four bytes rather than just one or two. UTF‑16 and UTF‑8 are mathematical ways of encoding the same numbers so that the most common characters take only two or even just a single byte. Some more rarely used characters require more than two bytes – the -8 and -16 refer to the minimum number of bits used).

encodings of the characters ‘é’, ‘ž’ and ‘д’
desired character in metadata é ž д
 
numerical character referencetext in file
decimal&#233;&#382;&#1076;
hexadecimal&#xe9;&#x17e;&#x434;
 
binary encodingbinary data in file (in hexadecimal)
UTF-8c3 a9c5 bed0 b4
UTF-16LEe9 007e 0134 04
UTF-16BE00 e901 7e04 34
Latin-1 (ISO 8859-1)e9— ¹
Latin-9 (ISO 8859-15)e9b8
Windows-1251e4
Windows-1252e99e
MacRoman8e
 
named character entitytext in file
(not valid in ONIX 3.0, used in 2.1)&eacute;&zcaron;&dcy;

¹ dash indicates the character cannot be represented in this encoding – but it can still be included in ONIX data using a numerical character reference

UTF‑8 and UTF‑16 are encodings that allow any Unicode character number to be encoded. Most modern operating systems and programming frameworks use one or the other by default, and UTF‑8 is the preferred encoding for ONIX, particularly for messages exchanged internationally. In contrast, Latin‑1, Windows‑1252 and MacRoman are common legacy encodings that can only encode a small, Latin-focused subset of the Unicode character repertoire. So while each of the three can encode the ‘é’ character, the character ‘ž’ cannot be encoded using Latin‑1 – it is not included in the Latin‑1 repertoire subset – and none can encode the (Cyrillic) letter ‘д’. Latin‑9, an update of Latin‑1, can encode ‘ž’. And in contrast, Windows‑1251 – a Cyrillic-focused subset – can encode ‘д’, but not ‘é’ or ‘ž’.

If you choose an encoding other than UTF‑8 or UTF‑16, there are inevitably a large number of characters that cannot be encoded, simply because the character is not included in the subset available. But you can still include that character in ONIX data using the numerical character reference.

This illustrates the difference between a character set and a character encoding. The difference is clear-cut with Unicode (a character set, or repertoire) and UTF‑8 (a way of encoding the characters in that set as sequences of numbers), and more blurred with Latin‑1 or Windows‑1252, which define both a limited character set and a way of encoding that set of characters as numbers.

The relatively small repertoire of around 200 Latin script characters available in Windows‑1252 or Latin‑1 makes them more or less suitable for text in most Western European languages. But they are unsuitable for many other languages which use the Latin script as they require characters outside the limited repertoire, and cannot be used for languages that use other scripts (Cyrillic, Arabic etc). There are many other encodings tailored for other languages and scripts, each in effect enabling the use of a different subset of the full Unicode repertoire.

The fact that a single character like ‘é’ can be encoded in different ways means that unless the encoding is known, a character can be misinterpreted. A ‘ž’ character stored as the hexadecimal number e9 using the Windows‑1252 encoding, then read as if it were using the MacRoman encoding would be misinterpreted as ‘û’, since ‘û’ is stored as hex e9 in MacRoman. And the same e9 would cause an error if read as if it were Latin‑1 or UTF‑8, because e9 doesn’t represent any character in those encodings. Naturally, text can be read (with the correct encoding) then converted to a different encoding, but only if the repertoire of characters in the text is limited and includes only characters that are within the repertoire of the new encoding – a single ‘ž’ in the text would prevent conversion to Latin‑1 (though some software might silently substitute ‘z’ and allow conversion to go ahead). So software developers need to be aware how their applications encode textual data, and applications should control both the repertoire of characters used and the encoding used to store the data. This control needs to be maintained end-to-end, from the application used to create, store and manage the data, through the ONIX message itself, to the application or website used by the eventual data recipient.

An XML message can contain an encoding declaration to ensure the recipient of the data can interpret the content correctly, so an application that uses the Windows‑1252 encoding must include the following declaration in any ONIX message:

<?xml version="1.0" encoding="Windows-1252"?>

The recipient can then ensure text characters in the data are interpreted correctly, or perform a controlled conversion to another encoding if necessary.

If no encoding is declared, the default is UTF‑8 or UTF‑16 (XML software should make an automatic choice). However, it is best practice to declare the encoding, even if it is UTF‑8 or UTF‑16. And because UTF‑16 comes in two distinct flavors – UTF‑16BE and UTF‑16LE – you should declare which one it is (and you should omit any ‘byte order mark’).

Unicode text – whether encoded as UTF‑8, UTF‑16 or whatever – can be coded using one of four ‘normalization’ forms. Normalization concerns whether the character é is encoded as a single character é, or as two characters, e followed by ´ (the acute accent). Diacritics and other so-called ‘combining characters’ can be ‘precomposed’ (combined with the character they modify, like é), or decomposed (supplied as a separate character, like e followed by ´). It also concerns whether characters like fi (the fi ligature ¹) can be used, or whether it is decomposed into its separate f and i characters. These two choices give the four possible normalization forms.

Data recipients should not rely on Unicode text being supplied in any particular normalization form, though typically it will be supplied in NFC (where é and fi are single characters) – and NFC is the recommended normalization form for data senders. However, recipients may wish to create an NFKC copy of text internally within their database to improve text matching in searches (NFKC is usually viewed as the best choice for string handling in databases), while displaying the NFC form.

¹ The difference between fi and fi may not be apparent, but the first is a single character – on-screen, try selecting just the f…

A.7 Reference list of allowed HTML / XHTML tags

The ONIX 3.0 Specification defines a range of XHTML tags that can be used within certain textual data elements with the textformat attribute (use textformat="05"). These do not need any special treatment (eg embedding within CDATA tags), and their structure will be validated by the ONIX 3.0 DTD, XSD and RNG schemas. However, while the Specification allows a long list of XHTML tags, it is strongly recommended that XHTML markup is limited to a simple subset of tags.

The same textual data elements can also contain HTML tags (use textformat="02"). These require special treatment to prevent them making the overall ONIX file invalid – either the use of CDATA or replacement of the < character in HTML markup with &lt;. CDATA is preferred. Note that the structure of the HTML tags will not be validated – since HTML is not XML, it cannot be validated, and the whole point of CDATA or of escaping the < character is to ‘hide’ the non-XML markup from the validation process. However, it is strongly recommended that any HTML markup be limited to the same simple subset of tags.

Recommended
It is strongly recommended that HTML and XHTML tags are limited to this small set
paragraphs and line breaks<p><br />
emphasis / book titles<strong><em><b><i><cite>
bulleted and numbered lists<ul><ol><li>
sub- and superscript<sub><sup>
definition lists<dl><dt><dd>
simple glosses<ruby><rb><rp><rt>

The ‘outermost’ HTML / XHTML tags within an ONIX element that accepts HTML / XHTML should be ‘block-level‘ tags. Of the recommended tags, only <p> and the three list tags <ul>, <ol> and <dl> are block level. So, of these four:

<Text textformat="05">This is <strong>incorrect</strong>, as there are no outermost tags.</Text>
<Text textformat="05"><li>This is <strong>incorrect​</strong>, as the outermost tags are not block level.</li></Text>
<Text textformat="05"><p>This is <strong>correct</strong>.</p></Text>
<Text textformat="05"><p>This is <strong>correct</strong>.</p><ul><li>And so is this.</li></ul></Text>

only the third and fourth examples are correct. The first has no ‘outermost’ XHTML tags, and the outermost tags in the second example are not block-level tags. As shown in the last example, the marked-up text does not have to be enclosed within in a single block-level XHTML or HTML element. A mix of block-level tags meets the requirements.

Note that ONIX ruby support is based on the structure of XHTML 1.1;

  • ruby tags are not valid in XHTML 1.0, but modern browsers will cope with them;
  • ONIX does not support the full HTML5 <ruby> syntax. The <rb> tag is not part of HTML5 or XHTML5, but is required in ONIX and in practice, modern browsers will cope with it. HTML5 also allows multiple <rt> elements within a single <ruby> element, but this is invalid in ONIX.

Note also that <cite> has been included in this recommended subset of HTML because of its importance in highlighting book titles within descriptions, biographies etc.

Allowed
These tags are allowed in ONIX 3.0, but not recommended
<h1><h2><h3><h4><h5><h6>
<table><caption><thead><tbody><tfoot>
<tr><th><td><colgroup><col>
<div><span><blockquote><pre>
<address><dfn><abbr><q><small>
<samp><code><kbd><var>
<a><img><map><area><bdo><hr />

HTML attributes such as style should be avoided.

Only <h1> to <h6>, <div>, <table>, <address>, <blockquote>, <pre> and <hr> are block-level elements.

These tags are also allowed, but not recommended
<acronym><big><tt>
<rbc><rtc>

They cannot be used by recipients using HTML5 / XHTML5. None are block-level.

Not allowed
These tags are not allowed
<menu><dir><isindex>
<basefont><rfont>
<strike><u><s><center>
<iframe><noframes>

Although they are part of HTML 4.01 and XHTML 1.0 and 1.1 Transitional, they are excluded from XHTML 1.0 and 1.1 Strict on which the ONIX subset is based.

These tags are not allowed
<html><head><body>
<title><base><meta><link><style>
<script><noscript><object><param><applet>
<form><label><input><select><optgroup><option>
<textarea><fieldset><legend><button>
<ins><del>

They are excluded by the ONIX prohibitions on tags that may not appear within <body>, tags for embedded objects, forms, scripting and document revision.

These tags are not allowed, as they are not part of HTML 4.01 or XHTML 1.1
<header><footer><nav><section><article><aside>
<details><summary>
<figure><figcaption><meter><progress>
<time><wbr><mark><bdi>
<canvas><audio><video><source><embed><track>
<datalist><keygen><output><command><dialog>

These tags are valid only in HTML5 / XHTML5.

A.8 Reference list of integer / real number data elements

Prior to the release of ONIX 3.0 revision 3 in April 2016, the Specification did not explicitly define numeric data elements as real or integer values. However, there are common-sense limitations – you cannot have a negative number of illustrations, a non-integer number of copies in stock or a map scale of zero – and the XML schema implemented stricter checks on numeric values as listed. These limitations are made explicit from the ONIX 3.0.3 Specification.

Integers
Positive integer (1, 2, 3…)
<BatchQuantity> <MinimumOrderQuantity>
<ConferenceNumber> <NumberOfCopies>
<EditionNumber> <NumberOfItemsOfThisForm>
<EventNumber> <NumberOfPages>
<FreeQuantity> <OrderQuantityMinimum>
<LatestReprintNumber> <OrderQuantityMultiple>
<MapScale> <PackQuantity>
<MessageNumber> <PositionOnList>
<MessageRepeat> <SequenceNumber>
Positive integer or zero (0, 1, 2, 3…)
<CBO> <OrderTime>
<Number> <RatingLimit>
<NumberOfIllustrations> <Reserved>
<OnOrder>
Integer (…−3, −2, −1, 0, 1, 2, 3…)
<OnHand> <Rate>
Real numbers
Positive decimal (> 0)
<ExtentValue> <PriceAmount>
<Measurement> <TaxableAmount>
Positive decimal or zero (≥ 0)
<DiscountAmount> <TaxAmount>
<Quantity> <ToQuantity>
<Rating>
Percent decimal (≥ 0 and ≤ 100)
<DiscountPercent> <TaxRatePercent>
<Percent>

A.9 Reference list of empty data elements

In general, ONIX XML elements must contain either data or other XML elements – empty elements are not allowed, and if required data is missing, then the element itself should be omitted entirely. In some cases, this means omitting an entire composite, if one of its required constituent elements has to be omitted.

However, there are a small number of data elements that must be empty – they act as logical ‘flags’ or as placeholders instead of some required data, and must not contain any data of their own:

  • <NoProduct/>
  • <NoCollection/>
  • <NoContributor/>
  • <NoEdition/>
  • <NoPrefix/>
  • <MainSubject/>
  • <PrimaryPart/>
  • <TaxExempt/>

In addition, the following three blocks may be empty (in block updates only):

  • <CollateralDetail/>
  • <ContentDetail/>
  • <RelatedMaterial/>

(In full records, an empty block must be omitted entirely.)

A.10 Reference list of XPaths for ONIX XML tags

This is a list of XPaths that can be used to select the content of each ONIX XML tag.

However, some XPaths still select multiple repeats of a data element or composite within a single context, and would need an additional XPath predicate to select a single instance of that element or composite. For example, the XPath for the <Date> element within the <PublishingDate> composite is /ONIXMessage/​Product/​PublishingDetail/​PublishingDate/Date, but multiple repeats of the composite can carry several different types of date – for example the publication date, sales embargo date, out-of-print date and so on, as indicated by the Publishing date role. To select specifically the date of publication, the predicated path /ONIXMessage/​Product/​PublishingDetail/​PublishingDate[PublishingDateRole eq '01']/​Date is required. Further processing based on the date format in the dateformat attribute or the deprecated <Dateformat> data element may also be required. Similarly, the XPath /ONIXMessage/​Product/​DescriptiveDetail/​Contributor may select multiple contributors. The path to select the ISNI of the second contributor (assuming it is present, and using the sequence number rather than the order of data elements in the XML file) would have a predicate to select a single contributor and another to pick out the ISNI from (potentially) multiple identifiers: /ONIXMessage/​Product/​DescriptiveDetail/​Contributor[number(SequenceNumber) eq 2]/​NameIdentifier[NameIDType eq '16']/​IDValue.

A handful of XPaths already contain predicates, which are necessary in order to select the correct data element. These are highlighted in blue in the table. Red text indicates deprecated elements.

XPaths for use in XML toolkits
#Reference nameXPath
<ONIXMessage>/ONIXMessage
. <Header>/ONIXMessage/​Header
. . <Sender>/ONIXMessage/​Header/​Sender
. . . <SenderIdentifier>/ONIXMessage/​Header/​Sender/​SenderIdentifier
H.1. . . . <SenderIDType>/ONIXMessage/​Header/​Sender/​SenderIdentifier/​SenderIDType
H.2. . . . <IDTypeName>/ONIXMessage/​Header/​Sender/​SenderIdentifier/​IDTypeName
H.3. . . . <IDValue>/ONIXMessage/​Header/​Sender/​SenderIdentifier/​IDValue
H.4. . . <SenderName>/ONIXMessage/​Header/​Sender/​SenderName
H.5. . . <ContactName>/ONIXMessage/​Header/​Sender/​ContactName
H.6. . . <EmailAddress>/ONIXMessage/​Header/​Sender/​EmailAddress
. . <Addressee>/ONIXMessage/​Header/​Addressee
. . . <AddresseeIdentifier>/ONIXMessage/​Header/​Addressee/​AddresseeIdentifier
H.7. . . . <AddresseeIDType>/ONIXMessage/​Header/​Addressee/​AddresseeIdentifier/​AddresseeIDType
H.8. . . . <IDTypeName>/ONIXMessage/​Header/​Addressee/​AddresseeIdentifier/​IDTypeName
H.9. . . . <IDValue>/ONIXMessage/​Header/​Addressee/​AddresseeIdentifier/​IDValue
H.10. . . <AddresseeName>/ONIXMessage/​Header/​Addressee/​AddresseeName
H.11. . . <ContactName>/ONIXMessage/​Header/​Addressee/​ContactName
H.12. . . <EmailAddress>/ONIXMessage/​Header/​Addressee/​EmailAddress
H.13. . <MessageNumber>/ONIXMessage/​Header/​MessageNumber
H.14. . <MessageRepeat>/ONIXMessage/​Header/​MessageRepeat
H.15. . <SentDateTime>/ONIXMessage/​Header/​SentDateTime
H.16. . <MessageNote>/ONIXMessage/​Header/​MessageNote
H.17. . <DefaultLanguageOfText>/ONIXMessage/​Header/​DefaultLanguageOfText
H.18. . <DefaultPriceType>/ONIXMessage/​Header/​DefaultPriceType
H.19. . <DefaultCurrencyCode>/ONIXMessage/​Header/​DefaultCurrencyCode
. <Product>/ONIXMessage/​Product
P.1.1. . <RecordReference>/ONIXMessage/​Product/​RecordReference
P.1.2. . <NotificationType>/ONIXMessage/​Product/​NotificationType
P.1.3. . <DeletionText>/ONIXMessage/​Product/​DeletionText
P.1.4. . <RecordSourceType>/ONIXMessage/​Product/​RecordSourceType
. . <RecordSourceIdentifier>/ONIXMessage/​Product/​RecordSourceIdentifier
P.1.5. . . <RecordSourceIDType>/ONIXMessage/​Product/​RecordSourceIdentifier/​RecordSourceIDType
P.1.6. . . <IDTypeName>/ONIXMessage/​Product/​RecordSourceIdentifier/​IDTypeName
P.1.7. . . <IDValue>/ONIXMessage/​Product/​RecordSourceIdentifier/​IDValue
P.1.8. . <RecordSourceName>/ONIXMessage/​Product/​RecordSourceName
. . <ProductIdentifier>/ONIXMessage/​Product/​ProductIdentifier
P.2.1. . . <ProductIDType>/ONIXMessage/​Product/​ProductIdentifier/​ProductIDType
P.2.2. . . <IDTypeName>/ONIXMessage/​Product/​ProductIdentifier/​IDTypeName
P.2.3. . . <IDValue>/ONIXMessage/​Product/​ProductIdentifier/​IDValue
. . <Barcode>/ONIXMessage/​Product/​Barcode
P.2.4. . . <BarcodeType>/ONIXMessage/​Product/​Barcode/​BarcodeType
P.2.5. . . <PositionOnProduct>/ONIXMessage/​Product/​Barcode/​PositionOnProduct
. . <DescriptiveDetail>/ONIXMessage/​Product/​DescriptiveDetail
P.3.1. . . <ProductComposition>/ONIXMessage/​Product/​DescriptiveDetail/​ProductComposition
P.3.2. . . <ProductForm>/ONIXMessage/​Product/​DescriptiveDetail/​ProductForm
P.3.3. . . <ProductFormDetail>/ONIXMessage/​Product/​DescriptiveDetail/​ProductFormDetail
. . . <ProductFormFeature>/ONIXMessage/​Product/​DescriptiveDetail/​ProductFormFeature
P.3.4. . . . <ProductFormFeatureType>/ONIXMessage/​Product/​DescriptiveDetail/​ProductFormFeature/​ProductFormFeatureType
P.3.5. . . . <ProductFormFeatureValue>/ONIXMessage/​Product/​DescriptiveDetail/​ProductFormFeature/​ProductFormFeatureValue
P.3.6. . . . <ProductFormFeatureDescription>/ONIXMessage/​Product/​DescriptiveDetail/​ProductFormFeature/​ProductFormFeatureDescription
P.3.7. . . <ProductPackaging>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPackaging
P.3.8. . . <ProductFormDescription>/ONIXMessage/​Product/​DescriptiveDetail/​ProductFormDescription
P.3.9. . . <TradeCategory>/ONIXMessage/​Product/​DescriptiveDetail/​TradeCategory
P.3.10. . . <PrimaryContentType>/ONIXMessage/​Product/​DescriptiveDetail/​PrimaryContentType
P.3.11. . . <ProductContentType>/ONIXMessage/​Product/​DescriptiveDetail/​ProductContentType
. . . <Measure>/ONIXMessage/​Product/​DescriptiveDetail/​Measure
P.3.12. . . . <MeasureType>/ONIXMessage/​Product/​DescriptiveDetail/​Measure/​MeasureType
P.3.13. . . . <Measurement>/ONIXMessage/​Product/​DescriptiveDetail/​Measure/​Measurement
P.3.14. . . . <MeasureUnitCode>/ONIXMessage/​Product/​DescriptiveDetail/​Measure/​MeasureUnitCode
P.3.15. . . <CountryOfManufacture>/ONIXMessage/​Product/​DescriptiveDetail/​CountryOfManufacture
P.3.16. . . <EpubTechnicalProtection>/ONIXMessage/​Product/​DescriptiveDetail/​EpubTechnicalProtection
. . . <EpubUsageConstraint>/ONIXMessage/​Product/​DescriptiveDetail/​EpubUsageConstraint
P.3.17. . . . <EpubUsageType>/ONIXMessage/​Product/​DescriptiveDetail/​EpubUsageConstraint/​EpubUsageType
P.3.18. . . . <EpubUsageStatus>/ONIXMessage/​Product/​DescriptiveDetail/​EpubUsageConstraint/​EpubUsageStatus
. . . . <EpubUsageLimit>/ONIXMessage/​Product/​DescriptiveDetail/​EpubUsageConstraint/​EpubUsageLimit
P.3.19. . . . . <Quantity>/ONIXMessage/​Product/​DescriptiveDetail/​EpubUsageConstraint/​EpubUsageLimit/​Quantity
P.3.20. . . . . <EpubUsageUnit>/ONIXMessage/​Product/​DescriptiveDetail/​EpubUsageConstraint/​EpubUsageLimit/​EpubUsageUnit
. . . <EpubLicense>/ONIXMessage/​Product/​DescriptiveDetail/​EpubLicense
P.3.20a. . . . <EpubLicenseName>/ONIXMessage/​Product/​DescriptiveDetail/​EpubLicense/​EpubLicenseName
. . . . <EpubLicenseExpression>/ONIXMessage/​Product/​DescriptiveDetail/​EpubLicense/​EpubLicenseExpression
P.3.20b. . . . . <EpubLicenseExpressionType>/ONIXMessage/​Product/​DescriptiveDetail/​EpubLicense/​EpubLicenseExpression/​EpubLicenseExpressionType
P.3.20c. . . . . <EpubLicenseExpressionTypeName>/ONIXMessage/​Product/​DescriptiveDetail/​EpubLicense/​EpubLicenseExpression/​EpubLicenseExpressionTypeName
P.3.20d. . . . . <EpubLicenseExpressionLink>/ONIXMessage/​Product/​DescriptiveDetail/​EpubLicense/​EpubLicenseExpression/​EpubLicenseExpressionLink
P.3.21. . . <MapScale>/ONIXMessage/​Product/​DescriptiveDetail/​MapScale
. . . <ProductClassification>/ONIXMessage/​Product/​DescriptiveDetail/​ProductClassification
P.3.22. . . . <ProductClassificationType>/ONIXMessage/​Product/​DescriptiveDetail/​ProductClassification/​ProductClassificationType
P.3.23. . . . <ProductClassificationCode>/ONIXMessage/​Product/​DescriptiveDetail/​ProductClassification/​ProductClassificationCode
P.3.24. . . . <Percent>/ONIXMessage/​Product/​DescriptiveDetail/​ProductClassification/​Percent
. . . <ProductPart>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart
P.4.1. . . . <PrimaryPart>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​PrimaryPart
. . . . <ProductIdentifier>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​ProductIdentifier
P.4.2. . . . . <ProductIDType>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​ProductIdentifier/​ProxuctIDType
P.4.3. . . . . <IDTypeName>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​ProductIdentifier/​IDTypeName
P.4.4. . . . . <IDValue>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​ProductIdentifier/​IDValue
P.4.5. . . . <ProductForm>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​ProductForm
P.4.6. . . . <ProductFormDetail>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​ProductFormDetail
. . . . <ProductFormFeature>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​ProductFormFeature
P.4.7. . . . . <ProductFormFeatureType>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​ProductFormFeature/​ProductFormFeatureType
P.4.8. . . . . <ProductFormFeatureValue>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​ProductFormFeature/​ProductFormFeatureValue
P.4.9. . . . . <ProductFormFeatureDescription>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​ProductFormFeature/​ProductFormFeatureDescription
P.4.9a. . . . <ProductPackaging>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​ProductPackaging
P.4.10. . . . <ProductFormDescription>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​ProductFormDescription
P.4.11. . . . <ProductContentType>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​ProductContentType
P.4.12. . . . <NumberOfItemsOfThisForm>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​NumberOfItemsOfThisForm
P.4.13. . . . <NumberOfCopies>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​NumberOfCopies
P.4.14. . . . <CountryOfManufacture>/ONIXMessage/​Product/​DescriptiveDetail/​ProductPart/​CountryOfManufacture
. . . <Collection>/ONIXMessage/​Product/​DescriptiveDetail/​Collection
P.5.1. . . . <CollectionType>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​CollectionType
P.5.2. . . . <SourceName>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​SourceName
. . . . <CollectionIdentifier>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​CollectionIdentifier
P.5.3. . . . . <CollectionIDType>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​CollectionIdentifier/​CollectionIDType
P.5.4. . . . . <IDTypeName>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​CollectionIdentifier/​IDTypeName
P.5.5. . . . . <IDValue>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​CollectionIdentifier/​IDValue
. . . . <CollectionSequence>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​CollectionSequence
P.5.5a. . . . . <CollectionSequenceType>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​CollectionSequence/​CollectionSequenceType
P.5.5b. . . . . <CollectionSequenceTypeName>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​CollectionSequence/​CollectionSequenceTypeName
P.5.5c. . . . . <CollectionSequenceNumber>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​CollectionSequence/​CollectionSequenceNumber
. . . . <TitleDetail>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​TitleDetail
P.5.6. . . . . <TitleType>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​TitleDetail/​TitleType
. . . . . <TitleElement>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​TitleDetail/​TitleElement
P.5.6a. . . . . . <SequenceNumber>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​TitleDetail/​TitleElement/​SequenceNumber
P.5.7. . . . . . <TitleElementLevel>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​TitleDetail/​TitleElement/​TitleElementLevel
P.5.8. . . . . . <PartNumber>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​TitleDetail/​TitleElement/​PartNumber
P.5.9. . . . . . <YearOfAnnual>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​TitleDetail/​TitleElement/​YearOfAnnual
P.5.10. . . . . . <TitleText>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​TitleDetail/​TitleElement/​TitleText
P.5.11. . . . . . <TitlePrefix>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​TitleDetail/​TitleElement/​TitlePrefix
P.5.11a. . . . . . <NoPrefix/>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​TitleDetail/​TitleElement/​NoPrefix
P.5.12. . . . . . <TitleWithoutPrefix>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​TitleDetail/​TitleElement/​TitleWithoutPrefix
P.5.13. . . . . . <Subtitle>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​TitleDetail/​TitleElement/​Subtitle
P.5.13a. . . . . <TitleStatement>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​TitleDetail/​TitleStatement
. . . . <Contributor>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor
P.5.14. . . . . <SequenceNumber>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​SequenceNumber
P.5.15. . . . . <ContributorRole>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​ContributorRole
P.5.16. . . . . <FromLanguage>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​FromLanguage
P.5.17. . . . . <ToLanguage>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​ToLanguage
P.5.18. . . . . <NameType>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​NameType
. . . . . <NameIdentifier>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​NameIdentifier
P.5.19. . . . . . <NameIDType>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​NameIdentifier/​NameIDType
P.5.20. . . . . . <IDTypeName>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​NameIdentifier/​IDTypeName
P.5.21. . . . . . <IDValue>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​NameIdentifier/​IDValue
P.5.22. . . . . <PersonName>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​PersonName
P.5.23. . . . . <PersonNameInverted>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​PersonNameInverted
P.5.24. . . . . <TitlesBeforeNames>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​TitlesBeforeNames
P.5.25. . . . . <NamesBeforeKey>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​NamesBeforeKey
P.5.26. . . . . <PrefixToKey>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​PrefixToKey
P.5.27. . . . . <KeyNames>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​KeyNames
P.5.28. . . . . <NamesAfterKey>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​NamesAfterKey
P.5.29. . . . . <SuffixToKey>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​SuffixToKey
P.5.30. . . . . <LettersAfterNames>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​LettersAfterNames
P.5.31. . . . . <TitlesAfterNames>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​TitlesAfterNames
P.5.31a. . . . . <Gender>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​Gender
P.5.32. . . . . <CorporateName>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​CorporateName
P.5.33. . . . . <CorporateNameInverted>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​CorporateNameInverted
P.5.33a. . . . . <UnnamedPersons>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​UnnamedPersons[not(exists(​preceding‑sibling::ContributorDate|​preceding‑sibling::ProfessionalAffiliation|​preceding‑sibling::Prize|​preceding‑sibling::BiographicalNote|​preceding‑sibling::Website|​preceding‑sibling::ContributorDescription|​preceding‑sibling::ContributorPlace​))​]
. . . . . <AlternativeName>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName
P.5.34. . . . . . <NameType>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​NameType
. . . . . . <NameIdentifier>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​NameIdentifier
P.5.35. . . . . . . <NameIDType>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​NameIdentifier/​NameIDType
P.5.36. . . . . . . <IDTypeName>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​NameIdentifier/​IDTypeName
P.5.37. . . . . . . <IDValue>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​NameIdentifier/​IDValue
P.5.38. . . . . . <PersonName>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​PersonName
P.5.39. . . . . . <PersonNameInverted>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​PersonNameInverted
P.5.40. . . . . . <TitlesBeforeNames>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​TitlesBeforeNames
P.5.41. . . . . . <NamesBeforeKey>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​NamesBeforeKey
P.5.42. . . . . . <PrefixToKey>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​PrefixToKey
P.5.43. . . . . . <KeyNames>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​KeyNames
P.5.44. . . . . . <NamesAfterKey>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​NamesAfterKey
P.5.45. . . . . . <SuffixToKey>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​SuffixToKey
P.5.46. . . . . . <LettersAfterNames>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​LettersAfterNames
P.5.47. . . . . . <TitlesAfterNames>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​TitlesAfterNames
P.5.47a. . . . . . <Gender>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​Gender
P.5.48. . . . . . <CorporateName>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​CorporateName
P.5.49. . . . . . <CorporateNameInverted>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​AlternativeName/​CorporateNameInverted
. . . . . <ContributorDate>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​ContributorDate
P.5.50. . . . . . <ContributorDateRole>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​ContributorDate/​ContributorDateRole
P.5.51. . . . . . <DateFormat>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​ContributorDate/​DateFormat
P.5.52. . . . . . <Date>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​ContributorDate/​Date
. . . . . <ProfessionalAffiliation>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​ProfessionalAffiliation
P.5.53. . . . . . <ProfessionalPosition>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​ProfessionalAffiliation/​ProfessionalPosition
P.5.54. . . . . . <Affiliation>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​ProfessionalAffiliation/​Affiliation
. . . . . <Prize>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​Prize
P.5.54a. . . . . . <PrizeName>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​Prize/​PrizeName
P.5.54b. . . . . . <PrizeYear>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​Prize/​PrizeYear
P.5.54c. . . . . . <PrizeCountry>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​Prize/​PrizeCountry
P.5.54d. . . . . . <PrizeCode>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​Prize/​PrizeCode
P.5.54e. . . . . . <PrizeStatement>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​Prize/​PrizeStatement
P.5.54f. . . . . . <PrizeJury>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​Prize/​PrizeJury
P.5.55. . . . . <BiographicalNote>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​BiographicalNote
. . . . . <Website>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​Website
P.5.56. . . . . . <WebsiteRole>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​Website/​WebsiteRole
P.5.57. . . . . . <WebsiteDescription>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​Website/​WebsiteDescription
P.5.58. . . . . . <WebsiteLink>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​Website/​WebsiteLink
P.5.59. . . . . <ContributorDescription>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​ContributorDescription
P.5.60. . . . . <UnnamedPersons>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​UnnamedPersons[exists(​preceding‑sibling::ContributorDate|​preceding‑sibling::ProfessionalAffiliation|​preceding‑sibling::Prize|​preceding‑sibling::BiographicalNote|​preceding‑sibling::Website|​preceding‑sibling::ContributorDescription|​preceding‑sibling::ContributorPlace​)]
. . . . . <ContributorPlace>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​ContributorPlace
P.5.61. . . . . . <ContributorPlaceRelator>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​ContributorPlace/​ContributorPlaceRelator
P.5.62. . . . . . <CountryCode>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​ContributorPlace/​CountryCode
P.5.63. . . . . . <RegionCode>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​ContributorPlace/​RegionCode
P.5.63a. . . . . . <LocationName>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​ContributorPlace/​LocationName
P.5.63b. . . . <ContributorStatement>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​Contributor/​ContributorStatement
P.5.63c. . . . <NoContributor/>/ONIXMessage/​Product/​DescriptiveDetail/​Collection/​NoContributor
P.5.64. . . <NoCollection/>/ONIXMessage/​Product/​DescriptiveDetail/​NoCollection
. . . <TitleDetail>/ONIXMessage/​Product/​DescriptiveDetail/​TitleDetail
P.6.1. . . . <TitleType>/ONIXMessage/​Product/​DescriptiveDetail/​TitleDetail/​TitleType
. . . . <TitleElement>/ONIXMessage/​Product/​DescriptiveDetail/​TitleDetail/​TitleElement
P.6.1a. . . . . <SequenceNumber>/ONIXMessage/​Product/​DescriptiveDetail/​TitleDetail/​TitleElement/​SequenceNumber
P.6.2. . . . . <TitleElementLevel>/ONIXMessage/​Product/​DescriptiveDetail/​TitleDetail/​TitleElement/​TitleElementLevel
P.6.3. . . . . <PartNumber>/ONIXMessage/​Product/​DescriptiveDetail/​TitleDetail/​TitleElement/​PartNumber
P.6.4. . . . . <YearOfAnnual>/ONIXMessage/​Product/​DescriptiveDetail/​TitleDetail/​TitleElement/​YearOfAnnual
P.6.5. . . . . <TitleText>/ONIXMessage/​Product/​DescriptiveDetail/​TitleDetail/​TitleElement/​TitleText
P.6.6. . . . . <TitlePrefix>/ONIXMessage/​Product/​DescriptiveDetail/​TitleDetail/​TitleElement/​TitlePrefix
P.6.6a. . . . . <NoPrefix/>/ONIXMessage/​Product/​DescriptiveDetail/​TitleDetail/​TitleElement/​NoPrefix
P.6.7. . . . . <TitleWithoutPrefix>/ONIXMessage/​Product/​DescriptiveDetail/​TitleDetail/​TitleElement/​TitleWithoutPrefix
P.6.8. . . . . <Subtitle>/ONIXMessage/​Product/​DescriptiveDetail/​TitleDetail/​TitleElement/​Subtitle
P.6.8a. . . . <TitleStatement>/ONIXMessage/​Product/​DescriptiveDetail/​TitleDetail/​TitleStatement
P.6.9. . . <ThesisType>/ONIXMessage/​Product/​DescriptiveDetail/​ThesisType
P.6.10. . . <ThesisPresentedTo>/ONIXMessage/​Product/​DescriptiveDetail/​ThesisPresentedTo
P.6.11. . . <ThesisYear>/ONIXMessage/​Product/​DescriptiveDetail/​ThesisYear
. . . <Contributor>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor
P.7.1. . . . <SequenceNumber>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​SequenceNumber
P.7.2. . . . <ContributorRole>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​ContributorRole
P.7.3. . . . <FromLanguage>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​FromLanguage
P.7.4. . . . <ToLanguage>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​ToLanguage
P.7.5. . . . <NameType>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​NameType
. . . . <NameIdentifier>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​NameIdentifier
P.7.6. . . . . <NameIDType>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​NameIdentifier/​NameIDType
P.7.7. . . . . <IDTypeName>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​NameIdentifier/​IDTypeName
P.7.8. . . . . <IDValue>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​NameIdentifier/​IDValue
P.7.9. . . . <PersonName>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​PersonName
P.7.10. . . . <Person​NameInverted>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​PersonNameInverted
P.7.11. . . . <TitlesBeforeNames>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​TitlesBeforeNames
P.7.12. . . . <NamesBeforeKey>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​NamesBeforeKey
P.7.13. . . . <PrefixToKey>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​PrefixToKey
P.7.14. . . . <KeyNames>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​KeyNames
P.7.15. . . . <NamesAfterKey>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​NamesAfterKey
P.7.16. . . . <SuffixToKey>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​SuffixToKey
P.7.17. . . . <LettersAfterNames>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​LettersAfterNames
P.7.18. . . . <TitlesAfterNames>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​TitlesAfterNames
P.7.18a. . . . <Gender>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​Gender
P.7.19. . . . <CorporateName>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​CorporateName
P.7.20. . . . <Corporate​NameInverted>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​CorporateNameInverted
P.7.20a. . . . <UnnamedPersons>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​UnnamedPersons[not(exists(​preceding‑sibling::ContributorDate|​preceding‑sibling::ProfessionalAffiliation|​preceding‑sibling::Prize|​preceding‑sibling::BiographicalNote|​preceding‑sibling::Website|​preceding‑sibling::ContributorDescription​|​preceding‑sibling::ContributorPlace​))​]
. . . . <AlternativeName>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName
P.7.21. . . . . <NameType>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​NameType
. . . . . <NameIdentifier>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​NameIdentifier
P.7.22. . . . . . <NameIDType>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​NameIdentifier/​NameIDType
P.7.23. . . . . . <IDTypeName>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​NameIdentifier/​IDTypeName
P.7.24. . . . . . <IDValue>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​NameIdentifier/​IDValue
P.7.25. . . . . <PersonName>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​PersonName
P.7.26. . . . . <Person​NameInverted>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​PersonNameInverted
P.7.27. . . . . <TitlesBeforeNames>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​TitlesBeforeNames
P.7.28. . . . . <NamesBeforeKey>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​NamesBeforeKey
P.7.29. . . . . <PrefixToKey>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​PrefixToKey
P.7.30. . . . . <KeyNames>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​KeyNames
P.7.31. . . . . <NamesAfterKey>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​NamesAfterKey
P.7.32. . . . . <SuffixToKey>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​SuffixToKey
P.7.33. . . . . <LettersAfterNames>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​LettersAfterNames
P.7.34. . . . . <TitlesAfterNames>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​TitlesAfterNames
P.7.34a. . . . . <Gender>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​Gender
P.7.35. . . . . <CorporateName>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​CorporateName
P.7.36. . . . . <CorporateNameInverted>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​AlternativeName/​CorporateNameInverted
. . . . <ContributorDate>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​ContributorDate
P.7.37. . . . . <Contributor​DateRole>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​ContributorDate/​ContributorDateRole
P.7.38. . . . . <DateFormat>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​ContributorDate/​DateFormat
P.7.39. . . . . <Date>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​ContributorDate/​Date
. . . . <Professional​Affiliation>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​ProfessionalAffiliation
P.7.40. . . . . <Professional​Position>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​ProfessionalAffiliation/​ProfessionalPosition
P.7.41. . . . . <Affiliation>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​ProfessionalAffiliation/​Affiliation
. . . . <Prize>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​Prize
P.7.41a. . . . . <PrizeName>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​Prize/​PrizeName
P.7.41b. . . . . <PrizeYear>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​Prize/​PrizeYear
P.7.41c. . . . . <PrizeCountry>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​Prize/​PrizeCountry
P.7.41d. . . . . <PrizeCode>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​Prize/​PrizeCode
P.7.41e. . . . . <PrizeStatement>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​Prize/​PrizeStatement
P.7.41f. . . . . <PrizeJury>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​Prize/​PrizeJury
P.7.42. . . . <BiographicalNote>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​BiographicalNote
. . . . <Website>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​Website
P.7.43. . . . . <WebsiteRole>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​Website/​WebsiteRole
P.7.44. . . . . <WebsiteDescription>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​Website/​WebsiteDescription
P.7.45. . . . . <WebsiteLink>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​Website/​WebsiteLink
P.7.46. . . . <ContributorDescription>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​ContributorDescription
P.7.47. . . . <UnnamedPersons>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​UnnamedPersons[exists(​preceding‑sibling::ContributorDate|​preceding‑sibling::ProfessionalAffiliation|​preceding‑sibling::Prize|​preceding‑sibling::BiographicalNote|​preceding‑sibling::Website|​preceding‑sibling::ContributorDescription|​preceding‑sibling::ContributorPlace​)​]
. . . . <ContributorPlace>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​ContributorPlace
P.7.48. . . . . <ContributorPlaceRelator>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​ContributorPlace/​ContributorPlaceRelator
P.7.49. . . . . <CountryCode>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​ContributorPlace/​CountryCode
P.7.50. . . . . <RegionCode>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​ContributorPlace/​RegionCode
P.7.50a. . . . . <LocationName>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​ContributorPlace/​LocationName
P.7.51. . . <ContributorStatement>/ONIXMessage/​Product/​DescriptiveDetail/​Contributor/​ContributorStatement
P.7.52. . . <NoContributor/>/ONIXMessage/​Product/​DescriptiveDetail/​NoContributor
. . . <Conference>/ONIXMessage/​Product/​DescriptiveDetail/​Conference
P.8.1. . . . <ConferenceRole>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​ConferenceRole
P.8.2. . . . <ConferenceName>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​ConferenceName
P.8.3. . . . <ConferenceAcronym>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​ConferenceAcronym
P.8.4. . . . <ConferenceNumber>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​ConferenceNumber
P.8.5. . . . <ConferenceTheme>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​ConferenceTheme
P.8.6. . . . <ConferenceDate>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​ConferenceDate
P.8.7. . . . <ConferencePlace>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​ConferencePlace
. . . . <ConferenceSponsor>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​ConferenceSponsor
. . . . . <ConferenceSponsorIdentifier>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​ConferenceSponsor/​ConferenceSponsorIdentifier
P.8.8. . . . . . <ConferenceSponsorIDType>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​ConferenceSponsor/​ConferenceSponsorIdentifier/​ConferenceSponsorIDType
P.8.9. . . . . . <IDTypeName>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​ConferenceSponsor/​ConferenceSponsorIdentifier/​IDTypeName
P.8.10. . . . . . <IDValue>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​ConferenceSponsor/​ConferenceSponsorIdentifier/​IDValue
P.8.11. . . . . <PersonName>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​ConferenceSponsor/​PersonName
P.8.12. . . . . <CorporateName>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​ConferenceSponsor/​CorporateName
. . . . <Website>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​Website
P.8.13. . . . . <WebsiteRole>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​Website/​WebsiteRole
P.8.14. . . . . <WebsiteDescription>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​Website/​WebsiteDescription
P.8.15. . . . . <WebsiteLink>/ONIXMessage/​Product/​DescriptiveDetail/​Conference/​Website/​WebsiteLink
. . . <Event>/ONIXMessage/​Product/​DescriptiveDetail/​Event
P.8.16. . . . <EventRole>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​EventRole
P.8.17. . . . <EventName>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​EventName
P.8.18. . . . <EventAcronym>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​EventAcronym
P.8.19. . . . <EventNumber>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​EventNumber
P.8.20. . . . <EventTheme>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​EventTheme
P.8.21. . . . <EventDate>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​EventDate
P.8.22. . . . <EventPlace>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​EventPlace
. . . . <EventSponsor>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​EventSponsor
. . . . . <EventSponsorIdentifier>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​EventSponsor/​EventSponsorIdentifier
P.8.23. . . . . . <EventSponsorIDType>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​EventSponsor/​EventSponsorIdentifier/​EventSponsorIDType
P.8.24. . . . . . <IDTypeName>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​EventSponsor/​EventSponsorIdentifier/​IDTypeName
P.8.25. . . . . . <IDValue>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​EventSponsor/​EventSponsorIdentifier/​IDValue
P.8.26. . . . . <PersonName>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​EventSponsor/​PersonName
P.8.27. . . . . <CorporateName>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​EventSponsor/​CorporateName
. . . . <Website>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​Website
P.8.28. . . . . <WebsiteRole>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​Website/​WebsiteRole
P.8.29. . . . . <WebsiteDescription>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​Website/​WebsiteDescription
P.8.30. . . . . <WebsiteLink>/ONIXMessage/​Product/​DescriptiveDetail/​Event/​Website/​WebsiteLink
P.9.1. . . <EditionType>/ONIXMessage/​Product/​DescriptiveDetail/​EditionType
P.9.2. . . <EditionNumber>/ONIXMessage/​Product/​DescriptiveDetail/​EditionNumber
P.9.3. . . <EditionVersionNumber>/ONIXMessage/​Product/​DescriptiveDetail/​EditionVersionNumber
P.9.4. . . <EditionStatement>/ONIXMessage/​Product/​DescriptiveDetail/​EditionStatement
P.9.5. . . <NoEdition/>/ONIXMessage/​Product/​DescriptiveDetail/​NoEdition
. . . <ReligiousText>/ONIXMessage/​Product/​DescriptiveDetail/​ReligiousText
. . . . <Bible>/ONIXMessage/​Product/​DescriptiveDetail/​ReligiousText/​Bible
P.9.6. . . . . <BibleContents>/ONIXMessage/​Product/​DescriptiveDetail/​ReligiousText/​Bible/​BibleContents
P.9.7. . . . . <BibleVersion>/ONIXMessage/​Product/​DescriptiveDetail/​ReligiousText/​Bible/​BibleVersion
P.9.8. . . . . <StudyBibleType>/ONIXMessage/​Product/​DescriptiveDetail/​ReligiousText/​Bible/​BibleType
P.9.9. . . . . <BiblePurpose>/ONIXMessage/​Product/​DescriptiveDetail/​ReligiousText/​Bible/​BiblePurpose
P.9.10. . . . . <BibleTextOrganization>/ONIXMessage/​Product/​DescriptiveDetail/​ReligiousText/​Bible/​BibleTextOrganization
P.9.11. . . . . <BibleReferenceLocation>/ONIXMessage/​Product/​DescriptiveDetail/​ReligiousText/​Bible/​BibleReferenceLocation
P.9.12. . . . . <BibleTextFeature>/ONIXMessage/​Product/​DescriptiveDetail/​ReligiousText/​Bible/​BibleTextFeature
P.9.13. . . . <ReligiousTextIdentifier>/ONIXMessage/​Product/​DescriptiveDetail/​ReligiousText/​ReligiousTextIdentifier
. . . . <ReligiousTextFeature>/ONIXMessage/​Product/​DescriptiveDetail/​ReligiousText/​ReligiousTextFeature
P.9.14. . . . . <ReligiousTextFeatureType>/ONIXMessage/​Product/​DescriptiveDetail/​ReligiousText/​ReligiousTextFeature/​ReligiousTextFeatureType
P.9.15. . . . . <ReligiousTextFeatureCode>/ONIXMessage/​Product/​DescriptiveDetail/​ReligiousText/​ReligiousTextFeature/​ReligiousTextFeatureCode
P.9.16. . . . . <ReligiousTextFeatureDescription>/ONIXMessage/​Product/​DescriptiveDetail/​ReligiousText/​ReligiousTextFeature/​ReligiousTextFeatureDescription
. . . <Language>/ONIXMessage/​Product/​DescriptiveDetail/​Language
P.10.1. . . . <LanguageRole>/ONIXMessage/​Product/​DescriptiveDetail/​Language/​LanguageRole
P.10.2. . . . <LanguageCode>/ONIXMessage/​Product/​DescriptiveDetail/​Language/​LanguageCode
P.10.3. . . . <CountryCode>/ONIXMessage/​Product/​DescriptiveDetail/​Language/​CountryCode
P.10.4. . . . <ScriptCode>/ONIXMessage/​Product/​DescriptiveDetail/​Language/​ScriptCode
. . . <Extent>/ONIXMessage/​Product/​DescriptiveDetail/​Extent
P.11.1. . . . <ExtentType>/ONIXMessage/​Product/​DescriptiveDetail/​Extent/​ExtentType
P.11.2. . . . <ExtentValue>/ONIXMessage/​Product/​DescriptiveDetail/​Extent/​ExtentValue
P.11.3. . . . <ExtentValueRoman>/ONIXMessage/​Product/​DescriptiveDetail/​Extent/​ExtentValueRoman
P.11.4. . . . <ExtentUnit>/ONIXMessage/​Product/​DescriptiveDetail/​Extent/​ExtentUnit
P.11.5. . . <Illustrated>/ONIXMessage/​Product/​DescriptiveDetail/​Illustrated
P.11.6. . . <NumberOfIllustrations>/ONIXMessage/​Product/​DescriptiveDetail/​NumberOfIllustrations
P.11.7. . . <IllustrationsNote>/ONIXMessage/​Product/​DescriptiveDetail/​IllustrationsNote
. . . <AncillaryContent>/ONIXMessage/​Product/​DescriptiveDetail/​AncillaryContent
P.11.8. . . . <AncillaryContentType>/ONIXMessage/​Product/​DescriptiveDetail/​AncillaryContent/​AncillaryContentType
P.11.9. . . . <AncillaryContentDescription>/ONIXMessage/​Product/​DescriptiveDetail/​AncillaryContent/​AncillaryContentDescription
P.11.10. . . . <Number>/ONIXMessage/​Product/​DescriptiveDetail/​AncillaryContent/​Number
. . . <Subject>/ONIXMessage/​Product/​DescriptiveDetail/​Subject
P.12.1. . . . <MainSubject/>/ONIXMessage/​Product/​DescriptiveDetail/​Subject/​MainSubject
P.12.2. . . . <SubjectSchemeIdentifier>/ONIXMessage/​Product/​DescriptiveDetail/​Subject/​SubjectSchemeIdentifier
P.12.3. . . . <SubjectSchemeName>/ONIXMessage/​Product/​DescriptiveDetail/​Subject/​SubjectSchemeName
P.12.4. . . . <SubjectSchemeVersion>/ONIXMessage/​Product/​DescriptiveDetail/​Subject/​SubjectSchemeVersion
P.12.5. . . . <SubjectCode>/ONIXMessage/​Product/​DescriptiveDetail/​Subject/​SubjectCode
P.12.6. . . . <SubjectHeadingText>/ONIXMessage/​Product/​DescriptiveDetail/​Subject/​SubjectHeadingText
. . . <NameAsSubject>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject
P.12.7. . . . <NameType>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​NameType
. . . . <NameIdentifier>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​NameIdentifier
P.12.8. . . . . <NameIDType>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​NameIdentifier/​NameIDType
P.12.9. . . . . <IDTypeName>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​NameIdentifier/​IDTypeName
P.12.10. . . . . <IDValue>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​NameIdentifier/​IDValue
P.12.11. . . . <PersonName>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​PersonName
P.12.12. . . . <PersonNameInverted>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​PersonNameInverted
P.12.13. . . . <TitlesBeforeNames>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​TitlesBeforeNames
P.12.14. . . . <NamesBeforeKey>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​NamesBeforeKey
P.12.15. . . . <PrefixToKey>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​PrefixToKey
P.12.16. . . . <KeyNames>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​KeyNames
P.12.17. . . . <NamesAfterKey>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​NamesAfterKey
P.12.18. . . . <SuffixToKey>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​SuffixToKey
P.12.19. . . . <LettersAfterNames>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​LettersAfterNames
P.12.20. . . . <TitlesAfterNames>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​TitlesAfterNames
P.12.20a. . . . <Gender>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​Gender
P.12.21. . . . <CorporateName>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​CorporateName
P.12.22. . . . <CorporateNameInverted>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​CorporateNameInverted
. . . . <AlternativeName>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName
P.12.23. . . . . <NameType>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​NameType
. . . . . <NameIdentifier>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​NameIdentifier
P.12.24. . . . . . <NameIDType>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​NameIdentifier/​NameIDType
P.12.25. . . . . . <IDTypeName>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​NameIdentifier/​IDTypeName
P.12.26. . . . . . <IDValue>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​NameIdentifier/​IDValue
P.12.27. . . . . <PersonName>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​PersonName
P.12.28. . . . . <PersonName​Inverted>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​PersonNameInverted
P.12.29. . . . . <TitlesBeforeNames>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​TitlesBeforeNames
P.12.30. . . . . <NamesBeforeKey>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​NamesBeforeKey
P.12.31. . . . . <PrefixToKey>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​PrefixToKey
P.12.32. . . . . <KeyNames>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​KeyNames
P.12.33. . . . . <NamesAfterKey>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​NamesAfterKey
P.12.34. . . . . <SuffixToKey>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​SuffixToKey
P.12.35. . . . . <LettersAfterNames>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​LettersAfterNames
P.12.36. . . . . <TitlesAfterNames>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​TitlesAfterNames
P.12.36a. . . . . <Gender>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​Gender
P.12.37. . . . . <CorporateName>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​CorporateName
P.12.38. . . . . <CorporateNameInverted>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​AlternativeName/​CorporateNameInverted
. . . . <SubjectDate>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​SubjectDate
P.12.39. . . . . <SubjectDateRole>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​SubjectDate/​ContributorDateRole
P.12.40. . . . . <DateFormat>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​SubjectDate/​DateFormat
P.12.41. . . . . <Date>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​SubjectDate/​Date
. . . . <ProfessionalAffiliation>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​ProfessionalAffiliation
P.12.42. . . . . <ProfessionalPosition>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​ProfessionalAffiliation/​ProfessionalPosition
P.12.43. . . . . <Affiliation>/ONIXMessage/​Product/​DescriptiveDetail/​NameAsSubject/​ProfessionalAffiliation/​Affiliation
P.13.1. . . <AudienceCode>/ONIXMessage/​Product/​DescriptiveDetail/​AudienceCode
. . . <Audience>/ONIXMessage/​Product/​DescriptiveDetail/​Audience
P.13.2. . . . <AudienceCodeType>/ONIXMessage/​Product/​DescriptiveDetail/​Audience/​AudienecCodeType
P.13.3. . . . <AudienceCodeTypeName>/ONIXMessage/​Product/​DescriptiveDetail/​Audience/​AudienecCodeTypeName
P.13.4. . . . <AudienceCodeValue>/ONIXMessage/​Product/​DescriptiveDetail/​Audience/​AudienceCodeValue
. . . <AudienceRange>/ONIXMessage/​Product/​DescriptiveDetail/​AudienceRange
P.13.5. . . . <AudienceRangeQualifier>/ONIXMessage/​Product/​DescriptiveDetail/​AudienceRange/​AudienceRangeQualifier
P.13.6. . . . <AudienceRangePrecision>/ONIXMessage/​Product/​DescriptiveDetail/​AudienceRange/​AudienceRangePrecision[1]
P.13.7. . . . <AudienceRangeValue>/ONIXMessage/​Product/​DescriptiveDetail/​AudienceRange/​AudienceRangeValue[1]
P.13.8. . . . <AudienceRangePrecision>/ONIXMessage/​Product/​DescriptiveDetail/​AudienceRange/​AudienceRangePrecision[2]
P.13.9. . . . <AudienceRangeValue>/ONIXMessage/​Product/​DescriptiveDetail/​AudienceRange/​AudienceRangeValue[2]
P.13.10. . . <AudienceDescription>/ONIXMessage/​Product/​DescriptiveDetail/​AudienceDescription
. . . <Complexity>/ONIXMessage/​Product/​DescriptiveDetail/​Complexity
P.13.11. . . . <ComplexitySchemeIdentifier>/ONIXMessage/​Product/​DescriptiveDetail/​Complexity/​ComplexitySchemeIdentifier
P.13.12. . . . <ComplexityCode>/ONIXMessage/​Product/​DescriptiveDetail/​Complexity/​ComplexityCode
. . <CollateralDetail>/ONIXMessage/​Product/​CollateralDetail
. . . <TextContent>/ONIXMessage/​Product/​CollateralDetail/​TextContent
P.14.1. . . . <TextType>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​TextType
P.14.2. . . . <ContentAudience>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​ContentAudience
. . . . <Territory>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​Territory
P.14.2a. . . . . <CountriesIncluded>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​Territory/​CountriesIncluded
P.14.2b. . . . . <RegionsIncluded>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​Territory/​RegionsIncluded
P.14.2c. . . . . <CountriesExcluded>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​Territory/​CountriesExcluded
P.14.2d. . . . . <RegionsExcluded>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​Territory/​RegionsExcluded
P.14.3. . . . <Text>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​Text
. . . . <ReviewRating>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​ReviewRating
P.14.3a. . . . . <Rating>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​ReviewRating/​Rating
P.14.3b. . . . . <RatingLimit>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​ReviewRating/​RatingLimit
P.14.3c. . . . . <RatingUnits>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​ReviewRating/​RatingUnits
P.14.4. . . . <TextAuthor>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​TextAuthor
P.14.5. . . . <TextSourceCorporate>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​TextSourceCorporate
P.14.6. . . . <SourceTitle>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​SourceTitle
. . . . <ContentDate>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​ContentDate
P.14.7. . . . . <ContentDateRole>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​ContentDate/​ContentDateRole
P.14.8. . . . . <DateFormat>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​ContentDate/​DateFormat
P.14.9. . . . . <Date>/ONIXMessage/​Product/​CollateralDetail/​TextContent/​ContentDate/​Date
. . . <CitedContent>/ONIXMessage/​Product/​CollateralDetail/​CitedContent
P.15.1. . . . <CitedContentType>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​CitedContentType
P.15.2. . . . <ContentAudience>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​ContentAudience
. . . . <Territory>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​Territory
P.15.2a. . . . . <CountriesIncluded>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​Territory/​CountriesIncluded
P.15.2b. . . . . <RegionsIncluded>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​Territory/​RegionsIncluded
P.15.2c. . . . . <CountriesExcluded>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​Territory/​CountriesExcluded
P.15.2d. . . . . <RegionsExcluded>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​Territory/​RegionsExcluded
P.15.3. . . . <SourceType>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​SourceType
. . . . <ReviewRating>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​ReviewRating
P.15.3a. . . . . <Rating>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​ReviewRating/​Rating
P.15.3b. . . . . <RatingLimit>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​ReviewRating/​RatingLimit
P.15.3c. . . . . <RatingUnits>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​ReviewRating/​RatingUnits
P.15.4. . . . <SourceTitle>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​SourceTitle
P.15.5. . . . <ListName>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​ListName
P.15.6. . . . <PositionOnList>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​PositionOnList
P.15.7. . . . <CitationNote>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​CitationNote
P.15.8. . . . <ResourceLink>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​ResourceLink
. . . . <ContentDate>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​ContentDate
P.15.9. . . . . <ContentDateRole>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​ContentDate/​ContentDateRole
P.15.10. . . . . <DateFormat>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​ContentDate/​DateFormat
P.15.11. . . . . <Date>/ONIXMessage/​Product/​CollateralDetail/​CitedContent/​ContentDate/​Date
. . . <SupportingResource>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource
P.16.1. . . . <ResourceContentType>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ResourceContentType
P.16.2. . . . <ContentAudience>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ContentAudience
. . . . <Territory>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​Territory
P.16.2a. . . . . <CountriesIncluded>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​Territory/​CountriesIncluded
P.16.2b. . . . . <RegionsIncluded>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​Territory/​RegionsIncluded
P.16.2c. . . . . <CountriesExcluded>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​Territory/​CountriesExcluded
P.16.2d. . . . . <RegionsExcluded>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​Territory/​RegionsExcluded
P.16.3. . . . <ResourceMode>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ResourceMode
. . . . <ResourceFeature>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ResourceFeature
P.16.4. . . . . <ResourceFeatureType>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ResourceFeature/​ResourceFeatureType
P.16.5. . . . . <FeatureValue>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ResourceFeature/​FeatureValue
P.16.6. . . . . <FeatureNote>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ResourceFeature/​FeatureNote
. . . . <ResourceVersion>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ResourceVersion
P.16.7. . . . . <ResourceForm>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ResourceVersion/​ResourceForm
. . . . . <ResourceVersionFeature>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ResourceVersion/​ResourceVersionFeature
P.16.8. . . . . . <ResourceVersionFeatureType>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ResourceVersion/​ResourceVersionFeature/​ResourceVersionFeatureType
P.16.9. . . . . . <FeatureValue>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ResourceVersion/​ResourceVersionFeature/​FeatureValue
P.16.10. . . . . . <FeatureNote>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ResourceVersion/​ResourceVersionFeature/​FeatureNote
P.16.11. . . . . <ResourceLink>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ResourceVersion/​ResourceLink
. . . . . <ContentDate>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ContentDate
P.16.12. . . . . . <ContentDateRole>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ContentDate/​ContentDateRole
P.16.13. . . . . . <DateFormat>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ContentDate/​DateFormat
P.16.14. . . . . . <Date>/ONIXMessage/​Product/​CollateralDetail/​SupportingResource/​ContentDate/​Date
. . . <Prize>/ONIXMessage/​Product/​CollateralDetail/​Prize
P.17.1. . . . <PrizeName>/ONIXMessage/​Product/​CollateralDetail/​Prize/​PrizeName
P.17.2. . . . <PrizeYear>/ONIXMessage/​Product/​CollateralDetail/​Prize/​PrizeYear
P.17.3. . . . <PrizeCountry>/ONIXMessage/​Product/​CollateralDetail/​Prize/​PrizeCountry
P.17.4. . . . <PrizeCode>/ONIXMessage/​Product/​CollateralDetail/​Prize/​PrizeCode
P.17.4a. . . . <PrizeStatement>/ONIXMessage/​Product/​CollateralDetail/​Prize/​PrizeStatement
P.17.5. . . . <PrizeJury>/ONIXMessage/​Product/​CollateralDetail/​Prize/​PrizeJury
. . <ContentDetail>/ONIXMessage/​Product/​ContentDetail
. . . <ContentItem>/ONIXMessage/​Product/​ContentDetail/​ContentItem
P.18.1. . . . <LevelSequenceNumber>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​LevelSequenceNumber
. . . . <TextItem>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextItem
P.18.2. . . . . <TextItemType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextItem/​TextItemType
. . . . . <TextItemIdentifier>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextItem/​TextItemIdentifier
P.18.3. . . . . . <TextItemIDType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextItem/​TextItemIdentifier/​TextItemIDType
P.18.4. . . . . . <IDTypeName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextItem/​TextItemIdentifier/​IDTypeName
P.18.5. . . . . . <IDValue>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextItem/​TextItemIdentifier/​IDValue
. . . . . <PageRun>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextItem/​PageRun
P.18.6. . . . . . <FirstPageNumber>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextItem/​PageRun/​FirstPageNumber
P.18.7. . . . . . <LastPageNumber>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextItem/​PageRun/​LastPageNumber
P.18.8. . . . . <NumberOfPages>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextItem/​NumberOfPages
. . . . <AVItem>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​AVItem
P.18.8a. . . . . <AVItemType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​AVItem/​AVItemType
. . . . . <AVItemIdentifier>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​AVItem/​AVItemIdentifier
P.18.8b. . . . . . <AVItemIDType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​AVItem/​AVItemIdentifier/​AVItemIDType
P.18.8c. . . . . . <IDTypeName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​AVItem/​AVItemIdentifier/​IDTypeName
P.18.8d. . . . . . <IDValue>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​AVItem/​AVItemIdentifier/​IDValue
. . . . . <TimeRun>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​AVItem/​TimeRun
P.18.8e. . . . . . <StartTime>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​AVItem/​TimeRun/​StartTime
P.18.8f. . . . . . <EndTime>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​AVItem/​TimeRun/​EndTime
P.18.8g. . . . . <AVDuration>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​AVItem/​AVDuration
P.18.9. . . . <ComponentTypeName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​ComonentTypeName
P.18.10. . . . <ComponentNumber>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​ComonentNumber
. . . . <TitleDetail>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TitleDetail
P.18.11. . . . . <TitleType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TitleDetail/​TitleType
. . . . . <TitleElement>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TitleDetail/​TitleElement
P.18.11a. . . . . . <SequenceNumber>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TitleDetail/​TitleElement/​SequenceNumber
P.18.12. . . . . . <TitleElementLevel>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TitleDetail/​TitleElement/​TitleElementLevel
P.18.13. . . . . . <PartNumber>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TitleDetail/​TitleElement/​PartNumber
P.18.14. . . . . . <YearOfAnnual>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TitleDetail/​TitleElement/​YearOfAnnual
P.18.15. . . . . . <TitleText>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TitleDetail/​TitleElement/​TitleText
P.18.16. . . . . . <TitlePrefix>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TitleDetail/​TitleElement/​TitlePrefix
P.18.16a. . . . . . <NoPrefix/>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TitleDetail/​TitleElement/​NoPrefix
P.18.17. . . . . . <TitleWithoutPrefix>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TitleDetail/​TitleElement/​TitleWithoutPrefix
P.18.18. . . . . . <Subtitle>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TitleDetail/​TitleElement/​Subtitle
P.18.18a. . . . . <TitleStatement>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TitleDetail/​TitleStatement
. . . . <Contributor>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor
P.18.19. . . . . <SequenceNumber>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​SequenceNumber
P.18.20. . . . . <ContributorRole>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​ContributorRole
P.18.21. . . . . <FromLanguage>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​FromLanguage
P.18.22. . . . . <ToLanguage>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​ToLanguage
P.18.23. . . . . <NameType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​NameType
. . . . . <NameIdentifier>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​NameIdentifier
P.18.24. . . . . . <NameIDType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​NameIdentifier/​NameIDType
P.18.25. . . . . . <IDTypeName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​NameIdentifier/​IDTypeName
P.18.26. . . . . . <IDValue>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​NameIdentifier/​IDValue
P.18.27. . . . . <PersonName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​PersonName
P.18.28. . . . . <Person​NameInverted>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​PersonNameInverted
P.18.29. . . . . <TitlesBeforeNames>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​TitlesBeforeNames
P.18.30. . . . . <NamesBeforeKey>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​NamesBeforeKey
P.18.31. . . . . <PrefixToKey>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​PrefixToKey
P.18.32. . . . . <KeyNames>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​KeyNames
P.18.33. . . . . <NamesAfterKey>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​NamesAfterKey
P.18.34. . . . . <SuffixToKey>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​SuffixToKey
P.18.35. . . . . <LettersAfterNames>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​LettersAfterNames
P.18.36. . . . . <TitlesAfterNames>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​TitlesAfterNames
P.18.36a. . . . . <Gender>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​Gender
P.18.37. . . . . <CorporateName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​CorporateName
P.18.38. . . . . <Corporate​NameInverted>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​CorporateNameInverted
P.18.38a. . . . . <UnnamedPersons>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​UnnamedPersons[not(exists(​preceding‑sibling::ContributorDate|​preceding‑sibling::ProfessionalAffiliation|​preceding‑sibling::Prize|​preceding‑sibling::BiographicalNote|​preceding‑sibling::Website|​preceding‑sibling::ContributorDescription|​preceding‑sibling::ContributorPlace​))​]
. . . . . <AlternativeName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName
P.18.39. . . . . . <NameType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​NameType
. . . . . . <NameIdentifier>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​NameIdentifier
P.18.40. . . . . . . <NameIDType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​NameIdentifier/​NameIDType
P.18.41. . . . . . . <IDTypeName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​NameIdentifier/​IDTypeName
P.18.42. . . . . . . <IDValue>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​NameIdentifier/​IDValue
P.18.43. . . . . . <PersonName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​PersonName
P.18.44. . . . . . <Person​NameInverted>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​PersonNameInverted
P.18.45. . . . . . <TitlesBeforeNames>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​TitlesBeforeNames
P.18.46. . . . . . <NamesBeforeKey>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​NamesBeforeKey
P.18.47. . . . . . <PrefixToKey>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​PrefixToKey
P.18.48. . . . . . <KeyNames>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​KeyNames
P.18.49. . . . . . <NamesAfterKey>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​NamesAfterKey
P.18.50. . . . . . <SuffixToKey>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​SuffixToKey
P.18.51. . . . . . <LettersAfterNames>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​LettersAfterNames
P.18.52. . . . . . <TitlesAfterNames>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​TitlesAfterNames
P.18.52a. . . . . . <Gender>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​Gender
P.18.53. . . . . . <CorporateName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​CorporateName
P.18.54. . . . . . <Corporate​NameInverted>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​AlternativeName/​CorporateNameInverted
. . . . . <ContributorDate>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​ContributorDate
P.18.55. . . . . . <ContributorDateRole>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​ContributorDate/​ContributorDateRole
P.18.56. . . . . . <DateFormat>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​ContributorDate/​DateFormat
P.18.57. . . . . . <Date>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​ContributorDate/​Date
. . . . . <ProfessionalAffiliation>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​ProfessionalAffiliation
P.18.58. . . . . . <ProfessionalPosition>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​ProfessionalAffiliation/​ProfessionalPosition
P.18.59. . . . . . <Affiliation>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​ProfessionalAffiliation/​Affiliation
. . . . . <Prize>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​Prize
P.18.59a. . . . . . <PrizeName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​Prize/​PrizeName
P.18.59b. . . . . . <PrizeYear>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​Prize/​PrizeYear
P.18.59c. . . . . . <PrizeCountry>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​Prize/​PrizeCountry
P.18.59d. . . . . . <PrizeCode>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​Prize/​PrizeCode
P.18.59e. . . . . . <PrizeStatement>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​Prize/​PrizeStatement
P.18.59f. . . . . . <PrizeJury>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​Prize/​PrizeJury
P.18.60. . . . . <BiographicalNote>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​BiographicalNote
. . . . . <Website>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​Website
P.18.61. . . . . . <WebsiteRole>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​Website/​WebsiteRole
P.18.62. . . . . . <WebsiteDescription>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​Website/​WebsiteDescription
P.18.63. . . . . . <WebsiteLink>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​Website/​WebsiteLink
P.18.64. . . . . <ContributorDescription>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​ContributorDescription
P.18.65. . . . . <UnnamedPersons>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​UnnamedPersons[exists(​preceding‑sibling::ContributorDate|​preceding‑sibling::ProfessionalAffiliation|​preceding-sibling::Prize|​preceding‑sibling::BiographicalNote|​preceding‑sibling::Website|​preceding‑sibling::ContributorDescription|​preceding‑sibling::ContributorPlace​)]
. . . . . <ContributorPlace>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​ContributorPlace
P.18.66. . . . . . <ContributorPlaceRelator>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​ContributorPlace/​ContributorPlaceRelator
P.18.67. . . . . . <CountryCode>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​ContributorPlace/​CountryCode
P.18.68. . . . . . <RegionCode>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​ContributorPlace/​RegionCode
P.18.68a. . . . . . <LocationName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​ContributorPlace/​LocationName
P.18.68b. . . . <ContributorStatement>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Contributor/​ContributorStatement
P.18.68c. . . . <NoContributor/>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NoContributor
P.18.68d. . . . <Language>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Language
P.18.68e. . . . . <LanguageRole>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Language/​LanguageRole
P.18.68f. . . . . <LanguageCode>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Language/​LanguageCode
P.18.68g. . . . . <CountryCode>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Language/​CountryCode
P.18.68h. . . . . <ScriptCode>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Language/​ScriptCode
. . . . <Subject>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Subject
P.18.69. . . . . <MainSubject/>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Subject/​MainSubject
P.18.70. . . . . <SubjectSchemeIdentifier>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Subject/​SubjectSchemeIdentifier
P.18.71. . . . . <SubjectSchemeName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Subject/​SubjectSchemeName
P.18.72. . . . . <SubjectSchemeVersion>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Subject/​SubjectSchemeVersion
P.18.73. . . . . <SubjectCode>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Subject/​SubjectCode
P.18.74. . . . . <SubjectHeadingText>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​Subject/​SubjectHeadingText
. . . . <NameAsSubject>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject
P.18.75. . . . . <NameType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​NameType
. . . . . <NameIdentifier>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​NameIdentifier
P.18.76. . . . . . <NameIDType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​NameIdentifier/​NameIDType
P.18.77. . . . . . <IDTypeName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​NameIdentifier/​IDTypeName
P.18.78. . . . . . <IDValue>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​NameIdentifier/​IDValue
P.18.79. . . . . <PersonName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​PersonName
P.18.80. . . . . <PersonNameInverted>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​PersonNameInverted
P.18.81. . . . . <TitlesBeforeNames>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​TitlesBeforeNames
P.18.82. . . . . <NamesBeforeKey>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​NamesBeforeKey
P.18.83. . . . . <PrefixToKey>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​PrefixToKey
P.18.84. . . . . <KeyNames>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​KeyNames
P.18.85. . . . . <NamesAfterKey>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​NamesAfterKey
P.18.86. . . . . <SuffixToKey>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​SuffixToKey
P.18.87. . . . . <LettersAfterNames>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​LettersAfterNames
P.18.88. . . . . <TitlesAfterNames>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​TitlesAfterNames
P.18.88a. . . . . <Gender>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​Gender
P.18.89. . . . . <CorporateName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​CorporateName
P.18.90. . . . . <CorporateNameInverted>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​CorporateNameInverted
. . . . . <AlternativeName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName
P.18.90a. . . . . . <NameType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​NameType
. . . . . . <NameIdentifier>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​NameIdentifier
P.18.90b. . . . . . . <NameIDType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​NameIdentifier/​NameIDType
P.18.90c. . . . . . . <IDTypeName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​NameIdentifier/​IDTypeName
P.18.90d. . . . . . . <IDValue>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​NameIdentifier/​IDValue
P.18.90e. . . . . . <PersonName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​PersonName
P.18.90f. . . . . . <PersonNameInverted>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​PersonNameInverted
P.18.90g. . . . . . <TitlesBeforeNames>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​TitlesBeforeNames
P.18.90h. . . . . . <NamesBeforeKey>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​NamesBeforeKey
P.18.90i. . . . . . <PrefixToKey>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​PrefixToKey
P.18.90j. . . . . . <KeyNames>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​KeyNames
P.18.90k. . . . . . <NamesAfterKey>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​NamesAfterKey
P.18.90l. . . . . . <SuffixToKey>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​SuffixToKey
P.18.90m. . . . . . <LettersAfterNames>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​LettersAfterNames
P.18.90n. . . . . . <TitlesAfterNames>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​TitlesAfterNames
P.18.90o. . . . . . <Gender>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​Gender
P.18.90p. . . . . . <CorporateName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​CorporateName
P.18.90q. . . . . . <Corporate​NameInverted>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​AlternativeName/​CorporateNameInverted
. . . . . <SubjectDate>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​SubjectDate
P.18.90r. . . . . . <SubjectDateRole>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​SubjectDate/​ContributorDateRole
P.18.90s. . . . . . <DateFormat>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​SubjectDate/​DateFormat
P.18.90t. . . . . . <Date>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​SubjectDate/​Date
. . . . . <ProfessionalAffiliation>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​ProfessionalAffiliation
P.18.90u. . . . . . <ProfessionalPosition>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​ProfessionalAffiliation/​ProfessionalPosition
P.18.90v. . . . . . <Affiliation>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​NameAsSubject/​ProfessionalAffiliation/​Affiliation
. . . . <TextContent>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent
P.18.91. . . . . <TextType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​TextType
P.18.92. . . . . <ContentAudience>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​ContentAudience
. . . . . <Territory>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​Territory
P.18.92a. . . . . . <CountriesIncluded>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​Territory/​CountriesIncluded
P.18.92b. . . . . . <RegionsIncluded>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​Territory/​RegionsIncluded
P.18.92c. . . . . . <CountriesExcluded>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​Territory/​CountriesExcluded
P.18.92d. . . . . . <RegionsExcluded>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​Territory/​RegionsExcluded
P.18.93. . . . . <Text>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​Text
. . . . . <ReviewRating>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​ReviewRating
P.18.93a. . . . . . <Rating>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​ReviewRating/​Rating
P.18.93b. . . . . . <RatingLimit>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​ReviewRating/​RatingLimit
P.18.93c. . . . . . <RatingUnits>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​ReviewRating/​RatingUnits
P.18.94. . . . . <TextAuthor>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​TextAuthor
P.18.95. . . . . <TextSourceCorporate>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​TextSourceCorporate
P.18.96. . . . . <SourceTitle>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​SourceTitle
. . . . . <ContentDate>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​ContentDate
P.18.97. . . . . . <ContentDateRole>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​ContentDate/​ContentDateRole
P.18.98. . . . . . <DateFormat>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​ContentDate/​DateFormat
P.18.99. . . . . . <Date>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​TextContent/​ContentDate/​Date
. . . . <CitedContent>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent
P.18.100. . . . . <CitedContentType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​CitedContentType
P.18.101. . . . . <ContentAudience>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​ContentAudience
. . . . . <Territory>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​Territory
P.18.101a. . . . . . <CountriesIncluded>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​Territory/​CountriesIncluded
P.18.101b. . . . . . <RegionsIncluded>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​Territory/​RegionsIncluded
P.18.101c. . . . . . <CountriesExcluded>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​Territory/​CountriesExcluded
P.18.101d. . . . . . <RegionsExcluded>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​Territory/​RegionsExcluded
P.18.102. . . . . <SourceType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​SourceType
. . . . . <ReviewRating>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​ReviewRating
P.18.102a. . . . . . <Rating>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​ReviewRating/​Rating
P.18.102b. . . . . . <RatingLimit>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​ReviewRating/​RatingLimit
P.18.102c. . . . . . <RatingUnits>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​ReviewRating/​RatingUnits
P.18.103. . . . . <SourceTitle>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​SourceTitle
P.18.104. . . . . <ListName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​ListName
P.18.105. . . . . <PositionOnList>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​PositionOnList
P.18.106. . . . . <CitationNote>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​CitationNote
P.18.107. . . . . <ResourceLink>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​ResourceLink
. . . . . <ContentDate>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​ContentDate
P.18.108. . . . . . <ContentDateRole>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​ContentDate/​ContentDateRole
P.18.109. . . . . . <DateFormat>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​ContentDate/​DateFormat
P.18.110. . . . . . <Date>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​CitedContent/​ContentDate/​Date
. . . . <SupportingResource>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource
P.18.111. . . . . <ResourceContentType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ResourceContentType
P.18.112. . . . . <ContentAudience>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ContentAudience
. . . . . <Territory>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​Territory
P.18.112a. . . . . . <CountriesIncluded>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​Territory/​CountriesIncluded
P.18.112b. . . . . . <RegionsIncluded>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​Territory/​RegionsIncluded
P.18.112c. . . . . . <CountriesExcluded>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​Territory/​CountriesExcluded
P.18.112d. . . . . . <RegionsExcluded>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​Territory/​RegionsExcluded
P.18.113. . . . . <ResourceMode>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ResourceMode
. . . . . <ResourceFeature>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ResourceFeature
P.18.114. . . . . . <Resource​FeatureType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ResourceFeature/​ResourceFeatureType
P.18.115. . . . . . <FeatureValue>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ResourceFeature/​FeatureValue
P.18.116. . . . . . <FeatureNote>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ResourceFeature/​FeatureNote
. . . . . <ResourceVersion>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ResourceVersion
P.18.117. . . . . . <ResourceForm>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ResourceVersion/​ResourceForm
. . . . . . <ResourceVersionFeature>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ResourceVersion/​ResourceVersionFeature
P.18.118. . . . . . . <ResourceVersionFeatureType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ResourceVersion/​ResourceVersionFeature/​ResourceVersionFeatureType
P.18.119. . . . . . . <FeatureValue>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ResourceVersion/​ResourceVersionFeature/​FeatureValue
P.18.120. . . . . . . <FeatureNote>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ResourceVersion/​ResourceVersionFeature/​FeatureNote
P.18.121. . . . . . <ResourceLink>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ResourceVersion/​ResourceLink
. . . . . . <ContentDate>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ContentDate
P.18.122. . . . . . . <ContentDateRole>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ContentDate/​ContentDateRole
P.18.123. . . . . . . <DateFormat>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ContentDate/​DateFormat
P.18.124. . . . . . . <Date>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​SupportingResource/​ContentDate/​Date
. . . . <RelatedWork>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​RelatedWork
P.18.125. . . . . <WorkRelationCode>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​RelatedWork/​WorkRelationCode
. . . . . <WorkIdentifier>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​RelatedWork/​WorkIdentifier
P.18.126. . . . . . <WorkIDType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​RelatedWork/​WorkIdentifier/​WorkIDType
P.18.127. . . . . . <IDTypeName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​RelatedWork/​WorkIdentifier/​IDTypeName
P.18.128. . . . . . <IDValue>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​RelatedWork/​WorkIdentifier/​IDValue
. . . . <RelatedProduct>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​RelatedProduct
P.18.129. . . . . <ProductRelationCode>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​RelatedProduct/​ProductRelationCode
. . . . . <ProductIdentifier>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​RelatedProduct/​ProductIdentifier
P.18.130. . . . . . <ProductIDType>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​RelatedProduct/​ProductIdentifier/​ProductIDType
P.18.131. . . . . . <IDTypeName>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​RelatedProduct/​ProductIdentifier/​IDTypeName
P.18.132. . . . . . <IDValue>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​RelatedProduct/​ProductIdentifier/​IDValue
P.18.133. . . . . <ProductForm>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​RelatedProduct/​ProductForm
P.18.134. . . . . <ProductFormDetail>/ONIXMessage/​Product/​ContentDetail/​ContentItem/​RelatedProduct/​ProductFormDetail
. . <PublishingDetail>/ONIXMessage/​Product/​PublishingDetail
. . . <Imprint>/ONIXMessage/​Product/​PublishingDetail/​Imprint
. . . . <ImprintIdentifier>/ONIXMessage/​Product/​PublishingDetail/​Imprint/​ImprintIdentifier
P.19.1. . . . . <ImprintIDType>/ONIXMessage/​Product/​PublishingDetail/​Imprint/​ImprintIdentifier/​ImprintIDType
P.19.2. . . . . <IDTypeName>/ONIXMessage/​Product/​PublishingDetail/​Imprint/​ImprintIdentifier/​IDTypeName
P.19.3. . . . . <IDValue>/ONIXMessage/​Product/​PublishingDetail/​Imprint/​ImprintIdentifier/​IDValue
P.19.4. . . . <ImprintName>/ONIXMessage/​Product/​PublishingDetail/​Imprint/​ImprintName
. . . <Publisher>/ONIXMessage/​Product/​PublishingDetail/​Publisher
P.19.5. . . . <PublishingRole>/ONIXMessage/​Product/​PublishingDetail/​Publisher/​PublishingRole
. . . . <PublisherIdentifier>/ONIXMessage/​Product/​PublishingDetail/​Publisher/​PublisherIdentifier
P.19.6. . . . . <PublisherIDType>/ONIXMessage/​Product/​PublishingDetail/​Publisher/​PublisherIdentifier/​PublisherIDType
P.19.7. . . . . <IDTypeName>/ONIXMessage/​Product/​PublishingDetail/​Publisher/​PublisherIdentifier/​IDTypeName
P.19.8. . . . . <IDValue>/ONIXMessage/​Product/​PublishingDetail/​Publisher/​PublisherIdentifier/​IDValue
P.19.9. . . . <PublisherName>/ONIXMessage/​Product/​PublishingDetail/​Publisher/​PublisherName
. . . . <Funding>/ONIXMessage/​Product/​PublishingDetail/​Publisher/​Funding
. . . . . <FundingIdentifier>/ONIXMessage/​Product/​PublishingDetail/​Publisher/​Funding/​FundingIdentifier
P.19.9a. . . . . . <FundingIDType>/ONIXMessage/​Product/​PublishingDetail/​Publisher/​Funding/​FundingIdentifier/​FundingIDType
P.19.9b. . . . . . <IDTypeName>/ONIXMessage/​Product/​PublishingDetail/​Publisher/​Funding/​FundingIdentifier/​IDTypeName
P.19.9c. . . . . . <IDValue>/ONIXMessage/​Product/​PublishingDetail/​Publisher/​Funding/​FundingIdentifier/​IDVlalue
. . . . <Website>/ONIXMessage/​Product/​PublishingDetail/​Publisher/​Website
P.19.10. . . . . <WebsiteRole>/ONIXMessage/​Product/​PublishingDetail/​Publisher/​Website/​WebsiteRole
P.19.11. . . . . <WebsiteDescription>/ONIXMessage/​Product/​PublishingDetail/​Publisher/​Website/​WebsiteDescription
P.19.12. . . . . <WebsiteLink>/ONIXMessage/​Product/​PublishingDetail/​Publisher/​Funding/​Website/​WebsiteLink
P.19.13. . . <CityOfPublication>/ONIXMessage/​Product/​PublishingDetail/​CityOfPublication
P.19.14. . . <CountryOfPublication>/ONIXMessage/​Product/​PublishingDetail/​CountryOfPublication
. . . <ProductContact>/ONIXMessage/​Product/​PublishingDetail/​ProductContact
P.19.15. . . . <ProductContactRole>/ONIXMessage/​Product/​PublishingDetail/​ProductContact/​ProductContactRole
. . . . <ProductContactIdentifier>/ONIXMessage/​Product/​PublishingDetail/​ProductContact/​ProductContactIdentifier
P.19.16. . . . . <ProductContactIDType>/ONIXMessage/​Product/​PublishingDetail/​ProductContact/​ProductContactIdentifier/​ProductContactIDType
P.19.17. . . . . <IDTypeName>/ONIXMessage/​Product/​PublishingDetail/​ProductContact/​ProductContactIdentifier/​IDTypeName
P.19.18. . . . . <IDValue>/ONIXMessage/​Product/​PublishingDetail/​ProductContact/​ProductContactIdentifier/​IDValue
P.19.19. . . . <ProductContactName>/ONIXMessage/​Product/​PublishingDetail/​ProductContact/​ProductContactName
P.19.20. . . . <ContactName>/ONIXMessage/​Product/​PublishingDetail/​ProductContact/​ContactName
P.19.21. . . . <EmailAddress>/ONIXMessage/​Product/​PublishingDetail/​ProductContact/​EmailAddress
P.20.1. . . <PublishingStatus>/ONIXMessage/​Product/​PublishingDetail/​PublishingStatus
P.20.2. . . <PublishingStatusNote>/ONIXMessage/​Product/​PublishingDetail/​PublishingStatusNote
. . . <PublishingDate>/ONIXMessage/​Product/​PublishingDetail/​PublishingDate
P.20.3. . . . <PublishingDateRole>/ONIXMessage/​Product/​PublishingDetail/​PublishingDate/​PublishingDateRole
P.20.4. . . . <DateFormat>/ONIXMessage/​Product/​PublishingDetail/​PublishingDate/​DateFormat
P.20.5. . . . <Date>/ONIXMessage/​Product/​PublishingDetail/​PublishingDate/​Date
P.20.6. . . <LatestReprintNumber>/ONIXMessage/​Product/​PublishingDetail/​LatestReprintNumber
. . . <CopyrightStatement>/ONIXMessage/​Product/​PublishingDetail/​CopyrightStatement
P.20.6a. . . . <CopyrightType>/ONIXMessage/​Product/​PublishingDetail/​CopyrightStatement/​CopyrightType
P.20.7. . . . <CopyrightYear>/ONIXMessage/​Product/​PublishingDetail/​CopyrightStatement/​CopyrightYear
. . . . <CopyrightOwner>/ONIXMessage/​Product/​PublishingDetail/​CopyrightStatement/​CopyrightOwner
. . . . . <CopyrightOwnerIdentifier>/ONIXMessage/​Product/​PublishingDetail/​CopyrightStatement/​CopyrightOwner/​CopyrightOwnerIdentifier
P.20.8. . . . . . <CopyrightOwnerIDType>/ONIXMessage/​Product/​PublishingDetail/​CopyrightStatement/​CopyrightOwner/​CopyrightOwnerIdentifier/​CopyrightOwnerIDType
P.20.9. . . . . . <IDTypeName>/ONIXMessage/​Product/​PublishingDetail/​CopyrightStatement/​CopyrightOwner/​CopyrightOwnerIdentifier/​IDTypeName
P.20.10. . . . . . <IDValue>/ONIXMessage/​Product/​PublishingDetail/​CopyrightStatement/​CopyrightOwner/​CopyrightOwnerIdentifier/​IDValue
P.20.11. . . . . <PersonName>/ONIXMessage/​Product/​PublishingDetail/​CopyrightStatement/​CopyrightOwner/​PersonName
P.20.12. . . . . <CorporateName>/ONIXMessage/​Product/​PublishingDetail/​CopyrightStatement/​CopyrightOwner/​CorporateName
. . . <SalesRights>/ONIXMessage/​Product/​PublishingDetail/​SalesRights
P.21.1. . . . <SalesRightsType>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​SalesRightsType
. . . . <Territory>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​Territory
P.21.2. . . . . <CountriesIncluded>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​Territory/​CountriesIncluded
P.21.3. . . . . <RegionsIncluded>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​Territory/​RegionsIncluded
P.21.4. . . . . <CountriesExcluded>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​Territory/​CountriesExcluded
P.21.5. . . . . <RegionsExcluded>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​Territory/​RegionsExcluded
. . . . <SalesRestriction>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​SalesRestriction
P.21.5a. . . . . <SalesRestrictionType>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​SalesRestriction/​SalesRestrictionType
. . . . . <SalesOutlet>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​SalesRestriction/​SalesOutlet
. . . . . . <SalesOutletIdentifier>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​SalesRestriction/​SalesOutlet/​SalesOutletIdentifier
P.21.5b. . . . . . . <SalesOutletIDType>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​SalesRestriction/​SalesOutlet/​SalesOutletIdentifier/​SalesOutletIDType
P.21.5c. . . . . . . <IDTypeName>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​SalesRestriction/​SalesOutlet/​SalesOutletIdentifier/​IDTypeName
P.21.5d. . . . . . . <IDValue>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​SalesRestriction/​SalesOutlet/​SalesOutletIdentifier/​IDValue
P.21.5e. . . . . . <SalesOutletName>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​SalesRestriction/​SalesOutlet/​SalesOutletName
P.21.5f. . . . . <SalesRestrictionNote>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​SalesRestriction/​SalesRestrictionNote
P.21.5g. . . . . <StartDate>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​SalesRestriction/​StartDate
P.21.5h. . . . . <EndDate>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​SalesRestriction/​EndDate
. . . . <ProductIdentifier>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​ProductIdentifier
P.21.6. . . . . <ProductIDType>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​ProductIdentifier/​ProductIDType
P.21.7. . . . . <IDTypeName>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​ProductIdentifier/​IDTypeName
P.21.8. . . . . <IDValue>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​ProductIdentifier/​IDValue
P.21.9. . . . <PublisherName>/ONIXMessage/​Product/​PublishingDetail/​SalesRights/​PublisherName
P.21.10. . . <ROWSalesRightsType>/ONIXMessage/​Product/​PublishingDetail/​ROWSalesRightsType
. . . <SalesRestriction>/ONIXMessage/​Product/​PublishingDetail/​SalesRestriction
P.21.11. . . . <SalesRestrictionType>/ONIXMessage/​Product/​PublishingDetail/​SalesRestriction/​SalesRestrictionType
. . . . <SalesOutlet>/ONIXMessage/​Product/​PublishingDetail/​SalesRestriction/​SalesOutlet
. . . . . <SalesOutletIdentifier>/ONIXMessage/​Product/​PublishingDetail/​SalesRestriction/​SalesOutlet/​SalesOutletIdentifier
P.21.12. . . . . . <SalesOutletIDType>/ONIXMessage/​Product/​PublishingDetail/​SalesRestriction/​SalesOutlet/​SalesOutletIdentifier/​SalesOutletIDType
P.21.13. . . . . . <IDTypeName>/ONIXMessage/​Product/​PublishingDetail/​SalesRestriction/​SalesOutlet/​SalesOutletIdentifier/​IDTypeName
P.21.14. . . . . . <IDValue>/ONIXMessage/​Product/​PublishingDetail/​SalesRestriction/​SalesOutlet/​SalesOutletIdentifier/​IDValue
P.21.15. . . . . <Sales​OutletName>/ONIXMessage/​Product/​PublishingDetail/​SalesRestriction/​SalesOutlet/​SalesOutletName
P.21.16. . . . <SalesRestrictionNote>/ONIXMessage/​Product/​PublishingDetail/​SalesRestriction/​SalesRestrictionNote
P.21.17. . . . <StartDate>/ONIXMessage/​Product/​PublishingDetail/​SalesRestriction/​StartDate
P.21.18. . . . <EndDate>/ONIXMessage/​Product/​PublishingDetail/​SalesRestriction/​EndDate
. . <RelatedMaterial>/ONIXMessage/​Product/​RelatedMaterial
. . . <RelatedWork>/ONIXMessage/​Product/​RelatedMaterial/​RelatedWork
P.22.1. . . . <WorkRelationCode>/ONIXMessage/​Product/​RelatedMaterial/​RelatedWork/​WorkRelationCode
. . . . <WorkIdentifier>/ONIXMessage/​Product/​RelatedMaterial/​RelatedWork/​WorkIdentifier
P.22.2. . . . . <WorkIDType>/ONIXMessage/​Product/​RelatedMaterial/​RelatedWork/​WorkIdentifier/​WorkIDType
P.22.3. . . . . <IDTypeName>/ONIXMessage/​Product/​RelatedMaterial/​RelatedWork/​WorkIdentifier/​IDTypeName
P.22.4. . . . . <IDValue>/ONIXMessage/​Product/​RelatedMaterial/​RelatedWork/​WorkIdentifier/​IDValue
. . . <RelatedProduct>/ONIXMessage/​Product/​RelatedMaterial/​RelatedProduct
P.23.1. . . . <ProductRelationCode>/ONIXMessage/​Product/​RelatedMaterial/​RelatedProduct/​ProductRelationCode
. . . . <ProductIdentifier>/ONIXMessage/​Product/​RelatedMaterial/​RelatedProduct/​ProductIdentifier
P.23.2. . . . . <ProductIDType>/ONIXMessage/​Product/​RelatedMaterial/​RelatedProduct/​ProductIdentifier/​ProductIDType
P.23.3. . . . . <IDTypeName>/ONIXMessage/​Product/​RelatedMaterial/​RelatedProduct/​ProductIdentifier/​IDTypeName
P.23.4. . . . . <IDValue>/ONIXMessage/​Product/​RelatedMaterial/​RelatedProduct/​ProductIdentifier/​IDValue
P.23.5. . . . <ProductForm>/ONIXMessage/​Product/​RelatedMaterial/​RelatedProduct/​ProductForm
P.23.6. . . . <ProductFormDetail>/ONIXMessage/​Product/​RelatedMaterial/​RelatedProduct/​ProductFormDetail
. . <ProductSupply>/ONIXMessage/​Product/​ProductSupply
. . . <Market>/ONIXMessage/​Product/​ProductSupply/​Market
. . . . <Territory>/ONIXMessage/​Product/​ProductSupply/​Market/​Territory
P.24.1. . . . . <CountriesIncluded>/ONIXMessage/​Product/​ProductSupply/​Market/​Territory/​CountriesIncluded
P.24.2. . . . . <RegionsIncluded>/ONIXMessage/​Product/​ProductSupply/​Market/​Territory/​RegionsIncluded
P.24.3. . . . . <CountriesExcluded>/ONIXMessage/​Product/​ProductSupply/​Market/​Territory/​CountriesExcluded
P.24.4. . . . . <RegionsExcluded>/ONIXMessage/​Product/​ProductSupply/​Market/​Territory/​RegionsExcluded
. . . . <SalesRestriction>/ONIXMessage/​Product/​ProductSupply/​Market/​SalesRestriction
P.24.5. . . . . <SalesRestrictionType>/ONIXMessage/​Product/​ProductSupply/​Market/​SalesRestriction/​SalesRestrictionType
. . . . . <SalesOutlet>/ONIXMessage/​Product/​ProductSupply/​Market/​SalesRestriction/​SalesOutlet
. . . . . . <SalesOutletIdentifier>/ONIXMessage/​Product/​ProductSupply/​Market/​SalesRestriction/​SalesOutlet/​SalesOutletIdentifier
P.24.6. . . . . . . <SalesOutletIDType>/ONIXMessage/​Product/​ProductSupply/​Market/​SalesRestriction/​SalesOutlet/​SalesOutletIdentifier/​SalesOutletIDType
P.24.7. . . . . . . <IDTypeName>/ONIXMessage/​Product/​ProductSupply/​Market/​SalesRestriction/​SalesOutlet/​SalesOutletIdentifier/​IDTypeName
P.24.8. . . . . . . <IDValue>/ONIXMessage/​Product/​ProductSupply/​Market/​SalesRestriction/​SalesOutlet/​SalesOutletIdentifier/​IDValue
P.24.9. . . . . . <SalesOutletName>/ONIXMessage/​Product/​ProductSupply/​Market/​SalesRestriction/​SalesOutlet/​SalesOutletName
P.24.10. . . . . <SalesRestrictionNote>/ONIXMessage/​Product/​ProductSupply/​Market/​SalesRestriction/​SalesRestrictionNote
P.24.11. . . . . <StartDate>/ONIXMessage/​Product/​ProductSupply/​Market/​SalesRestriction/​StartDate
P.24.12. . . . . <EndDate>/ONIXMessage/​Product/​ProductSupply/​Market/​SalesRestriction/​EndDate
. . . <MarketPublishingDetail>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail
. . . . <PublisherRepresentative>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative
P.25.1. . . . . <AgentRole>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​AgentRole
. . . . . <AgentIdentifier>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​AgentIdentifier
P.25.2. . . . . . <AgentIDType>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​AgentIdentifier/​AgentIDType
P.25.3. . . . . . <IDTypeName>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​AgentIdentifier/​IDTypeName
P.25.4. . . . . . <IDValue>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​AgentIdentifier/​IDValue
P.25.5. . . . . <AgentName>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​AgentName
P.25.6. . . . . <TelephoneNumber>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​TelephoneNumber
P.25.7. . . . . <FaxNumber>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​FaxNumber
P.25.8. . . . . <EmailAddress>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​EmailAddress
. . . . . <Website>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​Website
P.25.9. . . . . . <WebsiteRole>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​Website/​WebsiteRole
P.25.10. . . . . . <WebsiteDescription>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​Website/​WebsiteDescription
P.25.11. . . . . . <WebsiteLink>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​Website/​WebsiteLink
. . . . <ProductContact>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​ProductContact
P.25.11a. . . . . <ProductContactRole>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​ProductContact/​ProductContactRole
. . . . . <ProductContactIdentifier>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​ProductContact/​ProductContactIdentifier
P.25.11b. . . . . . <ProductContactIDType>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​ProductContact/​ProductContactIdentifier/​ProductContactIDType
P.25.11c. . . . . . <IDTypeName>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​ProductContact/​ProductContactIdentifier/​IDTypeName
P.25.11d. . . . . . <IDValue>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​ProductContact/​ProductContactIdentifier/​IDValue
P.25.11e. . . . . <ProductContactName>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​ProductContact/​ProductContactName
P.25.11f. . . . . <ContactName>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​ProductContact/​ContactName
P.25.11g. . . . . <EmailAddress>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​ProductContact/​EmailAddress
P.25.12. . . . <MarketPublishingStatus>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​MarketPublishingStatus
P.25.13. . . . <MarketPublishingStatusNote>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​MarketPublishingStatusNote
. . . . <MarketDate>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​MarketDate
P.25.14. . . . . <MarketDateRole>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​MarketDate/​MarketDateRole
P.25.15. . . . . <DateFormat>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​MarketDate/​DateFormat
P.25.16. . . . . <Date>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​MarketDate/​Date
P.25.17. . . . <PromotionCampaign>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​PromotionCampaign
P.25.18. . . . <PromotionContact>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​PromotionContact
P.25.19. . . . <InitialPrintRun>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​InitialPrintRun
P.25.20. . . . <ReprintDetail>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​ReprintDetail
P.25.21. . . . <CopiesSold>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​CopiesSold
P.25.22. . . . <BookClubAdoption>/ONIXMessage/​Product/​ProductSupply/​MarketPublishingDetail/​PublisherRepresentative/​BookClubAdoption
. . . <SupplyDetail>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail
. . . . <Supplier>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Supplier
P.26.1. . . . . <SupplierRole>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Supplier/​SupplierRole
. . . . . <SupplierIdentifier>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Supplier/​SupplierIdentifier
P.26.2. . . . . . <SupplierIDType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Supplier/​SupplierIdentifier/​SupplierIDType
P.26.3. . . . . . <IDTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Supplier/​SupplierIdentifier/​IDTypeName
P.26.4. . . . . . <IDValue>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Supplier/​SupplierIdentifier/​IDValue
P.26.5. . . . . <SupplierName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Supplier/​SupplierName
P.26.6. . . . . <TelephoneNumber>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Supplier/​TelephoneNumer
P.26.7. . . . . <FaxNumber>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Supplier/​FaxNumber
P.26.8. . . . . <EmailAddress>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Supplier/​EmailAddress
. . . . . <Website>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Supplier/​Website
P.26.9. . . . . . <WebsiteRole>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Supplier/​Website/​WebsiteRole
P.26.10. . . . . . <WebsiteDescription>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Supplier/​Website/​WebsiteDescription
P.26.11. . . . . . <WebsiteLink>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Supplier/​Website/​WebsiteLink
. . . . <SupplyContact>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplyContact
P.26.11a. . . . . <SupplyContactRole>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplyContact/​SupplyContactRole
. . . . . <SupplyContactIdentifier>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplyContact/​SupplyContactIdentifier
P.26.11b. . . . . . <SupplyContactIDType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplyContact/​SupplyContactIdentifier/​SuppluyContactIDType
P.26.11c. . . . . . <IDTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplyContact/​SupplyContactIdentifier/​IDTypeName
P.26.11c. . . . . . <IDValue>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplyContact/​SupplyContactIdentifier/​IDValue
P.26.11e. . . . . <SupplyContactName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplyContact/​SupplyContactName
P.26.11f. . . . . <ContactName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplyContact/​ContactName
P.26.11g. . . . . <EmailAddress>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplyContact/​EmailAddress
. . . . <SupplierOwnCoding>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplierOwnCoding
P.26.12. . . . . <SupplierCodeType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplierOwnCoding/​SupplierCodeType
P.26.12a. . . . . <SupplierCodeTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplierOwnCoding/​SupplierCodeTypeName
P.26.13. . . . . <SupplierCodeValue>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplierOwnCoding/​SupplierCodeValue
. . . . <ReturnsConditions>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​ReturnsConditions
P.26.14. . . . . <ReturnsCodeType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​ReturnsConditions/​ReturnsCodeType
P.26.15. . . . . <ReturnsCodeTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​ReturnsConditions/​ReturnsCodeTypeName
P.26.16. . . . . <ReturnsCode>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​ReturnsConditions/​ReturnsCode
P.26.16a. . . . . <ReturnsNote>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​ReturnsConditions/​ReturnsNote
P.26.17. . . . <ProductAvailability>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​ProductAvailability
. . . . <SupplyDate>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplyDate
P.26.18. . . . . <SupplyDateRole>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplyDate/​Supp;yDateRole
P.26.19. . . . . <DateFormat>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplyDate/​DateFormat
P.26.20. . . . . <Date>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​SupplyDate/​Date
P.26.21. . . . <OrderTime>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​OrderTime
. . . . <NewSupplier>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​NewSupplier
. . . . . <SupplierIdentifier>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​NewSupplier/​SuppilerIdentifier
P.26.22. . . . . . <SupplierIDType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​NewSupplier/​SuppilerIdentifier/​SupplierIDType
P.26.23. . . . . . <IDTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​NewSupplier/​SuppilerIdentifier/​IDTypeName
P.26.24. . . . . . <IDValue>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​NewSupplier/​SuppilerIdentifier/​IDValue
P.26.25. . . . . <SupplierName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​NewSupplier/​SupplierName
P.26.26. . . . . <TelephoneNumber>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​NewSupplier/​TelephoneNumber
P.26.27. . . . . <FaxNumber>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​NewSupplier/​FaxNumber
P.26.28. . . . . <EmailAddress>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​NewSupplier/​EmailAddress
. . . . <Stock>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock
. . . . . <LocationIdentifier>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​LocationIdentifier
P.26.29. . . . . . <LocationIDType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​LocationIdentifier/​LocationIDType
P.26.30. . . . . . <IDTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​LocationIdentifier/​IDTypeName
P.26.31. . . . . . <IDValue>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​LocationIdentifier/​IDValue
P.26.32. . . . . <LocationName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​LocationName
. . . . . <StockQuantityCoded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​StockQuantityCoded
P.26.33. . . . . . <StockQuantityCodeType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​StockQuantityCoded/​StockQuantityCodeType
P.26.34. . . . . . <StockQuantityCodeTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​StockQuantityCoded/​StockQuantityCodeTypeName
P.26.35. . . . . . <StockQuantityCode>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​StockQuantityCoded/​StockQuantityCode
P.26.36. . . . . <OnHand>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​OnHand
P.26.36a. . . . . <Proximity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​Proximity[preceding-sibling::*[1]/self::OnHand]
P.26.36b. . . . . <Reserved>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​Reserved
P.26.36c. . . . . <Proximity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​Proximity[preceding-sibling::*[1]/self::Reserved]
P.26.37. . . . . <OnOrder>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​OnOrder
P.26.37a. . . . . <Proximity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​Proximity[preceding-sibling::*[1]/self::OnOrder]
P.26.38. . . . . <CBO>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​CBO
P.26.38a. . . . . <Proximity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​Proximity[preceding-sibling::*[1]/self::CBO]
. . . . . <OnOrderDetail>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​OnOrderDetail
P.26.39. . . . . . <OnOrder>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​OnOrderDetail/​OnOrder
P.26.39a. . . . . . <Proximity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​OnOrderDetail/​Proximity
P.26.40. . . . . . <ExpectedDate>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​OnOrderDetail/​ExpectedDate
. . . . . <Velocity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​Velocity
P.26.40a. . . . . . <VelocityMetric>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​Velocity/​VelocityMetric
P.26.40b. . . . . . <Rate>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​Velocity/​Rate
P.26.40c. . . . . . <Proximity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Stock/​Velocity/​Proximity
P.26.41. . . . <PackQuantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​PackQuantity
P.26.41a. . . . <PalletQuantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​PalletQuantity
P.26.41b. . . . <OrderQuantityMinimum>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​OrderQuantityMinimum[1]
P.26.41c. . . . <OrderQuantityMinimum>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​OrderQuantityMinimum[2]
P.26.41d. . . . <OrderQuantityMultiple>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​OrderQuantityMultiple
P.26.42. . . . <UnpricedItemType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​UnpricedItemType
. . . . <Price>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price
. . . . . <PriceIdentifier>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceIdentifier
P.26.42a. . . . . . <PriceIDType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceIdentifier/​PriceIDType
P.26.42b. . . . . . <IDTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceIdentifier/​IDTypeName
P.26.42c. . . . . . <IDValue>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceIdentifier/​IDValue
P.26.43. . . . . <PriceType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceType
P.26.44. . . . . <PriceQualifier>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceQualifier
P.26.44a. . . . . <EpubTechnicalProtection>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​EpubTechnicalProtection
. . . . . <PriceConstraint>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceConstraint
P.26.44b. . . . . . <PriceConstraintType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceConstraint/​PriceConstraintType
P.26.44c. . . . . . <PriceConstraintStatus>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceConstraint/​PriceConstraintStatus
. . . . . . <PriceConstraintLimit>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceConstraint/​PriceConstraintLimit
P.26.44d. . . . . . . <Quantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceConstraint/​PriceConstraintLimit/​Quantity
P.26.44e. . . . . . . <PriceConstraintUnit>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceConstraint/​PriceConstraintLimit/​PriceConstraintUnit
. . . . . <EpubLicense>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​EpubLicense
P.26.44f. . . . . . <EpubLicenseName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​EpubLicense/​EpubLicenseName
. . . . . . <EpubLicenseExpression>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​EpubLicense/​EpubLicenseExpression
P.26.44g. . . . . . . <EpubLicenseExpressionType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​EpubLicense/​EpubLicenseExpression/​EpubLicenseExpressionType
P.26.44h. . . . . . . <EpubLicenseExpression​TypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​EpubLicense/​EpubLicenseExpression/​EpubLicenseExpressionTypeName
P.26.44i. . . . . . . <EpubLicenseExpressionLink>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​EpubLicense/​EpubLicenseExpression/​EpubLicenseExpressionLink
P.26.45. . . . . <PriceTypeDescription>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceTypeDescription
P.26.46. . . . . <PricePer>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PricePer
. . . . . <PriceCondition>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceCondition
P.26.47. . . . . . <PriceConditionType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceCondition/​PriceConditionType
. . . . . . <PriceConditionQuantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceCondition/​PriceConditionQuantity
P.26.48. . . . . . . <PriceConditionQuantityType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceCondition/​PriceConditionQuantity/​PriceConditionQuantityType
P.26.49. . . . . . . <Quantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceCondition/​PriceConditionQuantity/​Quantity
P.26.50. . . . . . . <QuantityUnit>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceCondition/​PriceConditionQuantity/​QuantityUnit
. . . . . . <ProductIdentifier>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceCondition/​ProductIdentifier
P.26.50a. . . . . . . <ProductIDType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceCondition/​ProductIdentifier/​ProductIDType
P.26.50b. . . . . . . <IDTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceCondition/​ProductIdentifier/​IDTypeName
P.26.50c. . . . . . . <IDValue>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceCondition/​ProductIdentifier/​IDValue
P.26.51. . . . . <MinimumOrderQuantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​MinimumOrderQuantity
. . . . . <BatchBonus>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​BatchBonus
P.26.52. . . . . . <BatchQuantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​BatchBonus/​BatchQuantity
P.26.53. . . . . . <FreeQuantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​BatchBonus/​FreeQuantity
. . . . . <DiscountCoded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​DiscountCoded
P.26.54. . . . . . <DiscountCodeType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​DiscountCoded/​DiscountCodeType
P.26.55. . . . . . <DiscountCodeTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​DiscountCoded/​DiscountCodeTypeName
P.26.56. . . . . . <DiscountCode>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​DiscountCoded/​DiscountCode
. . . . . <Discount>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Discount
P.26.57. . . . . . <DiscountType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Discount/​DiscountType
P.26.58. . . . . . <Quantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Discount/​Quantity
P.26.58a. . . . . . <ToQuantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Discount/​ToQuantity
P.26.59. . . . . . <DiscountPercent>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Discount/​DiscountPercent
P.26.60. . . . . . <DiscountAmount>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Discount/​DiscountAmount
P.26.61. . . . . <PriceStatus>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceStatus
P.26.62. . . . . <PriceAmount>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceAmount
. . . . . <PriceCoded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceCoded
P.26.63. . . . . . <PriceCodeType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceCoded/​PriceCodeType
P.26.64. . . . . . <PriceCodeTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceCoded/​PriceCodeTypeName
P.26.65. . . . . . <PriceCode>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceCoded/​PriceCode
. . . . . <Tax>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Tax
. . . . . . <ProductIdentifier>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Tax/​ProductIdentifier
P.26.65a. . . . . . . <ProductIDType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Tax/​ProductIdentifier/​ProductIDType
P.26.65b. . . . . . . <IDTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Tax/​ProductIdentifier/​IDTypeName
P.26.65c. . . . . . . <IDValue>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Tax/​ProductIdentifier/​IDValue
P.26.65d. . . . . . <PricePartDescription>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Tax/​PricePartDescription
P.26.66. . . . . . <TaxType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Tax/​TaxType
P.26.67. . . . . . <TaxRateCode>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Tax/​TaxRateCode
P.26.68. . . . . . <TaxRatePercent>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Tax/​TaxRatePercent
P.26.69. . . . . . <TaxableAmount>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Tax/​TaxableAmount
P.26.70. . . . . . <TaxAmount>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Tax/​TaxAmount
P.26.70a. . . . . <TaxExempt/>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​TaxExempt
P.26.70b. . . . . <UnpricedItemType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​UnpricedItemType
P.26.71. . . . . <CurrencyCode>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​CurrencyCode
. . . . . <Territory>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Territory
P.26.72. . . . . . <CountriesIncluded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Territory/​CountriesIncluded
P.26.73. . . . . . <RegionsIncluded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Territory/​RegionsIncluded
P.26.74. . . . . . <CountriesExcluded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Territory/​CountriesExcluded
P.26.75. . . . . . <RegionsExcluded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​Territory/​RegionsExcluded
P.26.76. . . . . <CurrencyZone>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​CurrencyZone
. . . . . <ComparisonProductPrice>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​ComparisonProductPrice
. . . . . . <ProductIdentifier>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​ComparisonProductPrice/​ProductIdentifier
P.26.77. . . . . . . <ProductIDType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​ComparisonProductPrice/​ProductIdentifier/​ProductIDType
P.26.78. . . . . . . <IDTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​ComparisonProductPrice/​ProductIdentifier/​IDTypeName
P.26.79. . . . . . . <IDValue>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​ComparisonProductPrice/​ProductIdentifier/​IDValue
P.26.80. . . . . . <PriceType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​ComparisonProductPrice/​ProductIdentifier/​PriceType
P.26.81. . . . . . <PriceAmount>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​ComparisonProductPrice/​ProductIdentifier/​PriceAmount
P.26.82. . . . . . <CurrencyCode>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​ComparisonProductPrice/​ProductIdentifier/​CurrencyCode
. . . . . <PriceDate>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceDate
P.26.83. . . . . . <PriceDateRole>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceDate/​PriceDateRole
P.26.84. . . . . . <DateFormat>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceDate/​DateFormat
P.26.85. . . . . . <Date>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PriceDate/​Date
P.26.86. . . . . <PrintedOnProduct>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PrintedOnProduct
P.26.87. . . . . <PositionOnProduct>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Price/​PositionOnProduct
. . . . <Reissue>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue
P.26.88. . . . . <ReissueDate>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​ReissueDate
P.26.89. . . . . <ReissueDescription>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​ReissueDescription
. . . . . <Price>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price
. . . . . . <PriceIdentifier>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceIdentifier
P.26.89a. . . . . . . <PriceIDType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceIdentifier/​PriceIDType
P.26.89b. . . . . . . <IDTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceIdentifier/​IDTypeName
P.26.89c. . . . . . . <IDValue>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceIdentifier/​IDValue
P.26.90. . . . . . <PriceType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceType
P.26.91. . . . . . <PriceQualifier>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceQualifier
P.26.91a. . . . . . <EpubTechnicalProtection>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​EpubTechnicalProtection
. . . . . . <PriceConstraint>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceConstraint
P.26.91b. . . . . . . <PriceConstraintType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceConstraint/​PriceConstraintType
P.26.91c. . . . . . . <PriceConstraintStatus>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceConstraint/​PriceConstraintStatus
. . . . . . . <PriceConstraintLimit>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceConstraint/​PriceConstraintLimit
P.26.91d. . . . . . . . <Quantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceConstraint/​PriceConstraintLimit/​Quantity
P.26.91e. . . . . . . . <PriceConstraintUnit>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceConstraint/​PriceConstraintLimit/​PriceConstraintUnit
. . . . . . <EpubLicense>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​EpubLicense
P.26.91f. . . . . . . <EpubLicenseName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​EpubLicense/​EpubLicenseName
. . . . . . . <EpubLicenseExpression>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​EpubLicense/​EpubLicenseExpression
P.26.91g. . . . . . . . <EpubLicenseExpressionType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​EpubLicense/​EpubLicenseExpression/​EpubLicenseExpressionType
P.26.91h. . . . . . . . <EpubLicenseExpression​TypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​EpubLicense/​EpubLicenseExpression/​EpubLicenseExpressionTypeName
P.26.91i. . . . . . . . <EpubLicenseExpressionLink>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​EpubLicense/​EpubLicenseExpression/​EpubLicenseExpressionLink
P.26.92. . . . . . <PriceTypeDescription>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceTypeDescription
P.26.93. . . . . . <PricePer>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PricePer
. . . . . . <PriceCondition>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceCondition
P.26.94. . . . . . . <PriceConditionType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceCondition/​PriceConditionType
. . . . . . . <PriceConditionQuantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceCondition/​PriceConditionQuantity
P.26.95. . . . . . . . <PriceCondition​QuantityType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceCondition/​PriceConditionQuantity/​PriceConditionQuantityType
P.26.96. . . . . . . . <Quantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceCondition/​PriceConditionQuantity/​Quantity
P.26.97. . . . . . . . <QuantityUnit>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceCondition/​PriceConditionQuantity/​QuantityUnit
. . . . . . . <ProductIdentifier>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceCondition/​ProductIdentifier
P.26.97a. . . . . . . . <ProductIDType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceCondition/​ProductIdentifier/​ProductIDType
P.26.97b. . . . . . . . <IDTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceCondition/​ProductIdentifier/​IDTypeName
P.26.97c. . . . . . . . <IDValue>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceCondition/​ProductIdentifier/​IDValue
P.26.98. . . . . . <MinimumOrderQuantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​MinimumOrderQuantity
. . . . . . <BatchBonus>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​BatchBonus
P.26.99. . . . . . . <BatchQuantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​BatchBonus/​BatchQuantity
P.26.100. . . . . . . <FreeQuantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​BatchBonus/​FreeQuantity
. . . . . . <DiscountCoded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​DiscountCoded
P.26.101. . . . . . . <DiscountCodeType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​DiscountCoded/​DiscountCodeType
P.26.102. . . . . . . <DiscountCode​TypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​DiscountCoded/​DiscountCodeTypeName
P.26.103. . . . . . . <DiscountCode>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​DiscountCoded/​DiscountCode
. . . . . . <Discount>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Discount
P.26.104. . . . . . . <DiscountType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Discount/​DiscountType
P.26.105. . . . . . . <Quantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Discount/​Quantity
P.26.105a. . . . . . . <ToQuantity>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Discount/​ToQuantity
P.26.106. . . . . . . <DiscountPercent>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Discount/​DiscountPercent
P.26.107. . . . . . . <DiscountAmount>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Discount/​DiscountAmount
P.26.108. . . . . . <PriceStatus>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceStatus
P.26.109. . . . . . <PriceAmount>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceAmount
. . . . . . <PriceCoded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceCoded
P.26.110. . . . . . . <PriceCodeType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceCoded/​PriceCodeType
P.26.111. . . . . . . <PriceCodeTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceCoded/​PriceCodeTypeName
P.26.112. . . . . . . <PriceCode>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceCoded/​PriceCode
. . . . . . <Tax>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Tax
. . . . . . . <ProductIdentifier>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Tax/​ProductIdentifier
P.26.112a. . . . . . . . <ProductIDType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Tax/​ProductIdentifier/​ProductIDType
P.26.112b. . . . . . . . <IDTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Tax/​ProductIdentifier/​IDTypeName
P.26.112c. . . . . . . . <IDValue>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Tax/​ProductIdentifier/​IDValue
P.26.112d. . . . . . . <PricePartDescription>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Tax/​PricePartDescription
P.26.113. . . . . . . <TaxType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Tax/​TaxType
P.26.114. . . . . . . <TaxRateCode>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Tax/​TaxRateCode
P.26.115. . . . . . . <TaxRatePercent>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Tax/​TaxRatePercent
P.26.116. . . . . . . <TaxableAmount>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Tax/​TaxableAmount
P.26.117. . . . . . . <TaxAmount>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Tax/​TaxAmount
P.26.117a. . . . . . <TaxExempt/>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​TaxExempt
P.26.117b. . . . . . <UnpricedItemType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​UnpricedItemType
P.26.118. . . . . . <CurrencyCode>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​CurrencyCode
. . . . . . <Territory>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Territory
P.26.119. . . . . . . <CountriesIncluded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Territory/​CountriesIncluded
P.26.120. . . . . . . <RegionsIncluded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Territory/​RegionsIncluded
P.26.121. . . . . . . <CountriesExcluded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Territory/​CountriesExcluded
P.26.122. . . . . . . <RegionsExcluded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​Territory/​RegionsExcluded
P.26.123. . . . . . <CurrencyZone>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​CurrencyZone
. . . . . . <ComparisonProductPrice>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​ComparisonProductPrice
. . . . . . . <ProductIdentifier>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​ComparisonProductPrice/​ProductIdentifier
P.26.124. . . . . . . . <ProductIDType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​ComparisonProductPrice/​ProductIdentifier/​ProductIDType
P.26.125. . . . . . . . <IDTypeName>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​ComparisonProductPrice/​ProductIdentifier/​IDTypeName
P.26.126. . . . . . . . <IDValue>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​ComparisonProductPrice/​ProductIdentifier/​IDValue
P.26.127. . . . . . . <PriceType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​ComparisonProductPrice/​ProductIdentifier/​PriceType
P.26.128. . . . . . . <PriceAmount>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​ComparisonProductPrice/​ProductIdentifier/​PriceAmount
P.26.129. . . . . . . <CurrencyCode>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​ComparisonProductPrice/​ProductIdentifier/​CurrencyCode
. . . . . . <PriceDate>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceDate
P.26.130. . . . . . . <PriceDateRole>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceDate/​PriceDateRole
P.26.131. . . . . . . <DateFormat>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceDate/​DateFormat
P.26.132. . . . . . . <Date>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PriceDate/​Date
P.26.133. . . . . . <PrintedOnProduct>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PrintedOnProduct
P.26.134. . . . . . <PositionOnProduct>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​Price/​PositionOnProduct
. . . . . <SupportingResource>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource
P.26.135. . . . . . <ResourceContentType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceContentType
P.26.136. . . . . . <ContentAudience>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​CongtentAudience
. . . . . . <Territory>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​Territory
P.26.136a. . . . . . . <CountriesIncluded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​Territory/​CountriesIncluded
P.26.136b. . . . . . . <RegionsIncluded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​Territory/​RegionsIncluded
P.26.136c. . . . . . . <CountriesExcluded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​Territory/​CountriesExcluded
P.26.136d. . . . . . . <RegionsExcluded>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​Territory/​RegionsExcluded
P.26.137. . . . . . <ResourceMode>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceMode
. . . . . . <ResourceFeature>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceFeature
P.26.138. . . . . . . <ResourceFeatureType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceFeature/​ResourceFeatureType
P.26.139. . . . . . . <FeatureValue>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceFeature/​FeatureValue
P.26.140. . . . . . . <FeatureNote>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceFeature/​FeatureNote
. . . . . . <ResourceVersion>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceVersion
P.26.141. . . . . . . <ResourceForm>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceVersion/​ResourceForm
. . . . . . . <ResourceVersionFeature>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceVersion/​ResourceVersionFeature
P.26.142. . . . . . . . <ResourceVersion​FeatureType>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceVersion/​ResourceVersionFeature/​ResourceVersionFeatureType
P.26.143. . . . . . . . <FeatureValue>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceVersion/​ResourceVersionFeature/​FeatureValue
P.26.144. . . . . . . . <FeatureNote>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceVersion/​ResourceVersionFeature/​FeatureNote
P.26.145. . . . . . . <ResourceLink>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceVersion/​ResourceLink
. . . . . . . <ContentDate>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceVersion/​ContentDate
P.26.146. . . . . . . . <ContentDateRole>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceVersion/​ContentDate/​ContentDateRole
P.26.147. . . . . . . . <DateFormat>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceVersion/​ContentDate/​DateFormat
P.26.148. . . . . . . . <Date>/ONIXMessage/​Product/​ProductSupply/​SupplyDetail/​Reissue/​SupportingResource/​ResourceVersion/​ContentDate/​Date
P.26.149. <NoProduct/>/ONIXMessage/​NoProduct

A.11 ONIX Acknowledgement message

The ONIX for Books Acknowledgement Format Specification, released January 2015, is a separate and optional message intended to be sent by the recipient of an ONIX message to the data supplier in response to receipt of a standard ONIX for Books message. It allows an ONIX for Books recipient to:

  • confirm receipt of the original ONIX message;
  • report to the original sender a summary of Product records processed and updated into the recipient’s database;
  • report details of any errors encountered, or any queries about the product data supplied; or
  • return to the sender details of proprietary identifiers asigned by the recipient.

The Acknowledgement message can form part of a ‘choreography’ of messages between sender and recipient (say between publisher and data aggregator, or between distributor and retailer). For example, by agreement, the absence of an Acknowledgement after 24 hours could be used to trigger retransmission of the original ONIX message, with suitable modification of <MessageRepeat>, or Acknowledgements could be used to monitor and assess agreed service levels. However, it is not expected that it will be used in every ONIX 3.0 data feed, and where it is adopted, implementations might at first use only the simplest functionality (confirmation of receipt).

Simple Acknowledgement noting receipt of an ONIX message
using Reference names
<?xml version="1.0" encoding="UTF-8"?>
<ONIXMessageAcknowledgement release="3.0" xmlns="http://ns.editeur.org/​onix/​3.0/​acknowledgement/​reference">
    <Header>
        <Sender>
            <SenderName>Waterstones</SenderName>
        </Sender>
        <Addressee>
            <AddresseeName>Publisher GmbH</AddresseeName>
        </Addressee>
        <MessageNumber>571</MessageNumber>
        <SentDateTime>20130327T1510Z</SentDateTime>
        <AcknowledgementNumber>1</AcknowledgementNumber>
        <AcknowledgementSentDateTime>20130327T1805Z​</AcknowledgementSentDateTime>
        <MessageStatus>00</MessageStatus>
        <MessageStatusDate>
            <MessageStatusDateRole>01</MessageStatusDateRole>
            <Date dateformat="00">20130328</Date>
        </MessageStatusDate>
    </Header>
    <NoProduct/>
</ONIXMessageAcknowledgement>
using Short tags
<?xml version="1.0" encoding="UTF-8"?>File may contain extended characters without need for special coding
<ONIXmessageacknowledgement release="3.0" xmlns="http://ns.editeur.org/​onix/​3.0/​acknowledgement/​short">Includes optional namespace
    <header>
        <sender>
            <x298>Waterstones</x298>The recipient of the original ONIX message
        </sender>
        <addressee>
            <x300>Publisher GmbH</x300>The sender of the original ONIX message
        </addressee>
        <m180>571</m180>Message number and sent date
        <x307>20130327T1510Z</x307>…of the original ONIX message
        <m485>1</m485>First acknowledgement (to 571)
        <m487>20130327T1805Z​</m487>…and its sent date
        <m489>00</m489>Message received
        <messagestatusdate>
            <m490>01</m490>Expected to be processed
            <b306 dateformat="00">20130328</b306>…tomorrow
        </messagestatusdate>
    </header>
    <x507/>No product record-level info (yet)
</ONIXmessageacknowledgement>
Although labelled ‘Release 3.0’, the January 2015 version is the first full release of the Acknowledgement message. It is numbered for consistency with ONIX 3.0 (although it could in principle be used with legacy ONIX 2.1 messages too).

A.12 ONIX ‘strict’ XSD 1.1 schema

The ONIX 3.0 XSD schema can be used to validate ONIX messages, checking both the tagging structure and the use of codes from codelists. However, the normal or ‘classic’ XSD cannot implement co-occurrence constraints (‘if it’s an e‑book, it cannot have a <Measure> composite’), calculate tax, or check on values drawn from one of a number of codelists where the specific codelist to use is dependent on data elsewhere (for example, the codelist used with <ProductFormFeatureValue> is dependent on the code used in <ProductFormFeatureType>). It cannot check identifier check digits, or ‘microformats’ like the structure of Product classification codes, FSC certifications or Lexile measures. (Note that validation with a DTD is even more limited.)

The ONIX 3.0 advanced or ‘strict’ schema uses XSD 1.1 technology to add hundreds of further checks on the integrity of ONIX message files. For example, it checks:

  • record references are unique within the message;
  • identifier check digits are correct on GTINs, ISBNs, ISNIs, GLNs, SANs and others;
    • it also checks that identifiers which lack built-in check digits (for example DOIs, Ringgold IDs or subject codes from a scheme such as BISAC or Thema) look ‘plausible’, with the correct structure;
    • and that if a proprietary identifier of any kind is included, <IDTypeName> is also present;
  • dates are correctly structured (eg no 30th February), and start dates of ranges are before the matching end dates;
  • sequence numbers are consecutive;
  • country and region codes are not repeated within a list like <CountriesIncluded>;
    • and that <ROWSalesRightstype> is included or omitted correctly;
    • a range of other rules around <SalesRights> are also checked;
  • tax detail is not included in prices where <PriceType> is exc-tax;
    • a range of other rules around <TaxableAmount>, <TaxAmount> and <PriceAmount> are also checked;
  • information is not repeated unnecessarily in repeatable composites or data elements (eg if identical edition, subject or audience codes are repeated);
  • multilingual data elements all have unique language attributes;
  • it ensures there is no leading or trailing white space characters at the beginning and end of ordinary text fields.

The strict XSD avoids imposing rules that are not already in the Specification, and it does not invalidate messages where the issue is a question of best or poor practice.

Because it uses XSD 1.1, the strict schema can be used for validation with the common Java-based parser libraries Saxon and Xerces (for example in oXygen), and with the Raptor parser in XML Spy. (These are the only known implementations of an XSD 1.1 parser.) The strict XSD is used in the same way as the standard XSD, and shares the same codelists. However, not all XML parsers implement XSD 1.1, and the strict schema cannot be used with either Microsoft’s standard .NET parser or any tool based on the common libxml. For this reason, the strict schema will not replace the standard ONIX XSD.

The strict schema also contains embedded Schematron rules. These are ignored, unless specifically enabled with a special XML processing instruction. When enabled, the embedded Schematron rules provide warnings of the use of deprecated codes and data elements. It can also report whether the message uses any of the new data elements introduced in releases 3.0.4, 3.0.5 and so on. However, these optional Schematron rules are purely informative – they never invalidate an ONIX message.

message start with namespace declaration, location of the strict XSD 1.1 schema file and optional xml-model XML processing instruction enabling Schematron, for advanced validation purposes
using Reference names
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model type="application/xml" schematypens="http://purl.oclc.org/dsdl/​schematron" href="ONIX_BookProduct_3.0_reference_strict.xsd"?>
<ONIXMessage release="3.0" xmlns="http://ns.editeur.org/​onix/​3.0/​reference" xmlns:xsi="http://www.w3.org/​2001/​XMLSchema-instance" xsi:schemaLocation="http://ns.editeur.org/​onix/​3.0/​reference ONIX_BookProduct_3.0_reference_strict.xsd">
using Short tags
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model type="application/xml" schematypens="http://purl.oclc.org/dsdl/​schematron" href="ONIX_BookProduct_3.0_short_strict.xsd"?>
<ONIXmessage release="3.0" xmlns="http://ns.editeur.org/​onix/​3.0/​short" xmlns:xsi="http://www.w3.org/​2001/​XMLSchema-instance" xsi:schemaLocation="http://ns.editeur.org/​onix/​3.0/​short ONIX_BookProduct_3.0_short_strict.xsd">
The actual location of the XSD schema file is specified in the second part of the value of the xsi:schemaLocation attribute and in the href attribute within the XML processing instruction that enables the embedded Schematron rules, and these need to be adjusted depending on local circumstance. The example indicates the strict schema file is in the same location as the ONIX file being validated. An earlier example in the section High-level message structure and conformance shows how validation can use a schema file accessed via http.

A.13 Key changes between ONIX 2.1 and ONIX 3.0

The table below summarizes the major changes in ONIX 3.0, for implementors planning a transition from ONIX for Books 2.1 to 3.0. For each numbered data element group in the Release 2.1 Product record, the table below shows the equivalent in 3.0, and notes where there have been significant changes. It does not list every minor change, but indicates where the majority of work will be required.

The impact of these changes – and the amount of development work required to support ONIX 3.0 messages in an existing IT system that already supports ONIX 2.1 – will vary, depending on the database schema and on the complexity of the business models that the message is required to support.

The difficulty of supporting 3.0 in an application that already supports 2.1 will also depend on whether the 2.1 implementation has been kept ‘current’. ONIX 2.1 includes a large number of specialized data elements inherited from 1.x and 2.0, but these are complemented by more flexible composite data elements that are new in 2.0, 2.1 or in its subsequent minor revisions (2.1.1 to 2.1.4). In 2.1, the composite elements are strongly preferred, but for reasons of compatibility, the old elements are retained and deprecated. So for example, ONIX 2.1 contains the (deprecated) specialized elements <EAN13> and <UPC>, but the use of the <ProductIdentifier> composite is strongly preferred. Many of the changes in 3.0 amount to removal of these deprecated elements. Thus if the implementation of 2.1 has already eliminated use of the deprecated elements and maximized the use of generalized composites (as recommended), a significant portion of the work needed to support 3.0 has already been done. If the 2.1 implementation amounts to a minimally-updated 2.0, and still uses many deprecated elements, then the migration to 3.0 will likely be more onerous. Note that ONIX 2.1 superseded 2.0 in 2003.

If migrating from ‘up-to-date’ ONIX 2.1 to 3.0, radical changes in the underlying IT system or database are unlikely to be required (circumstances vary, of course). Most of the necessary changes are likely to be in adding or improving support for multi-component, multi-item and digital products, in handling sets and series, sales rights, and – optionally – in adding support for block updates. After that, further changes are related to taking advantage of the added flexibility of ONIX 3.0, in the areas of collateral material, parallel multilingual text and international market supply details for example.

Having said this, limited development work on an existing IT system or database, simply to migrate to ONIX 3.0 may not in itself result in a system suitable for the modern publishing supply chain. Development to enable metadata to be managed in a more normalized way (where most metadata is managed once at a ‘work’ level rather than many times at a product level), and to integrate the management of e-publications with print products in a single, hybrid business process may be necessary.

‘So here is my ONIX 2.1 data. Where do I put it in ONIX 3.0?’ This is not usually a good strategy with which to approach an ONIX 2.1 to 3.0 transition. Not all data elements have direct equivalents, and the way certain types of data are included in the record has changed significantly. Nor should it be assumed that data practices that were good or acceptable in ONIX 2.1 remain good or acceptable practices in ONIX 3.0. ‘Translation’ of ONIX 2.1 into ONIX 3.0 – producing an ONIX 3.0 record based solely on the data in an ONIX 2.1 record – is not always possible and is rarely desirable.

 
Key changes between ONIX 2.1 and ONIX 3.0
2.1 3.0 Notes
<ONIXMessage> Root element: the <ONIXMessage> tag now has a mandatory release attribute and may include a namespace declaration (release was optional in 2.1). The message should not contain a DOCTYPE declaration. The use of Unicode and UTF‑8 is strongly recommended, particularly for ONIX messages exchanged internationally.
<Header> Header: some restructuring with elements renamed, and redundant elements have been removed.
<Product> Product record: a new six-part block structure within the Product record, intended to support more granular, block by block updating, is new to ONIX 3.0. The ONIX Price and Availability Update message is no longer a separate message format – it is simply a block update containing only an identification preamble (‘block zero’) and Block 6. For regularly-timetabled updates, it is possible to send a message containing no Product records (from 3.0 revision 2).
PR.1 P.1 Record reference number, type and source: no significant changes.
PR.2 P.2 Product identifiers: the Barcode element has been replaced by a new <Barcode> composite allowing barcode type and position to be specified separately, and redundant elements have been removed. No other changes.
PR.3 P.3
P.4
Product form: significant changes in the elements and coding used for multiple-item and multiple-component products with a richer <ProductPart> composite, and for digital products, including DRM, usage constraints and (from 3.0 revision 2) licensing details. There is little change in the handling of most single-component physical products. Provision has been added to allow a country of manufacture to be specified when this is required for cross-border supply.
PR.4   Epublication detail: this data element group has been deleted, since product form description for digital products is now integrated into Group P.3.
PR.5 P.5 Series: the <Series> composite in Release 2.1 has been replaced with a new <Collection> composite. This carries collective attributes (of series or sets), where they are not carried in P.6 (ie where they are not required as part of the distinctive title of the product). A new <CollectionSequence> composite can carry details of ordered collections (from 3.0 revision 1).
PR.6   Set: this data element group has been deleted. Sets are now handled in the same way as series, in P.5.
PR.7 P.6 Title: the <Title> composite in Release 2.1 has been replaced by an expanded <TitleDetail> composite. This can also include collective title elements (of series or sets) when these are required as part of the distinctive title of the product.
PR.8 P.7 Authorship: little or no significant change in the elements typically used for a personal or corporate contributor name. However the <Contributor> composite has been restructured to make it more logical, and the name identifier elements have been redefined. Associations between contributors and places can be defined in a more flexible way (from 3.0 revision 2), and the gender of a contributor persona can be specified (from 3.0 revision 3). The handling of <UnnamedPersons> has been modified (from revision 3) to make it possible for anonymous contributors to have identifiers, alternative names etc.
PR.9 P.8 Conference: redundant elements have been deleted, otherwise no change in the structure. However, from 3.0 revision 3, the entire composite has been renamed <Event> to allow more flexible use for events other than conferences (eg artistic or sporting events), and the old <Conference> name is deprecated.
PR.10 P.9 Edition: no significant change.
PR.11 P.10 Language: a new element allows script as well as language to be specified, and redundant elements have been deleted. No other changes.
PR.12 P.11 Extents and other content: all extent types are now handled in a slightly extended <Extent> composite, and redundant elements have been removed. Minor adjustments in the treatment of illustrations and ancillary content.
PR.13 P.12 Subject: both main and subsidiary subjects are now handled as repeats of a single <Subject> composite, and redundant elements have been deleted. The <PersonAsSubject> composite in Release 2.1 has been renamed as <NameAsSubject> and slightly restructured consistent with changes to the <Contributor> composite in P.7, and from revision 3 has been extended significantly.
PR.14 P.13 Audience: redundant elements have been deleted, otherwise unchanged.
PR.15
PR.16
P.14
P.15
P.16
Descriptions and other supporting text / Links to image/audio/video files: two ONIX 2.1 data element groups have been replaced by three new groups, significantly extending the capability for handling collateral materials, particularly resources made available on the web. From 3.0 revision 3, this can include a specification of the territory within which the collateral should be used.
PR.17 P.17 Prizes: one redundant element has been deleted, otherwise unchanged. From 3.0 revision 3, prizes given to authors for their whole body of work (rather than for a specific book) should be specified within <Contributor>.
PR.18 P.18 Content items: changes are limited to those which follow from the revision of some of the composites from other data element groups which are re-used here. From 3.0 revision 3, content items may have related products in addition to related works. From revision 5, content items may be both time-based (ie audio or video material) as well as paged.
PR.19 P.19 Publisher: redundant elements have been deleted. The <Imprint> and <Publisher> composites have been revised so that handling of identifiers is consistent with general ONIX practice. Provision for providing promotional and other contact details on a per-product basis has been added (from 3.0 revision 1), as has provision for providing funding details for open access publications (from 3.0 revision 3).
PR.20 P.20 Publishing status and dates, and copyright: individual date elements have been deleted and replaced by a repeatable date composite. For books published in international markets, it is no longer mandatory that there will be a single publishing status and pub date in P.20, if that ‘global’ status is unknown (a publisher would be aware of the global status, but other ONIX senders may not be). Instead, status and date can be specified for individual markets in P.25. A new element for Latest Reprint Number has been added, for use only in certain countries where this information is understood to have legal significance. From 3.0 revision 2, copyright details are more flexible.
PR.21 P.21 Territorial rights and other sales restrictions: the <NotForSale> composite has been deleted, with adjustments to the <SalesRights> composite so that all cases can now be handled within this single composite. A new <ROWSalesRights> data element has been added to define the rights associated with countries not specifically listed, which can mean an explicit statement that the rights position is unknown. The country and region elements have been grouped inside a new <Territory> composite which is also used in P.24 and P.26, so that wherever a geographical area is specified it is handled in the same way. The underlying logic, however, remains the same. Provision has also been added to allow a non-geographical restriction to be stated with date limits, and (from 3.0 revision 2), the <SalesRestriction> composite is moved inside the <SalesRights> composite to resolve issues with interpreting retailer exclusive products.
PR.22   Dimensions: the <Measure> composite has been moved to P.3, and redundant elements have been deleted. Consequently this data element group is no longer required.
PR.23 P.22
P.23
Related products: a new <RelatedWork> composite has been added as P.22. The <RelatedProduct> composite has been radically cut back, by general agreement, so that it usually carries only a relation type and an identifier. Provision is retained for carrying a product form, but this is not recommended for general use.
PR.24
PR.25
PR.26
P.24
P.25
P.26
Supplier, availability and prices / Market representation / Sales promotion information: these three groups have been significantly restructured within a new <ProductSupply> block. P.24 now specifies a territorially-defined market together with any non-territorial sales restrictions which are specific to that market. P.25 details the publishing status of a product within a particular market. P.26 details the distribution source, availability, and prices for the product within a particular market. Within the new structure, many of the most frequently used elements remain the same, though there are some detailed changes and additions, notably a new and more flexible <Tax> composite, price conditions for rentals and linked product offers, tiered pricing, and a facility for provision of prices of other, comparable products and (from 3.0 revision 2) for price identifiers. From 3.0 revision 3, the treatment of free of charge and other unpriced items is restructured, there is new provision for specifying minimum order quantities, and a new <PriceConstraint> composite can be used to specify certain contractual limitations linked to prices. In revision 4, a separate license associated with each price can be specified. The recommended treatment of reissues has been changed and the <Reissue> composite deprecated.
Attributes The meaning of the datestamp attribute has been slightly modified.
Multilingual text Most textual data elements are repeatable if the text is supplied in multiple parallel languages (from 3.0 revision 1). Note that named entities for non-ASCII characters – for example &ndash; or &uuml; – are not supported in 3.0. Use native characters in your chosen encoding, or numerical character references (eg &#x2013; or &#252;) instead. The five built-in XML entities including &amp; and &lt; are exceptions.
Use of XHTML 1.1  Allows the use of the <ruby> tag in XHTML marked up textual data (from 3.0 revision 1). For textual data elements that do not support XHTML markup, Unicode interlinear annotation delimiters (characters &#xfff9;, &#xfffa; and &#xfffb;) may be used to delimit text glosses.
XML schemas XML developers can choose between DTD, XSD or RNG expressions of the ONIX data structure and of the codelists, for validation. An extended validation tool based on XSD 1.1 with embedded Schematron rules is also available.
UML diagrams A data model, documented as a set of UML class diagrams, is available for application developers. Contact info@editeur.org for details.
Application notes A selection of notes on specific aspects of ONIX 3.0 practice are available on the EDItEUR website, for example How to describe sets, series and multiple-item products in ONIX 3.
Acknowledge­ment message Can be used to confirm receipt or pass status and error information from recipient of an ONIX message back to its sender.
This Guide Publication of a global implementation and best practice guide to accompany the Specification is intended to reduce country-to-country variation in the implementation of ONIX 3.0 and ensure that metadata can flow freely in an increasingly global metadata supply chain. Note however that although national best practices follow this international guide closely, local practices do sometimes vary, and some ONIX national groups provide modified guidelines for use within a particular country.