ONIX for Books Implementation and Best Practice Guide Release 3.0.7

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, implementers 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 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 – the latest that is compatible with ONIX 2.1 – 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).

Introduction to Release 3.0 revision 7 (3.0.7)

This revision of the Guide includes the major new <PromotionDetail> data block introduced in Release 3.0 revision 7 (3.0.7). Full use of this new Block 7 (which occurs between Blocks 2 and 3 in message order) requires the use of Codelists Issue 47 or later.

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.; 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.
31 Oct 2019: Revised release, to accompany Release 3.0 revision 7 of ONIX for Books.; Added section for Block 7 <PromotionDetail> guidance.; Revised ‘At a glance’ diagrams and data examples to incorporate new region options in <Language> and <Prize>, and changes in <CopyrightStatement>.; Added examples of block updates.; Extension of trade-only pack example.; Minor updates to align with Codelists Issue 47.

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:

the Specification is available as PDF and HTML files;
this Guide is only available as an HTML file;
XML schemas are available in DTD, XSD and RNG formats;
an advanced XSD for extended validation is available;
- this so-called ‘strict’ XSD requires XSD 1.1, and is not compatible with all validating parsers;
codelists are available in human-readable PDF and HTML, as CSV, TXT (tab-separated) and a proprietary XML format for integration into proprietary applications, and DTD, XSD and RNG formats to work with the main ONIX schema files;
- a multilingual online codelist browser is available at https://ns.editeur.org/onix;
the Acknowledgement Specification is available as PDF and HTML files;
- accompanying DTD and XSD schemas are available.

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’.

All documentation and tools are available free of charge, no registration process is necessary, and there are no charges or royalties payable if you use the ONIX framework – although use is covered by EDItEUR’s highly permissive license.

All implementers should take care to use the latest documentation – the Specification, this Guide, and the XML schemas and Codelists available from the EDItEUR website.

Wherever possible, organizations that implement ONIX for Books should establish contact with a National Group, and are encouraged to take an active role within such groups.

Implementers should join the onix@groups.io e‑mail listserver (subscribe by e-mailing the group). This is a discussion forum for ONIX-related questions, and any updates to documentation, schemas and codelists are announced here. Implementers may also wish to subscribe to EDItEUR’s regular newsletter.

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:

a publisher needs to provide information about its catalog of products to a distributor, wholesaler, retailer or other supply chain partner;
- this can include both current and forthcoming products;
- it may cover basic product information and a wide range of collateral material;
- the scope extends over the full lifecycle for book, e‑book and other products (ie it includes post-publication updates to price and availability);
a specialist data aggregator, distributor, wholesaler or other organization providing data services needs to receive metadata from many sources, and redistribute consolidated data about products to supply chain partners;
- this may include managing the ‘authority’ of data received from multiple data suppliers. Any data recipient might receive data about a particular product from multiple sources – recipients need to manage the data according to its source, currency and reliability;
a distributor, wholesaler, retailer or library needs to receive metadata from its suppliers to populate its internal or customer-facing product catalog, and to enable its distribution and retail business;
- again, recipients may need to manage data about a particular product from multiple suppliers;
an organization needs to transfer detailed product metadata between its internal applications, or between an internal application and an outsourced service.

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 just ‘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 just 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).

A word on terminology. As noted above, ONIX draws upon the <indecs> framework. ONIX Product records describe <indecs> manifestations – these are ‘products’. A hardback, a large-format paperback, mass-market paperback, PDF e‑book, EPUB e‑book are all distinct manifestations, and in ONIX, each of these must have a separate Product record and a separate identity. ISBNs identify manifestations. There may of course be thousands of identical copies – instances or occasionally, items – of any one of these products or manifestations, but as far as the supply chain is concerned, these multiple instances of each product are identical and interchangeable (ie they are fungible).

Products are the manifestations of works – abstract entities comprising the intellectual property embodied in a manifestation. Each product manifests a work, and a work may be made manifest in several products. Works are also related to other works: a new work can be derived from an existing work by translation, revision, abridgement, compilation and so on. A third edition is a new work, derived (by revision) from the preceding second edition work, and a translated novel in English is a new work that is derived (by translation) from the original work in another language. ISTCs identify works.

Each manifestation is a set of essentially identical instances (or copies), and each work is a cluster of ‘identical’ manifestations (identical at least in terms of their content). Works themselves also gather in groups or chains, related by their derivation from earlier works.

Note that in library contexts derived from FRBR, the term expression is sometimes used to denote what ONIX and <indecs> define as a work, and a FRBR work is a broader and yet more abstract entity from which related expressions (ie the original, translated and abridged works above) are derived. Within the <indecs> model, while such a broad entity might plausibly be defined, it carries no relevant metadata.

The metadata communicated in a single ONIX Product record describes a single manifestation. However, this does not require that metadata be managed entirely on a product-by-product basis in a publisher or retailer database. The message schema used for communication, the database schema used for data management, and the underlying abstract data model are not usually the same. Some metadata elements are managed at manifestation or product level – the product form or price for example, since they are part of what distinguishes one manifestation from another. Other elements are more naturally managed at a higher level – the title, contributors or edition number can often be ‘inherited’ from the work to each manifestation, since they do not usually vary between manifestations of a single work (though there are circumstances where a single work may be published under two different titles, or an extra contributor such as an audiobook reader might need to be added to one manifestation but not another).

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.

ONIX data depends on semantic precision, and broad agreement across the metadata supply chain. A data sender should ensure that a <Subtitle> data element contains the true subtitle of the book. A date labelled with <PublishingDateRole> 01 (ie publication date) must be the publication date as it is defined within ONIX, not the date your organization chooses to call the ‘pub date’ (which may have an entirely different definition). A <PriceAmount> must be interpreted by the recipient in accordance with any associated Price type and qualifiers, territory, currency, conditions and constraints etc.

Supplier and recipient should also take care when choosing not to support particular data elements. Some can be ignored, provided they are not important for the business purposes of sender and recipient. But others – which might appear unimportant – qualify the meaning of other, more obviously vital data. As an example, <PriceQualifier> can indicate a price is limited to libraries, or to members of some particular group, while a higher price pertains to general consumers. Less obviously, a <PublishingDate> composite is not used only for publication dates and sales embargoes: it may contain a date that embargoes public listing of the product (eg on a website). Senders and recipients must discuss this prior to establishing a data feed, to ensure all critical elements can be correctly taken into account.

Every ONIX recipient should be able to receive and process any correctly-constructed ONIX message, irrespective of whether they use every particular data element. For data senders, there should be no need to omit or include elements or whole composites, or modify the data in those elements, on a recipient-by-recipient basis. As a simple example, if a particular retailer requires the book’s subject expressed using a code from a particular subject classification scheme, it should not reject messages that also contain codes from other schemes. At the very least, a recipient should be able to ignore non-critical elements and composites it does not wish to process. In a more complex case, there are some elements of ONIX data that may apparently be communicated in two different ways, but with the ‘correct’ option depending on the exact circumstances: for example, a collection title might be included in Group P.5 or in Group P.6. Suppliers and recipients should ensure they enable both options, rather than supporting only one and thus forcing business partners to use an incorrect option.

There is however, an occasional requirement to vary the records included in a particular data feed – for example, removing a retailer-exclusive product from data sent to other retailers (prior to publication of that product). Often the best way to arrange this is for a data sender to establish a generic data feed suitable for all recipients (and without those retailer-exclusives), and then to set up supplementary mini-feeds containing only the exclusives, one mini-feed per partner retailer.

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 implementers, 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.

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 attribute names, codes drawn from the codelists, numerical metadata and most dates remain the same. These use only characters from the ASCII character set, which can be represented easily in virtually any encoding.

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>`

30 ONIX XML hints and tips

ONIX messages should use the UTF‑8 character encoding for messages intended to be exchanged with a global range of recipients, and should include an explicit encoding declaration. UTF‑8 allows (effectively) any character, in any language or script, to be included within the ONIX data, without having to use numeric character references (and note also that named character entities like ‘é’ cannot be used in ONIX 3.0). For the truly technical, use Unicode Normalisation Form C;
but for practical purposes, data senders should still maintain some control over the range or repertoire of characters used in their data – the Windows‑1252 or ISO 8859‑15 character repertoires would be good choices in North America and Western Europe, for example. While the message should ideally use a Unicode encoding, with a limited character repertoire a matching encoding such as the Windows‑1252 or ISO Latin‑9 encodings is acceptable. A Russian, Japanese or Arabic ONIX user would choose a different repertoire of characters, and may still encode them for transmission in UTF‑8, or might use another widely used encoding (eg Windows‑1251 or ISO 8859‑5 for Cyrillic, ISO 8859‑6 or Windows‑1256 for Arabic);
Whatever the chosen character encoding, the XML encoding declaration in the first line of the file must match the encoding that is actually used;
all ONIX markup – the various tags used in an ONIX message and all attribute names – and all code values in the ONIX codelists must use only ASCII characters (Unicode characters 32 to 126). Numeric dates and integer or real number data elements must also be limited to a subset of ASCII characters (the digits 0–9, plus the period character ‘.’ as the decimal separator for real numbers, and ‘+’, ‘-’, ‘T’ and ‘Z’ in certain date or datetime elements. Use of the comma as a decimal separator in real numbers is not valid);
ONIX implementers must pay attention to case, in both markup and data. XML is case sensitive: <Contributor> is different from <contributor>. But case sensitivity also extends to codelist values – it’s BC, not bc or Bc in <ProductForm> – and to codes derived from external lists such as the ISO Country, Currency, Language and Script codes – it’s FR (country), EUR (currency), fre (language) and Latn (script);
the order of the XML data elements in the message is critical. In any Product Record, elements must occur in the correct order, as defined in the ONIX schemas and DTD. For example, all elements from Group P.12 must occur before any elements from Group P.13, and within an <Audience> composite in P.13, <AudienceCodeType> must come before <AudienceCodeValue>. Out-of-order elements will make a message unusable;
in contrast, the order of particular repeats of repeatable data elements or composites is not meaningful – which is why <Contributor> composites contain sequence numbers to make the ordering or priority of multiple contributors explicit. So <EditionType> LTE (large type) followed by <EditionType> ABR (abridged) means the same as it would if the order of the two elements were reversed. However, it’s good practice to assume that recipients may inadvertently use the order of repeatable data elements such as <Subject> to indicate relative importance in their internal systems, so put the ‘most important’ first;
senders should ensure that their ONIX messages are structured correctly by validating them using the XSD or RNG schemas;
however, ONIX is not defined by the schema files alone, and implementers should also ensure messages meet the other requirements of the Specification too. One way of checking many of these other requirements is by validating with the ‘strict’ XSD, an enhanced schema that is able to check certain business rules and internal dependencies. (Note the strict XSD is not compatible with all XML parsers – only Saxon, Xerces, Raptor are known to work, and many common tools based on libxml do not work);
ONIX messages should make use of attributes – language, textformat, textcase, dateformat and so on – to provide ‘data about metadata’. In a few circumstances, use of such attributes is mandatory;
senders should avoid the continued long-term use of deprecated data elements or deprecated codes from codelists (even though they remain valid);
both senders and recipients should keep reasonably up-to-date with new issues of the ONIX codelists (these are typically released quarterly), and with minor revisions of ONIX 3.0 itself (3.0.1, 3.0.2… etc);
in particular, recipients should have the ability to ignore optional data elements and composites added in later revisions, or other data elements that they do not themselves use. In general, if a recipient implements version 3.0.5, a message that includes a data element added in revision 3.0.6 should not prevent ingestion of the remainder of the data. And if a recipient chooses not to make use of (for example) <CountryOfManufacture>, its inclusion should not cause rejection of the data – recipients should ignore most valid ONIX data elements that they choose not to use, and should not ask for them to be removed from the data feed. Exception – elements that modify the meaning of other data, such as Sales restrictions or Price qualifiers which modify the Sales rights and Price types. These modifiers cannot simply be ignored;
many textual data elements have recommended maximum character lengths that should not be exceeded by data senders. Meanwhile, data recipients should be generous in accepting data that exceeds the limits whenever they can;
messages must never include any empty XML elements, with the exception those few specifically defined to be empty such as <NoEdition/> or <MainSubject/>. If there’s no data available, you should leave the entire data element out. Of course that means that if there is no data available for a mandatory element, you may need to omit a whole composite. There are a very few data elements without which a sensible Product record cannot be constructed, but one such is <ProductForm>: if you don’t know what form the product is intended to take, you cannot send an initial ONIX message to ‘announce’ it;
to avoid any doubt, those elements defined to be empty can be expressed as either <NoEdition/> or as <NoEdition /> – the extra space is optional in XML syntax, but the version without a space is more common in ONIX (one exception to this is the <br /> tag in any embedded XHTML, where an extra space is strongly recommended for compatibility reasons). And while <NoEdition></NoEdition> is syntactically identical to <NoEdition/>, it should be avoided in ONIX;
ONIX senders should avoid extraneous white space characters (particularly spaces and tabs) between data elements: while examples in this document are indented for readability and to emphasize structure, don’t indent real messages with tabs or extra spaces. (Note that even new line or return characters between data elements are unnecessary, but can be useful if ONIX messages ever need to be read ‘by eye’ in a text editor.) Additional white space characters can increase the amount of memory and time the recipient requires to parse the XML, and in some circumstances can even count against the suggested length limits on text fields;
for similar reasons, senders should not include any leading or trailing white space within data elements – avoid ‘<b012> BC </b012>’ or ‘<KeyNames>Winstanley </KeyNames>’, and use ‘<b012>BC</b012>’ and ‘<KeyNames>Winstanley</KeyNames>’ instead. In fact, leading or trailing white space in data elements using a codelist (eg <b012>) will not validate using the ONIX 3.0 XSD schema, so must not be included;
simple coded, numeric or textual data elements (ie those in which XHTML markup is not enabled) must not contain return or new line characters, so avoid formatting (‘wrapping’) XML data to a maximum width – this inserts unwanted return or new line characters automatically, and the wrapped XML file will not validate. Note that ONIX occasionally looks as if simple data elements contain return characters, like this:
    <b012>
        BC
    </b012>
particularly when viewed in a web browser. The extra line breaks and indentation are added by the browser itself, for legibility purposes, and must not be present in the ONIX file;
and in those textual data elements where XHTML markup is enabled, white space characters such as tabs or new lines within a data element will not be treated consistently by all recipients, so do not rely on multiple spaces, new lines, carriage returns or tab characters to align text or create multiple paragraphs within a text data element such as <Text> – you should use simple XHTML markup instead;
you should not use <![CDATA[ … ]]>, unless there is a specific need to embed HTML markup within the ONIX message. It is very poor practice to surround any ordinary data (plain text, codes from codelists, numbers or dates) or XHTML-tagged text with <![CDATA[ … ]]> tags: it is entirely unnecessary, and can lead to the possibility of inserting bad data into your trading partners’ systems – your unnecessary CDATA tag may circumvent their data validation process. And if you’re using <![CDATA[ … ]]> with HTML tagging, consider whether you could use XHTML (without CDATA) instead;
you should limit HTML and XHTML markup elements to a simple subset of possible tags – to be cautious, use only <p>, <br />, <em>, <strong>, <i>, <b>, <cite>, <ul>, <ol>, <li>, plus possibly <dl>, <dt> and <dd>, <sub> and <sup>, and <ruby>, <rb>, <rp> and <rt> in specialized circumstances;
in environments where ONIX 3.0 and earlier versions are in parallel use, you must ensure that codes valid only in 2.1 are used only in 2.1, and ONIX 3.0-only codes are used only in 3.0. This can be an issue where the codelist used with a particular data element has changed (eg <ProductForm> uses List 7 in 2.1, but List 150 in 3.0), and where new codes have been added to a shared list after Issue 36 (eg Contributor role code B30 in shared List 17 is not valid in ONIX 2.1, because it was added at Issue 37);
you should not ascribe meaning to special numbers or dates, most especially when there are defined methods within the standard to convey the same meaning. For example, a workaround using a dummy publication date such as 20991231 to represent ‘postponed indefinitely’ may be acceptable in an internal system, but in ONIX, it’s not. Use Publishing status code 03 – Postponed indefinitely – and omit the publication date;
aside from the initial <?xml … ?>, you should not include XML processing instructions (anything surrounded by <? … ?>) in the ONIX message;
- an XML processing instruction may be necessary to enable Schematron rules using the ‘strict’ schema;
don’t include more than a small number of XML comments () in a production file. Liberal comments can be useful in initial phases of testing ONIX output, where the file may need to be checked ‘by eye’, but these should be removed before the output is put into production use. Place any comments between ONIX data elements, not within them, even though the latter might technically be valid XML (ie avoid <ProductForm>BC</ProductForm>);
data recipients should avoid imposing non-standard requirements or limitations on data element content, and must not require non-standard data elements be inserted into ONIX messages. ONIX messages should be broadly interoperable;
a single ONIX message typically consists of many product records. Do not send an update of multiple product records as a series of many files each containing a single record;
implementers should consider joining the ONIX implementation forum (subscribe by sending a blank e-mail to onix+subscribe@groups.io). Announcements about new codelists, new revisions of ONIX are posted to this forum;
all implementers should note the license agreement that governs the use of ONIX (DOI: 10.4400/nwgj).

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 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–7 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–7 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 and confirms 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 from a block update 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 and 7 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: records for complex non-fiction with chapter-level metadata (in Block 3) and an extensive table of contents, comprehensive Product records in languages other than English and non-Latin based scripts may be much 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 just 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 records	reference names (kB)	short tags (kB)	reference names zipped (kB)	short tags zipped (kB)
1 (sample file)	17	13	5	5
100 (production file)	1405	1117	175	170

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 implementers 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 some cases, when EDItX or EDI is in use for post-publication price and availability and the risk of conflict cannot be eliminated , 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 < and &, 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.

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 just a technical 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, and depend as much on staff skill and understanding as on technology. 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

Every ONIX for Books message must contain message header information in the <Header> composite. The header:

must specify the sender of the message in a <Sender> composite;
- <Sender> should contain an organization name, plus any applicable organization identifiers;
- details for a technical contact able to deal with queries about the message should be included;
should specify the recipient(s) of the message in an <Addressee> composite when the ONIX message is tailored for a specific addressee, for example through a specific selection of products that would not be suitable for other recipients;
should specify message sequence number in <MessageNumber>, particularly when the ONIX message is a ‘delta file’. Its role is vital in detecting missed messages;
must specify the date the message was sent, and should specify the time in UTC;
should not include various defaults that control how certain elements in the remainder of the message are interpreted: equivalent information should be included within each Product record instead.

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.

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 returned 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.

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.

The Message sequence number and the Sent date time are critical to recipients, to ensure messages are processed in the right order. Most ONIX data feeds are a mix of full files and delta files (incremental updates):

a recipient must process full files, unless the sender has deliberately given it the same sequence number as the latest delta . Except in this one exceptional circumstance, a recipient cannot rely on processing only the deltas, as there may be updates within the full file that would otherwise be missed. Even in this exceptional circumstance, processing the full file remains advisable;
a sender should avoid sending a full file too often (perhaps once a week at most) to avoid unnecessary processing of large numbers of unchanged records by recipients. Updates can be sent as often as necessary – daily is common, but intra-day updates are perfectly plausible;
- intra-day updates in a feed require hour and minute precision in <SentDateTime> in all messages in the feed;
- note that if generation of the ONIX file takes a significant time, <SentDateTime> should reflect the beginning of that process;
if a recipient receives a full file, there is no point in processing any delta files that precede the latest full file;
- but all incremental updates that follow the full file must be processed in order, in order to guarantee the feed’s integrity;
the sender should also add <MessageNumber>. This can be checked by the recipient to ensure that no incremental update is missed out. If a recipient receives and processes delta message number 135, without previously processing message 134, there is a problem which will most likely persist until processing of the next full file;
- the recipient should request re-transmission of message 134, then process the messages in the correct order;
as a double-check, the sender and recipient should agree a filenaming convention to include the sequence number, but the sequence number within the file should be treated as the authoritative sequence number.

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–7 (each Block is optional in a ‘block update’, but at least Blocks 1 and 4 are required – and 6 is normally expected – in a normal Product record).

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–7. 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 lies 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 more succinctly, ‘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–7 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–3and 5–7 should continue to be used unchanged. This type of Product record may be supplied only in the context of a ‘delta’ feed, and the Product record itself 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 data supplied in Blocks 1–5 and 7, 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

Every ONIX for Books Product record must contain elements from Group P.1. The record:

must specify the identifier for the Product record (not for the product) in the <RecordReference> element. This is critical: the Record reference allows a recipient to match an update with an existing record;
must specify the notification type of the Product record in the <NotificationType> element;
should specify a reason for deleting the whole record if <NotificationType> indicates the record is a deletion;
should specify the record source type and name in <RecordSourceType> and <RecordSourceName>, plus any applicable organization identifiers. This is particularly important where the message contains aggregated data from a variety of sources.

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>`

minimal block update to a Product record, ‘adding’ an extra identifier
using Reference names
`<Product>`
`<RecordReference>com.mypublisher.01734</RecordReference>`
`<NotificationType>04</NotificationType>`
`<ProductIdentifier>`
`<ProductIDType>03</ProductIDType>`
`<IDValue>9780001234567</IDValue`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9780001234567</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>24</ProductIDType>`
`<IDValue>9789991234564</IDValue>`
`</ProductIdentifier>`
`<!-- blocks 1–7 not updated -->`
`</Product>`

using Short tags
`<product>`
`<a001>com.mypublisher.01734</a001>`
`<a002>04</a002>`	Block update
`<productidentifier>`
`<b221>03</b221>`	‘Existing’ GTIN-13
`<b244>9780001234567</b244`
`</productidentifier>`
`<productidentifier>`
`<b221>15</b221>`	‘Existing’ ISBN
`<b244>9780001234567</b244>`
`</productidentifier>`
`<productidentifier>`
`<b221>24</b221>`	‘Added’ co-publisher ISBN
`<b244>9789991234564</b244>`
`</productidentifier>`
`<!-- blocks 1–7 not updated -->`
`</product>`

Note that most block updates are more extensive than this. The example Product record does not contain any of <DescriptiveDetail>, <CollateralDetail>, <PromotionDetail>, <ContentDetail>, <PublishingDetail>, <RelatedMaterial> or <ProductSupply>. These are the seven main blocks, and each is optional in a block update.

The ‘effect’ of this block update when processed by the ONIX recipient should be that the bibliographic, marketing, and supplier and price information held by the recipient (which must have been received in previous ONIX messages) is retained, unchanged, and the additional co-publisher ISBN (which was not in the previous ONIX) is added to the recipient’s database.

In contrast, if the message above was not a block update (it would have a different <NotificationType>), then such a message consisting only of block zero implies deletion of all information previously held, irrespective of which block it was supplied in, and replacement with only the data supplied in the new message. All that would remain in the recipient’s database would be the supplied GTIN and ISBNs. In fact, this hypothetical ONIX would be invalid, because Blocks 1 and 4 are mandatory (except in a block update), and Block 6 is normally expected to be included too.

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–7 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.

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 any errors that build up in the record are 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. However, it is a common error for publishers and suppliers 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. As a result of frequent misuse, data recipients are wary of full deletion. 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 merely 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.


: The preferred <RecordSourceIDType> for international use is the GLN (code 06 from List 44).

P.2 Product identifiers

Every ONIX for Books Product record must contain elements from Group P.2. The record:

must specify at least one unique identifier for the product, in the <ProductIdentifier> composite;
if the product carries an ISBN, should include the product’s ISBN labelled as a GTIN-13 with <ProductIDType> code 03, and the ISBN labelled explicitly as an ISBN in a separate repeat of the <ProductIdentifier> composite with <ProductIDType> code 15. Similar best practice applies to ISMNs on notated music products;

The <Barcode> composite is not a ‘best practice’ globally, but is recommended for physical products available in North America and does no harm to include in other markets.

Common issues in Group P.2:

incorrect use of ISBNs, for example using the same ISBN for multiple e‑book file formats. The use of ISBNs should be aligned with guidance in the ISBN Manual (available in many languages from the International ISBN Agency);
inclusion of hyphens or spaces within ISBNs;
erroneous assumption that an ISBN is required. ONIX requires at least one identifier, but that identifier does not have to be an ISBN. While most ONIX records do describe a product with an assigned ISBN, ONIX is routinely used to describe products that do not have ISBNs, for example stationery and diary items which carry GTIN-13s or proprietary identifiers instead of ISBNs;
proprietary product identifiers provided without an <IDTypeName>, or with an <IDTypeName> set as a default by the application (so that every installation of that application at different companies uses the same name);
misleading barcode information (eg implying an electronic product carries an barcode). Note also that <PositionOnProduct> must be included in <Barcode> if <BarcodeType> indicates the product carries a barcode, and omitted if it indicates it does not.

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.


: 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 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).

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.

The <DescriptiveDetail> composite that forms Block 1 of a Product record is optional, but should occur in all ONIX for Books Product records, unless:

the Notification type is 04 (a block-level partial update) and no data elements in Block 1 have been updated since a previous message;
the Notification type is 08 (notice of sale of a product from one publisher to another), in which case Blocks 1–3 and 5–6 are unnecessary;
the Notification type is 05 (a record deletion), in which case Blocks 1–7 are wholly unnecessary.

When present, the Block must include, at minimum, the <ProductComposition> and <ProductForm>, but should normally contain the main physical or digital details of the product and most of the elements of bibliographic description.

P.3 Product form

If the Product record contains a <DescriptiveDetail> composite, then that composite must contain some data elements from P.3. The <DescriptiveDetail> composite:

must include the <ProductComposition> and <ProductForm> elements:
- if the record represents a multi-component product or multi-item pack or collection with <ProductComposition> codes 10, 11, 30 or 31, then P.4 Product part information should also be included in the Product record;
should include any relevant <ProductFormDetail> and (where it conveys an important product attribute) <ProductFormFeature> information:
- for a digital product, <ProductFormDetail> should specify the file format. Where file formats are versioned (eg EPUB 2, EPUB 3) then the version information should be included in a <ProductFormFeature> composite;
- <ProductFormFeature> should include any relevant hazard warnings and product safety information;
for a physical product:
- should describe any packaging using the <ProductPackaging> element;
- should include details of the product content using the <PrimaryContentType> and <ProductContentType> elements, particularly if the product is not a simple textual product;
- should include linear dimensions, and whenever possible, the weight of the product using the <Measure> composite;
- should include the country of manufacture;
for a digital product:
- should include details of any technical requirements (hardware or software) etc in the <ProductFormFeature> composite;
- should include details of technical protection measures incorporated in the product, and any usage constraints (whether enforced by technical measures or not), using the <EpubTechnicalProtection> element and the <EpubUsageConstraint> composite;
- should include details of the product content using the <PrimaryContentType> and <ProductContentType> elements, particularly if the product is an ‘enhanced e‑book’ or is not a simple textual product;
for a cartographic product should include the <MapScale> data element.

Common issues in Group P.3:

use of generic product form codes such as BA (‘book’). This may be acceptable at an early stage of product planning, but retailers require more detailed codes such as BB or BC (hardback or paperback) before placing orders;
critical missing details such as e-publication file type in <ProductFormDetail>, hazard information in <ProductFormFeature>, or country of manufacture;
missing <ProductPart> information for multi-component and multi-item products;
inconsistency, for example between a <ProductForm> that specifies an e-publication and <Measure> that specifies a physical size, or more subtly between <ProductComposition> and <ProductForm> or between a <ProductForm> and a <ProductFormDetail> that lacks an affinity for that product form;
physical dimensions in inches and ounces only. Use millimeters and grams for all countries, and additionally provide inch and ounce measurements if the product is for sale in the US;
confusion between trimmed page size and overall dimensions of a book. While the former is used when publishers specify the size of a book product to the printer, the latter is required by all other parties in the supply chain;
confusion between <CountryOfManufacture> and <CountryOfPublication>;
dummy data, perhaps derived from some default template in an internal IT system and intended to be overwritten for each actual product, and which is never corrected;
timing: some publishers are reluctant to provide early information on weight, for example, but it’s vital for online retailers and mail-order. Estimated weights (calculated from the height, width, production extent, paper weight, cover weight etc) are acceptable prior to physical manufacture, and may be replaced by a measured weight after printing and binding.

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 <ProductPart>, 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-Audio	AC	A101–A102
Digital audio files	AA, AE, AJ–L, AZ, D, E	A103–A112 A201–A212
All audio	A, D, E*	A301–A304
Paperback books	BC	B101–B107 B113–B114, B116–B118 B504
Hardback books	BB	B115 B306–B307, B315 B401–B402
Loose leaf	BD	B301–B303
Spiral-bound	BE	B311–B314
Fine binding	BG	B308–B309 B403–B406
All printed books	B*	B108–B112, B119–B130 B201–B215 B304–B305, B310 B409–B415 B501–B503, B505–B510 B601–B602 B701–B707
Digital video files	D, E, VA, VZ	D101–D105
Digital on carrier	D*	D201–D207 D301–D316
e‑books and ‘apps’	D, E	E1xx E2xx
Calendars	PC	P101–P113
Calendars or organizers	PC, PS	P114
Stationery	PA, PB, PF, PL, PR, PS, PZ	P201–P204
Analogue video	VA, VI–K, VZ	V201–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:

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.

<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	NAV
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).

California Proposition 65 warning
using Reference names
`<ProductFormFeature>`
`<ProductFormFeatureType>12</ProductFormFeatureType>`
`<ProductFormFeatureValue>21</ProductFormFeatureValue>`
`<ProductFormFeatureDescription>WARNING: This product can expose you to chemicals including 2,4,6-Trinitrotoluene, which is known to the State of California to cause cancer.</ProductFormFeatureDescription>`
`</ProductFormFeature>`

using Short tags, with additional identification of the specific chemical
`<productformfeature>`
`<b334>12</b334>`	CPSIA or other US hazard warning
`<b335>21</b335>`	California Proposition 65 warning
`<b336>WARNING: This product can expose you to chemicals including 2,4,6-Trinitrotoluene, which is known to the State of California to cause cancer.</b336>`	Text of warning (long form, as mandated at www.P65Warnings.ca.gov)
`</productformfeature>`
`<productformfeature>`
`<b334>12</b334>`
`<b335>23</b335>`	California Proposition 65 chemical name
`<b336>2,4,6-Trinitrotoluene</b336>`	TNT!
`</productformfeature>`

It is unlikely that ordinary book products require such warnings, but warnings may be required on certain bundled products.

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:

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 merely 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.


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

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 even in both USA and Canada only), 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 1⁄16in. 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 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.

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 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.

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.

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.

It is also possible to supply a proprietary product classification code using code 07 from List 9 in <ProductClassifictionType> (‘Sender’s product category’), and in this case a name for the proprietary scheme should be included in <ProductClassificationTypeName>. Details of the proprietary scheme must of course be shared with the intended recipient of the data in advance.

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

The <ProductPart> composite:

should be used if <ProductComposition> indicates the product is a multi-component or multi-item product (ie with codes 10, 11, 30 and 31 from List 2). <ProductPart> should not be included in records with other <ProductComposition> code values;
should include the <PrimaryPart/> flag to indicate whenever one specific part is deemed the most important of the several items in the product;
should use the <ProductIdentifier> composite to provide separate identifiers for each item in the product, whenever such identifiers exist. This is vital where those items are also available as individual products. Where separate identifiers are not available, parts may be described in groups of similar Product form;
must specify a <ProductForm> for each item (or group of items) in the product;
should include any relevant <ProductFormDetail> and (where it conveys an important item attribute) <ProductFormFeature> information;
must use either <NumberOfItemsOfThisForm> or <NumberOfCopies> to specify the number of items in the multi-item product;
should include the country of manufacture for each item within the product, unless it is supplied for the product as a whole in P.3.

<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.

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:

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;
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:

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;
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.

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 does not indicate there is no <Collection> composite in P.5. It 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). 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.

A <Collection> composite:

should be used to describe the collective identity a product shares with other products in a collection, except when that collective identity is fully described in P.6;
must include a <CollectionType> to indicate whether the collection is prescribed or ascribed;
should include any relevant collection identifiers (such as an ISSN or a series identifier issued by a national library) in one or more <CollectionIdentifier> composites;
should include any shared titles for the collection in one or more <TitleDetail> composites, unless they are included in P.6;
- include the collection title in P.5 if the product title is distinctive enough on its own;
- include the collection title in P.6 if the product title alone is not distinctive enough;
ordered collections should include the <CollectionSequence> composite, to specify the ordinal position of the product within the collection, particularly where the ordinal position is not trivially discernible from the title elements (eg where the <PartNumber> includes words, roman numerals, or where the product is part of a subcollection).

A <NoCollection/> flag should be included in records that contain neither a <Collection> composite nor any collection description in P.6.

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).

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</x329`	Publisher 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 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 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).

There must be at least one <TitleDetail> composite, to carry the primary title of the product. The composite:

must include a <TitleType> and typically this should indicate it is a distinctive title;
must carry one or more <TitleElement> composites carrying details of the product title;
should separate any prefix to the title into the <TitlePrefix> element, or indicate there is no prefix using <NoPrefix/>, most especially in languages that ignore articles (eg A, The) or other prefixes for sorting purposes;
should separate any subtitle into the <Subtitle> element;
should include any collection-level title details that are not included in Group P.5.
- include the collection title in P.5 if the product title is distinctive enough on its own;
- include the collection title in P.6 if the product title alone is not distinctive enough;
if collection-level title details are provided in P.6, they should be differentiated from the product-level title details in a separate <TitleElement> composite;
titles should not carry extra information about the product form, edition etc (one exception: the distributor’s title often combines an abbreviated title, edition, product form).

Where the product is also known under an alternative title, an abbreviation or a translation of the title, the other titles should be provided in addition to the primary title, in separate repeats of the <TitleDetail> composite.

Common issues in Group P.6:

using P.6 for all collection titles, irrespective of whether the product title is distinctive or not (where the product title alone is distinctive enough, then the collection title should be specified in Group P.5);
inclusion of a collection title as part of the main title. Collection titles should be provided in a separate <TitleElement>, either in Group P.6 where the collective identity is an integral part of the title, or in Group P.5;
inclusion of product form, edition or other extraneous information within the title or subtitle;
use of the <Subtitle> element to carry translation or edition information;
use of <Subtitle> to carry a marketing message. Retailers and librarians consider promotional subtitles that do not reflect the text on the book’s title page a serious problem. Use <TextContent> in Group P.14 with <TextType> code 10 for short promotional messages.

<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 legacy 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 & 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 & 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

Each contributor to a product should be named within a <Contributor> composite. The composite:

should include a sequence number to indicate the order in which multiple contributor names should be presented;
must indicate the role of that contributor in the creation of the product;
should carry any available identifiers for the contributor in the <NameIdentifier> composite;
should carry the name of the person or corporate contributor in the form it appears on the product, or an <UnnamedPersons> element;
- personal names should be carried in one or more of the following forms (in order of preference):
  1. a fully structured name using P.7.11–P.7.18;
  2. an inverted name using <PersonNameInverted>;
  3. the contributor name in <PersonName>;
- corporate names should be carried in <CorporateName> and ideally also in <CorporateNameInverted>, particularly if the name includes a prefix that should be ignored for collation;
- there should be an <UnnamedPersons> element for contributors unnamed because their identity is unknown, who wish to remain anonymous, or who are unnamed as a matter of policy (eg ‘no more than three named authors’);
should include an <AlternativeName> composite if the form of a name that appears on the product is not the usual or most familiar form used by that contributor.

It is always extremely valuable to provide a short biographical note for named contributors. Literary prizes awarded to contributors for their whole body of work are also valuable (though note that prizes awarded for the specific book are listed in Group. P.17). The <ContributorPlace> composite is also recommended, to help promote ‘local’ contributors.

In some cases, a machine-generated list of individual contributor roles and names may not produce a satisfactory description of the authorship for display to a customer. In this event, a <ContributorStatement> should be included. Where it is provided, recipients should use <ContributorStatement> for display purposes.

If there are no contributors to a product (either in P.7 or in Group P.5, where contributors to a collection can be listed), then the <NoContributor/> empty element should be included instead.

Common issues in Group P.7:

providing only <PersonName>;
incorrect placement of commas in <PersonNameInverted>;
supplying only <KeyNames> and omitting other parts of the structured name;
use of <PrefixToKey> to hold ‘middle names’ or initials. Middle names and initials should be included in <NamesBeforeKey>;
incomplete lists of contributors. Use <UnnamedPersons> with code 03 – et al – if there is a limit on the number of contributors that can be listed;
inconsistencies in contributor names between different versions of the same book (between hardback and paperback, for example);
confusion over contributor roles – for example the reader of an audiobook should use the role code E07 (Read by), not E03 (Narrator), and the code B01 (Edited by) refers to the editor of a collected works, not the internal commissioning or desk editor employed by the publisher;
reliance on return or new line characters to format multiple paragraphs within <BiographicalNote>. Use HTML or XHTML markup instead;
HTML or XHTML markup within <BiographicalNote> that does not match the Specification (for example using > instead of >, double-escaping of character entities or failure to include the textformat attribute);
over-complex HTML or XHTML that uses markup tags that are not in the preferred ‘minimal set’;
invalid HTML or XHTML – often enclosed within <![CDATA[ … ]]> tags to suppress any validation errors;
entirely unnecessary use of <![CDATA[ … ]]>, where no markup is present.

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.

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 ‘ü’)
`</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 (at least 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.

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 Marsh	Marsh, Dame Ngaio
Henry of Huntingdon	Huntingdon, Henry of
Henriette d’Angeville	Angeville, Henriette d’
Mary O’Connor	O’Connor, Mary
Máire ó Conchobhair	Conchobhair, Máire ó
Gabriel Garcia Márquez	Garcia Márquez, Gabriel
Megan Lloyd George	Lloyd George, Megan
His Holiness the Dalai Lama	Dalai Lama, His Holiness the
Luo Guanzhong	Luo Guanzhong	(family name first)
村上春樹	村上春樹	(Haruki Murakami, family name first)
Björk Guðmundsdóttir	Bjö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 שפרה הורן.

Can <PersonName> and <PersonNameInverted> be derived automatically from the various more granular parts of a name?

Frequently, the content of <PersonName> and <PersonNameInverted> is strictly limited to the personal name data elements, omitting all titles, honorifics and qualifications, numerations (like III) and other suffixes to the name. Based on this:
NamesBeforeKey PrefixToKey KeyNames NamesAfterKey
for <PersonName> and
KeyNames NamesAfterKey (comma) NamesBeforeKey PrefixToKey
for <PersonNameInverted> would usually suffice. This conforms with common library practice (the MARC 100 $a subfield).

In some other cases, suffixes and titles are included, and arranging the data elements something like this should generate acceptable values for <PersonName> and <PersonNameInverted> in almost all cases:
TitlesBeforeNames NamesBeforeKey PrefixToKey KeyNames NamesAfterKey SuffixToKey LettersAfterNames (comma) TitlesAfterNames
and
KeyNames NamesAfterKey (comma) NamesBeforeKey PrefixToKey (comma) SuffixToKey (comma) TitlesBeforeNames (comma) LettersAfterNames (comma) TitlesAfterNames

In all cases, a little logic would be required to deal with empty fields and superfluous spaces and commas, and there are a few cases where names concatenated in this manner might not be ideal (royal names with regnal numbers as a suffix, perhaps). And note that there’s no particularly reliable method of ‘going the other way’ – of deriving the granular parts of a name from <PersonName> or <PersonNameInverted>.

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="むらかみはるき">￹村上春樹￺むらかみはるき￻</b037>

This uses Unicode interlinear annotation delimiters (￹, ￺ and ￻) 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:

replace ￹ with ‘<ruby><rb>’;
change ￺ to ‘</rb><rp> (</rp><rt>’;
and substitute ‘</rt><rp>)</rp>’ for ‘￻’.

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.

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.

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.

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.

<BiographicalNote> and two dozen or so other fields can include HTML or XHTML markup, so you can create biographies with multiple paragraphs of text, and add text styling like italic or bold, bulleted lists etc. XHTML is strongly preferred to HTML;
HTML tags require special treatment to ensure the ONIX remains valid XML. (This is because some end tags like </p> and </li> are optional in HTML.) There are two methods of embedding HTML:
- CDATA – enclosing the entire HTML in <![CDATA[ … ]]> tags (the preferred method);
- escaping – replacing the < character in HTML tags (only) with <. Don’t be tempted to escape the > or any other character;
- you must not mix the two methods within a single data element. Ideally, pick one and use it consistently throughout your ONIX metadata;
- using either method, you must add the textformat="02" attribute;
- validating the ONIX using the DTD or XSD schema will not validate the structure of the HTML, so some other method to check the HTML is correct HTML is required;
HTML tags are case-insensitive, so <p> and <P> are equivalent – but lower-case tags are overwhelmingly preferred by web developers. XHTML tags must always be lower case;
- if your HTML uses only lower case tags (ie <p> and not <P>), and if optional </p> and </li> tags are never omitted, then it is likely that your HTML can be treated as XHTML;
XHTML is a more rigorous form of HTML, where end tags cannot be omitted and all tags must be lower case. XHTML tags can be embedded in ONIX data without special precautions – do not use either CDATA or escaping:
- you must add the textformat="05" attribute;
- validating the ONIX using the DTD or XSD schema will also validate the structure of the XHTML;
whether HTML or XHTML, it is best practice to use only a small selection of simple tags – <p>, <br />, <i>, <em>, <b>, <strong>, <cite> for book titles, and <ul>, <ol> and <li> for lists:
- <sup>, <sub>, <dl>, <dt> and <dd> are also okay;
- <ruby>, <rb>, <rp> and <rt> are fine if you need them for glosses on East-Asian language text;
do not include headings, tables, links, images, etc;
and do not use HTML attributes, in particular the style attribute;
- one possible exception – you may wish to use the type or start attributes on the <ol> tag to control the numbering of tables of contents with HTML or XHTML markup;
avoid leaving any text entirely outside of any markup tags:
- ensure all the text is enclosed within a series of ‘block-level’ HTML tags like <p> or <ul>;
do not include named character entities (eg …, – or ö) in the HTML or XHTML (they aren’t valid in ONIX 3.0):
- use either the native character or a numerical character reference instead;
- exception – named character entities may sometimes be okay in HTML inside CDATA;
if the & and < characters are supposed to appear in the text itself – not as part of the HTML markup – replace them with & and either < or < (use < if you’re using the escaping method with HTML);
do not use CDATA or escaping in any data elements other than those that can accept HTML and XHTML.

Common issues with embedded HTML and XHTML:

missing textformat attribute;
an inconsistent mix of some CDATA, some escaped markup within the same data element – it might start with <![CDATA[<p>… or something similar;
> – escaping > is not recommended;
something like &ouml; – double-escaping of named character entities;
unnecessary use of CDATA for data elements that do not contain HTML markup at all;
recipients ignoring or stripping correct markup.

Many errors stem from cutting and pasting HTML text from elsewhere. This leads to wildly over-complex markup, reliance on style attributes and stylesheets that will not be accessible to the recipient of the ONIX data.

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 ‘ö’ 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"><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>`

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"><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>`	Replace < character with < (and avoid also replacing > with > 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 … or ö 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 … or ö 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 … or numerical reference like … might require the ampersand to be escaped – just as the < character in the HTML markup is escaped to <, the ampersand character within a named character entity or numerical reference could also be escaped, so a single ellipsis becomes &hellip; or &#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 <). 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 & 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.

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

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.

The Product record:

should include at least one of <EditionType> or <EditionNumber>, or the <NoEdition/> empty element;
should include an <EditionStatement> whenever the edition type and/or edition number do not fully express the nature of the edition, or to clarify how the edition type or number should be displayed.

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’ 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

The <Language> composite should be used to:

to specify the language of the main text used in the product;
for works in translation, specify the original language from which the text has been translated;
- ideally, the translator should be named as a contributor in Group P.7.

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> or <RegionCode>, 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 that 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.

The ONIX codes for language, script and country (but not the region) 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>`	English
`</language>`
`<language>`
`<b253>02</b253>`	Original language
`<b252>por</b252>`	Portuguese
`</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>`	German
`</language>`

Use <Subject> to specify Japan and/or Japanese. The book is (largely) in German and is intended for readers of German, while Japan and Japanese is the subject.

Braille novel in Québécois French
using Reference names
`<EditionType>BRL</EditionType>`
`. . .`
`<Language>`
`<LanguageRole>01</LanguageRole>`
`<LanguageCode>fre</LanguageCode>`
`<RegionCode>CA-QC</RegionCode>`
`</Language>`

using Short tags
`<x419>BRL</x419>`	Braille edition
`. . .`
`<language>`
`<b253>01</b253>`	Language of text
`<b252>fre</b252>`	French
`<b398>CA-QC</b398>`	Quebec
`</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.

The Product record for:

a physical book or an e-publication with fixed pagination (eg PDF format) should contain an <Extent> composite specifying the number of pages;
- multiple <Extent> composites providing separate extents for the front matter, main content, back matter and any unnumbered inserts are preferred;
an audiobook should contain an <Extent> composite specifying the running time;
a ‘reflowable’ e-publication with no fixed pagination (eg typical EPUB format) should contain an <Extent> indicating the number of pages in any print counterpart, or a notional number of pages if it is a digital-only product;
- the print counterpart can be important for accessibility, as it is the print book from which any print-equivalent page numbering is drawn. The print counterpart can be identified in <RelatedProduct>;
for all book types, it may also be useful to provide a word count;
a downloadable e-publication should also include an indication of the filesize.

Major ancillary content included in a book that is primarily text – for example, illustrations, plates, maps, extensive tabular material, a bibliography or an index should be listed in the <AncillaryContent> composite, or in an <IllustrationsNote> data element. The former is strongly preferred.

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 just 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.

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.

¹ 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 merely 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.

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.

Every Product record should include one or more <Subject> composites, to specify the subject of the product.

There are many subject classification schemes, often endemic to a particular territory: none is both commercially-focused and globally-accepted – although this is the explicit aim of the new Thema subject scheme, and it should eventually reduce the need to use multiple schemes. Meantime, the record should include repeated <Subject> composites to specify the subject using each scheme commonly used in the territories in which the product is sold.

For each classification scheme or controlled vocabulary used:

the data should conform to the best practices established for that scheme;
if a classification within a particular scheme makes use of multiple classification codes, one should be flagged as being primary with the <MainSubject/> empty element.

In addition, the subject matter, theme or content should be indicated using keywords, words or short phrases that are not part of a controlled vocabulary.

A <NameAsSubject> composite should be included for products where a real person or organization forms the subject matter of the product.

Common issues in Group P.12:

overly general subject codes (eg FIC000000, Fiction / general in the BISAC scheme);
both general and specific codes for the same subject (both PB, Mathematics, and PBKJ, Differential calculus in the Thema scheme);
use of outdated versions of subject schemes (most standardized schemes are updated regularly);
failure to consult guidance notes associated with categories in some schemes – for example, the Thema, BIC, CLIL schemes have important usage notes attached to many categories;
for phrasebooks, foreign language learning and bilingual dictionaries, confusion over the language a book is in, and the language it is about. For the former, use <Language>;
mistaken guidance to ‘always provide x subject codes’. If the first code describes the book comprehensively, that’s all you need. If the book needs three codes, use three codes. But don’t add superfluous codes just to ‘make up the numbers’;
conflicting subject codes (though in post-coordinated schemes, some apparent conflicts are entirely legitimate – for example in Thema, a combination of FG (sports fiction) and a specific sport code that would normally be used for non-fiction titles about that sport);
subject information at odds with audience information, for example children’s subject codes combined with an adult audience code (or vice versa);
inconsistent subject coding applied to different editions, or different versions of the same work (though on occasion this can correctly reflect contrasting marketing for the different versions);
keywords supplied individually, each in its own repeat of <SubjectHeadingText> – they should be combined into a single semicolon-separated list;
misleading or inappropriate keywords, in an attempt to ‘game the system’ and boost search rankings.

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.

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
Scheme	Current	Selected previous versions
BIC	2.1	2.0, 1.1 etc
BISAC	2018	2014, 2011, 2010, 2.9, 2.6 etc
CCE	2.0
CLIL	2018	2014, 2010, 2006 etc
Thema	1.3	1.2, 1.1, 1.0
Warengruppen-Systematik neu	2.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 barely-relevant classifications 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 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 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.

Every Product record should include one or more <Audience> composites, to specify the intended readership for the product. (This is true even though some subject classification schemes incorporate some limited audience details.) At minimum, the audience should be described using the ONIX audience codes in List 28.

As with subject coding, there are many audience classification schemes, endemic to different territories, so the record should include repeated <Audience> composites to specify the audience using each scheme commonly used in the territories in which the product is sold.

Product records for children’s and school education titles should include an <AudienceRange> composite to specify the intended reading age and/or interest age range, school grade or year range precisely. Where possible, <AudienceRange> should also be used to specify an intended higher education application.

Product records for school education titles should also include a <Complexity> composite wherever appropriate: quantitative text leveling is of increasing importance to educators’ book selection process.

Common issues in Group P.13:

a general adult audience specified for highly specialist material;
audience information at odds with subject information, for example children’s audience codes combined with an adult subject code (or vice versa), or more subtly, a general children or adult audience for material that is intended to be used in an educational context. Another example: professional development material for educators is not aimed at an education audience (specify a professional/scholarly audience instead);
inconsistent audience coding applied to different editions, or different versions of the same work (though on occasion this can correctly reflect contrasting marketing for the different versions);
omission of detailed audience ranges for children’s and educational material;
lack of precision, particularly in children’s audience ranges – an overly-broad age range of 5–12 is unlikely to be useful. Broad age ranges do not increase discoverability: parents and teachers need precise and relevant age ranging information;
omission of an ONIX Adult audience rating or warning for strongly sexual or violent content, extreme or offensive language, drug misuse or extreme intolerance.

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).

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 <CollateralDetail> composite that forms Block 2 of a Product record is optional, but should occur in all ONIX for Books Product records, unless:

there is no relevant data about marketing material to include in any of the enclosed <TextContent>, <CitedContent> or <SupportingResource> composites – in which case the entire Block should be omitted;
the Notification type is 04 (a block-level partial update) and no data elements in Block 2 have been updated since a previous message;
the Notification type is 08 (notice of sale of a product from one publisher to another), in which case Blocks 1–3 and 5–6 are unnecessary;
the Notification type is 05 (a record deletion), in which case Blocks 1–7 are wholly unnecessary.

When present, the Block should contain the main marketing collateral and other promotional material associated with the product. In the very rare case of a block update that’s intended to delete all previously-sent collateral detail and not replace it with anything, the block may be empty (ie with Notification type 04, an empty <CollateralDetail/> tag may be used).

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.

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

Every Product record should include one or more <TextContent> composites, carrying descriptive details of the product. It is best practice to provide at least two repeats of the composite, carrying:

a short description (<TextType> code 02), a short (up to around 50 words, or a maximum of 350 characters) description that might be displayed alongside the product in a list or group of search results;
a long description (code 03), a longer (no length restriction) description that might be displayed alongside the product on a solus catalog web page;
- where only one description can be provided and its length cannot be controlled, code 03 should be used, irrespective of its length.

Many other valuable types of text should be supplied wherever possible, the most important of which for commercial metadata include a promotional headline (<TextType> code 10) that could be attached to either of the short or long descriptions, the table of contents (<TextType> code 04, particularly valuable for non-fiction) and short quotations from product reviews (<TextType> code 06).

Each repeat of the composite:

must use <TextType> to specify the type of description;
must include an indication of the intended audience for the description. Recipients should take great care to limit access to the description to the specified group;
must carry the descriptive text itself in the <Text> data element;
- XHTML markup should be used within the <Text> element if anything other than a single line or paragraph of plain text is required. Use the textformat attribute to indicate the presence of any markup;
- where a particular type of descriptive text is provided in more than one language, the <Text> element should include the language attribute;
should include <TextAuthor>, <SourceTitle> or both, where the supplied text is a review or an endorsement;
should use the <ContentDate> composite to indicate when the collateral text was last updated, to help recipients processing large numbers of mostly unchanged resources.

In some cases, publishers might place a time limitation on when a recipient can display the supplied text (particularly in a consumer context). Recipients should take great care to comply with any limits supplied in the <ContentDate> composite. This includes both dates before which the text may not be used, and dates after which the text may not be used (ie when it should be removed from display).

Data suppliers may also provide guidance on which markets the supplied text is intended for, using the <Territory> composite. Recipients should prefer text with an appropriate territory over text without any territory specification.

If a Product record is prepared and distributed some months before planned publication of the product, it is possible that no descriptive text of any sort is available. In this case, the entire Group can be omitted. Later updates of the ONIX message should include descriptive text.

Common issues in Group P.14:

including several review snippets within a single <Text> element;
including the author or source of a review within the text of the review itself. Use <TextAuthor> and <SourceTitle> instead;
<TextContent> used to deliver a single author biography. Use <BiographicalNote> instead;
use of unrelated data elements like <Subtitle> for promotional text that should be in Group P.14. Use a promotional headline instead;
reliance on return or new line characters to format multiple paragraphs within <Text>. Use HTML or XHTML markup instead;
HTML or XHTML markup within <Text> that does not match the Specification (for example using > instead of >, or failure to include the textformat attribute);
over-complex HTML or XHTML that uses markup tags that are not in the preferred ‘minimal set’;
invalid HTML or XHTML – often enclosed within <![CDATA[ … ]]> tags to suppress any validation errors;
use of <![CDATA[ … ]]> when it is unnecessary. It should only be used to enclose text that includes HTML tags. Plain text, or text with XHTML tags should not be enclosed.

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 <cite>UML 2.0 Pocket Reference</cite> 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><cite>UML 2.0 Pocket Reference</cite> 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</TextAuthor>`
`<TextSourceDescription>CEO, Universal Consulting LLP</TextSourceDescription>`
`</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 <cite>UML 2.0 Pocket Reference</cite> 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><cite>UML 2.0 Pocket Reference</cite> 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</d107>`
`<x557>CEO, Universal Consulting LLP</x557>`
`</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 é or € (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 é and € (or the hexadecimal equivalents é or €).

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 say nothing more than ‘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, and expanded 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-formatted, and 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"><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:

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

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. In earlier releases of ONIX, this use of type and start attributes can only be validated when used in combination with CDATA, due to a limitation in the ONIX_XHTML_Subset.xsd file distributed as part of the XSD schema. The ONIX_XHTML_Subset.xsd file released with 3.0.7 correctly validates the type and start attributes without CDATA. (If desired, this version of the Subset file can be used to replace older Subset files originally distributed with earlier XSD schemas).

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 ‘<’;
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 including the reviewer’s rating within the text of the review extract. Of course, not every review provides a rating.

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 which the review was published in <SourceTitle>, and possibly also the name of the reviewer in <TextAuthor>. A brief description of the reviewer in <TextSourceDescription> can boost the credibility of the review.

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>`
`<TextSourceDescription textformat="05">Author of <cite>The Big Crash</cite></TextSourceDescription>`
`<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
`<x557 textformat="05">Author of <cite>The Big Crash</cite></x557>`
`<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 <TextSourceDescription> (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.

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

If Group P.15 is used, each repeat of the <CitedContent> composite:

must use <CitedContentType> to specify the nature of the linked material;
should include an indication of the intended audience for the cited resource. Where this is omitted, recipients may assume that the cited material is suitable for all audiences. But where it is provided, recipients should take care to limit access to the citation to the specified group;
for references to most printed or broadcast material, <CitedContent> should carry the name of the source of the cited material (eg a newspaper or magazine title, a broadcast program name), and should ideally also include the publication or broadcast date in a <ContentDate> composite;
for a reference to a specific published bestseller list or sales chart, <CitedContent> should carry the name of the list and the position reached, and should ideally also include the publication date in a <ContentDate> composite;
should include the URL for cited content that is accessible online. Note that not all cited content has to be online.

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.

P.15.8 Resource link

If the cited material is accessible online, the full URL should be specified, including the protocol (ie the http:, https: or ftp: part).

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.

Every Product record should include at least one <SupportingResource> composite, specifying a link to some type of product image. It is best practice to supply at least a cover image (or equivalent).

Each <SupportingResource> composite:

must use <ResourceContentType> to specify the type of resource, and <ResourceMode> to specify whether it’s an audio, video, still image or text resource;
must include an indication of the intended audience for the resource. Recipients should take great care to limit access to the resource material to the specified group;
should specify any captions or required credits associated with the resource material. When specified, recipients must take great care that required credits are displayed alongside the resource;
must describe at least one version of the resource that recipients can either link to or download and use. A URL for the version must be included;
should always use the <ContentDate> composite to indicate when a downloadable resource was last updated, to help recipients processing large numbers of mostly unchanged resources.

In some cases, publishers might place a time limitation on when a recipient can link to or display the specified resource material (particularly in a consumer context). Recipients should take great care to comply with any limits supplied in the <ContentDate> composite. This includes both dates before which the resource may not be used, and dates after which the text may not be used (ie when it should be removed from display).

Data suppliers may also provide guidance on which markets the supplied resource is intended for, using the <Territory> composite. Recipients should prefer resources with an appropriate territory over resources without any territory specification.

Recipients should not mandate a specific naming scheme for downloadable resource files – if necessary, resources should be renamed according to the recipient’s specific requirements as they are downloaded from the provided URL and stored in the recipient’s system.

If a Product record is prepared and distributed some months before planned publication of the product, it is possible that no resource material of any sort is available. In this case, the entire Group can be omitted. Later updates of the ONIX message should include relevant supporting resources. Providing generic ‘cover not yet available’ images is not recommended practice.

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 only 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.

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 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 URLs that the recipient might add to a web page – and the recipient’s customers may click on the link and read or download the resource. 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.

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.

P.16.11 Resource link

The Resource link must be a URI.

Since access to the resource might require either http:, https: or ftp:, you should normally include the protocol part of the URI, and not just a web address like ‘www.editeur.org/images/pic1.jpeg’. A complete, or ‘absolute’ URI normally looks something like ‘https://www.editeur.org/images/pic1.jpeg’, including protocol, server name, folder or directory path and the file name.

However, it is also possible to specify a ‘relative’ URI instead – this might look like ‘images/pic1.jpeg’ or even just ‘pic1.jpeg’, and in this case, the implied location of the resource depends on the actual location of the ONIX file itself – a relative URI such as ‘pic1.jpeg’ is not a merely simple filename, but means that the resource must be in the same folder or directory, on the same server as the ONIX file itself, and that it can be accessed using the same protocol. The location of the ONIX file is used as the ‘base’, and the absolute location of the resource file is composed by appending the relative URI to this base. Exceptionally, the base location to which the URI is appended must be agreed in advance between the sender and receiving parties (this agreement would have a similar effect on the implied location of resource files as the HTML <base> tag). This relative URI option should only be used when ONIX message is delivered to the recipient in such a way that the resource is guaranteed to exist at that relative address. This might be the case if the ONIX message and associated resources are on the same server, or if the ONIX file and the associated resources are delivered to the recipient in a predictable or neatly packaged way (eg in a single ZIP file, or into a specified folder on a server). This relative URI option should not be used to deliver a simple filename where the relative location of the ONIX message file and the resource is not fixed.

using a relative URI
using Reference names
`<ResourceLink>covers/9780007232833-fc500.jpeg</ResourceLink>`

using Short tags
`<x435>covers/9780007232833-fc500.jpeg</x435>`

In this example, if the ONIX message itself is at the address
ftp://www.publisher.com/onix/130719.xml
then the cover image file must be found at
ftp://www.publisher.com/onix/covers/9780007232833-fc500.jpeg
or – if a base URI of ftp://ftp.recipient.com/publisher/ is agreed in advance – then it must be found at
ftp://ftp.recipient.com/publisher/covers/9780007232833-fc500.jpeg

A relative URI starting with a ‘/’ means ‘relative to the root directory of the server’ rather than relative to the location of the ONIX file. This should never be used in ONIX.

In the special case where an ONIX file and the resources are packaged inside a single ZIP file, ensure when zipping that the ONIX file is in the current directory.

The resource specified should be accessible to all ONIX recipients (for downloadable resources and embeddable resources), or accessible to all internet users (for linkable resources). Downloadable or embeddable resources may require account credentials, for example, a username and password to access, where these credentials are shared with ONIX recipients in advance. Linkable resources may not.

Instead of the URI carrying a link to the image data, it is possible to embed the actual image inside the URI, using the data: URI scheme [this technique is used to embed the EDItEUR logo within this document]. In this case, the URI is the data, and nothing need be downloaded by the recipient. While technically interesting, this is not recommended at present in ONIX. It may be a viable way to carry thumbnail-sized JPEG images or small embeddable resources (such as the YouTube video player example above) in the future.

embedding image data within a URI (not recommended)
using Reference names
`<ResourceLink>data:image/jpeg;base64,/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+IIJElDQ19QUk9GSUxFAAEBAAAIFEFEQkUCQAA . . . /yR/yfz/yx+V/i/vfhoAWx+ce3zj/L2P8AXoA//9k=</ResourceLink>`

using Short tags
`<x435>data:image/jpeg;base64,/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHV . . . /yR/yfz/yx+V/i/vfhoAWx+ce3zj/L2P8AXoA//9k=</x435>`

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

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 or region 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 7: Promotion detail

Promotion detail composite

Block 7 – the <PromotionDetail> composite contains one or more repeats of the <PromotionalEvent> composite. It’s intended to be used for describing author signings, readings or other events arranged to promote sales of the product. These are frequently arranged in ‘tours’, so an author might visit a dozen bookstores in a region, with the activity in each store more or less identical. In ONIX, such a tour is described in a single promotional event composite, and each individual stop on the tour is an ‘occurrence’ of that event.

If the activity at each store is significantly different – for example a different celebrity guest participates alongside the author – then the ‘tour’ should be described as multiple individual events.

The <PromotionDetail> composite that forms Block 7 of a Product record should be used to describe one or more promotional events such as a series or ‘tour’ of book signings, public appearances etc, each of which might have one or several ‘occurrences’ (individual bookstore visits, appearances etc).

The entire Block should be omitted:

if such a description is unnecessary or there is no relevant data about promotional events to include in the enclosed <PromotionalEvent> composites;
if the Notification type is 04 (a block-level partial update) and no data elements in Block 7 have been updated since a previous message;
the Notification type is 08 (notice of sale of a product from one publisher to another), in which case Blocks 1–3 and 5–7 are unnecessary;
the Notification type is 05 (a record deletion), in which case Blocks 1–7 are wholly unnecessary.

When present, the Block must describe at least one promotional event with at least a single occurrence, except in the very rare case of a block update that’s intended to delete any previously-sent promotional event detail and not replace it with anything (in this very rare case, with Notification type 04, an empty <PromotionDetail/> tag may be used).

P.27 Promotional events

The structure of the <PromotionalEvent> composite may encompass one or many occurrences of an event – in effect, the Promotional event is a series of individual and more or less identical events.

The intent of the composite is to describe in detail events such as author appearances, signings, readings and so on. These are an increasingly important part of the marketing mix for many publishers and types of book. Each <PromotionalEvent> composite:

must specify the type of event and its target audience;
must specify a name for the event (and by extension, for each occurrence of the event);
should list each of the participants in the event;
- event participants who are Product contributors or are listed in <NameAsSubject> should be listed using <ContributorReference>, and must therefore have a matching ID in <Contributor> (in Groups P.5, P.7 or P.18) or <NameAsSubject> (in Groups P.12 or P.18) and in <ContributorReference> – even if this is a proprietary ID;
- other participants should be listed using a full <Contributor> composite;
- participants’ sequence numbers and role codes relate to their participation in the event, and are likely to be different from their roles and sequence numbers that relate to the product (as given in Groups P.5 or P.7)
must list the details for at least one occurrence of the event in <EventOccurrence>.

Each occurrence of the event must include a status and a date and time.

For physical events, the venue details – country or region, and city (in <LocationName>) plus the venue – are mandatory;
For virtual events, necessary details of the website or URL must be provided (nb codelist entries for this are yet to be defined).

Listing a two-stop interview tour
using Reference names
`<PromotionDetail>`
`<PromotionalEvent>`
`<EventType>01</EventType>`
`<EventStatus>A</EventStatus>`
`<ContentAudience>00</ContentAudience>`
`<EventName>An evening with André Morell</EventName>`
`<ContributorReference>`
`<SequenceNumber>1</SequenceNumber>`
`<ContributorRole>A44</ContributorRole>`
`<NameIdentifier>`
`<NameIDType>16</NameIDType>`
`<IDValue>0000000121336847</IDValue>`
`</NameIdentifier>`
`</ContributorReference>`
`<Contributor>`
`<SequenceNumber>2</Sequence Number>`
`<ContributorRole>A43</ContributorRole>`
`<NameIdentifier>`
`<NameIDType>01</NameIDType>`
`<IDTypeName>BeachPress AuthorID</IDTypeName>`
`<IDValue>3101</IDValue>`
`</NameIdentifier>`
`</Contributor>`
`<EventDescription>Actor André Morell in conversation with his biographer Murray Folland.</EventDescription>`
`<EventOccurrence>`
`<EventIdentifier>`
`<EventIDType>01</EventIDType>`
`<IDTypeName>BeachPress EventID</EventIDType>`
`<IDValue>9d0fd2b5-e9cc-4337-8838-f869f1b159ef</IDValue>`
`</EventIdentifier>`
`<OccurrenceDate>`
`<OccurrenceDateRole>01</OccurrenceDateRole>`
`<Date>20191107T1900Z</Date>`
`</OccurrenceDate>`
`<OccurrenceDate>`
`<OccurrenceDateRole>02</OccurrenceDateRole>`
`<Date>20191107T2030Z</Date>`
`</OccurrenceDate>`
`<EventStatus>A</EventStatus>`
`<CountryCode>GB</CountryCode>`
`<LocationName>Brighton</LocationName>`
`<VenueName>Seaside Bookshop</VenueName>`
`<StreetAddress>31 Union Street, The Lanes</StreetAddress>`
`<VenueNote>The venue is not fully wheelchair-accessible – please check in advance.</VenueNote>`
`</EventOccurrence>`
`<EventOccurrence>`
`<EventIdentifier>`
`<EventIDType>01</EventIDType>`
`<IDTypeName>BeachPress EventID</EventIDType>`
`<IDValue>2906ff98-2816-4255-90ae-ff38df3406e7</IDValue>`
`</EventIdentifier>`
`<OccurrenceDate>`
`<OccurrenceDateRole>01</OccurrenceDateRole>`
`<Date>20191108T1830Z</Date>`
`</OccurrenceDate>`
`<OccurrenceDate>`
`<OccurrenceDateRole>02</OccurrenceDateRole>`
`<Date>20191108T200Z</Date>`
`</OccurrenceDate>`
`<EventStatus>A</EventStatus>`
`<CountryCode>GB</CountryCode>`
`<LocationName>London WC2E 8RF</LocationName>`
`<VenueName>The Theatre Bookshop</VenueName>`
`<StreetAddress>The Market, Covent Garden</StreetAddress>`
`</EventOccurrence>`
`</PromotionalEvent>`
`</PromotionDetail>`

using Short tags
`<promotiondetail>`	Block 7
`<promotionalevent>`
`<x548>01</x548>`	Book signing
`<x549>A</x549>`	Announced
`<x427>00</x427>`	For any audience
`<x516>An evening with André Morell</x516>`
`<contributorreference>`
`<b034>1</b034>`
`<b035>A44</b035>`	Interviewee
`<nameidentifier>`
`<x415>16</x415>`	ISNI, matches ID
`<b244>0000000121336847</b244>`	in <NameAsSubject>
`</nameidentifier>`
`</contributorreference>`
`<contributorreference>`
`<b034>2</b034>`
`<b035>A43</b035>`	Interviewer
`<nameidentifier>`
`<x415>01</x415>`	Proprietary, matches ID
`<b233>BeachPress AuthorID</b233>`	in <Contributor>
`<b244>3101</b244>`
`</nameidentifier>`
`</contributorreference>`
`<x550>André Morell in conversation with his biographer Murray Folland.</x550>`
`<eventoccurrence>`	First occurrence of event
`<eventidentifier>`
`<x547>01</x547>`	Proprietary
`<b233>BeachPress EventID</b233>`	Publisher uses a UUID…
`<b244>9d0fd2b5-e9cc-4337-8838-f869f1b159ef</b244>`	for each event occurrence
`</eventidentifier>`
`<occurrencedate>`
`<x554>01</x554>`
`<b306>20191107T1900Z</b306>`	Nov 7th at 7pm (UTC/GMT)
`</occurrencedate>`
`<occurrencedate>`
`<x554>02</x554>`
`<b306>20191107T2030Z</b306>`	Event lasts 90 minutes
`</occurrencedate>`
`<x549>A</x549>`
`<b251>GB</b251>`
`<j349>Brighton</j349>`
`<x551>Seaside Bookshop</x551>`
`<x552>31 Union Street, The Lanes</x552>`
`<x553>The venue is not fully wheelchair-accessible – please check in advance.</x553>`
`</eventoccurrence>`
`<eventoccurrence>`	Second occurrence of event
`<eventidentifier>`
`<x547>01</x547>`	Proprietary
`<b233>BeachPress EventID</b233>`
`<b244>2906ff98-2816-4255-90ae-ff38df3406e7</b244>`	UUID
`</eventidentifier>`
`<occurrencedate>`
`<x554>01</x554>`
`<b306>20191108T1830</b306>`	Nov 8th at 6:30–8:00pm
`</occurrencedate>`
`<occurrencedate>`
`<x554>02</x554>`	Without a timezone offset…
`<b306>20191108T2000</b306>`	times are ‘local’ to the venue
`</occurrencedate>`
`<x549>A</x549>`
`<b251>GB</b251>`
`<j349>London WC2E 8RF</j349>`
`<x551>Theatreland Bookshop</x551>`
`<x552>The Market, Covent Garden</x552>`
`<x553>Please book tickets in advance from the bookshop website.</x553>`
`</eventoccurrence>`
`</promotionalevent>`
`</promotiondetail>`

Promotional event composite

This composite is repeated for each ‘event’ (where an ‘event’ may in fact encompass several more or less identical repeats of an event, with the same activity and participants but at different venues and at different times).

Contributor by reference and Contributor

Named participants in the event are listed in different ways, depending on whether or not they are also contributors to the product itself (or possibly the subject of the product). If the event participant is already described elsewhere within the Product record – in Groups P.5, P.7 or P.18, or in Groups P.12 or P.18 if they are the subject – then they are linked to the promotional event by reference. This is to preserve the integrity of the data, eliminating the potential for contradictory data about the same persona. If the event participant is not described elsewhere within the Product record, a full <Contributor> composite – with the same structure as that used in Group P.7 – should be provided in Group P.27. For many promotional events, <ContributorReference> is all that is required.

Use of <ContributorReference> requires a unique Name identifier for the contributor/event participant, for example an ISNI or a proprietary ID. The Name identifier used in <ContributorReference> must match a Name identifier used in the ‘main’ metadata within <Contributor> in Groups P.5, P.7 or P.18, or within <NameAsSubject> in Groups P.12 or P.18. In fact, since <NameIdentifier> is repeatable, all the identifiers in <ContributorReference> must match the same instance of <Contributor> or <NameAsSubject>.

P.27.65 Event description

The Event description element may be used both within <PromotionalEvent> and within <EventOccurrence>. In the former position, it describes the event as a whole, and for clarity should not refer to any individual occurrence – the text should be applicable to all occurrences.

Event occurrence composite

The <EventOccurrence> composite is repeatable within a single Promotional event where the individual occurrences are essentially identical aside from their date, time and venue. A typical author book signing or reading is likely to be part of a programme of such occurrences, each in a different bookstore, and should be described as a single Promotional event with mutiple Event occurrences.

Event identifier

It is strongly recommended that each event occurrence be given an identifier, in order that distinct ONIX Product records that ‘advertise’ the same event occurrence can be recognised. Inevitably, since there is no standardised identifier, a proprietary ID is required.

: Event identifier can also occur as the first child of <PromotionalEvent>, where it identifies ‘the event as a whole’ rather than an individual occurrence. This may be useful in future for events such as literary festivals, where the whole event has an identity separate from any individual occurrence, and where many different authors and publishers are arranging occurrences.

Occurrence date

This should carry the date and time of the event occurrence. Note that the default date format differs from other <Date> elements – it is YYYYMMDDThhmm, where most other dates are YYYYMMDD by default. In this format, times may have additonal timezone information (using a Z suffix for UTC, or a ±hhmm offset from UTC for other timezones).

For occurrences of a physical event, local times (at the physical venue) are most useful, and cannot be misinterpreted as ‘rolling times’ even if the timezone is omitted (see the notes on rolling and instantaneous times in the Publishing date composite). However, for physical event occurrences that have any online component – for example a livestream of a physical event for those unable to attend – it is vital that the timezone is provided.

For online event occurrences, it is clearly vital to provide an instantaneous time including the timezone offset.

Time including Central European timezone offset (one hour ahead of UTC)
using Reference names
`<OccurrenceDate>`
`<OccurrenceDateRole>01</OccurrenceDateRole>`
`<Date>20191107T1900+0100</OccurrenceDateRole>`
`</OccurrenceDate>`
`<EventStatus>A</EventStatus>`

using Short tags
`<occurrencedate>`
`<x554>01</x554>`
`<b306>20191107T1900+0100</b306>`	Nov 7th, 7pm in CET zone
`</occurrencedate>`
`<x549>A</x549>`	Announced

The same time could be specfied as 20191107T1800Z – that is, 6pm UTC.

P.27.72 Event status

Cancelling a particular occurrence
using Reference names
`<EventStatus>C</EventStatus>`

using Short tags
`<x549>C</x549>`	Cancelled

Event status can also occur as a child of <PromotionalEvent>, where it specifies the status of ‘the event as a whole’ rather than of an individual occurrence. These are distinct – an occurrence of an event may be cancelled while the event as a whole and most of its occurrences proceed as announced.

Event venue and address

For occurrences of a physical event, the venue and street address are key data elements for potential attendees. The country, region and location fields are intended to enable the creation of a directory of events in a particular region, and services could allow a consumer to subscribe to notifications when particular authors visit a city or region.

At least a country or region code, the location name (typically a city) and the venue name are mandatory for physical events, but the street address of the venue is strongly recommended. Any additional information about the venue should be included in <VenueNote>.

For purely digital ‘events’ which nonetheless have a specific date and time, none of the country, region, location and venue elements should be included.

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 easily provided in Group P.14, and in many cases might be omitted entirely.

The <ContentItem> composite that forms Block 3 of a Product record should be used to describe a detailed table of contents of a product, or the constituent parts of an omnibus or multi-component product, particularly where items in that table or list might be available individually as independent products, or where there is collateral material that applies to the parts individually.

The entire Block should be omitted:

if such a description is unnecessary or unavailable;
if the Notification type is 04 (a block-level partial update) and no data elements in Block 3 have been updated since a previous message;
the Notification type is 08 (notice of sale of a product from one publisher to another), in which case Blocks 1–3 and 5–6 are unnecessary;
the Notification type is 05 (a record deletion), in which case Blocks 1–7 are wholly unnecessary.

When present, the Block must describe at least one content item, except in the very rare case of a block update that’s intended to delete any previously-sent content item detail and not replace it with anything (in this rare case, with Notification type 04, an empty <ContentDetail/> tag may be used).

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.

The primary intent of the composite is to specify detailed information about each part of the product that is not included in the description of the product as a whole, or in a <ProductPart> composite in Group P.4. Each <ContentItem> composite:

should contain a level sequence number if the order of the items is significant;
must contain a <TextItem> composite (or, for audiovisual material, the similarly-structured <AVItem> composite) that specifies the type of item (complete work, chapter, article…). The composite should also include a product identifier if the item is available as a separate product;
should contain detail of the distinctive title of the content item, for example where authorship, language or subject differs from textitem to textitem,;
should not contain contributor, language and subject detail, or collateral material, unless it differs from that provided for the product as a whole.

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>.

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>.

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.

block update, updating Block 4 (specifically, updating the publication date)
using Reference names
`<Product>`
`<RecordReference>com.mypublisher.01734</RecordReference`
`<NotificationType>04</NotificationType>`
`<ProductIdentifier>`
`<ProductIDType>03</ProductIDType>`
`<IDValue>9780001234567</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9780001234567</IDValue>`
`</ProductIdentifier>`
`<!-- blocks 1–3 and 7 not updated -->`
`<PublishingDetail>`
`<Imprint>`
`<ImprintName>MyBooks</ImprintName>`
`</Imprint>`
`<Publisher>`
`<PublishingRole>01</PublishingRole>`
`<PublisherName>My Publisher</PublisherName>`
`</Publisher>`
`<CityOfPublication>Springfield, IL</CityOfPublication>`
`<CountryOfPublication>US</CountryOfPublication>`
`<PublishingStatus>02</PublishingStatus>`
`<PublishingDate>`
`<PublishingDateRole>01</PublishingDateRole>`
`<Date>20190926</Date>`
`</PublishingDate>`
`<SalesRights>`
`<SalesRightsType>01</SalesRightsType>`
`<Territory>`
`<RegionsIncluded>WORLD</RegionsIncluded>`
`</Territory>`
`</SalesRights>`
`</PublishingDetail>`
`<!-- blocks 5 and 6 not updated -->`
`</Product>`

using Short tags
`<product>`
`<a001>com.mypublisher.01734</a001`
`<a002>04</a002>`	Block update
`<productidentifier>`	Mandatory ‘block zero’
`<b221>03</b221>`	GTIN-13
`<b244>9780001234567</b244>`
`</productidentifier>`
`<productidentifier>`
`<b221>15</b221>`	ISBN
`<b244>9780001234567</b244>`
`</productidentifier>`
`<!-- blocks 1–3 and 7 not updated -->`
`<publishingdetail>`	Block 4
`<imprint>`
`<b079>MyBooks</b079>`
`</imprint>`
`<publisher>`
`<b291>01</b291>`	Publisher
`<b081>My Publisher</b081>`
`</publisher>`
`<b209>Springfield, IL</b209>`
`<b083>US</b083>`
`<b394>02</b394>`
`<publishingdate>`
`<x448>01</x448>`	Nominal pub date
`<x448>20190926</x448>`	Updated date
`</publishingdate>`
`<salesrights>`
`<b089>01</b089>`	For sale (exclusive)
`<territory>`
`<x450>WORLD</x450>`
`</territory>`
`</salesrights>`
`</publishingdetail>`
`<!-- blocks 5 and 6 not updated -->`
`</product>`

It could be that the only updated element is a new publication date. It’s not possible to send just the new publication date in a block update – the whole of the block must be included. Even with a block update, there is still an ‘overhead’ of unchanged metadata that must be sent and processed, but it is much less than the complete record that would otherwise have to be sent in a conventional Product record.

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.

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, using 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 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 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 be simply ‘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).

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

within <Contributor>;
within <Event> or <Conference>;
within <Publisher>;
within <PromotionalEvent>;
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.

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.

The <PublishingDetail> composite should include a ‘global’ status in the <PublishingStatus> data element.

At least one <PublishingDate> composite should be included, to carry the global publication date of the product (unless this is specifically precluded by the <PublishingStatus>). Additional relevant dates should also be specified, including:

any embargo on retail sales;
any embargo on public release of product metadata;
an out of print date (as this can affect the acceptance of returns).

This best practice applies even when the markets in which a product is available each have a market-specific status and market-specific dates in Group P.25. Data providers must ensure that the global status and dates in P.20 are consistent with any market–specific status and dates provided in Block 6 – for example, a global publication date must be the earliest of any market-specific publication dates, and a product cannot be out of print globally if it is still active in any market.

ONIX recipients must ensure they comply with any stated embargo and/or announcement dates.

Common issues in Group P.20:

confusion between publication date and embargo date. The publication date is the date on which the product is nominally published, but is not necessarily the first date on which retail purchasers may obtain the product. This latter is the embargo date, and it must be specified separately where a publisher wishes to control it. In the absence of an embargo, sales often begin a few days before publication (as soon as physical stock or digital master files are available);
publishers sending a ‘deletion’ message (<NotificationType> 05) in an attempt to stop retailers listing a product as for sale. Data senders should use <PublishingStatus> 01 (Canceled) when a planned product is abandoned, or one of the Out of print / Withdrawn from sale statuses at the end of the product’s life;
use of dates such as 31/12/2099 with ‘special’ meanings;
confusion between publication date and date of first publication (which is the publication date of the very first manifestation of the work).

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:

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.


: 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 just 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.

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.

The <PublishingDetail> composite should include a full statement of the territorial sales rights associated with the product in one or more <SalesRights> composites. This includes specifying:

geographical areas where the product can be sold;
- it is good practice to specify whether the sales rights are based on exclusive publishing rights, or whether another publisher might legitimately exploit parallel rights in the same work via other products with the same content;
geographical areas where the product cannot be sold;
- it is good practice to specify whether this is because the publisher holds no rights, or whether the publisher chooses not to exploit rights it holds, using Sales rights type codes 04, 05 or 06;
any remaining geographical area where the rights position is unknown (or where the publisher wishes not to state a position, perhaps because of an in-progress negotiation) should be specified using <ROWSalesRightsType>.

Some territorial sales rights are accompanied by sales restrictions, for example where a product is exclusive to a particular retailer within a territory. Any such restrictions should be included.

This best practice applies even if each individual market a product is available in is described in Block 6. ONIX providers should ensure that individual market territories in Block 6 are consistent with the ‘global’ sales rights listed in Group P.21 (ie the markets are a subset of or identical to the P.21 territories with sales rights.)

Common issues in Group P.21:

sales rights information missing entirely – this may be acceptable in the earliest stages of product planning, but retailers need accurate sales rights information prior to placing orders for the product;
‘sales rights’ provided by a distributor or wholesaler which list as ‘not for sale’ those countries the distributor or wholesaler does not supply to, even though other suppliers may supply the book in those countries (ie a confusion between the global sales rights in Block 4 and the market or supplier-specific distribution rights in Block 6);
invalid combinations of data elements within <Territory>, for example using both <CountriesIncluded> and <CountriesExcluded> in the same <Territory> composite;
omitted minor territories like HK, RE or PR (parts of China, France and the US respectively);
invalid ‘country codes’ that are not a part of ONIX list 91 (for example ‘XK’). These are sometimes added as proprietary codes within internal systems, but must be ‘translated’ into the correct ONIX codes for data exchange;
contradictory sales rights where the product appears to be both for sale and not for sale in the same country or region, for example where ‘for sale’ is applied to WORLD and ‘not for sale’ is applied to a specific country;
incompatible sales rights where the product is not for sale in countries for which market, supplier and price details are provided in Block 6;
missing <ROWSalesRightsType> where it is required, or <ROWSalesRightsType> supplied when there is no ‘rest of world’ to which it applies. There is a simple 3-question test that defines whether <ROWSalesRightsType> is required;
recipients treating <ROWSalesRightsType> code 00 (sales rights are unknown or unstated) as ‘for sale’ on the basis that the product is not ‘not for sale’;
recipients ignoring sales restrictions.

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.

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 sale – either 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 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
Australia	AU	CC	Cocos Islands
		CX	Christmas Island
		NF	Norfolk Island
		HM	Heard Island and McDonald Islands
China	CN	HK	Hong Kong
		MO	Macao
		TW	Taiwan
Denmark	DK	FO	Faroe Islands
Denmark	DK	GL	Greenland
Finland	FI	AX	Åland Islands
France	FR	BL	Saint Barthélemy
		GF	French Guiana
		GP	Guadeloupe
		MF	Saint Martin
		MQ	Martinique
		NC	New Caledonia
		PF	French Polynesia
		PM	Saint Pierre and Miquelon
		RE	Réunion
		TF	French Southern Territories
		WF	Wallis and Futuna
		YT	Mayotte
Netherlands	NL	AW	Aruba
		BQ	Bonaire, Saba and Sint Eustatius
		CW	Curaçao
		SX	Sint Maarten
New Zealand	NZ	TK	Tokelau
Norway	NO	BV	Bouvet Island
Norway	NO	SJ	Svalbard and Jan Mayen
United Kingdom	GB	BM	Bermuda
		GS	South Georgia
		GG	Guernsey
		JE	Jersey
		IM	Isle of Man
		KY	Cayman Islands
		MS	Montserrat
		PN	Pitcairn Islands
		SH	Saint Helena, Ascension and Tristan da Cunha
		VG	Virgin Islands
United States	US	AS	American Samoa
		GU	Guam
		MP	Northern Mariana Islands
		PR	Puerto Rico
		UM	US Minor Outlying Islands
		VI	US 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.

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:

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;
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;
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).

All Product records should include a <RelatedMaterial> composite, unless:

there is no relevant data about related products or works to include in any enclosed <RelatedWork> or <RelatedProduct> composites – in which case the entire block should be omitted;
the Notification type is 04 (a block-level partial update) and no data elements in Block 5 have been updated since a previous message;
the Notification type is 08 (notice of sale of a product from one publisher to another), in which case Blocks 1–3 and 5–6 are unnecessary;
the Notification type is 05 (a record deletion), in which case Blocks 1–7 are wholly unnecessary.

When present, the Block should be used to specify links between the product and other related products and works – for example predecessor and successor products, products that share some, most or all the same content, and various looser relationships.

In the very rare case of a block update that’s intended to delete any previously-sent related work and product detail – and not replace it with anything – the block may be empty (ie with Notification type 04, an empty <RelatedMaterial/> tag may be used).

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.

Where an ISTC or similar work identifier has been registered for the work embodied in the product, it should be specified in a <RelatedWork> composite.

For ‘derived’ works (eg a work in translation, or an abridged version), ISTCs or similar work identifiers for any source works should also be included wherever possible (ie the original language version and the unabridged ‘grandparent works’). It is also good practice to include the work identifiers of other works derived from this work (‘child works’), where they are known;
Related works in the same collection should also be listed.

If a publisher uses a reliable but prioprietary internal work identifier, and a public work identifier is not available, the internal identifier should be used to specify these works.

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:

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.

The <RelatedProduct> composite should be used:

when a ‘work’ is available in multiple versions (for example, in hardback, paperback, and as one or more e‑books);
- this might include other products which are (in ISTC terms) not the same work – abridgements, illustrated versions and so on;
when one product is superseded by another (eg a second edition supersedes the first, and a media-tie in version may replace an original);
to list other products in the same collection;
when a product is also available as part of an omnibus, set, bundle or other multi-part product;
to link to parts of an omnibus, bundle or set that are available separately;
to identify the print counterpart of any e‑book with print-equivalent page numbering, which can be important for accessibility purposes.

If <ProductComposition> indicates the product is a multi-component or multi-item product (ie using codes 10, 11, 30 and 31 from List 2), <RelatedProduct> should not repeat relationships to component products that are included as product parts in Group P.4.

Each repeat of the <RelatedProduct> composite must contain an identifier for the related product, and must specify the relationship between the product and the related product. In general, further information about the related product should not be provided.

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.

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>
06	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>
01 02	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>
41	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>
03 05	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). Note also that code 05 generally indicates direct replacement – a third edition is directly replaced by the fourth, and but only indirectly by the fifth and sixth. This means searching for the current replacement for an old edition might need more than a single search step (from third to sixth via the fourth and fifth) – but it avoids having to update the ONIX records for all old editions every time a new edition is released. In contrast, a particular product might list all its related antecedents: the sixth edition may record that it replaces the fifth, fourth, third, second and first editions, but data recipients should not rely on this as it is more likely to list only the fifth
18 19	<Product> is a special edition based on the basic version <RelatedProduct> <Product> is also available as a special edition, as <RelatedProduct>
18 19	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>
30	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
13 27	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 could equally-well be related with code 06. However code 13 also implies that print-equivalent page numbering embedded in the e‑book match the real page numbering of the print book. These relationhips imply the paper and digital products are the same work, and they 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>
28 29	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>
26	use when <RelatedProduct> is digital, and available separately
07 08	<Product> has ancillary or supplementary <RelatedProduct> <Product> is ancillary or supplementary to <RelatedProduct>
07 08	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>
22 23 42	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.

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.

All Product records should contain at least one repeat of the <ProductSupply> composite, unless:

the Notification type is 04 (a block-level partial update) and no data elements in Block 6 have changed since a previous message;
the Notification type is 08 (notice of transfer of a product from one publisher to another), or 05 (a record deletion).

In these cases, Block 6 should be omitted.

When present, the Block should specify the market(s) where the product is available, unless they mirror the ‘global’ details in Block 4. It must include details of at least one <Supplier> in the market(s), and the prices the supplier(s) charge (which might be ‘as yet unpriced’ or ‘free of charge’).

Block 6 can be used as part of a full <Product> record, or on its own as a block-level update containing the Product preamble (‘block zero’) and one or more repeats of <ProductSupply>. As a block-level update, it has two closely-related uses – first, as a simple ‘price and availability update’ sent to all recipients, and second as a way of implementing so-called ‘personalised pricing’ where a version of Block 6 is tailored specifically for each recipient. Sending a full Product record to all recipients, followed by a tailored Block 6 update only to those requiring personalised pricing is more efficient than sending complete tailored Product records.

<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.

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.

block update, updating Block 6 (specifically, confirming a new lower price)
using Reference names
`<Product>`
`<RecordReference>com.mypublisher.01734</RecordReference>`
`<NotificationType>04</NotificationType>`
`<ProductIdentifier>`
`<ProductIDType>03</ProductIDType>`
`<IDValue>9780001234567</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9780001234567</IDValue>`
`</ProductIdentifier>`
`<!-- Blocks 1–5 and 7 not updated -->`
`<ProductSupply>`
`<SupplyDetail>`
`<Supplier>`
`<SupplierRole>01</SupplierRole>`
`<SupplierName>My Distributor</SupplierName>`
`</Supplier>`
`<ProductAvailability>10</ProductAvailability>`
`<SupplyDate>`
`<SupplyDateRole>08</SupplyDateRole>`
`<Date>20190923</Date>`
`</SupplyDate>`
`<Price>`
`<PriceType>01</PriceType>`
`<PriceStatus>02</PriceStatus>`
`<PriceAmount>9.95</PriceAmount>`
`<CurrencyCode>USD</CurrencyCode>`
`<Territory>`
`<CountriesIncluded>US</CountriesIncluded>`
`</Territory>`
`</Price>`
`<!-- other prices must be included here -->`
`</SupplyDetail>`
`<!-- other suppliers must be included -->`
`</ProductSupply>`
`<!-- other markets must be included -->`
`</Product>`

using Short tags
`<product>`
`<a001>com.mypublisher.01734</a001>`
`<a002>04</a002>`	Block update
`<productidentifier>`	Mandatory ‘block zero’
`<b221>03</b221>`	GTIN-13
`<b244>9780001234567</b244>`
`</productidentifier>`
`<productidentifier>`
`<b221>15</b221>`	ISBN-13
`<b244>9780001234567</b244>`
`</productidentifier>`
`<!-- Blocks 1–5 and 7 not updated -->`
`<productsupply>`	Block 6
`<supplydetail>`
`<supplier>`
`<j292>01</j292>`
`<j137>My Distributor</j137>`
`</supplier>`
`<j396>10</j396>`	Not yet available
`<supplydate>`
`<x461>08</x461>`
`<b306>20190923</b306>`	Expected ship date
`</supplydate>`
`<price>`	Price (excl tax) for USA
`<x462>01</x462>`
`<j266>02</j266>`	Updated firm status
`<j151>9.95</j151>`	Updated lower price
`<j152>USD</j152>`
`<territory>`
`<x449>US</x449>`
`</territory>`
`</price>`
`<!-- other prices must be included -->`	Otherwise the block update
`</supplydetail>`	would have the effect
`<!-- other suppliers must be included -->`	of deleting them from the
`</productsupply>`	recipient’s system
`<!-- other markets must be included -->`
`</product>`

Some data elements that are normally included within the Product supply composite – such as any market-specific details in <Market> and <MarketPublishingDetail>, a supplier identifier, returns information, discounts and so on – have been omitted from the example above for the sake of simplicity. In a real P&A block update, the whole of Block 6 must be supplied – including the full details of the market, and the full complement of multiple prices (if there are multiple prices across different territories within the market).

Special care is needed if there are multiple markets (that is, repeats of <ProductSupply>. If the original message contained two <ProductSupply> composites, then the block update should contain two <ProductSupply> composites too – even if only one of them contains any updated metadata. Failing this, information relating to the ‘other’ market (ie the unchanged market) may well be deleted by the recipient.

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.

Each <ProductSupply> composite should include a specification of the extent of the market, except when the product is available in only a single market – in which case <Market> may be omitted, because it is inevitably the same as the <SalesRights> details provided in Block 4.

Every <Market> composite must specify a geographical area using <Territory>, and any sales restrictions that apply within the territory should be included.

If <Market> is omitted, then the ‘global’ sales rights information in Block 4 should be used by ONIX recipients to determine the geographical extent of the market plus relevant sales restrictions within the market.

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 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 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

Each <ProductSupply> composite should include a <MarketPublishingDetail> composite, unless the following three conditions are all true:

the publisher deals directly with distributors, wholesalers, retailers, and possibly with consumers, in which case the <PublisherRepresentative> composite should be omitted;
the product is available in only a single market, in which case the publishing status and dates provided at ‘global’ level in P.20 apply, and need not be repeated in P.25;
- note that if there is a <PublisherRepresentative> composite, market publishing status and dates must not be omitted, even if there is only a single market. Group P.20 should reflect the publisher’s status, and Group P.25 should reflect the publisher’s representative’s status;
there is no relevant data to include in the remainder of the <MarketPublishingStatus> composite (elements from P.25.17 to P.25.22).

If the original publisher works through a local publisher or a sales agent (in this particular market), <PublisherRepresentative> should include the agent’s or publisher’s role and organizational details. Some countries and agencies maintain formal identifier schemes for publishers and agents. Where such identifiers are used, they should be included in the <AgentIdentifier> composite.

<MarketPublishingDetail> must include a <MarketPublishingStatus> element giving the publisher’s representative’s status for the product. At least one <MarketDate> composite should be included, to carry the market-specific ‘publication date’ of the product (unless this is specifically precluded by the <MarketPublishingStatus>). Additional relevant market-specific dates should also be specified, including any metadata or sales embargoes and any ‘out of print in this market’ date.

Data providers must ensure that the market status and dates are consistent with any global status and dates provided in Block 4. Market-specific dates cannot be earlier than the global dates (though they can be identical).

If <MarketPublishingDetail> is omitted, then the ‘global’ information in Block 4 should be used by ONIX recipients to determine the extent of the market plus relevant dates and statuses.

<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’.

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

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 merely 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>.

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

There must be at least one <SupplyDetail> composite within the <ProductSupply> composite. And each repeat of <SupplyDetail> describes one supplier, and must contain details of:

the supplier’s identity and contact details, in the <Supplier> composite;
the availability of the product from that supplier, in the <ProductAvailability> element;
- <ProductAvailability> should carry a datestamp attribute to indicate how current the data is;
- certain availabilities should be accompanied by dates in the <SupplyDate> composite and possibly an order lead time in <OrderTime>;
- for physical products, the <ReturnsConditions> composite should indicate whether the product can be returned to the supplier, and the number of items in each carton or binder’s pack should be quoted in <PackQuantity>;
either a <Price> composite, or <UnpricedItemType> to indicate that the product is not priced:
- free of charge products must use <UnpricedItemType>, not a <PriceAmount> of zero.

The <Supplier> composite:

must include the supplier’s role in the supply chain;
should include the business name of the supplier organization in the <SupplierName> element;
should include any applicable formal identifiers for the supplier organization or location. The preferred identifier for international use is the GLN (Global Location Number), but some countries and agencies maintain other identifier schemes for suppliers or supplier locations, and identifiers used in the territories where the product is sold should be included;

<SupplyDetail> should also include contact details for the supplier such as telephone number and e‑mail address, ideally within the <SupplyContact> composite.

For any one supplier, there may be multiple prices – because the supplier may plan to change the price in the future, or because the supplier may offer the product at different prices in different territories or to different types of customer. Each supplier should list all the prices valid in all territories they deal with (within the confines of the market), including prices that apply only to specific classes of customer (for example, corporate/institutional prices, or prices only applicable to library customers).

Each <Price> composite:

should include the type of price and terms of trade (recommended retail price, fixed retail price, net wholesale price, agency price etc). The price type also specifies whether the price is tax-inclusive or excludes any applicable taxes;
must include the price itself;
- prices should be quoted exc-tax in North America, and in other territories where prices are normally advertised exc-tax and where sales tax is applied only on the final sale to the consumer;
- prices should normally be quoted inc-tax in many European countries, and elsewhere VAT is applied all along the supply chain – at least for the publisher’s home country, and ideally in other countries where the publisher or supplier is aware of the applicable taxes;
tax-inclusive prices should normally include a breakdown of the taxes included within the quoted price amount;
- it is best practice to provide all elements within the <Tax> composite, even though only one of <TaxRatePercent> or <TaxAmount> is mandatory;
  - in addition, <TaxableAmount> is required when <Tax> is repeated, in order that taxes can be correctly calculated;
- <PriceAmount> should always be the sum of <TaxableAmount> and <TaxAmount>;
- inclusion of tax details almost inevitably means the price is only valid in one specific country. This country should be specified using <Territory>;
- omitting the tax breakdown from a price quoted inc-tax means the exc-tax price must be calculated separately. This should be avoided wherever possible;
- there should be no tax details for a price quoted exc-tax;
where the price is supplied on trade discount or agency terms (ie not a net wholesale price but one on which the retailer pays ‘retail less discount’ or is paid commission), the <Price> composite should specify the discount or commission, as a percentage or as a discount code, using the <Discount> or <DiscountCoded> composites;
should include the applicable currency, and the territory within which the price is valid;
- where the territory is omitted, the recipient should assume the price is valid throughout the market;
- the territory should never extend beyond the confines of the market;
if a future price change is planned, the current and future prices should both be included, with dates to indicate the validity of each;
for physical products, should indicate whether the price is printed on the product itself.

For reissues, the <Reissue> composite should not be used.

Common issues in Group P.26:

tax detail provided for prices that exclude tax;
tax detail provided for prices that are applicable in more than a single country (taxes are always country-specific);
multiple prices lacking any indication of where each is applicable. This is often caused by specifying currency but not country;
- if a <Price> omits the <Territory> to which that price applies, then it should be assumed to be valid throughout the <Territory> specified for that market (the market described by the entire <ProductSupply> composite). And any market that does not specify a geographical extent using <Territory> within <Market> must be assumed to be the whole area where the product is for sale – as defined by the <SalesRights>;
omitting pricing for minor territories like IM (a dependency of the UK), PR (a territory of the US) or RE (an overseas department of France) etc;
mismatches between the geographical applicability of various prices and the market or sales rights territories, leaving countries in which the product may be sold without applicable prices, or conversely, prices for countries where the product may not be sold;
mismatches of a similar nature arising from use of <PriceQualifier> which leave particular groups of customers to whom the product can be sold without applicable price information;
setting recommended retail prices for countries that are known to use fixed pricing for books (but if in doubt, use a recommended price);
a zero price amount. This sometimes arises as an error where the publisher has not set a price – because a database null or blank is conflated with an explicit database zero – and would cause retailers to assume the product is free-of-charge. For this reason, zero prices are not valid. Use <UnpricedItemType> instead.

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.

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.

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>.

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

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.

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.

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
Canceled	01
Not yet available ³	10
Available	20
Temporarily unavailable ³	30
Temporarily withdrawn ³	34
Not available	40
Not available, replaced by new product	41
Not available, other format available	42
No longer supplied by us	43
Withdrawn from sale	46
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.

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 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 minimum	Order multiple	Acceptable order sizes
6	not specified	6, 7, 8…
6	3	6, 9, 12…
6	4	6, 10, 14…
6	6	6, 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).

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.


: 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 the looser ‘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.

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)	01	02
Fixed retail price	03	04
Wholesale price ⁴	05	07
Alternative wholesale price ¹ ⁴	08	09
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 ³	21	22
Pre-publication fixed retail price ³	23	24
Pre-publication wholesale price ³ ⁴	25	27

Trade sales (agency terms)	exc-tax	inc-tax
Publisher’s retail price	41	42

Special sales (generally non-returnable, often retailer-specific) ⁶	exc-tax	inc-tax
Recommended retail price	11	12
Fixed retail price	13	14
Wholesale price ⁴	15	17

Price type qualifiers from List 59
Unqualified price (applies when no other qualified price applies) ⁷	00
Member/subscriber price	01
Export price (not recommended – use <Territory> instead)	02
Reduced price when purchased as part of a collection	03
Voucher/coupon promotion price	04
Consumer price	05
Library/corporate/institutional price	06
Reservation order	07
Promotional offer (temporary ‘special offer’ price reduction) ⁶	08
Library only price	10
Education only price	11
Corporate only price	12

¹ 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).

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 1	ISBN 1	buy as PDF	£17.95
		rent for 3 days	£5.95
		rent for one week	£8.95
		rent for one month	£11.95
Product 2	ISBN 2	buy 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 1	ISBN 1	buy 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 2	ISBN 2	buy 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>.

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 and Discount coded 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. Product A get put in a group with other products that attract the same discount. 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.

Retailers build up a number of these lookup tables, one from each supplier with whom they trade, so it's important that each discount group has a unique name (because every supplier has a Group 3!). It’s also important for suppliers to distribute updated metadata if ever a product is moved from one group to another.

Where such a scheme is operated, the Discount Code (termed a ‘Discount Group number’ in the example described 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).

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:

product announced, <UnpricedItemType> code 02 (price to be announced), no <Price> composite
price announced, <PriceStatus> code 01 (provisional)
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>).

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 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>.

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 implies 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.

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 1⁄16m², 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. See also WCAG.
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 ‘&’.
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.
AS2, AS3: Applicability Statement 2, 3 etc, IETF specifications covering the secure and reliable communication of business-to-business data on the internet using HTTP and digital signatures for document signing and encryption, with receipt confirmation returned after decryption and signature verificaton to guarantee successful delivery. Most used for EDI message delivery, but the content could be any standardised structured data (potentially including ONIX messages). AS3 uses the FTP protocol instead of HTTP.
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 (1⁄16th 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.
Backward compatibility: See compatibility.
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: Book Industry Systems Advisory Committee. It was later incorporated into BISG, along with SISAC, its serials publishing counterpart. In the past, BISAC and SISAC have also been known as BASIC (Book and Serial Industry Communications).; More frequently, the subject categorization scheme developed by the BISAC Subjects committee and administered by BISG and used mostly in the North American book trade. 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 a single pixel within an RGB image), or any other type of information – including a programming instruction for the computer itself. This document comprises more than 3.5 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. These are often called ‘square’, ‘curly’ and ‘round brackets’ in the 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, CC-By, CC Zero etc: 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 ‘…’ 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.
Compatibility: In an IT context, the ability of a system to interoperate with other systems. Backward compatibility is the ability of a system to accept and correctly process input intended for older systems. A data format is backward compatible with its predecessor if data that is valid under the old format remains valid and retains its meaning under the new format. Forward compatibility is the reverse, the ability of a system to accept and process input in a format intended primarily for later versions of itself, although of course it may not be able to extract all data from the newer format.
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.
Copyright: 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 < 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‘.
Digipack, Digipak: Folded card packaging with a distinct spine and one or more plastic trays affixed to hold a CD or DVD, as distinct from card sleeve packaging or plastic jewel or keep cases.
Digital asset distributor: See DAD.
Digital certificate: In cryptograph, a digital certificate or digital signature is a data file that securely identifies a particular web server or (less often) a legal entity such as an organization. On the internet, a certificate is used in the first stage of creating a connection via HTTPS, so you can be sure the www.editeur.org server you are interacting with really is EDItEUR’s web server and can therefore trust the information it provides. It also allows the communication to be encrypted and private. Certificates can also be used to validate identities in e-mail exchanges, and ensure the integrity of software applcations.
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).
Discount code, Discount group code: Index into a table of discounts shared in advance between supplier and retailer. Since each retailer may have a unique table, the actual discount percentage can be communicated without revealing commercially-sensitive information.
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: Former European Article Number. See GTIN.
Edge decoration: Colored, marbled or gilded edges of the book block.
EDI: Electronic Data Interchange: system for highly-automated exchange of strictly-formatted business documents such as invoices, orders or P&A updates. Common EDI document formatting standards include X.12 (used in North America), Tradacoms (in UK) and EDIFACT (common across much of the rest of the world). These are not XML-based standards, but XML equivalents do exist under the EDItX banner.
EDIFACT, UN/EDIFACT: Electronic Data Interchange for Administration, Commerce and Transport, the ISO 9735 standard developed by the United Nations that underlies much of the world’s e-commerce. Application of the standard to the book trade was coordinated by EDItEUR.
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 ends 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 block prior to addition of the cover.
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’.
Forward compatibility: See compatibility.
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 implementers 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.
GHS: Globally Harmonized System of Classification and Labelling of Chemicals, standardized system of classification for hazards and hazardous materials, including hazard statements, warning pictograms, safety data sheets etc.
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 globally 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. It uses a digital certificate for network authentication and for establishing the encrypted link to maintain 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 (more rarely) with 9791–9799. The 9790 numbers are ISMNs, and 9791–9799 ISBNs are being introduced as needed, and extend to France, Italy, Korea and USA so far. All ISBNs consist of 13 digits (eg 9780001234567). 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 æ, ﬀ, ﬁ, ﬂ, ĳ and a handful of others are common (depending on the fonts available, the difference between ﬀ 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 could be used as the subject of a linked data triple. Linked data triples can be expressed and exchanged in RDF JSON-LD or other formats, or stored in a specialized database called a ‘triple store’. 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.
Literal: A typographical error or ‘typo’ – an error in typeset text.
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 a method of communicating this highly structured and standardized metadata from one party to another within the supply chain. Some organizations might also consider internal workflow informtion to be part of the product’s metadata.
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 merely 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 ﬀ 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@groups.io: e‑mail mailing list and support forum for general questions about ONIX. Subscribe by sending a blank e-mail to onix+subscribe@groups.io
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 (the most common size in the UK), is designed to be handled using a pallet-jack or forklift truck, and can carry up to about 1000 typical hardback novels or 2500 paperbacks (depending on their extent), or a tonne or more of paper sheets. Common Euro and US ‘standard’ pallets differ in size – 1 × 0.8m and 48 × 40in respectively. In many Asian countries, 1.1m square is the most common size. Euro pallets are convenient because they fit through doors even when laden, but they waste more space than US and UK sizes when packed in a standard shipping container.
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.
Parser: In XML, a parser is software that can read an XML document (such as an ONIX message), check that it matches the required syntax and grammar (by comparing it with a DTD or schema file), and make each individual data element available to other software (via an API).
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 1⁄72nd of an inch (or about 0.3515mm). The use of points in PostScript has made exactly 1⁄72 (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 5⁄4 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 – and in contrast, using a new ISBN means it is 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, and which fail to sell at retail, can be returned to the wholesaler or distributor for credit. Returned copies can be re-sold to another retailer, 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). Publishers clearly aim to discourage over-ordering and minimise the consequent returns from retailers, but the trade as a whole benefits from ensuring bookstores are full of potentially-saleable books rather than full of books known to be unsaleaable. Thus, a certain level of returns is anticipated, and the credit on returns frees retailers to order new books that are more likely to sell.
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 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. Single copies of high-value books can be shrink-wrapped to protect them until they are sold, or entire pallets of cartons can be wrapped to maintain their stability and integrity during distribution.
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.
TEFL: Teaching (of) English as a foreign language. Also TESL, Teaching English as a second language.
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 was initially intended to be used in parallel with existing nationally-focused schemes, but with the potential to 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.; Transport layer security, a cryptographic security protocol used to ensure privacy and integrity of communication between two computers, for exaample within the HTTPS.
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.
Tradacoms: An early EDI standard used in the UK retail sector, an implementation of the UN/GTDI standard that pre-dates the very similar EDIFACT, and orginally managed by GS1 UK. The standard was superseded by EDIFACT in the 1990s – at least in principle – but is still in common use in UK retail (including the UK book trade).
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 regular or Garamond italic. cf font.
Typo: See literal.
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.; Uniform Code Council, the former organization that managed the UPC barcode system.
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 parser software is 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.
WCAG: Web content accessibility guidelines, W3C standard for ensuring the accessibility of resources on the web for people with disabilities including blindness or reduced vision, deafness or hearing loss, physical disabilities and other issues. The standard is also relevant when creating accessible e-books.
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.; A single member of a typeface family. Times Roman and Times Bold are two weights within the Times family.; 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: Early EDI document formatting standard developed by ANSI and managed by X12. It predates EDIFACT, but remains in common use in North American e-commerce (including in the the US book supply chain).
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, schema and parser.
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 implementers 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 just 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>`	☑ also include xmlns
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>`	☐ digital product file format ☐ digital accessibility ☐ 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/>`	☐ if product is not part of a collection
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>`	☐ for anon., et al
	`. . . <ContributorStatement>`	`<b049>`	☐
	`. . . <NoContributor/>`	`<n339/>`	☐ if no contributors
Group P.9
	`. . . <EditionType>`	`<x419>`	☐
	`. . . <EditionNumber>`	`<b057>`	☐
	`. . . <EditionStatement>`	`<b058>`	☐ if type, number insufficient
	`. . . <NoEdition/>`	`<n386/>`	☐ if no other edition information
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>`	☐ promotional headline ☐ short description ☐ long description ☐ reviews
	`. . . . <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>`	☐ cover image ☐ contributor image ☐ sample spreads (for picture books)
	`. . . . <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>`	☐ as URL
	`. . . . . <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>`	☑ publication date ☐ sales embargo ☐ out of print ☐ announcement dates
Group P.21
	`. . . <SalesRights>`	`<salesrights>`	☑
	`. . . . <SalesRightsType>`	`<b089>`	☑
	`. . . . <Territory>`	`<territory>`	☑
	`. . . . <SalesRestriction>`	`<salesrestriction>`	☐ if product is not for general distribution
	`. . . <ROWSalesRightsType>`	`<x456>`	☐ if sales rights not exhaustive
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>`	☐ unless same as global status
	`. . . . <MarketDate>`	`<marketdate>`	☐ unless same as global dates
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>`	☐ for expected ship date
	`. . . . <PackQuantity>`	`<j145>`	☐ if not single products
	`. . . . <UnpricedItemType>`	`<j192>`	☐ for FOC, 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>`	☐ unless price applies to whole market
	`. . . . . <PriceDate>`	`<pricedate>`	☐ for notice of price changes
	`. . . . . <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, for no reason other than 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.

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 unwanted 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);
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;
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;
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 implementers to plan and budget for future development.

The status of various ONIX releases (as at late-2019) is as follows:

ONIX 3.0: active development, latest revision 7 (version 3.0.7);
ONIX 2.1: legacy (extended use), latest revision 03 (or revision 04 in Japan only);
ONIX 2.0: obsolete;
ONIX 1.x: obsolete.

Outside Japan, ONIX 2.1 was ‘feature complete’ from 2008, when the decision to develop ONIX 3 was made – and in most countries, it was effectively feature complete following the release of ONIX 2.1 revision 02 in June 2004 (since revisions 03 and 04 were intended principally for Spain, Australia and Japan). With the agreement of the ONIX International Steering Committee, it was announced in January 2012 that all revisions of ONIX 2.1 would be considered ‘legacy’ from the end of 2014. At the same time, the status of ONIX 2.0 was revised to obsolete. ONIX 2.1 users (and any remaining ONIX 2.0 users) were strongly encouraged to ensure they had a plan in place to migrate to ONIX 3.0.

Following sunset of ONIX 2.1, full EDItEUR support for 2.1 codelists continued throughout 2015 (‘twilight’) and limited support continued until the end of 2016 (‘moonlight’). EDItEUR development of the codelists ceased entirely after Issue 36 in January 2017 (‘midnight’).

At the time of writing, most ONIX senders and recipients, and most commercial software applcations, support both ONIX 2.1 and ONIX 3.0. There are still a few data recipients which accept only ONIX 2.1. However, an increasing number of ONIX recipients now accept only ONIX 3.0, and others have announced deadlines for the end of support for 2.1. ONIX senders and recipients still relying on release 2.1 should urgently consider the business risks of delaying their migration to 3.0.

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:

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;
agree the overall character set and encoding;
check the method used to embed any markup within certain data elements (XHTML markup, or HTML with either CDATA or escaping);
confirm whether Reference names or Short tags will be used;
- an XSLT-based Tagname Converter is available from https://www.editeur.org/93/Release-3.0-Downloads/#Tag%203.0 if it proves necessary to translate messages between Reference names and Short tags (or vice versa);
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;
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?
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;
agree whether the ONIX Acknowledgement Message will be used, and whether it would be used only to confirm message receipt or as part of a more comprehensive query and error reporting message choreography;
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;
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);
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 be able to ignore elements they do not use);
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;
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;
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);
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;
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;
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

It is good practice to declare the character encoding used by the message file in the XML declaration (the first line of the message file).

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 ‘&’ and ‘<’ 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. Any single character can be included in ONIX data by encoding it as ‘&#xn;’ where n is the Unicode character number in hexadecimal (in base 16 numbers). 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 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 reference	text in file
decimal	`é`	`ž`	`д`
hexadecimal	`é`	`ž`	`д`

binary encoding	binary data in file (in hexadecimal)
UTF-8	`c3 a9`	`c5 be`	`d0 b4`
UTF-16LE	`e9 00`	`7e 01`	`34 04`
UTF-16BE	`00 e9`	`01 7e`	`04 34`
Latin-1 (ISO 8859-1)	`e9`	— ¹	—
Latin-9 (ISO 8859-15)	`e9`	`b8`	—
Windows-1251	—	—	`e4`
Windows-1252	`e9`	`9e`	—
MacRoman	`8e`	—	—

named character entity	text in file
(not valid in ONIX 3.0, used in 2.1)	`é`	`&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, 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 ﬁ (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 ﬁ 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 ﬁ 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 <. 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 four blocks may be empty (in block updates only):

<PromotionDetail/>
<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.

It is a feature of ONIX that some composite structures can occur at many places within a record. <ProductIdentifier> for example must appear in Group P.2, and may also occur in P.4, P.18, P.21, P.23 and at multiple locations in P.26. In each case, it’s ‘meaning’ is distinct: in P.2 it specifies an identifier for the product, whereas in P.21, it lists a related product and in P.4 it identifies a part of the product which may or may not be available as a product in its own right. The context in which a composite or data element appears is important, and so each XPath targets a particular tag in only one specific context.

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.

Note also that the XPaths as listed do not target a particular single product record: if there are multiple products in an ONIX message, a further predicate would be required to target a specific record in the message.

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 name	XPath
	`<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.22a	`. . . .<ProductClassificationTypeName>`	`/ONIXMessage/Product/DescriptiveDetail/ProductClassification/ProductClassificationTypeName`
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	`. . . . . . <PrizeRegion>`	`/ONIXMessage/Product/DescriptiveDetail/Collection/Contributor/Prize/PrizeRegion`
P.5.54e	`. . . . . . <PrizeCode>`	`/ONIXMessage/Product/DescriptiveDetail/Collection/Contributor/Prize/PrizeCode`
P.5.54f	`. . . . . . <PrizeStatement>`	`/ONIXMessage/Product/DescriptiveDetail/Collection/Contributor/Prize/PrizeStatement`
P.5.54g	`. . . . . . <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	`. . . . <PersonNameInverted>`	`/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	`. . . . <CorporateNameInverted>`	`/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	`. . . . . <PersonNameInverted>`	`/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	`. . . . . <ContributorDateRole>`	`/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`
	`. . . . <ProfessionalAffiliation>`	`/ONIXMessage/Product/DescriptiveDetail/Contributor/ProfessionalAffiliation`
P.7.40	`. . . . . <ProfessionalPosition>`	`/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	`. . . . . <PrizeRegion>`	`/ONIXMessage/Product/DescriptiveDetail/Contributor/Prize/PrizeRegion`
P.7.41e	`. . . . . <PrizeCode>`	`/ONIXMessage/Product/DescriptiveDetail/Contributor/Prize/PrizeCode`
P.7.41f	`. . . . . <PrizeStatement>`	`/ONIXMessage/Product/DescriptiveDetail/Contributor/Prize/PrizeStatement`
P.7.41g	`. . . . . <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.3a	`. . . . <RegionCode>`	`/ONIXMessage/Product/DescriptiveDetail/Language/RegionCode`
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	`. . . . . <PersonNameInverted>`	`/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.5a	`. . . . <TextSourceDescription>`	`/ONIXMessage/Product/CollateralDetail/TextContent/TextSourceDescription`
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.3a	`. . . . <PrizeRegion>`	`/ONIXMessage/Product/CollateralDetail/Prize/PrizeRegion`
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`
	`. . <PromotionDetail>`	`/ONIXMessage/Product/PromotionDetail`
	`. . . <PromotionalEvent>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent`
	`. . . . <EventIdentifier>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventIdentifier`
P.27.1	`. . . . . <EventIDType>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventIdentifier/EventIDType`
P.27.2	`. . . . . <IDTypeName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventIdentifier/IDTypeName`
P.27.3	`. . . . . <IDValue>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventIdentifier/IDValue`
P.27.4	`. . . . <EventType>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventType`
P.27.5	`. . . . <EventStatus>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventStatus`
P.27.6	`. . . . <ContentAudience>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/ContentAudience`
P.27.7	`. . . . <EventName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventName`
	`. . . . <ContributorReference>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/ContributorReference`
P.27.8	`. . . . . <SequenceNumber>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/ContributorReference/SequenceNumber`
P.27.9	`. . . . . <ContributorRole>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/ContributorReference/ContributorRole`
	`. . . . . <NameIdentifier>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/ContributorReference/NameIdentifier`
P.27.10	`. . . . . . <NameIDType>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/ContributorReference/NameIdentifier/NameIDType`
P.27.11	`. . . . . . <IDTypeName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/ContributorReference/NameIdentifier/IDTypeName`
P.27.12	`. . . . . . <IDValue>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/ContributorReference/NameIdentifier/IDValue`
	`. . . . <Contributor>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor`
P.27.13	`. . . . . <SequenceNumber>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/SequenceNumber`
P.27.14	`. . . . . <ContributorRole>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/ContributorRole`
P.27.15	`. . . . . <FromLanguage>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/FromLanguage`
P.27.16	`. . . . . <ToLanguage>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/ToLanguage`
P.27.17	`. . . . . <NameType>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/NameType`
	`. . . . . <NameIdentifier>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/NameIdentifier`
P.27.18	`. . . . . . <NameIDType>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/NameIdentifier/NameIDType`
P.27.19	`. . . . . . <IDTypeName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/NameIdentifier/IDTypeName`
P.27.20	`. . . . . . <IDValue>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/NameIdentifier/IDValue`
P.27.21	`. . . . . <PersonName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/PersonName`
P.27.22	`. . . . . <PersonNameInverted>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/PersonNameInverted`
P.27.23	`. . . . . <TitlesBeforeNames>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/TitlesBeforeNames`
P.27.24	`. . . . . <NamesBeforeKey>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/NamesBeforeKey`
P.27.25	`. . . . . <PrefixToKey>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/PrefixToKey`
P.27.26	`. . . . . <KeyNames>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/KeyNames`
P.27.27	`. . . . . <NamesAfterKey>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/NamesAfterKey`
P.27.28	`. . . . . <SuffixToKey>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/SuffixToKey`
P.27.29	`. . . . . <LettersAfterNames>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/LettersAfterNames`
P.27.30	`. . . . . <TitlesAfterNames>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/TitlesAfterNames`
P.27.30a	`. . . . . <Gender>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/Gender`
P.27.31	`. . . . . <CorporateName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/CorporateName`
P.27.32	`. . . . . <CorporateNameInverted>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/CorporateNameInverted`
P.27.32a	`. . . . . <UnnamedPersons>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/UnnamedPersons`
	`. . . . . <AlternativeName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName`
P.27.33	`. . . . . . <NameType>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/NameType`
	`. . . . . . <NameIdentifier>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/NameIdentifier`
P.27.34	`. . . . . . . <NameIDType>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/NameIdentifier/NameIDType`
P.27.35	`. . . . . . . <IDTypeName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/NameIdentifier/IDTypeName`
P.27.36	`. . . . . . . <IDValue>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/NameIdentifier/IDValue`
P.27.37	`. . . . . . <PersonName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/PersonName`
P.27.38	`. . . . . . <PersonNameInverted>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/PersonNameInverted`
P.27.39	`. . . . . . <TitlesBeforeNames>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/TitlesBeforeNames`
P.27.40	`. . . . . . <NamesBeforeKey>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/NamesBeforeKey`
P.27.41	`. . . . . . <PrefixToKey>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/PrefixToKey`
P.27.42	`. . . . . . <KeyNames>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/KeyNames`
P.27.43	`. . . . . . <NamesAfterKey>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/NamesAfterKey`
P.27.44	`. . . . . . <SuffixToKey>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/SuffixToKey`
P.27.45	`. . . . . . <LettersAfterNames>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/LettersAfterNames`
P.27.46	`. . . . . . <TitlesAfterNames>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/TitlesAfterNames`
P.27.46a	`. . . . . . <Gender>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/Gender`
P.27.47	`. . . . . . <CorporateName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/CorporateName`
P.27.48	`. . . . . . <CorporateNameInverted>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/AlternativeName/CorporateNameInverted`
	`. . . . . <ContributorDate>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/ContributorDate`
P.27.49	`. . . . . . <ContributorDateRole>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/ContributorDate/ContributorDateRole`
P.27.50	`. . . . . . <DateFormat>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/ContributorDate/DateFormat`
P.27.51	`. . . . . . <Date>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/ContributorDate/Date`
	`. . . . . <ProfessionalAffiliation>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/ProfessionalAffiliation`
P.27.52	`. . . . . . <ProfessionalPosition>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/ProfessionalAffiliation/ProfessionalPosition`
P.27.53	`. . . . . . <Affiliation>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/ProfessionalAffiliation/Affiliation`
	`. . . . . <Prize>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/Prize`
P.27.53a	`. . . . . . <PrizeName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/Prize/PrizeName`
P.27.53b	`. . . . . . <PrizeYear>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/Prize/PrizeYear`
P.27.53c	`. . . . . . <PrizeCountry>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/Prize/PrizeCountry`
P.27.53d	`. . . . . . <PrizeRegion>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/Prize/PrizeRegion`
P.27.53e	`. . . . . . <PrizeCode>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/Prize/PrizeCode`
P.27.53f	`. . . . . . <PrizeStatement>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/Prize/PrizeStatement`
P.27.53g	`. . . . . . <PrizeJury>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/Prize/PrizeJury`
P.27.54	`. . . . . <BiographicalNote>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/BiographicalNote`
	`. . . . . <Website>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/Website`
P.27.55	`. . . . . . <WebsiteRole>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/Website/WebsiteRole`
P.27.56	`. . . . . . <WebsiteDescription>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/Website/WebsiteDescription`
P.27.57	`. . . . . . <WebsiteLink>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/Website/WebsiteLink`
P.27.58	`. . . . . <ContributorDescription>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/ContributorDescription`
P.27.59	`. . . . . <UnnamedPersons>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/UnnamedPersons`
	`. . . . . <ContributorPlace>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/ContributorPlace`
P.27.60	`. . . . . . <ContributorPlaceRelator>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/ContributorPlace/ContributorPlaceRelator`
P.27.61	`. . . . . . <CountryCode>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/ContributorPlace/CountryCode`
P.27.62	`. . . . . . <RegionCode>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/ContributorPlace/RegionCode`
P.27.62a	`. . . . . . <LocationName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Contributor/ContributorPlace/LocationName`
P.27.63	`. . . . <ContributorStatement>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/ContributorStatement`
P.27.64	`. . . . <NoContributor/>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/NoContributor`
P.27.65	`. . . . <EventDescription>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventDescription`
	`. . . . <EventOccurrence>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence`
	`. . . . . <EventIdentifier>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/EventIdentifier`
P.27.66	`. . . . . . <EventIDType>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/EventIdentifier/EventIDType`
P.27.67	`. . . . . . <IDTypeName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/EventIdentifier/IDTypeName`
P.27.68	`. . . . . . <IDValue>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/EventIdentifier/IDValue`
	`. . . . . <OccurrenceDate>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/OccurrenceDate`
P.27.69	`. . . . . . <OccurrenceDateRole>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/OccurrenceDate/OccurrenceDateRole`
P.27.70	`. . . . . . <DateFormat>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/OccurrenceDate/DateFormat`
P.27.71	`. . . . . . <Date>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/OccurrenceDate/Date`
P.27.72	`. . . . . <EventStatus>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/EventStatus`
P.27.73	`. . . . . <CountryCode>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/CountryCode`
P.27.74	`. . . . . <RegionCode>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/RegionCode`
P.27.75	`. . . . . <LocationName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/LocationName`
P.27.76	`. . . . . <VenueName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/VenueName`
P.27.77	`. . . . . <StreetAddress>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/StreetAddress`
P.27.78	`. . . . . <VenueNote>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/VenueNote`
P.27.79	`. . . . . <EventDescription>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/EventDescription`
	`. . . . . <EventSponsor>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/EventSponsor`
	`. . . . . . <EventSponsorIdentifier>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/EventSponsor/EventSponsorIdentifier`
P.27.80	`. . . . . . . <EventSponsorIDType>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/EventSponsor/EventSponsorIdentifier/EventSponsorIDType`
P.27.81	`. . . . . . . <IDTypeName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/EventSponsor/EventSponsorIdentifier/IDTypeName`
P.27.82	`. . . . . . . <IDValue>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/EventSponsor/EventSponsorIdentifier/IDValue`
P.27.83	`. . . . . . <PersonName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/EventSponsor/PersonName`
P.27.84	`. . . . . . <CorporateName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/EventSponsor/CorporateName`
	`. . . . . <Website>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/Website`
P.27.85	`. . . . . . <WebsiteRole>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/Website/WebsiteRole`
P.27.86	`. . . . . . <WebsiteDescription>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/Website/WebsiteDescription`
P.27.87	`. . . . . . <WebsiteLink>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventOccurrence/Website/WebsiteLink`
	`. . . . <EventSponsor>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventSponsor`
	`. . . . . <EventSponsorIdentifier>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventSponsor/EventSponsorIdentifier`
P.27.88	`. . . . . . <EventSponsorIDType>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventSponsor/EventSponsorIdentifier/EventSponsorIDType`
P.27.89	`. . . . . . <IDTypeName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventSponsor/EventSponsorIdentifier/IDTypeName`
P.27.90	`. . . . . . <IDValue>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventSponsor/EventSponsorIdentifier/IDValue`
P.27.91	`. . . . . <PersonName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventSponsor/PersonName`
P.27.92	`. . . . . <CorporateName>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/EventSponsor/CorporateName`
	`. . . . <Website>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Website`
P.27.93	`. . . . . <WebsiteRole>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Website/WebsiteRole`
P.27.94	`. . . . . <WebsiteDescription>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Website/WebsiteDescription`
P.27.95	`. . . . . <WebsiteLink>`	`/ONIXMessage/Product/PromotionDetail/PromotionalEvent/Website/WebsiteLink`
	`. . <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	`. . . . . <PersonNameInverted>`	`/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	`. . . . . <CorporateNameInverted>`	`/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	`. . . . . . <PersonNameInverted>`	`/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	`. . . . . . <CorporateNameInverted>`	`/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	`. . . . . . <PrizeRegion>`	`/ONIXMessage/Product/ContentDetail/ContentItem/Contributor/Prize/PrizeRegion`
P.18.59e	`. . . . . . <PrizeCode>`	`/ONIXMessage/Product/ContentDetail/ContentItem/Contributor/Prize/PrizeCode`
P.18.59f	`. . . . . . <PrizeStatement>`	`/ONIXMessage/Product/ContentDetail/ContentItem/Contributor/Prize/PrizeStatement`
P.18.59g	`. . . . . . <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`
	`. . . . <Language>`	`/ONIXMessage/Product/ContentDetail/ContentItem/Language`
P.18.68d	`. . . . . <LanguageRole>`	`/ONIXMessage/Product/ContentDetail/ContentItem/Language/LanguageRole`
P.18.68e	`. . . . . <LanguageCode>`	`/ONIXMessage/Product/ContentDetail/ContentItem/Language/LanguageCode`
P.18.68f	`. . . . . <CountryCode>`	`/ONIXMessage/Product/ContentDetail/ContentItem/Language/CountryCode`
P.18.68g	`. . . . . <RegionCode>`	`/ONIXMessage/Product/ContentDetail/ContentItem/Language/RegionCode`
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	`. . . . . . <CorporateNameInverted>`	`/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.95a	`. . . . . <TextSourceDescription>`	`/ONIXMessage/Product/ContentDetail/ContentItem/TextContent/TextSourceDescription`
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	`. . . . . . <ResourceFeatureType>`	`/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	`. . . . . <SalesOutletName>`	`/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	`. . . . . . . <EpubLicenseExpressionTypeName>`	`/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	`. . . . . . . . <EpubLicenseExpressionTypeName>`	`/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	`. . . . . . . . <PriceConditionQuantityType>`	`/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	`. . . . . . . <DiscountCodeTypeName>`	`/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	`. . . . . . . . <ResourceVersionFeatureType>`	`/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 standard or proprietary identifiers assigned 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 explicit or implicit in the Specification and the codelists, 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 Why does ONIX use XML rather than JSON?

XML (eXtensible Markup Language) is a well-established syntax for building data interchange file formats. It was derived in part from earlier work on SGML (Standard Generalized Markup Language), and as such can also be viewed as a document markup language. In XML, the markup tags indicate both the logical structure of a document and define granular data elements that can be extracted and processed separately. The design goals outlined in the XML Specification include or imply ease of use while being formal and precise, human readability (ie it is based on text rather than being a binary format), and neutrality with regard to operating system, programming language and application. They do not include terseness.

As a result of at least the perception that XML is verbose, some view JSON (JavaScript Object Notation) as being a potential alternative to XML for ONIX. JSON – derived initially from JavaScript but usable independently – has some similar aims. It is simple to use, and text-based for neutrality and human legibility. JSON is widely used for data exchange, particularly in real time across the internet, as a ‘lightweight alternative’ to XML. However, it’s perceived as being more concise than XML, and has more direct integration with data object models in common programming languages.

So why does ONIX use XML and not JSON?

In part, this is a question of history. XML was specified a couple of years before ONIX itself, and was quickly supported by a wide range of software tools. In contrast, JSON wasn’t an option when ONIX was first developed: it arose in the early ’00s as a subset of a version of JavaScript (more correctly, of ECMAScript, and specifically of ECMA-262 3rd Edition from 1999), and wide acceptance and full standardisation of JSON took several years (it was only published as a standalone specification, independent of JavaScript, in 2013).

But the deeper contrasts are more important. ONIX data certainly could be expressed in JSON, but:

XML’s requirement for end tags (eg </Text>) makes XML more verbose. ONIX files carrying a particular payload of data are larger than JSON equivalents. Its terse syntax would have been a benefit for JSON when internet bandwidth and storage were both expensive, but this is no longer the case. Filesize matters much less than it did. And if large files are compressed (eg using Zip), ONIX files with long tags, ONIX file with short tags and equivalent JSON data all compress to approximately the same file size;
JSON lacks data attributes. In effect, an XML attribute like textformat in ONIX would require the <Text> data element to be a more complex object in JSON. In XML terms, each data element would have to be a composite in JSON. This negates much of the terseness and the ‘programming simplicity’ of JSON;
the human readability of deeply nested data structures may be poor in JSON (which relies on parentheses and semicolons rather than readable end tags). This is not important in routine data exchange, but legibility becomes valuable when testing and troubleshooting;
DTDs and XSD schemas allow the structure and (with XSD) some content of XML data files to be checked and validated. This is vitally important when data needs to be highly consistent and widely interoperable when exchanged between organizations, and a DTD was an integral part of the ONIX framework from version 1.0. As of the end of 2019, JSON still does not yet have viable standard schema tools for validation, although JSON Schema is in development and may make JSON an option when fully standardised and supported by a range of software tools;
the more direct support for JSON data in a range of common programming languages is a potential benefit, and may make JSON a better choice for internal data exchange within an organisation;
namespaces are unique to XML, but rarely used in the context of ONIX (and the development of JSON-LD offers similar benefits);
in other respects, including performance, parsing XML and equivalent JSON data are roughly equal.

Overall, XML is a better choice for the exchange of highly-standardised and complex data structures between organizations, where JSON may be better where the data is simpler in structure and under the full control of a single organization, and development speed is paramount.

A.14 Key changes between ONIX 2.1 and ONIX 3.0

The table below summarizes the major changes in ONIX 3.0, for implementers 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, enough to migrate to ONIX 3.0 but without any other development, 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 seven-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 merely 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>.
	P.27	Promotional events: new in ONIX 3.0 (from revision 7), with no 2.1 equivalent, and carrying details of promotional events such as author signings and readings to promote sales of the book.
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 – or ü – are not supported in 3.0. Use native characters in your chosen encoding, or numerical character references (eg – or ü) instead. The five built-in XML entities including & and < 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 ￹, ￺ and ￻) 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.. Other application note topics include use of (X)HTML markup in ONIX, open access monographs, audiobooks,
Acknowledgement 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.

WHI	SLV	GRY	BLK	NAV
GRN	TEA	SKY	BLU	PUR
CEL	GLD	CRE	PNK	TAN
YEL	ORG	RED	BUR	BRN

WHI	SLV	GRY	BLK	NAV
GRN	TEA	SKY	BLU	PUR
CEL	GLD	CRE	PNK	TAN
YEL	ORG	RED	BUR	BRN

WHI	SLV	GRY	BLK	NAV
GRN	TEA	SKY	BLU	PUR
CEL	GLD	CRE	PNK	TAN
YEL	ORG	RED	BUR	BRN