## 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 practice’, 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.

The essence of all ‘best practice’ is consistency and predictability. If every sender and recipient interprets the standard in a different way, the result is little better than having no standard at all. The aim is to have data presented in a consistent and predictable way so that data handling can be automated right across the supply chain. Beyond this, best practice is also about effectiveness. Thus the Guide presents numerous examples to be followed and recommended solutions for various business requirements. But best practice is also 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.

It is a poor approach to base your ONIX development solely on one or two ONIX example files. The standard is large and supports a wide range of business uses, and the Specification and this Guide illustrate some of that range.

If you want just the bare essentials of what constitutes ONIX best practice, look for these summaries in the rounded boxes. In the summaries, the word ‘must’ indicates a requirement that is enforced by the ONIX for Books schema, and the word ‘should’ indicates a requirement or best practice that is not enforced by the schema (though failure to follow such requirements or practices may generate errors or warnings when validated with an extended or ‘strict’ schema).

Throughout this guide, Reference names (‘long tags’) 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 practice described in this Implementation and Best Practice Guide may be – for some ONIX 3.0 or 3.1 users – somewhat beyond the current capabilities of their internal IT systems, and initial implementations of ONIX 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 – careful analysis is needed, 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.

The best practices described herein are intended to be applicable to all ONIX for Books Release 3.1 messages, and more broadly to all ONIX 3.0 messages. However, where there are specific local circumstances, ONIX National Groups may modify, supplement or replace this document with ‘localized’ best practice intended for use within specific national markets. National Groups may also define service level expectations for data suppliers and recipients much more precisely than in this guide, and administer data quality accreditation schemes for organizations within their domain.

  This Guide is intended for ONIX 3.1. There is a separate Guide intended for ONIX 3.0, doi:10.4400/zuim.

  Although ONIX 2.1 has been considered a legacy format since the end of 2014 and obsolete since early 2023, this Guide can still provide some useful help for 2.1 in areas where there are no differences, or only modest changes, between 2.1 and 3.0 or 3.1. An appendix lists these changes.

  Many codelists are shared between ONIX 2.1, 3.0 and 3.1, 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.1

This Release 3.1 of the Implementation and Best Practice Guide adds information on a number of composites and data elements to enable hybrid open access monographs, prioritization of collateral material, market-by-market price and availability block updates, and some minor changes to improve the consistency between similar ‘name and contact details’ composites. Full use of revision 3.1 requires use of Codelists Issue 60 or later.

Unlike earlier revisions of ONIX 3.0 (ie 3.0.1 up to 3.0.8), release 3.1 (March 2023) is not fully backwards-compatible with its predecessors, as support for various deprecated elements has been dropped. However, these deprecated elements have never been a part of the best practices, and earlier ONIX 3.0 that does not use any deprecated elements (or the outmoded <Gender> element) is already ‘3.1-ready’ and requires only trivial changes to make it valid ONIX 3.1. The Specification contains an appendix listing all previously deprecated elements that have been removed from 3.1, together with their preferred alternatives.

#### Introduction to Release 3.1 revision 1 (3.1.1)

This revision of the Guide includes a small number of updates to incorporate additions made in Release 3.1 revision 1 (3.1.1) in March 2024, which in particular enable <EpubUsageConstraint> and <EpubLicense> for collateral material. One addition – <PrizeIdentifier> – requires the use of Codelists Issue 65 or later.

#### Introduction to Release 3.1 revision 2 (3.1.2)

This minor revision includes updates related to Release 3.1 revision 2 (3.1.2) in October 2024, which enable inclusion of postal addresses in <ProductContact> and <SupplyContact> as required by the EU’s General Product Safety Regulation. Full use of this revision requires Codelists Issue 65 or later.

#### Introduction to Release 3.0

This initial publication of the Implementation and Best Practice Guide is intended to document best practice for use of ONIX for Books Release 3.0. Earlier releases of ONIX were not accompanied by any EDItEUR best practice documentation, as this was the remit of ONIX national groups. However, this guide is intended to encourage a globally interoperable set of best practices. The earliest release of the codelists suitable for use with Release 3.0 (as amended in October 2010) is Issue 12.

#### 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 in January 2012. 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 in January 2014. 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) in April 2016. 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) in October 2017. 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) in October 2018. 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) in April 2019.

#### 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) in October 2019. 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.

#### Introduction to Release 3.0 revision 8 (3.0.8)

Revision 8 of the Guide includes a major new data block, <ProductionDetail>, introduced in June 2021 and aimed at eliminating the need for so-called ‘sidecar files’ and file manifests in communication between publishers and digital service providers or POD manufacturers. This new Block 8 occurs between Blocks 5 and 6 in message order. Full use of this new block requires use of Codelists Issue 54 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.
21 Jan 2020
  Added appendix on choice between XML and JSON.
  Minor updates to align with Codelists Issue 48.
17 Mar 2020
  Added extended chapter-level metadata digital audio example.
  Added appendix on Canonical XML.
  Minor edits to align with changed UK VAT rate for e‑books.
  Minor updates to align with Codelists Issue 49.
9 July 2020
  Added example of statutory tax exemption.
  Added example of carton weight and dimensions.
  Minor updates to align with Codelists Issue 50.
23 Oct 2020
  Added sales USPs example.
  Added appendix on tag conversion.
  Minor updates to align with Codelists Issue 51.
25 Jan 2021
  Minor updates to align with Codelists Issue 52.
29 Jun 2021
  Revised release, to accompany Release 3.0 revision 8 of ONIX for Books.
  Added initial version of section for Block 8 <ProductionDetail> guidance.
  Extended note on recommended style for expressing Sales rights.
  Added appendices on character-based field length limits, tag conversion.
  Minor updates to align with Codelists Issue 53.
8 Aug 2021
  Added examples of alternative contributor names.
  Added virtual currency example.
  Minor updates for clarity and style, and to align with Codelists Issue 54.
28 Oct 2021
  Added Block 8 audio example.
  Added <FeatureNote> alternative description example.
  Minor updates for clarity and style, and to align with Codelists Issue 55.
21 Jan 2022
  Added ‘will not supply’ Unpriced item type example.
  Minor updates to align with Codelists Issue 56.
12 Apr 2022
  Added table of barcode extension prefixes.
  Added <ReturnsConditions> example.
  Minor updates to align with Codelists Issue 57.
18 July 2022
  Added Product content type and Audiobook language examples
  Extended battery safety example.
  Minor updates to align with Codelists Issue 58.
31 Oct 2022
  Extended explanation of Work relation codes introduced in Codelists Issue 59.
  Added guidance on <AudienceDescription>.
  Minor updates to ‘common issues’ boxes.
  Clarified advice on <PricePer>.
  Other minor updates to align with Codelists Issue 59.
16 Jan 2023
  Clarified advice on <PricePer>
  Minor updates to align with Codelists Issue 60.
26 Mar 2023
  Revised release, to accompany Release 3.1 of ONIX for Books.
  Modified ‘At a glance’ diagrams and examples to incorporate new fields and composites added and previously deprecated elements removed.
  Added appendix listing current deprecations.
  Other minor updates for clarity and style.
  Switched internal codelist links to use ns.editeur.org/onix/en.
26 April 2023
  Minor updates to align with Codelists Issue 61.
31 July 2023
  Added examples showing greenhouse gas emission certification, third-party accessibility certification and confirming long-term digital preservation.
  Added example illustrating more granular elements of copyright (broadcast and translation rights).
  Other minor updates to align with Codelists Issue 62.
25 Oct 2023
  Added paras on LRM terminology.
  Added appendix A.18 on ‘based on’ codelists.
  Other minor updates to align with Codelists Issue 63.
22 Jan 2024
  Added examples of AI narration and Block 3 copyright statements.
  Other minor updates to align with Codelists Issue 64.
28 Mar 2024
  Revised release, to accompany Release 3.1 revision 1 of ONIX for Books.
  Modified ‘At a glance’ diagrams and examples to incorporate new field and composites.
  Extended TDM reservation example to include TDMrep link and notes.
  Other minor updates to align with Codelists Issue 65.
16 July 2024
  Added text and examples for EUDR and GPSR.
  Added notes for Latest reprint number and date.
  Minor updates to align with Codelists Issue 66.
28 Oct 2024
  Minor revision to accompany Release 3.1 revision 2 of ONIX for Books.
  Modified ‘At a glance’ diagrams and examples to incorporate new postal addresses for Product and Supply contact.
  Extended notes and examples for EUDR, GPSR.
  Other minor updates to align with Codelists Issue 67.
22 Jan 2025
  Removed examples with now-obsolete BIC subject code scheme.
  Extended example and discussion of <PriceDate> composite.
  Clarified use of CDATA with URLs in <WebsiteLink> and similar fields.
  Other minor updates to align with Codelists Issue 68.
  Added warning about copy-and-paste with ZWSP characters.
17 Mar 2025
  Documented regexes for EUDR.
  Added examples showing proprietary Publisher IDs for internal business units and listing dramatis personae, extended example showing decorated page edges.
  Added section on <NoProduct/>.
  Other minor updates to align with Codelists Issue 69.
21 July 2025
  Added Appendix A.19 on interactions between fields.
  Clarifications relating to chapter-specific metadata and audio timings.
  Other minor updates to align with Codelists Issue 70.
31 Oct 2025
  Further notes on EUDR.
  Added example for artistic event in P.8.
  Other minor updates to align with Codelists Issue 71.
20 Jan 2026
  Added cited content podcast and playlist links.
  Added timing detail extracted from example ONIX.
  Minor updates to align with Codelists Issue 72.

## 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 benefits of adherence to the ONIX framework, the Standard and best practices include:

- the opportunity to develop robust business processes for the creation and maintenance of metadata;
- a common understanding of metadata concepts and an accepted industry-wide lexicon understood at the points of metadata creation and use;
- reduced costs of duplicated data entry and data processing, via automated communication and data sharing within an organization and across the supply chain;
- a basis for excellent metadata quality and consistency, which promotes growth in sales and helps eliminate supply chain inefficiencies;
- data interoperability across diverse IT systems, enabling growth of a competitive ecosystem of off-the-shelf software;
- improved internal communication;
- an enabler for innovation with new supply chain partners;
- a truly international approach, suitable for use across geographies, languages, scripts, currencies, and for all types of books, whether digital or physical, for audio, and for many other book-related product types;
- a consistent and stable data model reduces change management issues, promotes staff mobility and future-proofs investment in training;
- semantic compatibility with other standards (for example MARC or BIBFRAME) enables exchange of data across the broader sector;
- the standard is created by expert practitioners – and both informs and is informed by national and international consensus and metadata best practices;
- robust governance, managed by EDItEUR, provides continuity and protects investment in metadata and systems.

Those adopting ONIX often cite the following reasons for not adopting it earlier:

- lack of management awareness of the importance and commercial value of accurate, consistent and timely metadata;
  - in particular, a lack of visibility of the costs of missing or erroneous metadata in terms of lost sales, customer service costs and poor internal communication;
  - and failure to account for staff time dealing with spreadsheets;
- lack of budget to buy into off-the-shelf software or a service to manage their metadata;
- concerns about the availability or quality of current or pre-adoption data (usually in spreadsheets) and the likely costs of data migration;
  - and lack of available staff time for that data clean-up and migration.

Clearly, adopting ONIX requires a business rationale and a budget that balances the necessary spend and time against potential savings and increases in revenue.

A commitment to ONIX is really a commitment to investing in data management processes and metadata quality right across a business.

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 freely downloadable from the EDItEUR website:

- the Specification is available as PDF and HTML files;
- this Guide is only available as an HTML document;
- XML schemas are available in 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 HTML, as CSV, TXT (tab-separated) and proprietary XML and JSON formats for integration into proprietary applications, and 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;
- a range of Application notes and other supplementary guidance are also available from the EDItEUR website;
- 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 specifications, associated documentation, schemas and related tools are available free of charge to all, no registration process is necessary, and there are no charges or royalties payable to EDItEUR if you implement in your systems or otherwise make use of 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 implementation forum (subscribe by sending a blank e‑mail to onix+subscribe@groups.io). This is a discussion forum for ONIX-related questions, and any updates to documentation, schemas and codelists are announced there. Implementers may also wish to subscribe to EDItEUR’s regular e‑mail list for more general news (e-mail news-from@editeur.groups.io to subscribe).

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, e‑book and audiobook 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. Codelists are revised and extended on a regular basis – usually four times per year. 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 developments must be approved by the ISC. After approval, major developments are carried through in line with the ONIX development and support lifecycle. Typically, this process results in an update of the main Specification once every two years. From time to time, minor improvements that do not change the schema, and changes to correct errors are also incorporated into documentation and schemas.

Such updates to both Specification and codelists are announced via the EDItEUR website and the ONIX e‑mail implementation forum.

#### Design principles

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 rich bibliographic, promotional and commercial 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.

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 or library, 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.

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.

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. Recipients of all types may receive and integrate data from multiple sources – this is particularly complex when multiple sources describe the same product.

ONIX data is intended to be dynamic – that is, it can be updated at any time by sending another ONIX message that describes the same product. Matching incoming data in a message with existing data in a database is critical, and this is intended to make use of a unique and persistent Record reference that’s independent of the ISBN or other Product identifiers. The Record reference identifies ‘the sender’s metadata describing a product’: this allows recipients to update their data based on matching the incoming Record reference with previous data stored in the recipient’s system with incoming data, or to create new a new internal record when there is no match. It also allows a recipient to manage data about the same product but from different senders, since they will have different Record references but matching Product identifiers. In principle, the updated metadata entirely replaces the pre-existing metadata: the replacement happens at ‘whole product’ level, not on a field-by-field basis. However, there is an option for ‘partial updates’ (often termed ‘block updates’) whereby unchanged blocks of metadata may be omitted from an update – although once again, the granularity of partial updated does not extend to field-by-field updating.

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 understand and agree 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 merely a recommended price that may be reduced (or increased) 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. The fundamental entity in ONIX is the Product. ONIX Product records describe <indecs> manifestations – these are the ‘products’. A hardback, a large-format paperback, mass-market paperback, PDF e‑book, EPUB e‑book which all embody the same content are all distinct manifestations, and in ONIX, each of these must have a separate Product record and a separate identity. There may of course be thousands of identical copies – items or occasionally, instances – 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).

Occasionally, items are not singular objects and may comprise two or more components (eg a book in three volumes, or a book and a toy): these can be described as multi-component products. The components may or may not also be products in their own right and available separately. Products may also be composed of multiple identical items (eg 16 copies of a book, available as a single product).

ISBNs identify – though do not define – manifestations. That is, a manifestation can be unambiguously identified by an ISBN, though for practical purposes, a manifestation may sometimes be assigned more than a single ISBN, or may be assigned a different kind of identifier altogether.

In ONIX, products are the manifestations of works – abstract entities comprising the intellectual property embodied in a manifestation or a set of manifestations. In fact, in <indecs>, these works are termed abstractions, and they are often loosely termed ‘titles’). 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. Formerly, ISTCs identified works, but there is no standard textual work identifier in common use.

Each manifestation is a set of essentially identical items (or instances, or more loosely, ‘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.

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 reseller database. The message schema used for communication, the database schema used for data storage and management, and the underlying abstract data model are not usually the same. Some metadata elements are managed at manifestation or product level – the ISBN, product form or publication date 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).

Note that in library contexts derived from FRBR (including LRM), the term expression is sometimes used to denote the entity close to what ONIX and <indecs> term a work, and a FRBR / LRM work is a broader and yet more abstract entity from which related expressions (ie the original, revised, translated and abridged works above) are derived. Within the ONIX / <indecs> model, while such a broad entity might plausibly be defined – a FRBR / LRM work is conceptually similar to a complete chain of <indecs> works and derived works – it carries no relevant metadata. However, LRM in particular emphasizes the various agents (broadly, the contributors) linked to an expression, so an audio expression may be differentiated from a textual expression because it has an extra agent (the reader). In contrast, ONIX and <indecs> focus on transformation of the contained intellectual property to define and distinguish works, so unabridged audio would not be defined as a separate ONIX work, even though there may be different contributors.

In other library contexts derived from the BIBFRAME model, an ONIX work is close to that entity called a BIBFRAME work, and an ONIX manifestation (ie a product) is termed a BIBFRAME instance. A FRBR / LRM work is close to that entity termed a BIBFRAME hub.

It should be noted that while there are minor differences in the definitions of largely equivalent entities across FRBR, LRM, BIBFRAME and <indecs>, the variation in terminology causes much more confusion than any differences between the entities themselves in any discussion of these models. And it must be stressed that all of the models agree on the nature of a manifestation (even if in BIBFRAME it is termed an instance), and that FRBR / LRM expression, BIBFRAME work and ONIX / <indecs> work are at least roughly equivalent. A FRBR / LRM work and BIBFRAME hub might be represented in ONIX / <indecs> as an entire network of works derived from some original ‘ur-work’ (the head of a chain of derived works).

In principle, a single ONIX message that meets the requirements of the Specification, and follows best practices described here in the Guide should be suitable for any recipient able to accept ONIX 3.1 (and in many cases where the message does not make use of newly-introduced data elements, it will also be suitable if they are able to accept 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.

In practice, however, such interoperability is imperfect, usually because of incomplete implementation of the standard. This can be costly, because it means that senders must create bespoke ONIX files for each recipient. Senders and recipients should take great care to avoid imposing non-standard requirements on their business partners. This includes requirements to omit particular data fields, as well as requirements to include non-standard information in a particular field, or limit which codes in a codelist can be used.

ONIX data depends on semantic precision, shared definitions of terms, 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 a subtly or 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> may not appear important, but it can indicate a price is limited to libraries, or to members of some particular group, while a different 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.

Equally, recipients who choose to support only a subset of the codes in a particular codelist should ensure that non-supported codes that are supplied in a sender’s ONIX file are mapped (by the recipient) to the most appropriate supported code. This mapping cannot be done properly by the data sender, as the appropriate mapping is dependent on details of the recipient’s business processes.

There is however, a common requirement to vary the selection of records included in a particular data feed – for example, removing a retailer-exclusive product from data sent to other retailers (at least in the period 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.

Finally, ONIX is an evolving standard – it is constantly reviewed and regularly revised in reaction to emerging issues within the metadata supply chain that it serves. A failure to keep reasonably in alignment with the latest revisions of the Specification or the codelists, or worse, continued reliance on obsolete versions of the standard, adds long-term costs to the metadata supply chain.

Common issues with implementation:

- failure to implement specific data fields and composites, particularly those that are important to supply chain partners;
- supporting only a subset of a particular codelist;
- misuse of particular data fields for apparent convenience;
- failure to keep systems reasonably up-to-date.

Occasionally, issues arise from genuinely misunderstanding how ONIX ‘works’. But there is copious documentation and training available that should help avoid such issues. Only a couple of concepts or data structures in ONIX might be ‘difficult’ to grasp – collections and multiple markets, certainly, and perhaps the concept of works – and there is a range of EDItEUR Application notes to help demystify them.

Some of these issues arise because a data recipient bases an implementation on the messages sent by a particular sender whose data is idiosyncratic (or a data sender bases their entire implementation around the unique requirements of one particular recipient). This is a poor recipe for interoperable messaging. Recipients should try to ensure any valid message can be received and parsed, even if some unwanted data elements are ignored. Both senders and recipients should base their implementations on the standard Specification, then add any required elaborations afterwards.

And of course some issues arise from poor business analysis within an organization that fails to take account the requirements of other parts of the supply chain, or which focuses too narrowly on a ‘minimum’ implementation because it is seen as less expensive.

All of these issues encourage the use of many bespoke ONIX messages, each of which can only be used by one data recipient. This is sometimes termed the ‘flavors of ONIX’ problem. It raises costs, reduces interoperability and often reduces ONIX to a ‘lowest common denominator’ approach.

Above all, recipients should make all effort to avoid setting metadata ingestion requirements that contradict those of the standard itself. And senders should ensure their messages align with the Specification and the best practices, which helps reassure data recipients.

See the EDItEUR Application notes Twelve ONIX problems (doi:10.4400/agvg) and Another twelve ONIX problems (doi:10.4400/errv) for some concrete examples of these issues, seen from the differing points of view of data recipients and senders.

#### 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 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 through increased interoperability.

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.1 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 gray rather than blue. A small number of deprecated elements such as <DefaultLanguageOfText> (within <Header>) 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.1" xmlns="http://ns.editeur.org/​onix/​3.1/​reference">` | upper case M

  using Short tags |
  --- | ---
  `<?xml version="1.0" encoding="UTF-8"?>` |
  `<ONIXmessage release="3.1" xmlns="http://ns.editeur.org/​onix/​3.1/​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.1/​reference and /short do not represent real files on the internet – there is nothing at those addresses. They act merely as XML ‘namespaces’, names that can be used as prefixes 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 strongly 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 typically required for validation of the ONIX message using the XSD or RNG schemas.

For XSD validation in particular, the xmlns attribute must be present, and for many validation tools the xmlns:xsi and xsi:schemaLocation attributes need to be added as well. Together, the xmlns:xsi and xsi:schemaLocation attributes added to the <ONIXMessage> element give the local network location of the schema file when files are validated and processed internally.

However, ONIX 3.1 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. Note also that unlike some earlier versions of ONIX – transmitted messages must not include a DOCTYPE declaration. There is no DTD available for ONIX 3.1.

  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.1" xmlns="http://ns.editeur.org/​onix/​3.1/​reference" xmlns:xsi="http://www.w3.org/​2001/​XMLSchema-instance" xsi:schemaLocation="http://ns.editeur.org/​onix/​3.1/​reference http://intranet/​onix/​ONIX_BookProduct_3.1_reference.xsd">`

  using Short tags
  `<?xml version="1.0" encoding="UTF-8"?>`
  `<ONIXmessage release="3.1" xmlns="http://ns.editeur.org/​onix/​3.1/​short" xmlns:xsi="http://www.w3.org/​2001/​XMLSchema-instance" xsi:schemaLocation="http://ns.editeur.org/​onix/​3.1/​short http://intranet/onix/​ONIX_BookProduct_3.1_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.
  For more on validating XML – the technical process of checking ONIX messages meet the syntactic requirements of the standard – see EDItEUR’s Validating ONIX 3.0 and 3.1 files application notes (doi:10.4400/akzw), or DIY Schema Validation for Workmanlike ONIX, a comprehensive set of instructions for validation beginners by Tom Richardson of BookNet Canada. While the latter is 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

1. 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 ‘&eacute;’ cannot be used in ONIX 3.0 or 3.1). For the truly technical, use Unicode Normalization Form C;
2. 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);
3. whatever the chosen character encoding, the XML encoding declaration in the first line of the file must match the encoding that is actually used;
4. all ONIX markup – the various tags used in an ONIX message, including all the tag and attribute names, though not the attribute values – 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 a comma or mid-dot as a decimal separator in real numbers is not valid);
5. 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);
6. the order of the different XML data elements in the message is critical. In any Product Record, elements must occur in the correct order, as defined in the ONIX Specification and the XSD and RNG schemas. 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;
7. in contrast, the order of particular repeats of repeatable data elements or composites is not particularly meaningful – which is why <Contributor> composites contain sequence numbers to make the ordering or priority of multiple contributors explicit and why <MainSubject/> exists to prioritize one subject from each subject scheme. 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. Nonetheless, 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;
8. senders should ensure that their ONIX messages are structured correctly by validating them using the XSD or RNG schemas;
9. 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);
10. 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;
11. senders should avoid the continued long-term use of deprecated data elements or deprecated codes from codelists (even though they remain valid);
12. both senders and recipients should keep reasonably up-to-date with new issues of the ONIX codelists (these are typically released quarterly), and with any minor revisions of ONIX 3.1 itself (its predecessor ONIX 3.0 was subject to eight such minor revisions, 3.0.1, 3.0.2… etc);
13. 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.7, a message that includes a data element added in revision 3.0.8 or even in 3.1 should not necessarily 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 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;
14. 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;
15. messages must never include any empty XML elements, with the exception of 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;
16. 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> followed immediately by </NoEdition> (with no data, not even a space, between the opening and closing tags) is syntactically identical to <NoEdition/>, the former should be avoided in ONIX;
17. ONIX senders should avoid excessive white space (particularly spaces and tabs, or multiple blank lines) between data elements: while examples in this document are indented for readability and to emphasize structure – and such simple indentation is okay – there is no requirement to indent real messages with tabs or extra spaces in this way. (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 slightly 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;
18. 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.1 or 3.0 XSD schemas, so must not be included;
19. 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;
20. 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;
21. where XHTML markup is allowed, HTML is also allowed. However, it must be escaped (using ‘&lt;’ instead of ‘<’) or placed within <![CDATA[ … ]]> tags;
22. you should not use <![CDATA[ … ]]>, unless there is a specific need to embed HTML markup within a particular data element. It is very poor practice to surround any ordinary data (plain text, codes from codelists, numbers or dates) or any 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 careful data validation process. And if you’re using <![CDATA[ … ]]> with HTML tagging (which is its most common use in ONIX), consider whether you could use XHTML (without CDATA) instead;
    - exceptionally, CDATA may also be useful with data fields that hold URLs which include multiple query parameters, but this is relatively rare;
23. you should limit HTML and XHTML markup elements to a simple subset of possible tags – to be cautious, use only <p>, <br /> (or <br> in HTML), <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. Note that <u> is not valid in XHTML within ONIX, and is not recommended in HTML. Also avoid XHTML or HTML attributes (things like style="color: red") – with the exception of the type and start attributes on HTML list tags;
24. in environments where ONIX 3.1 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- or 3.1-only codes are used only in 3.0 or 3.1 as appropriate. 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.1 and 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);
25. 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;
26. aside from the initial <?xml … ?>, you should not include XML processing instructions (anything surrounded by <? … ?>) in the ONIX message;
    - exceptionally, an XML processing instruction may be necessary to enable Schematron rules using the ‘strict’ XSD schema, but like any xsi:schemaLocation attribute that specifies the file location of an XSD or RNG schema, the processing instruction should be removed before sending the ONIX message onwards to data supply chain partners;
27. 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. One useful comment that might be left in place is something like <!‑‑ product #5 of 106 ‑‑> at the top of each Product record. Place any comments between ONIX data elements, not within them, even though the latter might technically be valid XML (ie avoid <ProductForm><!‑‑ paperback ‑‑>BC</ProductForm>);
28. 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;
29. 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;
30. developers, implementers and those responsible for ongoing management of ONIX systems should join the ONIX implementation forum (subscribe by sending a blank e‑mail to onix+subscribe@groups.io). Announcements about new codelists, and new releases or revisions of ONIX are posted to this forum.

Finally, all developers, implementers and system managers should note the license agreement that governs the use of ONIX, EDItEUR’s specifications, supporting documentation and XML tools (doi:10.4400/nwgj), and those responsible for ongoing management of ONIX systems should particularly note the ‘implied license’ covering the use of any metadata supplied using ONIX.

#### Organization of data delivery

All ONIX message files must be well-formed XML, must be valid according to the latest XSD schema available from EDItEUR – see High-level message structure and conformance – and must conform with any additional business rules outlined in the ONIX for Books Specification.

Parties exchanging ONIX data should ensure each understands the criteria for inclusion of particular Product records in the data feed.

Data senders should establish and maintain a data feed with an initial full file containing data on all products, followed by a sequence of delta update messages when product details are changed. Update messages should be generated at least weekly – and ideally daily – unless there have been no changes since the last update was sent. If updates are scheduled in advance, and there have been no changes, a message including <NoProduct/> helps make this explicit;

- a typical ONIX message contains many product records or updates;
- it is normal to combine new Product records and updates of existing records in the same ONIX message.

Within the context of a feed, messages must be processed by the recipient in the order they were created by the sender. <SentDateTime> indicates this order. If a message is inadvertently processed out of order, it and all subsequent messages must be re-processed.

All key information about each individual product should be included in an ONIX data feed at least four months prior to publication (up to six months in some national supply chains), and the product metadata should be maintained throughout the life of the product – at least until the product is out of commerce.

Common problems with data delivery

- failure to agree details of the data exchange outlined in Appendix A.5;
- messages that are invalid, for example because the character encoding is omitted from the XML declaration and the file does not use Unicode (see Appendix A.6), or because they do not meet the requirements of the ONIX Specification or the accompanying XML schemas;
- recipient demands that valid data fields be removed, because the recipient cannot ‘ignore’ the data elements they do not use;
- recipient requirements for non-standard additions or non-standard data content in specific data elements;
  - any business requirements that cannot be met within the current standard should be discussed with EDItEUR, to determine whether they need to be incorporated into the next revision of the ONIX Specification or of the codelists;
- very large numbers of ONIX message files deliberately constructed with one Product record per ONIX file, which are unreasonably onerous for recipients. The ONIX structure is designed to carry multiple Product records in a single message.

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 two 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. However, a data feed consisting only of full updates is hugely inefficient, as each message requires re-processing of a large proportion of unchanged data;
  - recipients should first match each newly-received record with existing records in the recipient’s system on the basis of the <RecordReference>, then replace any and all data previously associated with each product with the new data in the latest message (this means that any data previously held for a particular matched product, but not included in the new full update, should be deleted). Note – the primary method of deletion of fields from a record is by replacement of the whole record;
  - all remaining newly-received product records that cannot be matched with existing records represent products newly added to the sender’s product range, and should be added to the recipient’s system;
  - depending on the feed’s selection criteria, recipients’ existing records that are not matched with a newly-received record might appear to require deletion. However, this is not the case: recipients’ existing records that are not matched should be left unchanged. Data suppliers should use a change of Publishing status (eg publication abandoned or publication out of print or permanently withdrawn from the market) 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 which are brand new or 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. Only the necessary brand new and modified replacement records are sent;
  - 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’;
  - recipients 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 data previously associated with each product with the new data in the latest message (this means that any data previously held for a particular matched product, but not included in the new full update, should be deleted). Note – the primary method of deletion of fields from a record is by replacement of the whole record;
  - all remaining unmatched records in the message represent products newly added to the sender’s product range, and should be added tothe recipient’s data;
  - recipients’ existing records that are not matched should be left unchanged;
  - except that – in more sophisticated implementations – 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.

The majority of ONIX data feeds begin with an initial full update followed by numerous delta updates. In principle, there is no need for any further full update. However, providing a full update perhaps once every six months helps avoid the accumulation of any processing errors.

Note that ‘full’ or ‘delta’ are characteristics of an ONIX file – the message either contains the sender’s full product range (or the full range falling within some set of criteria agreed for the feed), or it contains just the subset of that range that is subject to update (ie the delta file does not contain those product records that remain unchanged since the previous ONIX file). In contrast, a partial or ‘block update’ (below) is a characteristic more clearly associated with a particular Product record within an ONIX message. A partial or ‘block update file’ is an ONIX message containing at least one Block update record (and this could be viewed as a third supply mode);

- Partial update – more often termed a Block update – is a refined type of Product record that may only be used in the context of a delta update, introduced in ONIX 3.0. The body of any Product record consists of up to eight more or less independent groups of data elements, or ‘blocks’. There are blocks dedicated to describing the nature of the product itself, to marketing collateral, to publishing details and territorial rights, etc. These Blocks 1–8 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’. Normally, a Product record contains all relevant Blocks, and a recipient should replace all previous data with the content of the newly-received record. A Block update includes only Groups P.1 and P.2 (‘block zero’) plus whichever of Blocks 1–8 contain data that has changed. A recipient should replace previously-received data related to the block supplied in the update, but leave data related to other blocks unchanged:
  - this minimizes the message size because unchanged Product records and unchanged Blocks within changed records are omitted. Only the necessary replacement blocks (plus the required block zero) are sent, and only those blocks need be processed by the recipient;
  - but note that updates cannot be more granular than ‘whole block’ – you cannot send an update that consists of just the individual data elements that have changed;
  - block updates are more complex to implement for both sender and recipient – for example, journaling of changes must be more granular than for ordinary delta updates;
  - many recipients forget that a block update of one or more blocks also signifies no change in all other blocks, which means that the <SentDateTime> of the block update in fact applies to the modified record as a whole. Omission of a block from a block update carries the implication that previously-supplied data is still correct – not that it should be deleted – 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);
  - if deletion of all data previously supplied in a particular block is the intention, most blocks can be empty (but only in a block update). A block such as <PromotionDetail/> (an empty Block 7) implies deletion of all previously-supplied Block 7 data;
  - note that Block 6 consists of the repeatable <ProductSupply> composite. In most circumstances, it is best to view these <ProductSupply> composites as inseparable, ie there is in effect a single and non-repeatable Block 6, consisting of a single or multiple <ProductSupply> composites representing one single or 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 should 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;
  - however in Release 3.1, the new <MarketReference> data element is intended to enable Block updates of a single market, independent of any others. With appropriate use of Market reference, Block 6 can be treated as truly repeatable, with each repeat of <ProductSupply> individually updatable via a Block update;
  - note that Block updates and ‘full record’ Product 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);
    - although the Specification does not preclude them, Block update records within a Full update message make no sense and should not be used;
  - it is likely that initial ONIX 3.0 and 3.1 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 and 3.1, 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 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, 7 and (perhaps) 8 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 very large. A comprehensive sample message included in an earlier version of the ONIX Specification is a little under 17 kilobytes for a single Product record: records for complex non-fiction with chapter-level metadata (in Block 3) and an extensive table of contents, and 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 further. ‘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 helps a little – it usually reduces the message size by around 20–25%, and the sample message included with the Specification is reduced from 16.7 kilobytes using Reference names (long tags) to 12.5 kilobytes with short tags . However, 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 long or short tags and ZIP compression on typical ONIX file size
  Product records | file size with reference names (kB) | file size with short tags (kB) | reference names zipped (kB) and compression % | short tags zipped (kB) and compression %
  --- | --- | --- | --- | ---
  1 (sample file) | 17 | 13 | 5 | 5
  100 (production file) | 1405 | 1117 | 175 (87.5%) | 170 (85%)
  1000 (production file) | 19,923 | 15,865 | 1898 (90.5%) | 1853 (88.5%)

  ZIP compression reduces the file size of typical large (English language) ONIX production files by up to about 90%. The percentage compression above was calculated using various real-world files from different publishers, with different data content – which is why the average record length varies between the three files – and your compression rate will vary.

  Note that zipped reference name files are not significantly larger than zipped short tag files.

  Files don’t necessarily need to be compressed in advance. When transferring files via HTTP or FTP (or their secure alternatives), it is possible to apply ZIP (or more specifically, GZIP) compression as the file is transferred.

  Reference names are more commonly used than Short tags, but both are fully supported in ONIX 3.1.
  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.1-Downloads/#Tools.

ONIX messages are normally exchanged via FTP, FTPS or SFTP, or via HTTP or HTTPS file transfers (the ‘S’ variants are preferred), 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 and HTTP file transfers, 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 or for file transfers via HTTP 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 also possible for senders to push collateral resources to an FTP server maintained by the recipient – and in this case, senders should provide filenames rather than full URLs 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

Purely factual information – such as the title of a book or its publication date – is not usually subject to copyright. However, 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.

For this reason, ONIX data sent to a recipient is sometimes accompanied by an explicit and formal license covering the acceptable use of that copyright data. However – even in the absence of such an ‘express 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 some or all of the ONIX product data supplied (including that to which copyright applies, and including any associated collateral material linked from the product data) for the purposes of cataloging, trading in, merchandising, promoting and selling the products described, both internally within the recipient organization and in its customer-facing applications. ONIX data recipients should treat this implied license as limited, non-exclusive, non-transferable, non-sublicensable, and should not redistribute or provide access to the original or modified data in bulk to third parties either commercially or non-commercially without express permission. The geographical scope of the implied license extends to at least those territories with positive sales rights. ONIX recipients should also treat compliance with Embargo, Valid From/Until and Announcement dates, Sales rights and restrictions, 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). There is no particular duty to use the metadata exactly as supplied: recipients may make reasonable corrections or augment the supplied metadata with information from other sources, and need not use every supplied data element. The implied license does not cover uses beyond those for which the ONIX data is clearly intended.

A typical reseller 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 broadly as supplied), or intending to redistribute or make modified or unmodified data available in bulk to a third party in any manner (eg via an API, via data harvesting, via file distribution, and whether commercially or non-commercially), or intending to make use of the data in any way other than for cataloging, promoting and trading of the products described, should secure an express license from the data supplier rather than relying solely on the implied license.

Such formal licensing agreements should be concluded separately between data supplier and recipient, and might cover both permitted uses of the supplied data and the duties, limitations and service level expectations placed upon data supplier and recipient.

Use of the ONIX message format itself – as distinct from the metadata supplied in ONIX format – is covered by EDItEUR’s highly permissive license (doi:10.4400/nwgj).

#### Checking ONIX 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, and no DTD is available for ONIX 3.1). 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 within 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 this ‘strict’ XSD 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.12.
  Many product data management applications which support ONIX output incorporate application-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), Atom (cross-platform, though no longer fully supported) or BBEdit (on Mac OS), and it can be viewed (but not edited) in a modern web browser. Even the simple built-in Notepad (Windows) or TextEdit (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 in this way, by eye, it is best to stick to a very small ONIX file – just one, or certainly no more than a couple of dozen Product records – at least until you have more experience.

Opening a small ONIX file in a modern web browser (Firefox version 4+, Chrome 9+, Safari 5.1+, Edge 20+, IE 9+) or text editor (Notepad++, BBEdit) 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 disclosure triangles (▼ or ►) in your chosen web browser or text editor application hides or reveals the contents of the composite elements – the first of the two <Measure> composites has been collapsed in the example above.

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

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

  Text editors like Notepad++ and BBEdit 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 using a web browser or plain text editor makes it straightforward – though laborious – to check your ONIX file against the examples given in this guide, or to discover how data elements visible in the user interface of 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 <TitlesBeforeNames>, 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 it receives from its metadata suppliers, and insert the parsed data into its 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.

Having said that, 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.

So what should you do if you discover an issue such as an invalid message, an internal inconsistency, missing data that’s critical to your business process or that of your supply chain partners, or any clearly erroneous metadata? Senders should clearly fix the issue in their outgoing metadata. But recipients should usually not fix it – lest they have to repeat the fix every time an update is received. Recipients should contact the sender of the ONIX message (named in <Sender>), or the original source of the metadata (named in <RecordSourceName> or – if it’s present – in <ProductContact> with Contact role 00), and the sender or original source should fix it in a subsequent update message.

## ONIX for Books Message header

### Header composite

Every ONIX for Books message must contain message header information in the <Header> composite. The header contains metadata about the message itself that’s critical to the way that the recipient treats the message. It:

- 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 whenever possible specify a 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. The time is vital if there is any possibility of intra-day updates;
  - recipients must process messages in the order they were sent. If the <SentDateTime> of the current message is earlier than that of the previous message, the message is out of order. If a message is inadvertently processed out of order, previous messages that were processed ‘too early’ must be re-processed;
- 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.

Common issues in the message header:

- inconsistency between the message order implied by a message sequence number, the date and time of the message, and any overall file naming convention. Messages must be processed in strict order, and <MessageNumber>, <SentDateTime> and any file naming convention must be consistent to avoid any ambiguity;
- inclusion of the contact’s phone number in <ContactName>, instead of in its own field;
- inclusion of default language, price type and currency parameters – these are not recommended and are formally deprecated – language, price type and currency should be explicit in each Product record;
- lack of response to queries directed to the sender’s e‑mail address.

  sending a <Header>
  using Reference names |
  --- | ---
  `<Header>` |
  `<Sender>` |
  `<SenderIdentifier>` |
  `<SenderIDType>06</SenderIDType>` |
  `<IDValue>5030670137992</IDValue>` |
  `</SenderIdentifier>` |
  `<SenderIdentifier>` |
  `<SenderIDType>07</SenderIDType>` |
  `<IDValue>0137995</IDValue>` |
  `</SenderIdentifier>` |
  `<SenderName>HarperCollins UK</SenderName>` |
  `<ContactName>Jane King</ContactName>` |
  `<TelephoneNumber>+44 20 7946 0123</TelephoneNumber>` |
  `<EmailAddress>jbk@hcp.co.uk</EmailAddress>` |
  `</Sender>` |
  `<Addressee>` |
  `<AddresseeIdentifier>` |
  `<AddresseeIDType>06</AddresseeIDType>` |
  `<IDValue>5030670090754</IDValue>` |
  `</AddresseeIdentifier>` |
  `<AddresseeIdentifier>` |
  `<AddresseeIDType>07</AddresseeIDType>` |
  `<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>` | GLN
  `<b244>5030670137992</b244>` |
  `</senderidentifier>` |
  `<senderidentifier>` |
  `<m379>07</m379>` | SAN
  `<b244>0137995</b244>` |
  `</senderidentifier>` |
  `<x298>HarperCollins UK</x298>` |
  `<x299>Jane King</x299>` |
  `<j270>+44 20 7946 0123</j270>` |
  `<j272>jbk@hcp.co.uk</j272>` |
  `</sender>` |
  `<addressee>` |
  `<addresseeidentifier>` |
  `<m380>06</m380>` | GLN
  `<b244>5030670090754</b244>` |
  `</addresseeidentifier>` |
  `<addresseeidentifier>` |
  `<m380>07</m380>` | SAN
  `<b244>0090751</b244>` |
  `</addresseeidentifier>` |
  `<x300>Gardners Books</x300>` |
  `</addressee>` |
  `<m180>262</m180>` |
  `<x307>20100510</x307>` | 10th May 2010
  `</header>` |

##### Sender composite

The <Sender> composite is mandatory, and identifies the sender of the ONIX message file (which is not necessarily the organization originally responsible for the data within the message – the Sender may be an intermediary organization).

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, phone number and e‑mail address of a contact person who is responsible for the technical and operational aspects of the ONIX message, in the <ContactName>, <TelephoneNumber> 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 NielsenIQ Bookdata and Bowker.
  SANs and GLNs are – to some degree – interoperable. Specifically, SANs assigned by the NielsenIQ UK SAN Agency (only) may be prefixed with the six-digit ‘magic number’ 503067, then the check digit recalculated to create a valid GLN. If you have a SAN (from NielsenIQ Bookdata) 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.

Phone numbers should be in full international format including the leading + sign, as in the examples above.

Providing at least 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 entire 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 all – or at least multiple – supply chain partners.

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 – and the latter can only be detected if a <MessageNumber> is present in each message file.

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 solely on, say, the day number or date 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 local time at the sender’s location, 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 Sent date time and Message sequence number are critical to recipients. The former can be used alone to ensure messages are processed in the right order – and often this appears to be enough. But unless there is a predetermined and detailed schedule for messages in place and <NoProduct/> is used correctly, the latter is required to detect messages that have been missed, for example due to a problem in transmission.

- if an out-of-order message is received, the recipient must process it, and then re-process all previously-received messages with a later <SentDateTime>.

Most ONIX data feeds are a mix of full files and delta files (incremental updates):

- a recipient must process a full file, unless the sender has deliberately given it the same Message sequence number as the latest delta update. 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 month at most, and annually at the least) 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 strictly 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 it ad all subsequent messages in the correct order;
- as a double-check, the sender and recipient may agree a filenaming convention to include the sequence number, but the message sequence number within the file should be treated as the authoritative sequence number.

An often-overlooked aspect of a delta file is that is serves to re-confirm that all previously-sent data that is not included in the message remains correct. If the sender maintains rigorous datestamping of data, datestamps on previously-received data may be updated.

##### H.16 Message note

Message note is optional, but it can be useful when diagnosing issues if a short note is included to describe the type of Product records in the message and indicate the IT system – off-the-shelf or in-house developed – that created the ONIX file.

  including a Message note
  using Reference names |
  --- | ---
  `<MessageNote>HCUK daily block updates for digital resellers – sent from Plan G</MessageNote>` |

  using Short tags, including a multilingual variation |
  --- | ---
  `<m183 language="eng">HCUK daily block updates for digital resellers – sent from Plan G</m183>` | Note in English
  `<m183 language="fre">Mises à jour de bloc de HCUK pour les revendeurs numériques – envoyées par Plan G</m183>` | …and in French

  Note that <MessageNote> is repeatable with parallel text in different languages. If there are multiple notes, the language attribute is mandatory on each repeat. Many other textual data fields are repeatable in this way.

##### 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 explicitly within each Product record instead.

Note that if it is used, <DefaultLanguageOfText> refers to the default value of <LanguageCode> when <LanguageRole> is 01 (the language of the text within the product), to be used when a particular Product record does not specify the language. It does not indicate the language used within the metadata that describes the product. The default Price type and Currency code specify the defaults to be used when any <Price> in the message does not explicitly specify <PriceType> or <CurrencyCode> data elements.

## ONIX for Books Product record

### Product composite

Every ONIX for Books message must contain at least one repeat of the <Product> composite, unless it contains a <NoProduct/> tag. Each <Product> composite – a ‘Product record’ – describes a single product. It 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–8 (each Block is optional in a ‘block update’, but in a normal Product record at least Blocks 1 and 4 are required – and 6 is normally expected).

  Note that in some circumstances, the singular Block 6 is considered to be the combination of all the <ProductSupply> composites. In others, Block 6 comprises just one <ProductSupply>, but is itself repeatable.
  Data elements and composites must occur in the order shown in the diagrams. Blocks 7 and 8 appear out of sequentially numbered order because they were added to the message long after 1–6.

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–8. 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 recipient with 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 sender’s 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 together are often informally referred to as block zero) plus only those of Blocks 1–8 which contain data that has changed since a previous Product record was supplied. If a particular Product record contains only Groups P.1, P.2 and Block 4, it means that recipients should update information based on the Groups and Blocks supplied, and any previously-supplied data from Blocks 1–3 and 5–8 should continue to be used unchanged. A Product record like this could be used to update the Publication date of a forthcoming product, for example. This type of block update 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).

In the context of block updates, Block 6 has two interpretations. It can be thought of as a single (and non-repeatable) block which contains the repeatable <ProductSupply> composite – there can be one or more <ProductSupply> composites, each of which pertains to what ONIX calls a ‘market’. If metadata for one particular market has to be updated, the metadata for all markets must be sent – even though all but one are unchanged.

However in ONIX 3.1, if each market (ie each of the <ProductSupply> composites) has a consistent <MarketReference>, then Block 6 can be treated as a repeatable block, with each repeat of the block containing only one <ProductSupply>. Thus in ONIX 3.1, a block update can be used to update the metadata for a single market, without sending data about other markets – the <MarketReference> identifies which market is to be updated by the recipient. This has the potential to make price and availability updates much more efficient than in ONIX 3.0.

For recipients, Block 6 is exceptional for another reason: 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–8, 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 publisher’s primary distributor.

### Product record preamble (block zero)

#### P.1 Record reference, type and source

Every ONIX for Books Product record must contain elements from Group P.1, as it includes elements that are critical to the way that a recipient must handle the supplied metadata.

The <RecordReference> is an identifier for the metadata record (as distinct from an identifier for the product, in Group P.2). Recipients should compare a received <RecordReference> with existing Record references stored in their database to deduce whether a received metadata record is brand new, or is an update of a previously-received metadata record. (In most circumstances, <NotificationType> provides a double-check on this.) Senders should construct their Record references so that recipients can distinguish clearly between records from different ONIX senders about the same product.

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 previously-received Product metadata held in an existing record in the recipient database, and to identify brand new Product records which require a new record to be added to the recipient database;
- must specify the notification type of the Product record in the <NotificationType> element;
  - code 01 indicates the Product record is being sent more than about six months prior to publication;
  - code 02 indicates the record is being sent less than about six months prior to publication;
  - code 03 indicates either a confirmation record sent at time of publication (this would be the first update where <PublishingStatus> is ‘active’ – see P.20.1 in Block 4), or a post-publication update of the metadata in the record;
  - code 04 indicates a block update of the metadata, at any point in the lifecycle;
    - see EDItEUR’s application note Deletions in ONIX (doi:10.4400/sjiz) for more details;
  - code 05 indicates a deletion request for a record issued in error;
  - codes 88 and 89 are special because they indicate a test record or block update that should not be applied to a production database;
- should specify a reason for deleting the whole record if <NotificationType> indicates the record is a deletion request;
- 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.

Common issues in Group P.1:

- using the ISBN as a <RecordReference>: at minimum, add something like a reversed domain name to ensure uniqueness of the Record reference (other organizations may also be providing metadata about the same product), and better still, use a UUID, or a persistent and meaningless internal ID combined with a reversed domain name;
- use of <NotificationType> code 05, which requests ‘deletion’ of a record, to instead indicate a product is Postponed, Canceled or abandoned before publication, or declared Out of print or withdrawn. Abandoning a planned product before publication, indefinite postponement, withdrawal or putting a product out of print, are all routine changes of Publishing status, not deletions, and should be handled using <PublishingStatus>;
  - genuine code 05 deletion requests should only be sent following a record having been issued entirely in error. Any 05 notification should follow within a couple of days of the error being made, as it is unlikely to have the desired effect if delayed beyond that. Ensure a <DeletionText> is included, to explain the nature of the error and the need for the deletion;
- recipient’s inability to support block updates (<NotificationType> code 04).

  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 (though it may match a previously-sent test 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–8 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–8 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>, <ProductionDetail> or <ProductSupply>. These are the eight 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 were 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. In theory, all that would remain in the recipient’s database would be the supplied GTIN and ISBNs. In fact, this hypothetical ‘full record’ 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>` |

  A deletion request with Notification type code 05 is unlikely to be honored by recipients unless issued within a day or two of issue of the erroneous record.

##### 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 it identifies the particular collection of metadata that describes the product. But multiple parties might supply data about the same product – the publisher, the distributor, a metadata aggregator…. For this reason, the record reference should also be unique across potential multiple suppliers of metadata about a particular product – it should be both product-specific and sender-specific. It should not be (or look like) a product identifier such as an ISBN, since while using an ISBN would be product-specific, it would not be sender-specific. However, the record reference may include a product identifier within some longer string of characters that adds sender-specificity, 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 identifier or database row number, 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).

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.

When creating unique Record references in this way, avoid the characters <, &, /, \, $, *, %, ?, plus the space and colon characters. Why? Because the Record reference can potentially 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.

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–8 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 – or nothing other than the <PublishingStatus> in Block 4 and the <ProductAvailability> in Block 6 – has changed. Any post-publication updates, for example price and availability updates, would be types 03 or 04.

The ‘first 03’ update sent at the time of publication can be particularly important for libraries and library data aggregators who do not always make use of the dynamic nature and updateability of ONIX – they capture the metadata just once, and while the ‘first 03’ is the best choice if a single ‘snapshot’ is to be captured and used, this means they may well miss any post-publication updates (the ‘second and subsequent 03s’).

  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. And Notification type 03 should indicate a very high degree of confidence in the data – though even this does not preclude future post-publication correction of genuine errors, updates of data elements such as reviews or price and availability, or enhancement of the data by addition of extra information.

  Note that the very first inclusion of a particular product in a data feed often uses <NotificationType> code 01, as announcement of a forthcoming product is often more than six months in advance of publication – usually, 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 even choose not to use type 01 records in consumer-facing contexts because of this unreliability.

  However, if the first notification is fairly close to publication, or even after publication, confidence in the data should be much higher. In the case of sending a first full file of products to a new data partner, codes 02 or 03 could reasonably be used immediately for products close to, at or after publication, even though this would be the first time the record has been included in the feed to that data partner and code 01 would normally be expected.

  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.
  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 (code 04), since not all recipients can cope with records of this type.

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.

Recipients receiving a record with <NotificationType> 05 should attempt to delete the record altogether. This may not always be possible, particularly if the delete request is sent close to or after publication, or more than a handful of days after the original record, as for example there may be details of orders, deliveries, shipments or sales attached to the product in the recipient’s system. However, recipients should suppress or 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, these should be treated as changes of Publishing status, and 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). In the UK, US and some other Anglophone countries, the SAN (code 07) is well established.

#### P.2 Product identifiers

What is an identifier? In effect, it is just a unique name or label for an entity – in this case, a product. But more specifically, identifiers are short alphanumeric strings, each uniquely and permanently bound to a single specific entity. Note the entity can be something concrete or something entirely abstract. ISO’s Principles of Identification (TS 22943) is a standard that defines good practice for designing identifier schemes. Each entity might have identifiers of different types, but generally only one of each type (although there are occasions when two ISBNs, for example, might be used to identify the same co-publication). Use of standardized identifiers in e‑commerce avoids any possible ambiguity about which product is being offered or ordered.

Publishers and resellers in all part of the supply chain needs unambiguous identification of the products that it creates or trades – for placing and fulfilling orders, for sales reporting and numerous other business processes.

EDItEUR’s application note Identifiers in ONIX (doi:10.4400/vxzs) includes an outline of the foundational characteristics of a ‘good’ identifier, and details of key identifier types used commonly with ONIX.

Group P.2 includes one or more identifiers for the product. Including a correct and unique identifier is vital to ensure trading partners can store information about and order the correct product. The book trade is heavily reliant on the ISBN and GTIN-13 identifiers. Note that for products that have ISBNs, the GTIN-13 is the same number, beginning 978 or 9791–9799. In some countries, 979 ISBNs have been in use alongside the more familiar 978s for several years now.

For physical books, identifiers such as the ISBN or GTIN-13 are printed on the title verso and (usually) on the back cover, and are embodied in a barcode. The barcodes are scanned at several points in the supply chain, including at the consumer point of sale, and it can therefore be particularly important to specify whether or not a barcode is printed on a physical product.

For digital products, the same types of identifiers can be used, although they are not always required, and sometimes proprietary identifiers are used instead. Note that e‑books with the same content but differing file formats require different identifiers and should have separate ONIX Product records.

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 – include twice in the ONIX, as a GTIN-13 beginning 9790 and explicitly as an ISMN.
- should include any other identifiers that uniquely identify the product.

Inclusion of 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 – or are ineligible for – an ISBN, 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). Note that <IDTypeName> is the name of the scheme from which the <IDValue> is drawn, not the identifier value itself;
- 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 and legacy ISBN-10 |
  --- | ---
  `<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>` |
  `<productidentifier>` |
  `<b221>02</b221>` | ISBN-10
  `<b244>0001234560</b244>` |
  `</productidentifier>` |

  All ISBNs are also GTIN-13s. In contrast only about one in 500 GTIN-13s is an ISBN.
  All 978- ISBNs have a legacy ISBN-10 equivalent, but 979- ISBNs do not.
  All legacy product-specific UPC-12s also have a GTIN-13 equivalent.

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

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. (This in fact implies it has two GTINs.) 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. Any barcode physically printed on the product should match the GTIN-13.

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>15</ProductIDType>` |
  `<IDValue>9780001234567</IDValue>` |
  `</ProductIdentifier>` |
  `<ProductIdentifier>` |
  `<ProductIDType>01</ProductIDType>` |
  `<IDTypeName>Amazon Standard Identification Number</IDTypeName>` |
  `<IDValue>0001234560</IDValue>` |
  `</ProductIdentifier>` |

  using Short tags |
  --- | ---
  `<productidentifier>` |
  `<b221>15</b221>` | ISBN
  `<b244>9780001234567</b244>` |
  `</productidentifier>` |
  `<productidentifier>` |
  `<b221>01</b221>` | Proprietary
  `<b233>ASIN</b233>` | Namespace – name of identifier scheme. At this point, ‘ASIN’ may be enough
  `<b244>0001234560</b244>` |
  `</productidentifier>` |

  Note that for books with an ISBN beginning 978, Amazon has stated that the ASIN is the same as the long-obsolete ISBN-10. However – as with any proprietary identifier – use only IDs confirmed by the owner of the proprietary scheme. Never simply assume ‘this is what the ASIN will be’.

  For ISBNs starting 979, the ASIN cannot be the same as the ISBN-10, since these ISBNs do not have an ISBN-10 equivalent, and any ASIN created using the same method could duplicate an existing ASIN.

  EPUB Release identifiers (or other granular version control IDs for e‑publications)
  using Reference names |
  --- | ---
  `<ProductIdentifier>` |
  `<ProductIDType>15</ProductIDType>` |
  `<IDValue>9798765432105</IDValue>` |
  `</ProductIdentifier>` |
  `<ProductIdentifier>` |
  `<ProductIDType>36</ProductIDType>` |
  `<IDValue>urn:uuid:a1b0d67e-2e81-4df5-9e67-a64cbe366809@2011-01-01T13:08:01Z</IDValue>` |
  `</ProductIdentifier>` |

  using Short tags |
  --- | ---
  `<productidentifier>` |
  `<b221>15</b221>` | ISBN
  `<b244>9798765432105</b244>` |
  `</productidentifier>` |
  `<productidentifier>` |
  `<b221>36</b221>` | Digital file internal version number
  `<b244>urn:uuid:a1b0d67e-2e81-4df5-9e67-a64cbe366809@2011-01-01T13:08:01Z</b244>` |
  `</productidentifier>` |

  EPUB packages and some other e-publication types contain internal data fields for granular version control. The example above is an EPUB Release identifier (see §5.5.1 and §5.5.5 of the EPUB specification) which combines the internal dc:identifier pub-id of the EPUB (usually its ISBN or, as in the example, a UUID), an @ separator, and its dcterms:modified timestamp. These are specified as separate properties in the EPUB, but are used together for version control purposes: the release identifier is unique to a particular publication yet changes each time the EPUB is even trivially modified or the package re-compiled. This is not a ‘tradeable’ identifier, in the sense it cannot be used to order a copy (though the ISBN itself would normally be enough).

  Although the example is specific to EPUB packages, code 36 (Digital file internal version number) is generic, and could also be used for version control in a POD scenario, particularly in combination with additional metadata in Block 8.

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.

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 / ISBN using EAN version NR barcode 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>` |

  The example above uses version NR of the EAN barcode symbology to display the book’s GTIN-13 / ISBN as a barcode. Version NK allows for an optional 5-digit extension to the right of the main barcode, used to encode the consumer price (the RRP) in one of a small selection of currencies – so an extension of 51995 indicates a price of $19.95 in US Dollars. Version NF allows the use of the 5-digit extension for proprietary uses.

  Initial digit | Currency code | Price range | Notes
  --- | --- | --- | ---
  0 | UKP | £0.01–£99.99 | 00000 is undefined (ie does not imply free of charge)
  5 | USD | $0.01–$99.98 | 50000 is undefined, 59999 means price not encoded but is greater than $99.98 (see also 1–4 below)
  6 | CAD | $0.01–$99.98 |
  1–4 | USD | $100 or more | eg 31995 = $319.95
  9 |  | No price encoded | use 90000 – other extension numbers are reserved

  See advice from BISG and BIC. Different advice may apply in non-English language markets.

  Note that the digits of the barcode extension do not appear as such in the ONIX metadata, though obviously, if the extension represents a price and currency, they are implied by the <CurrencyCode> and <PriceAmount> within the <Price> composite. There is an exception with Product ID type code 34 (ISSN-13) and Barcode type codes 12 or 13, when all 13 of the barcode digits plus the extension digits represent the Product identifier of a single issue of a serial publication. In this case, <IDValue> within <ProductIdentifier> may be 15 or 18 digits long (and must start with 977).

The <Barcode> composite is repeatable in the case where the product carries two (or more) barcodes. Mass market paperbacks in the US often carry two copies of the ISBN barcode, on the outer back cover as normal, and on the inside front cover. The latter facilitates scanning of returns, when only the stripped cover is returned.

### 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–8 are unnecessary;
- the Notification type is 05 (a record deletion), in which case Blocks 1–8 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

<ProductComposition>, <ProductForm> and <ProductFormDetail> are among the fundamental data elements of ONIX. These elements define the main distinctions between different products with the same content – for example, between a hardback, a paperback and e‑books in several file formats that all contain the same content, or between a single book and a pack containing multiple copies of that book – and they allow resellers and customers to find and choose the product they want.

Publishers often underestimate the importance of packaging and accurate dimensional metadata for physical products. The size, weight and packaging control warehouse storage and shipping costs, mail order fulfillment costs, and have to be taken into account in retailer’s inventory planning and merchandising. If available, Country of manufacture and the <ProductClassification> composite together inform freight forwarders, third-party logistics organizations and importers of likely shipping costs, duties and tariffs, and any locally-applicable taxes.

For digital products, the huge range of variations of file format, DRM and usage restrictions means customers need to know whether and how they can use a product. An EPUB readable on one device may not be readable on another because of differences in DRM support, and a usage restriction may make the product useless for a particular purchaser.

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;
  - for digital and physical products, <ProductFormFeature> should include any relevant hazard warnings and product safety information;
- for a physical product:
  - should describe any packaging using the <ProductPackaging> element;
  - may 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;
    - for more details of physical measurements, see EDItEUR’s application note Weights and dimensions in ONIX (doi:10.4400/pdyy);
  - should include the country of manufacture, and – if the product is to be traded internationally – the relevant Product classification codes;
- 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;
  - should include details of the accessibility of the product, including specific features that promote accessibility or mitigate accessibility issues with different types of product content, accessibility standards conformance, and accessibility certification credentials;
- 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, EA or AA (‘book’, ‘digital’ or ‘audio’). 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 (see Group P.4) 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>, between <ProductForm> and <ProductClassification>, or between a <ProductForm> and a <ProductFormDetail> that lacks an affinity for that product form;
- misuse of text fields such as <ProductFormDescription> to carry unrelated information;
- 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;
- misleading precision in physical measurements – for example, height specified to the nearest 0.0001in (one ten-thousandth of an inch). Accuracy is more valuable than precision;
- confusion between trimmed page size and overall dimensions of a book (or of its packaging). 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>. Note that ‘country of origin’ is an ambiguous term that should be avoided;
- misleading <CountryOfManufacture> information, for example through a failure to update the country when printing is moved for later reprints;
- 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 sizes and weight, for example, but it’s vital for distributors and wholesalers planning storage, physical retailers planning their merchandising, and for online retailers planning mail-order fulfillment. Estimated sizes and weights (calculated from the height, width, production extent, paper weight, cover weight etc as specified to the manufacturer) are acceptable prior to physical manufacture, and should be replaced by confirmed sizes and weights after printing and binding.

Additional guidance on the description of digital products in ONIX 3.1 and 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 metric units and in US customary (or Imperial) 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 metric units (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

  Use of US customary units alone is not recommended, unless the product is for sale only in the USA.
  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 more usually associated with trade hardbacks). ‘Trade paperback’ has a third meaning in comic book publishing, where it implies a book-bound omnibus edition of material previously published in episodic ‘floppies’.

  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 which is 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 such as <ProductFormFeatureDescription> 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-disk 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-disk 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-disk 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 -->` |

  ‘Red book’ audio CDs are conventional audio CDs – 44.1kHz sample rate, 16-bits per sample, stereo (or mono duplicated in both L and R channels) – in contrast to ‘Yellow book’ discs which are CD-Roms containing audio files. Use code AC for Red book Audio CDs and code AE for Yellow book discs.

These two examples describing a multi-disk audiobook 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, shrink-wrapped 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

  A ‘slip case’ is a box with five faces, whereas ‘box’ implies six faces including a lid or other closure. ‘Boxed sets’ are often packaged in slip cases.

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 essential 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 digital formats. Two good examples are ‘MP3 CDs’, which should not carry the Compact Disk 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 disk (WAV, MP3, AAC etc);
  - reserve <ProductForm> code DB for other types of CD-Rom that contain non-audio data;
- use <ProductForm> code AJ in preference to code ED for digital audio products that can be downloaded in their entirety and listened to later while ‘offline’, and use code AO for audio products that are ‘streamed’ in real time to a listener’s device and where the complete product is never stored on the device:
  - 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 size categories 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, rounded corners to the cover boards or pop-up engineering, or features of fine binding such as the use of acid-free or archival-quality paper, and real leather quarter- 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 such as Amazon’s KF8, 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 digital 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.1 and 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. Making e‑books accessible and providing metadata to describe this accessibility are required for full compliance with the EU Accessibility Act;
- the provenance of raw materials such as timber and pulp used to manufacture a physical product, where either the geographical source data or a Due Diligence Statement is needed for compliance with the EU Deforestation Regulation.

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

  Note that <ProductFormFeatureDescription> has a recommended maximum length of 10,000 characters. This is so that it can accomodate up to 400 or so GPS locations for EUDR purposes. Other uses of <ProductFormFeatureDescription> are highly unlikely to require more than 500 characters.

  <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, 26, 27 55, 57, 58 | 1 1 | 0 0…n
  Regionalized video | VI, VO | 05 | 1 | 0
  Electronic products | A* (except AB, AC, AF), D*, E* | 06 07, 08 | 1 0 | 0 1…n
  e‑books and ‘apps’ | D*, E* | 09 10, 15 16 18 | 1 1 1 0 | ² 0 1 1…n
  Hazardous products, batteries and chemicals | any | 12 13 14 19 20 21 | 1 1 0 1 1 1 | 0…n ³ 1…n ⁴ 0 ⁵
  Paper products | B*, C*, P* | 30, 40 31–37 47–49 50 | 0 1 1 1 | 0…n 0…n 1 0…1
  Other | any | 08, 17 | 0 | 1…n

  ¹ 0 = not used and must be omitted,
  1 = mandatory,
  0…n = optional and repeatable,
  1…n = mandatory and repeatable (nb repeats allow parallel text in multiple languages)

  ² must contain text if PFFV is 00, 94–99, otherwise omit

  ³ must contain text if PFFV is 00–07, otherwise omit

  ⁴ must contain text if PFFV is 02–04, otherwise may contain text

  ⁵ must contain text if PFFV is 02–05, otherwise omit

  specifying color of cover binding material
  using Reference names – single color |
  --- | ---
  `<ProductFormFeature>` |
  `<ProductFormFeatureType>01</ProductFormFeatureType>` |
  `<ProductFormFeatureValue>TEA</ProductFormFeatureValue>` |
  `</ProductFormFeature>` |

  using Short tags – multiple color binding with blue head/tail bands and bound-in ribbon bookmark |
  --- | ---
  `<productformfeature>` |
  `<b334>01</b334>` | Color of cover
  `<b335>MUL</b335>` | Multicolored
  `<b336>Pale blue with green panel</b336>` |
  `</productformfeature>` |
  `<productformfeature>` |
  `<b334>57</b334>` | Color of ribbon marker
  `<b335>SKY</b335>` | Pale blue
  `</productformfeature>` |
  `<productformfeature>` |
  `<b334>58</b334>` | Color of head/tail bands
  `<b335>SKY</b335>` |
  `</productformfeature>` |

  For clarity, color of cover refers to the overall color of the outer cover binding material (often a faux linen material, sometimes printed paper covering), not of the jacket, and is mostly used with hard covers.

  Cover color is most often used for the covers of Holy books (for example, Bibles), and the same list of colors is used for specifying decorative page edges, end papers etc. 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
  CEL | GRN | TEA | SKY | BLU
  GLD | YEL | CRE | TAN | CPR
  PUR | BRN | BUR | RED | ORG
  PNK | FCO | MUL | HOL | ZZZ

  Note the code MUL can be applied to multi-color (eg marbled or patterned) covers and page edges, and FCO can be used for four-color illustrated covers and page edges. Copper, silver and gold may be metallic, used to specify the color of stamping foil. HOL can be used in some circumstances (eg color of decorative foiling applied to a jacket) for ‘special effect’ finishes. ZZZ is for colors for which there is no other applicable code. Product form feature description can be used to provide further details.

  specifying color of gilded or sprayed page edges
  using Reference names – single color |
  --- | ---
  `<ProductFormDetail>B419</ProductFormDetail>` |
  `<ProductFormFeature>` |
  `<ProductFormFeatureType>02</ProductFormFeatureType>` |
  `<ProductFormFeatureValue>GLD</ProductFormFeatureValue>` |
  `</ProductFormFeature>` |

  using Short tags – multiple color or illustrated sprayed edges
  `<b333>B419</b333>` | Decorated page edges
  `<productformfeature>` |
  `<b334>02</b334>` | Color of page edge
  `<b335>MUL</b335>` | Multicolored (use FCO for four-color)
  `<b336>Dragon illustration on page edges</b336>` |
  `</productformfeature>` |
  `<!-- <SupportingResource> can be used to provide a JPEG of the illustration -->`

  Product form detail should be used to signal the presence of decorated page edges. Product form feature can be used to specify the color, and an image of the decoration can be supplied using the Suppporting resource composite (see Block 2) with Resource content type code 54.

  specifying the typeface of a large print product
  using Reference names |
  --- | ---
  `<ProductFormFeature>` |
  `<ProductFormFeatureType>03</ProductFormFeatureType>` |
  `<ProductFormFeatureValue>18</ProductFormFeatureValue>` |
  `<ProductFormFeatureDescription>Tiresias LP</ProductFormFeatureDescription>` |
  `</ProductFormFeature>` |
  `. . .` |
  `<EditionType>LTE</EditionType>` |

  using Short tags |
  --- | ---
  `<productformfeature>` |
  `<b334>03</b334>` | Text font
  `<b335>18</b335>` | Size in points
  `<b336>Tiresias LP</b336>` | Typeface name
  `</productformfeature>` |
  `. . .` |
  `<x419>LTE</x419>` | Large print edition

  Note that the font size (in points) can be carried in <ProductFormFeatureValue>, as above, or appended to the typeface name in <ProductFormFeatureDescription>. The former is preferred.

  book manufactured with certified environmentally-responsible paper, with DDS reference number, GPS and other provenance data including scientific and common species names, harvest dates to meet EU Deforestation Regulation (EUDR) requirements
  using Reference names |
  --- | ---
  `<ProductFormFeature>` |
  `<ProductFormFeatureType>32</ProductFormFeatureType>` |
  `<ProductFormFeatureValue>SGS-COC-002061</ProductFormFeatureValue>` |
  `</ProductFormFeature>` |
  `<ProductFormFeature>` |
  `<ProductFormFeatureType>36</ProductFormFeatureType>` |
  `<ProductFormFeatureValue>75</ProductFormFeatureValue>` |
  `</ProductFormFeature>` |
  `<ProductFormFeature>` |
  `<ProductFormFeatureType>47</ProductFormFeatureType>` |
  `<ProductFormFeatureValue>CA Picea mariana (Black Spruce) 202405</ProductFormFeatureValue>` |
  `<ProductFormFeatureDescription>48.558981 -58.578193, 48.563800 -58.568827</ProductFormFeatureDescription>` |
  `</ProductFormFeature>` |
  `<ProductFormFeature>` |
  `<ProductFormFeatureType>47</ProductFormFeatureType>` |
  `<ProductFormFeatureValue>GB Picea abies (Norway Spruce) 202311</ProductFormFeatureValue>` |
  `<ProductFormFeatureDescription>51.549040 -0.120975, 51.556838 -0.127326, 51.555092 -0.108261, 51.549040 -0.120975</ProductFormFeatureDescription>` |
  `</ProductFormFeature>` |
  `<ProductFormFeature>` |
  `<ProductFormFeatureType>48</ProductFormFeatureType>` |
  `<ProductFormFeatureValue>GB Picea glauca (White Spruce) 202401</ProductFormFeatureValue>` |
  `<ProductFormFeatureDescription>51.544708 0.061076</ProductFormFeatureDescription>` |
  `</ProductFormFeature>` |
  `<ProductFormFeature>` |
  `<ProductFormFeatureType>50</ProductFormFeatureType>` |
  `<ProductFormFeatureValue>24FRXVV3VOS991</ProductFormFeatureValue>` |
  `</ProductFormFeature>` |

  using Short tags, including optional verification code and UUID for the EUDR DDS reference number
  `<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>75</b335>` | Percentage (of recycled waste for FSC purposes)
  `</productformfeature>` |
  `<productformfeature>` |
  `<b334>47</b334>` | Source of raw material for interior
  `<b335>CA Picea mariana (Black Spruce) 202405</b335>` | Black spruce trees harvested in Canada in mid 2024
  `<b336>48.558981 -58.578193, 48.563800 -58.568827</b336>` | Two GPS points define a quadrilateral source plot
  `</productformfeature>` |
  `<productformfeature>` |
  `<b334>47</b334>` | Source of raw material for interior
  `<b335>GB Picea abies (Norway Spruce) 202311</b335>` | Norway spruce trees harvested in the United Kingdom in late 2023
  `<b336>51.549040 -0.120975, 51.556838 -0.127326, 51.555092 -0.108261, 51.549040 -0.120975</b336>` | Four GPS points define a closed triangular plot, see diagram below
  `</productformfeature>` |
  `<productformfeature>` |
  `<b334>48</b334>` | Source of raw material for cover
  `<b335>GB Picea glauca (White Spruce) 202401</b335>` | White spruce trees harvested in the United Kingdom in early 2024
  `<b336>51.544708 0.061076</b336>` | Single GPS point defines the center of a 4Ha source plot
  `</productformfeature>` |
  `<productformfeature>` |
  `<b334>50</b334>` |
  `<b335>24FRXVV3VOS991+0123456789</b335>` | EU Due Diligence Statement document reference and verification code (provided by the EU data portal)
  `<b336>e4ea2b9b-d875-4baa-a780-ed8d86966f40</b336>` | optional UUID (also provided by the portal)
  `</productformfeature>` |

  FSC certification may use an FSC license certificate number instead of a Chain of custody (CoC) number – for example <ProductFormFeatureValue>C007454</ProductFormFeatureValue>.

  Note however that use of non-FSC or non-PEFC raw material, or a change in CoC reference or license number, or a significant change in the percentage of recycled material in a later impression of the product implies a post-publication ONIX update must be sent. Latest reprint number and Latest reprint date should also be updated.

  FSC certification is not in itself enough to meet EUDR requirements.

  Books sold in or exported from the European Union must (from the end of 2026) comply with the EU Deforestation Regulation (EUDR). This requires assurance that the timber that forms the raw material for the paper, card and board embodied in the book comes from sources that don’t cause deforestation, forest degradation or loss of biodiversity. To achieve this, all raw materials – the timber used to make paper, card and board – must be traceable to their geographical source and must be registered in the EU’s Traces NT online portal. Organizations processing those raw materials into semi-finished goods and into finished books must carry out due diligence, risk assessment and necessary risk mitigation to ensure the supply chain remains ‘deforestation-free’.

  For EUDR compliance purposes, the document reference for the Due Diligence Statement (DDS) lodged with the EU’s Traces registry is the most important attribute of a product. Without a DDS, a paper-based product will be excluded from European market.

  To register a DDS for a product, data about the provenance of the various raw materials used in the product is uploaded to the EU’s online Traces portal, and the portal assigns both a proprietary DDS document reference and a UUID to identify a particular DDS. The DDS document reference may be accompanied by a verification code which allows other Traces users to view the provenance data in detail – the DDS reference, verification code and optionally the UUID can be carried in <ProductFormFeature> with Product form feature type code 50. There may potentially be multiple DDS document references for the same product, each in a separate repeat of <ProductFormFeature>.

  For a book where no DDS exists, the data necessary to create a DDS can be carried in the ONIX product record. For a book, this will sometimes consist of one or more references to DDSs for the semi-finished goods used to manufacture the book – a reel of paper is a product in its own right, and requires a DDS of its own, and this can be used as part of the registration of the book’s DDS. A list of such ‘embodied’ or ‘associated’ DDSs (with verification codes) can be included in <ProductFormFeature> with type code 51. In cases where the paper, card or board has no DDS, the necessary data includes GPS polygon data for the location the timber used to make the paper, card or board was harvested, the harvested species and harvest date etc. All the necessary data can be communicated in <ProductFormFeature> with Product form feature type codes 47–49. In many cases, a list of embodied DDSs for the paper, card and board may eliminate the need to supply detailed raw material provenances (GPS polygons). In the remaining cases, both a list of DDSs and additional GPS data may be required.

  GPS coordinates for EUDR may specify a list of one or more locations. A single point (one latitude and one longitude) denotes the center of a 4 hectare plot 200m × 200m); two points denote opposite corners of a ‘rectangular’ plot bounded by two lines of latitude and two of longitude; more than two points denote a simple polygon plot boundary. Each point is a space-separated pair of real numbers (±90 for latitude, with negative numbers being south of the equator, and ±180 [excluding -180 itself] for longitude with negative numbers being west of the Greenwich prime meridian). Multiple points are comma-separated. Note these coordinates use decimal parts of a degree, not minutes and seconds. Precision of six decimal places (implying an precision of roughly ±10cm) is allowed by the EU Deforestation Regulation, but in practice, this level of accuracy is unnecessary. Trailing zeros should be retained to avoid ambiguity. No plot may cross the 180° line of longitude, nor may a plot span a national boundary. Polygon edges may not intersect. For polygonal plots, best practice is that the sequence of points should be drawn clockwise and should be ‘closed’ – ie that the first and last points should be identical, thus requiring four points to define a triangular plot.

  The shaded area represents a geographic map of the forest plot from which trees are harvested as a polygon defined by (in this case) three points. The points should be listed clockwise, then the first (red) point is repeated to ‘close’ the polygon. Matching color coding is used for the points in the example ONIX above.

  For two points defining a ‘rectangle’ plot, best practice is south-west then north-east. The forest must be wholly within the rectangle bounded by the associated lines of latitude and longitude.

  The formats used and limitations for the GPS coordinates set out in List 79 (and illustrated here) are chosen so that conversion between ONIX and the GeoJSON format used by the EUDR Traces registry is straightforward.

  For most practical purposes, the area of a polygonal plot like this can be calculated using Gauss’s area formula (‘the shoelace formula’) with an adjustment based on latitude in the table below used when converting degrees to Cartesian coordinates. Most GIS software libraries also include a suitable area() function, which is likely to be more accurate for very large forests, as it will take better account of the variations in curvature of the earth. Note that some variants of the algorithm might produce a negative area because the points are listed clockwise – just use the absolute value.

  Variation of distance with latitude, using the WGS84 geodetic model used by GPS
  lat | Δ1° lat | Δ1° long
  --- | --- | ---
  0° | 110,574 m | 111,320 m
  15° | 110,649 m | 107,550 m
  30° | 110,852 m | 96,486 m
  45° | 111,132 m | 78,847 m
  60° | 111,412 m | 55,800 m
  75° | 111,618 m | 28,902 m
  90° | 111,694 m | 0 m

  The table shows that an angular distance of 1 degree of longitude (ie in an east-west directon) is around 107,550 metres if measured close to the equator (specifically at 15° north or south of the equator), but roughly half that distance – 55,800 metres – if measured in boreal latitudes (specifically, at 60° north or south). North-south distances also vary, though not as dramatically. The table is specific to the geodetic model used by GPS.

  Since a book will almost always embody more than one type of paper, card or board, and since each type will most likely be manufactured from a blend of pulp derived from different species and different geographical locations, many repeats of <ProductFormFeature> may be required for multiple plots and for multiple paper and board types, .

  In order to minimize the number of repeats of <ProductFormFeature>, multiple plots (multiple polygons, rectangles or multiple single points) can be combined into lists of polygons or points. Where multiple points defining a rectangle of polygon are separated with commas, multiple plots in a list are semicolon-separated:

  `<ProductFormFeature>` |
  `<ProductFormFeatureType>47</ProductFormFeatureType>` |
  `<ProductFormFeatureValue>GB Picea abies (Norway Spruce) 202311</ProductFormFeatureValue>` |
  `<ProductFormFeatureDescription>51.549040 -0.120975, 51.556838 -0.127326, 51.555092 ‑0.108261, 51.549040 -0.120975; 51.515333 -0.117380, 51.516582 -0.118347, 51.517177 -0.115544, 51.516026 -0.114760, 51.515333 -0.117380</ProductFormFeatureDescription>` |
  `</ProductFormFeature>` |

  The above combines two separate polygons (one triangular in green, one four-sided in blue) into a single list, separated by a semicolon (highlighted in red). Any species name, date and country must apply to all the plots in the list.

  Given the suggested maximum number of characters in <ProductFormFeatureDescription> (10,000 characters), a single plot, or a list of plots created in this way, can include at least 400 points in a single repeat of <ProductFormFeature>.

  You cannot mix polygons, rectangles and single points in the same list.

  Most geolocation data is provided to publishers as a GeoJSON file, equivalent to the polygon outlines above. The ONIX format for geolocation data is designed to be easy to convert to and from GeoJSON. However, some forestry and paper companies will make use of a procedure called ‘Declaration in Excess’, which produces huge GeoJSON files that do not provide the expected direct traceability from book back to paper, pulp and tree. Nonetheless, they are allowed within the framework of EUDR. Such Declaration in excess should be discouraged by publishers.

  The file size of these Declaration in excess GeoJSON files can be very large – 5 or 10MB – and it’s impractical to use the method above using codes 47–49 for listing the polygons. Codes 60–62 in List 79 mirror codes 47-49 in all respects, except they carry the URL of a GeoJSON file in <ProductFormFeatureDescription>.

  `<ProductFormFeature>` |
  `<ProductFormFeatureType>60</ProductFormFeatureType>` |
  `<ProductFormFeatureValue>GB Picea abies (Norway Spruce) 202311</ProductFormFeatureValue>` |
  `<ProductFormFeatureDescription>https://www.publisher.co.uk/​compliance/​EUDR/​2025/​10518.geojson</ProductFormFeatureDescription>` |
  `</ProductFormFeature>` |

  The URL should be for a copy of the supplied GeoJSON file that is under the control of the ONIX data sender (publishers and others should not naïvely pass on a URL supplied to them by a forestry company or paper manufacturer).

  With such large GeoJSON files, it is quite possible for a hardback using five different types of paper, each linked to a large GeoJSON file, to exceed the maximum data size for na DDS in Traces.

  As well as the GPS coordinates themselves, the EU’s Traces registry requires the country from which the trees were harvested, the scientific (Latin) and common names of the tree species for each plot or list of plots, and (at least until the end of 2028) a date of harvesting of the trees. Inevitably, common names vary by language, a single species may have more than one common name even in just one language, and a single common name might apply to more than one species – so the utility of a common name is questionable – but a common name (this one’s in French) might be provided like this:

  `<ProductFormFeatureValue>FI Picea abies (Épinette de Norvège) 202311</ProductFormFeatureValue>` |

  If not provided, these common names can be looked up at https://gd.eppo.int/search, the database of the European and Mediterranean Plant Protection Organization (EPPO), when creating a DDS.

  Where multiple species are harvested from the same forest plot, a list of species names can be provided, with each species comma-separated.

  `<ProductFormFeatureValue>FI Picea abies (Épinette de Norvège), Picea × fennica (Épicéa de Carélie) 202501</ProductFormFeatureValue>` |

  Either all species in the list must have both scientific and common names, or all must have only their scientific names.

  Note that with Product form feature types 47–49 and 60–62, Product form feature value is ‘overloaded’, in that it can contain more than one type of data – it must start with a country code, and may contain a species’ scientific name, its common name (or a list of names), an impression number and a harvest date. In many recipient environments, the various parts of <ProductFormFeatureValue> may be separated and extracted using the following suggested regular expressions for pattern matching.

  Country code | `^(?<country>[A-Z]{2})\b` | the country code must be the first two characters in <ProductFormFeatureValue>, both upper case ¹ ² ³
  Scientific name | `(?<!\()(?<species>[A-Z][a-z]+\s(?:[Xx×]\s|×)?[a-z]{2,})\b` | the species’ scientific (Latin) name must be two space-separated words using only the Latin characters A–Z and a–z (without diacritics), with the first character of the first word upper case and the remainder lower case, matching the way binomial names are usually presented ⁴ ⁵
  Common name | `(?<=\()(?<common>\p{L}+(?:\s\p{L}+)*(?=\)))` | the common name must be one or more words, enclosed in parentheses, and is not limited to Latin script
  Harvest date | `(?<= )(?<harvest>(20\d{6}|20\d{4}|20\d{2}))\b` | date must be a 21st century date as a sequence of 4, 6 or 8 digits (YYYY, YYYYMM or YYYYMMDD)
  Impression | `(?<= )\d{1,3}\b` | impression or reprint number must be any sequence of 1 to 3 digits. Only 999 impressions are supported

  ¹ these patterns use PCRE (Perl-compatible regular expressions) pattern matching, but similar expressions can be constructed in non-PCRE environments

  ² not every recipient data processing environment implements the PCRE `\b` word boundary match option – for example XSLT v2.0 does not. If it’s unavailable, the slightly less convenient `(?=\x20|$)` can be used in its place. Similarly, only PCRE-enabled pattern matching implements the negative lookahead and lookbehind in the pattern for the impression number – `[^\d]\d{1,3}([^\d]|$)` would be a simpler alternative

  ³ depending on the recipient data processing environment, you may need to ensure that pattern matching is case sensitive. This is usually the default, but if not, you can often prefix the patterns above with `(?-i)`

  ⁴ the patterns for scientific name and common name may return lists of names

  ⁵ varietal or cultivar names may not be supported by the Traces data portal (although hybrid names with the multiplication character × – for example Picea × lutzii – are supported by the regular expression and may be supported by Traces)

  Traces requires a legal attestation that the product is ‘deforestation-free’ and that the trees were harvested in accordance with local laws. These are mirrored in ONIX using <ProductFormFeature> with Product form feature type codes 52 and 53.

  For EUDR, the provenance of raw material for paper, card and board may change between impressions. One approach to this – when distributors and wholesalers offer strict lot control (tracking of stock from individual impressions and first in-first out stock rotation) and when an insignificant number of returns are used to fulfill new orders – would be to update the provenances, together with the Latest reprint number and Latest reprint date, and to send a judiciously-timed ONIX update to coincide with date when the new stock begins fulfillment. However, given the lack of lot control in the book supply chain, this is unlikely to be practical.

  An alternative, when distributors and wholesalers cannot offer lot control, or when a significant proportion of returns are used to fulfill new orders, is to add new provenances as new paper or board is used to manufacture new impressions, but not remove provenances for previous but no longer used raw materials, before sending a post-publication ONIX update. This results in a cumulative list of raw material provenances, including those used with previous impressions – since without lot control (or with fulfillment using returns), a customer may receive a copy of the current or any previous impression.

  There are a range of exceptions to the Deforestation Regulation, for example for product that appear to be ‘in scope’ but are in fact made entirely of recycled material or of plastic (eg Tyvek) or another fabric (eg rag books). These can be signalled in ONIX using <ProductFormFeatureType> code 56. There are also a set of Additional TARIC codes that should be included in <ProductClassification>.

  With materials that include some proportion of recycled content, ‘raw material’ refers to the source of timber used to make the non-recycled portion of the paper, card and board. Use <ProductFormFeature> with type codes 36 or 37.

  There are also special arrangements for ‘old stock’, particularly that manufactured from wood harvested prior to mid-2023 when EUDR was enacted, and stock physically present in the EU prior to the end of 2026 – though note that it is likely that such raw materials still need to conform to the older EU Timber Regulation (EUTR), and such special arrangements will end at the end of 2028.

  EDItEUR publishes an application note (doi:10.4400/wmvz) giving more detail on EUDR support in ONIX – including the suggested cumulative methodology, notes on compliance with EUDR for POD products etc.

  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 Standardized 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 third-party accessibility certification
  using Reference names |
  --- | ---
  `<ProductFormFeature>` |
  `<ProductFormFeatureType>09</ProductFormFeatureType>` |
  `<ProductFormFeatureValue>93</ProductFormFeatureValue>` |
  `<ProductFormFeatureDescription>https://bornaccessible.org/certification/gca-credential/</ProductFormFeatureDescription>` |
  `</ProductFormFeature>` |

  using Short tags |
  --- | ---
  `<productformfeature>` |
  `<b334>09</b334>` |
  `<b335>93</b335>` | Compliance certification
  `<b336>https://bornaccessible.org/​certification/​gca-credential/</b336>` | Benetech Global Certified Accessible
  `</productformfeature>` |

  Since the GCA certification scheme in fact certifies publishers’ workflows rather than an individual product or a publisher as a whole, this should be interpreted as ‘the product is the result of a GCA-certified workflow’. Other books by the same publisher may not be similarly certified, if they are the result of a different workflow or production process. Publishers must avoid any appearance of certifying the output of books from those other workflows.
  For recipients of accessibility metadata, the W3C has a set of guidelines for display of this data to consumers, available from its GitHub repository (Principles and ONIX guidelines).

  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>19</ProductFormFeatureType>` |
  `<ProductFormFeatureValue>10</ProductFormFeatureValue>` |
  `<ProductFormFeatureDescription>Warning: this product contains a button/coin battery which is hazardous if ingested</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 replaceable
  `<b336>1 x 2.9V CR2032</b336>` |
  `</productformfeature>` |
  `<productformfeature>` |
  `<b334>19</b334>` |
  `<b335>10</b335>` |
  `<b336>Warning: this product contains a button/coin battery which is hazardous if ingested</b336>` | Warning text, usually taken from the product itself or its packaging
  `</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.

  certifying the greenhouse gas emissions of the product
  using Reference names |
  --- | ---
  `<ProductFormFeature>` |
  `<ProductFormFeatureType>42</ProductFormFeatureType>` |
  `<ProductFormFeatureValue>100</ProductFormFeatureValue>` |
  `<ProductFormFeatureDescription>Part 3</ProductFormFeatureDescription>` |
  `</ProductFormFeature>` |
  `<ProductFormFeature>` |
  `<ProductFormFeatureType>43</ProductFormFeatureType>` |
  `<ProductFormFeatureValue>100</ProductFormFeatureValue>` |
  `<ProductFormFeatureDescription>SBT1001924</ProductFormFeatureDescription>` |
  `</ProductFormFeature>` |
  `<ProductFormFeature>` |
  `<ProductFormFeatureType>44</ProductFormFeatureType>` |
  `<ProductFormFeatureValue>100</ProductFormFeatureValue>` |
  `<ProductFormFeatureDescription>2.1</ProductFormFeatureDescription>` |
  `</ProductFormFeature>` |

  using short tags |
  --- | ---
  `<productformfeature>` |
  `<b334>42</b334>` | GHG scheme (and optional part)
  `<b335>100</b335>` | Code for specific scheme
  `<b336>Part 3</b336>` | Part
  `</productformfeature>` |
  `<productformfeature>` |
  `<b334>43</b334>` | GHG certification license number
  `<b335>100</b335>` | Code for specific scheme
  `<b336>SBT1001924</b336>` |
  `</productformfeature>` |
  `<productformfeature>` |
  `<b334>44</b334>` | GHG Scope 3 emissions
  `<b335>100</b335>` | Code for specific scheme
  `<b336>2.1</b336>` | Per-copy emissions (in kgs of CO₂e), calculated…
  `</productformfeature>` | according to the protocols of the scheme

  The above example illustrates how such certification schemes can be specified, and it indicates a product certified under Part 3 of a specific scheme identified by code 100 and with Scope 3 CO₂e emissions of 2.1kg per copy.

##### 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 shrink-wrapped, 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 (unless the specific Measure type code specifies otherwise).

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. For accessibility purposes, these content types will each have individual implications for print impaired readers, and each may imply the need for accessibility mitigations that can be listed using <ProductFormFeature> and List 196.

In general, if omitted from the Product record, the contents of the product are likely to be primarily textual. However, resellers and potential end purchasers cannot rely upon this for accessibility purposes.

‘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. Note that ‘enhanced’ products may also carry the ENH code in <EditionType>. An ENH 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.

  specifying content types
  using Reference names – one single content type |
  --- | ---
  `<PrimaryContentType>10</PrimaryContentType>` |

  using Short tags – multiple content types |
  --- | ---
  `<x416>10</x416>` | Eye-readable text
  `<b385>18</b385>` | …plus photographs,
  `<b385>19</b385>` | figures, diagrams, charts, graphs

  One of the following options is expected:

  - no content types at all (since both elements are optional);
  - a single Primary content type;
  - a single Primary content type plus one or more Product content types;
  - two or more Product content types (where none can be singled out as primary).

  Each listed content type must be unique.

The use of these data elements is not strictly 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.

##### Measure composite

The <Measure> composite should be included for all physical products – and of course should be omitted from records describing digital 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 some 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, as well as to books in slip cases.) Trimmed page size and overall dimensions may both be provided, in separate repeats of the <Measure> composite. If for any reason only the TPS measurements can be provided, ONIX senders and 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 or calculate a reasonably accurate estimate.

  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, US customary units (inches, ounces) should be used instead. If a product is sold in both USA and elsewhere (for example, globally, or even in USA and Canada only), inclusion of the same dimensions in both metric and US customary units is clearly the best option, but if only one set of dimensions can be provided, metric is preferred over US customary units. 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 US customary units indicates a size of 7.756in (to three decimal places of precision), 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>` |

  Carton (printer’s pack) size and weight for bulk deliveries
  Using reference names |
  --- | ---
  `<Measure>` |
  `<MeasureType>23</MeasureType>` |
  `<Measurement>30.7</Measurement>` |
  `<MeasureUnitCode>cm</MeasureUnitCode>` |
  `</Measure>` |
  `<!-- carton width 27.0cm and height 22.5cm omitted for brevity -->` |
  `<Measure>` |
  `<MeasureType>26</MeasureType>` |
  `<Measurement>12.8</Measurement>` |
  `<MeasureUnitCode>kg</MeasureUnitCode>` |
  `</Measure>` |
  `. . .` |
  `<PackQuantity>24<PackQuantity>` |

  Using short tags |
  --- | ---
  `<measure>` |
  `<x315>23</x315>` |
  `<c094>30.7</c094>` | Carton length is 30.7cm
  `<c095>cm</c095>` |
  `</measure>` |
  `<!-- carton width 27.7cm and height 22.5cm -->` |
  `<measure>` |
  `<x315>26</x315>` |
  `<c094>12.8</c094>` | Carton weight is 12.8kg…
  `<c095>kg</c095>` | (including the books!)
  `</measure>` |
  `. . .` |
  `<j145>24<j145>` | Copies per carton

  The Pack quantity must be included when carton and pallet dimensions and weights are specified. Provision of the carton weight allows two checks – the carton weight should be a little more than the Pack quantity multiplied by the individual product weight, and the calculated density of a carton should be in the range 4–700kg/m³ (uncoated paper in bulk is around 11–1200kg/m³, but binding and the airspace in the carton reduces this). The carton weight has implications for the safety of manual handling in a warehouse.

##### P.3.15 Country of manufacture

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). This information is required in some countries to meet legal requirements, and is almost always required for international shipping, so it is best practice to include it for all physical products available internationally or manufactured overseas.

Occasionally, when an initial impression (print run) of a product is manufactured in one country and a subsequent impression manufactured elsewhere, data suppliers should manage this through a judiciously-timed post-publication update of the ONIX data as the initial stock is sold. The inclusion in Block 4 of <LatestReprintNumber> and a Publishing date with Role code 12 (Last reprint date) should be used to clarify this when necessary.

For a multi-component product or multi-item pack, a product- or pack-level country of manufacture should be interpreted as the country in which the items were assembled or packaged together, rather than where they were each individually manufactured. In addition, the Country of manufacture should 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. Thus a product consisting of a book printed in one country and a toy made in another, but packaged together in a third may list all three countries, one at product level and one for each of the components.

In some cases, products that are manufactured on demand may not have a single country of manufacture. A POD manufacturer which operates multiple locations may choose the closest to the customer or the least busy location dynamically at the time of purchase – the Country of manufacture would not be known until the product is ordered by a customer. In a similar way, a distributor, wholesaler or retailer may be able to manufacture copies on demand when conventionally-printed copies are unavailable – and the conventional and POD copies have different Countries of manufacture. In these cases, where the Country of manufacture might vary in an unpredictable way, <CountryOfManufacture> should be omitted.

Country of manufacturer is never relevant for digital products.

##### P.3.16 Digital product technical protection

This element should be used to specify any technical protection measures applied to a digital product, and should be used for all downloadable, streamed 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 or EDRL’s LCP 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 (digital products)

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 with metered access
  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, and loans cannot be renewed. 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>16</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>` |
  `<EpubUsageConstraint>` |
  `<EpubUsageType>08</EpubUsageType>` |
  `<EpubUsageStatus>03</EpubUsageStatus>` |
  `</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). Any particular loan can be renewed just once. 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>16</x318>` | Library loans
  `<x319>02</x319>` | are 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>` |
  `<epubusageconstraint>` |
  `<x318>08</x318>` | Loan renewals
  `<x319>02</x319>` | are limited
  `<epubusagelimit>` |
  `<x320>1</x320>` | Up to one
  `<x321>10</x321>` | Time
  `</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.

  reserving text and data mining (TDM) rights
  using Reference names |
  --- | ---
  `<EpubUsageConstraint>` |
  `<EpubUsageType>11</EpubUsageType>` |
  `<EpubUsageStatus>03</EpubUsageStatus>` |
  `</EpubUsageConstraint>` |

  using Short tags, with two additional licenses: the first includes links to human-readable and ODRL expressions of the ‘intrinsic’ licence attached to the product, and the second links to human-readable and ODRL expressions of an additional license offer that uses the W3C TDM reservation protocol (a ‘TDMrep offer’) for a separately-available license
  `<epubusageconstraint>` |
  `<x318>11</x318>` | Text and data mining
  `<x319>03</x319>` | Is prohibited
  `</epubusageconstraint>` |
  `<epublicense>` | ‘Intrinsic’ license
  `<x511>MyPublisher License</x511>` |
  `<epublicenseexpression>` |
  `<x508>01</x508>` | Human-readable license
  `<x510>https://www.mypublisher.com/​licenses/​mypolicy.html</x510>` | URL of license text
  `</epublicenseexpression>` |
  `<epublicenseexpression>` |
  `<x508>20</x508>` | ODRL license
  `<x510>https://www.mypublisher.com/​licenses/​mypolicy.json</x510>` | URL of license expression
  `</epublicenseexpression>` |
  `</epublicense>` |
  `<epublicense>` | Additional license
  `<x511>MyPublisher TDM License Offer</x511>` |
  `<epublicenseexpression>` |
  `<x508>03</x508>` | Human-readable additional license offer
  `<x510>https://www.mypublisher.com/​.policies/​mypolicy-extension.html</x510>` | URL of additional license offer
  `</epublicenseexpression>` |
  `<epublicenseexpression>` |
  `<x508>21</x508>` | ODRL additional license offer
  `<x510>https://www.mypublisher.com/​.policies/​mypolicy-extension.json</x510>` | URL of TDMrep offer expression
  `</epublicenseexpression>` |
  `</epublicense>` |

  There is, in many legal jurisdictions, an explicit copyright exception that allows the use of copyrighted text in TDM applications. One such application is the training of large language models (LLMs). These LLMs are key components of ‘generative AI’. In some other jurisdictions, TDM for LLM training may be considered ‘fair use’ or outside the scope of copyright protection altogether. So the default legal position – in many jurisdictions – is that that TDM is allowed, including for purposes of AI training.

  However, in some circumstances, TDM rights may be reserved by the rightsholder. Within the EU, an explicit copyright exception for TDM applies as above, but a directive allows the rightsholder to express an ‘opt out from the copyright exception’ where the presumptive TDM is for purposes other than scientific research. Note that when opted out, the copyright exception continues to apply to TDM for scientific research applications by research and cultural heritage institutions.

  With text and data mining, reservation of the TDM rights (ie prohibition of TDM) should be interpreted as ‘prohibited to the full extent allowed by the law’ or otherwise expressly reserved by the rightsholder.

  The Usage constraint and Digital license composites allow the ONIX data sender to include a statement reserving TDM rights wherever possible, effectively expressing an opt out from the copyright exception (but of course only where an opt out is available).

  Purely from the point of view of ONIX, <EpubLicenseExpression> is enough to reserve the TDM rights (or express an opt-out).

  Where TDM is reserved or otherwise prohibited, it is also possible to use <EpubLicenseExpression> to specify an additional license that may be obtained, which may explicitly allow TDM for particular uses. In this instance, an additional reference to a W3C TDM Reservation protocol (TDMrep) policy expression can also useful. For more details, see EDItEUR’s application note Aspects of AI in ONIX (doi:10.4400/sfar).

  Note that used in Block 1, any usage constraint applies to use of the content of the product. It can also be used to reserve rights covering collateral material including long descriptions, other text or resources such as covers and other images – see Groups P.14 and P.16.

##### 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>` |
  `<PublisherIdentifier>` |
  `<PublisherIDType>16</PublisherIDType>` |
  `<IDValue>0000000085904658</IDValue>` |
  `</PublisherIdentifier>` |
  `<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>` |
  `. . .` |
  `<Supplier>` |
  `. . .` |
  `<Website>` |
  `<WebsiteRole>29</WebsiteRole>` |
  `<WebsiteDescription>OAPEN Repository</WebsiteDescription>` |
  `<WebsiteLink>https://www.oapen.org/​download?​type=​document&amp;​docid=​341341</WebsiteLink>` |
  `</Website>` |
  `</Supplier>` |
  `. . .` |
  `<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
  `<publisheridentifier>` |
  `<x447>16</x447>` | ISNI
  `<b244>0000000085904658</b244>` |
  `</publisheridentifier>` |
  `<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>` |
  `. . .` |
  `<supplier>` | Repository is supplier
  `. . .` |
  `<website>` |
  `<b367>29</b367>` | Full content available from
  `<b294>OAPEN Repository</b294>` |
  `<b295>https://www.oapen.org/​download?​type=​document&amp;​docid=​341341</b295>` |
  `</website>` |
  `</supplier>` |
  `. . .` |
  `<j192>01</j192>` | Free of charge

  Note the use of &amp; to represent the & separator between the type and docid query parameters in the repository’s Website link. The URL is part of the XML data, so & must be replaced by &amp;.

  There is an alternative approach to this: & must not be escaped to &amp; within CDATA, so the URL below is equivalent and may be simpler:

  `<![CDATA[https://www.oapen.org/​download?​type=​document&​docid=​341341]]>`

  This only applies if there are multiple query parameters following the ? in a URL. CDATA is unnecessary and should be avoided if there are no query parameters or only one.

  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, with coordinated license dates and OA statement dates
  using Reference names |
  --- | ---
  `<EpubLicense>` |
  `<EpubLicenseName>Creative Commons Attribution-NonCommercial 4.0 International Public License​</EpubLicenseName>` |
  `<EpubLicenseExpression>` |
  `<EpubLicenseExpressionType>01</EpubLicenseExpressionType>` |
  `<EpubLicenseExpressionLink>https://creativecommons.org/​licenses/​by-nc/​4.0/​deed</EpubLicenseExpressionLink>` |
  `</EpubLicenseExpression>` |
  `<EpubLicenseExpression>` |
  `<EpubLicenseExpressionType>02</EpubLicenseExpressionType>` |
  `<EpubLicenseExpressionLink>https://creativecommons.org/​licenses/​by-nc/​4.0/​legalcode<EpubLicenseExpressionLink>` |
  `</EpubLicenseExpression>` |
  `<EpubLicenseDate>` |
  `<EpubLicenseDateRole>14</EpubLicenseDateRole>` |
  `<Date>20180524</Date>` |
  `</EpubLicenseDate>` |
  `</EpubLicense>` |
  `. . . .` |
  `<TextContent>` |
  `<TextType>20</TextType>` |
  `<ContentAudience>00</ContentAudience>` |
  `<Text>From May 24th will be Open access – with attribution, no commercial reuse</Text>` |
  `<ContentDate>` |
  `<ContentDateRole>14</ContentDateRole>` |
  `<Date>20180222</Date>` |
  `</ContentDate>` |
  `<ContentDate>` |
  `<ContentDateRole>15</ContentDateRole>` |
  `<Date>20180523</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>` |
  `. . .` |
  `<UnpricedItemType>01</UnpricedItemType>` |
  `<PriceDate>` |
  `<PriceDateRole>14</PriceDateRole>` |
  `<Date>20180524</Date>` |
  `</PriceDate>` |
  `</Price>` |

  using Short tags, with two OA statements, for use before and after the delayed OA begins
  `<epublicense>` |
  `<x511>Creative Commons Attribution-NonCommercial 4.0 International Public License​</x511>` |
  `<epublicenseexpression>` |
  `<x508>01</x508>` | Human readable
  `<x510>https://creativecommons.org/​licenses/​by-nc/​4.0/​deed</x510>` |
  `</epublicenseexpression>` |
  `<epublicenseexpression>` |
  `<x508>02</x508>` | ‘Professional’ readable
  `<x510>https://creativecommons.org/​licenses/​by-nc/​4.0/​legalcode</x510>` |
  `</epublicenseexpression>` |
  `<epublicensedate>` |
  `<x585>14</x585>` | License valid from
  `<b306>20180524</b306>` | six months after pub date
  `</epublicensedate>` |
  `</epublicense>` |
  `. . . .` |
  `<textcontent>` |
  `<x426>20</x426>` | Open Access statement
  `<x427>00</x427>` |
  `<d104>From May 24th will be Open access – with attribution, no commercial reuse</d104>` |
  `<contentdate>` |
  `<x429>14</x429>` | Statement usable from
  `<b306>20180222</b306>` | three months after pub date
  `</contentdate>` |
  `<contentdate>` |
  `<x429>15</x429>` | Statement usable until
  `<b306>20180523</b306>` | six months after pub date
  `</contentdate>` |
  `</textcontent>` |
  `<textcontent>` |
  `<x426>20</x426>` | Open Access statement
  `<x427>00</x427>` |
  `<d104>Open access – with attribution, no commercial reuse</d104>` |
  `<contentdate>` |
  `<x429>14</x429>` | Statement usable 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
  `. . .` |
  `<j192>01</j192>` | Free of charge
  `<pricedate>` |
  `<x476>14</x476>` | From
  `<b306>20180524</b306>` | six months after pub date
  `</pricedate>` |
  `</price>` |

  The OA license and the Open Access statement can be linked with a 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 signaled in this way. The inevitable change of licensing and price can also be signaled in advance through use of <UnpricedItemType> within <Price> and the relevant <PriceDate>.
  In simple cases (such as the above), the same meaning could be conveyed by embedding the OA licensing details entirely within the free-of-charge <Price>.

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

  road atlas scale is 1:500,000 (1cm = 5km)
  using Reference names |
  --- | ---
  `<MapScale>500000</MapScale>` |

  using short tags, and with additional inset maps at 1:25000
  `<b063>500000</b063>` |
  `<b063>25000</b063>` |

##### 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: recipients of the ONIX data (overseas purchasers, freight forwarders and third-party logistics organizations, for example) can discover what taxes, tariffs or duties are payable as products are traded, and any import and export quotas that might apply. The recipient may also be able to decide whether any local VAT or Sales taxes are applicable to the product based on the commodity code.

Most national commodity code schemes come in two slight variations – for import and export. For example, the UK HMRC commodity codes (see www.gov.uk/trade-tariff). For import of printed books into the UK, the correct code is likely to be a 10-digit number beginning 4901 or 4903. For export from the UK, the same goods are coded using a 8-digit code beginning 4901 or 4903. International trading requires the export code from one country and the import code for another. Thus best practice would be to include the relevant export code for the country from which the product is distributed to overseas customers, as well as the most likely codes for import into specific countries – for example, US HTS codes if the product is likely to be imported into the US, TARIC import codes if the product is to be imported into the EU, and so on. And since it’s likely that not all potential export destinations will be covered, the basic 6-digit WCO Harmonized System code should also be included.

  TARIC product classification for an ordinary book
  using Reference names
  `<ProductClassification>` |
  `<ProductClassificationType>05</ProductClassificationType>` |
  `<ProductClassificationCode>4901000000</ProductClassificationCode>` |
  `</ProductClassification>` |

  using Short tags, with additional EUDR-related TARIC code
  `<productclassification>` |
  `<b274>05</b274>` | TARIC
  `<b275>4901000000</b275>` | for an ordinary book
  `</productclassification>` |
  `<productclassification>` |
  `<b274>20</b274>` | Additional TARIC code
  `<b275>C716</b275>` | DDS is available
  `</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, and in the case of multi-component products, the different components may attract tax at different rates.

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 <ProductClassificationType> (‘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

Some products consist of multiple components or parts – multiple book volumes, perhaps in a slipcase, CDs in a package, or a book sold along with a soft toy. Retailers and purchasers need to know the nature and number of the constituent components of the product in order to make their purchasing decision.

Some other ‘products’ in fact consist of multiple items, each a saleable product in its own right, with the multi-item product or pack usually intended to be broken down and the items sold individually to end purchasers. While the multi-item pack traded business-to-business might not be intended for business-to-consumer sale, the nature and number of the constituent items is vital information for resellers.

In both these cases, it is best practice to include one or more repeats of <ProductPart>. 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 or component within the product, unless it is supplied for the product as a whole in P.3.

Common issues in Group P.4:

- omitting <ProductPart> information when <ProductComposition> and <ProductForm> in Group P.3 indicates the product has multiple components or items;
- proprietary part identifiers provided without an <IDTypeName>;
- other issues as for Group 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-disk audiobook in sleeve attached to inside back cover (the audio version is not available as a separate product)
  using Reference names |
  --- | ---
  `<ProductComposition>10</ProductComposition>` |
  `<ProductForm>SF</ProductForm>` |
  `<!-- <Measure> omitted for brevity -->` |
  `<ProductPart>` |
  `<PrimaryPart/>` |
  `<ProductIdentifier>` |
  `<ProductIDType>03</ProductIDType>` |
  `<IDValue>9780001234567</IDValue>` |
  `</ProductIdentifier>` |
  `<ProductIdentifier>` |
  `<ProductIDType>15</ProductIDType>` |
  `<IDValue>9780001234567</IDValue>` |
  `</ProductIdentifier>` |
  `<ProductForm>BC</ProductForm>` |
  `<NumberOfCopies>1</NumberOfCopies>` |
  `<CountryOfManufacture>ES</CountryOfManufacture>` |
  `</ProductPart>` |
  `<ProductPart>` |
  `<!-- no separate identifier available -->` |
  `<ProductForm>AC</ProductForm>` |
  `<ProductFormDetail>A101</ProductFormDetail>` |
  `<NumberOfItemsOfThisForm>2</NumberOfItemsOfThisForm>` |
  `<CountryOfManufacture>AT</CountryOfManufacture>` |
  `</ProductPart>` |

  using Short tags |
  --- | ---
  `<x313>10</x313>` | Multi-component product
  `<b012>SF</b012>` | Part(s) enclosed within largest item
  `<!-- <measure> omitted -->` |
  `<productpart>` |
  `<x457/>` | Book is primary part
  `<productidentifier>` |
  `<b221>03</b221>` | GTIN-13
  `<b244>9780001234567</b244>` | (of book as single product)
  `</productidentifier>` |
  `<productidentifier>` |
  `<b221>15</b221>` | ISBN
  `<b244>9780001234567</b244>` |
  `</productidentifier>` |
  `<b012>BC</b012>` | Paperback
  `<x323>1</x323>` | One book
  `<x316>ES</x316>` | Printed in Spain
  `</productpart>` |
  `<productpart>` |
  `<!-- no separate identifier available -->` |
  `<b012>AC</b012>` | CD-Audio
  `<b333>A101</b333>` | ‘Red Book’ audio format
  `<x322>2</x322>` | Two discs
  `<x316>AT</x316>` | Pressed in Austria
  `</productpart>` |

  The <Measure> composite cannot be included inside <ProductPart> (although some size information may be included within <ProductFormDetail>). The exact physical size of each item in a multi-component product or (more relevantly) in a multi-item trade-only pack must be expressed in separate ONIX records for the individual items.

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

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

  using Reference names |
  --- | ---
  `<ProductPart>` |
  `<ProductForm>BA</ProductForm>` |
  `<NumberOfItemsOfThisForm>3</NumberOfItemsOfThisForm>` |
  `</ProductPart>` |

  using Short tags |
  --- | ---
  `<productpart>` |
  `<b012>BA</b012>` | Book – detail unspecified
  `<x322>3</x322>` |
  `</productpart>` |

  In this case, the only information about the components is that there are three different components, and that they are books (it is not stated whether they are hardcovers or paperbacks). Three identical components would use <NumberOfCopies> instead.

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

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

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

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

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

3. 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;
4. 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-subcollection 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;
- a title – whether collection-level or product level – can comprise a textual title, subtitle, part number and year.

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:

  Focus on Mathematics — Workbook 6 (method 1)
  `<!-- Group P.6 -->`
  `<TitleDetail>`
  `<-- collection-level title element = Focus on Mathematics -->`
  `<-- product-level title element = Workbook 6 -->`
  `</TitleDetail>`

  The Beautiful and the Damned (Penguin Modern Classics), illustrating the structure of collection- and product-level title elements only (method 2)
  `<!-- 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>`

  Choosing to use the first 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 – it may be as simple as displaying them differently: ‘Focus on Mathematics — Workbook 6’ and ‘The beautiful and the damned (Penguin Modern Classics)’.

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.

Many products are members of a ‘collection’, a group of two or more products which share some consistent collective identity, or which are grouped together for marketing and sales purposes – for example a collection of novels featuring the same protagonist, a group of leveled readers for education, or multiple otherwise unrelated non-fiction titles linked by their consistent style and design. Each part of a collection is retailed individually. Occasionally, the whole collection may be available as a single product.

Collections are powerful tools to encourage purchases and retain customers – a strong collective identity increases discoverability of all the members of a collection, and readers of one book in the collection are more likely to purchase further books in the same collection. The collection as a whole can be more recognizable than any individual member, so marketing and promotion can focus on the collection rather than any single book. Given this, it’s vital for resellers to be aware of the collective identity as well as the identity of any single product.

However, collection details are not always included in Group P.5 – it may sometimes be more appropriate to include the details in Group P.6 instead.

There are two types of collection – those prescribed by the publisher where the collection details form part of the bibliographic detail for the book, and those less formally ascribed by another party within the supply chain largely for marketing purposes.

Note that in early versions of ONIX, collections were defined as either ‘series’ or ‘sets’, but ONIX 3.1 and 3.0 term them all ‘collections’ since the distinction is not particularly meaningful within the supply chain.

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

The whole <Collection> composite can be repeated if a product is within two unrelated collections.

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

Common issues in Group P.5:

- using P.5 for all collection titles, irrespective of whether the product title is distinctive or not (where the product title is not distinctive enough, then the collection title should be specified in Group P.6);
- using the wrong Title element level. Where P.5 contains a <TitleElement> containing a part number, for example, it would normally be at product level (<TitleElementLevel> 01), not at collection level (02), even though it is inside the <Collection> composite. In fact, <PartNumber> cannot be used at Title element level 02 (collection level) at all, because logically that would indicate that the collection is a part of something larger;
- including <NoCollection/>, when in fact there is a collection title in P.6;
- inclusion of extraneous information such as the binding type or edition information in the Collection title.

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 vice versa, the set product can link to the individual product using relation code 01 (‘includes’).

  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 ⅩⅢ 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">ⅩⅢ</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">ⅩⅢ</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 ⅩⅢ 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>` |
  `<!-- A history of Greek philosophy collection identifier -->` |
  `<CollectionIdentifier>` |
  `<CollectionElementLevel>02</CollectionElementLevel>` |
  `<CollectionIDType>01</CollectionIDType>` |
  `<IDValue>8041bbe9-4751-4b5b-9bf8-47bd58847578</IDValue>` |
  `</CollectionIdentifier>` |
  `<!-- The fifth century enlightenment sub-collection identifier -->` |
  `<CollectionIdentifier>` |
  `<CollectionElementLevel>03</CollectionElementLevel>` |
  `<CollectionIDType>01</CollectionIDType>` |
  `<IDValue>026ea870-415f-4836-8dd3-ba0d482515e3</IDValue>` |
  `</CollectionIdentifier>` |
  `<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
  `<!-- collection identifier -->` |
  `<collectionidentifier>` |
  `<x586>02</x586>` | Collection level
  `<x344>01</x344>` | Proprietary ID
  `<b244>8041bbe9-4751-4b5b-9bf8-47bd58847578</b244>` | UUID identifies A history of Greek philosophy
  `</collectionidentifier>` | as a collection
  `<!-- sub-collection identifier -->` |
  `<collectionidentifier>` |
  `<x586>03</x586>` | Sub-collection level
  `<x344>01</x344>` | Proprietary ID
  `<b244>026ea870-415f-4836-8dd3-ba0d482515e3</b244>` | UUID identifies The fifth century enlightenment
  `</collectionidentifier>` | as a sub-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. It is even possible to include the collection details in P.5 and the subcollection details in P.6.
  The use of <CollectionElementLevel> within <CollectionIdentifier> is vital here: without it, it’s unclear to which collection or subcollection the identifier refers.
  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` |
  `<CollectionFrequency>q</CollectionFrequency>` |
  `<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
  `<x582>q</x582>` | Quarterly
  `<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.

##### P.5.1a Collection frequency

Some collections – particularly manga and other comic books, and some types of genre fiction such as romance collections – are published to a regular schedule, perhaps monthly or quarterly. The Collection frequency element contains a code to specify this.

Note that if the schedule specifies ‘six novels every three months’ and all six are published at the same time, then the frequency is quarterly (not fortnightly). On the other hand, if publication of the six is spread evenly through the quarter, the frequency is roughly fortnightly (ie one publication every two weeks). Collection frequency is really the frequency of publication dates, independent of the number of products published on each date.

##### Collection identifier composite

This composite should be used to specify any relevant identifiers for the collection as a whole. For bibliographic (publisher–defined) collections, formal identifiers such as an ISSN may be appropriate. Alternatively, when a collection of products is also (or at least, is potentially also) available as a product in its own right (ie the collection might be thought of as a set, in the sense of ‘boxed set’) then an ISBN can be used as a collection identifier – though there is some potential confusion between the ‘collection as a single product’ and the ‘collection as a collection of individual products’. For collections where ongoing publishing activity means the collection cannot be purchased as a fixed product (ie the collection might be thought of as an ongoing series) then an ISBN would not be appropriate, and some proprietary identifier should be used.

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.

The <RelatedProduct> composite is also important for collections. Products in the collection can be linked using ‘product in same collection’ Product relation (see List 51 code 30), and the relationship between the ‘collection as a product’ (eg a boxed set or an omnibus) and the contained products should be specified using ‘includes’ / ‘is part of’ relationships (see codes 01 and 02). A boxed set product will of course also use <ProductPart>.

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.

For some products that are part of a sub-collection nested within a larger collection, it may be appropriate to include multiple collection identifiers, covering both collection and sub-collection. In this case, <CollectionElementLevel> must be used to link each identifier to the correct ‘level’ of collection, sub-collection and so on.

  collection, nested sub-collection and multiple identifiers
  using Reference names |
  --- | ---
  `<Collection>` |
  `<CollectionType>10</CollectionType>` |
  `<CollectionIdentifier>` |
  `<CollectionElementLevel>02</CollectionElementLevel>` |
  `<CollectionIDType>02</CollectionIDType>` |
  `<IDValue>98765434</IDValue>` |
  `</CollectionIdentifier>` |
  `<CollectionIdentifier>` |
  `<CollectionElementLevel>02</CollectionElementLevel>` |
  `<CollectionIDType>01</CollectionIDType>` |
  `<IDTypeName>MyCollectionID</IDTypeName>` |
  `<IDValue>0012</IDValue>` |
  `</CollectionIdentifier>` |
  `<CollectionIdentifier>` |
  `<CollectionElementLevel>03</CollectionElementLevel>` |
  `<CollectionIDType>01</CollectionIDType>` |
  `<IDTypeName>MySubCollectionID</IDTypeName>` |
  `<IDValue>0014</IDValue>` |
  `</CollectionIdentifier>` |
  `<TitleDetail>` |
  `<TitleType>01</TitleType>` |
  `<TitleElement>` |
  `<TitleElementLevel>02</TitleElementLevel>` |
  `<NoPrefix/>` |
  `<TitleWithoutPrefix>World wide walking guides</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `<TitleElement>` |
  `<TitleElementLevel>03</TitleElementLevel>` |
  `<NoPrefix/>` |
  `<TitleWithoutPrefix>Europe</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `</TitleDetail>` |
  `</Collection>` |

  using Short tags |
  --- | ---
  `<collection>` |
  `<x329>10</x329>` |
  `<collectionidentifier>` |
  `<x586>02</x586>` | ID for collection
  `<x344>02</x344>` | ISSN
  `<b244>98765434</b244>` |
  `</collectionidentifier>` |
  `<collectionidentifier>` |
  `<x586>02</x586>` | ID for collection
  `<x344>01</x344>` | Proprietary
  `<b233>MyCollectionID</b233>` |
  `<b244>0012</b244>` |
  `</collectionidentifier>` |
  `<collectionidentifier>` |
  `<x586>03</x586>` | ID for sub-collection
  `<x344>01</x344>` | Proprietary
  `<b233>MySubCollectionID</b233>` |
  `<b244>0014</b244>` |
  `</collectionidentifier>` |
  `<titledetail>` |
  `<b202>01</b202>` |
  `<titleelement>` |
  `<x409>02</x409>` | Global collection contains
  `<x501/>` | several ‘continental’
  `<b031>World wide walking guides</b031>` | sub-collections
  `</titleelement>` |
  `<titleelement>` |
  `<x409>03</x409>` | European sub-collection
  `<x501/>` | contains several ‘national’
  `<b031>Europe</b031>` | guidebooks
  `</titleelement>` |
  `</titledetail>` |
  `</collection>` |

  In this example, the product – a hiking guide to Portugal, for example – belongs to the collection and sub-collection named. And it is possible for a data senders and recipients to associate a collection or sub-collection title unambiguously with a particular collection ID by matching the relevant Collection title element level within <CollectionIdentifier> to the Title element levels within <TitleDetail>.

  As an example of this, the <CollectionElementLevel> code 02 in the example makes it clear that the ISSN and the proprietary identifier 0012 specified both identify the collection World wide walking guides, and not the sub-collection Europe.

  Note that the Collection title element level within a <CollectionIdentifier> composite must match at least one Title element level within a <TitleDetail> composite. The matching <TitleElement> within <TitleDetail> could be within the same <Collection> composite as the identifier, or outside of <Collection> and within Group P.6.

  Since the collection identifier can refer to a collection named in Group P.5 or Group P.6, care should be taken to avoid potential ambiguity where a product is within two different collections – a maximum of one collection should be described in Group 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 Ⅳ (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.
  Since the collection order can refer to a collection named in Group P.5 or Group P.6, care should be taken to avoid ambiguity where a product is within two different collections – at least one of them should be described in Group P.5.

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 twelfth suggests that there are two planned ‘prequels’ included in the sub-collection.
  It is common for the collection sequence metadata for books in a collection to be modified post-publication, as later books are published. Do not assume the collection sequence is fixed at publication.

##### Title detail composite (collection)

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 (collection)

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) or character set (eg ASCII only). This type of title is primarily intended used in e-commerce messages.

The title of a book is single the most visible piece of metadata about that product, vying only with the author’s name. It is a key access point in libraries, a frequently-searched field in online bookstores and in day-to-day human speech ‘identifies’ the book in the way an ISBN cannot. Providing a full and accurate title is among the first few steps an ONIX data supplier needs to take.

So 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 to be a serious problem. Use <TextContent> in Group P.14 with <TextType> code 10 (Promotional headline) for short promotional messages, and use code 37 (Cover line) for more informational cover lines that often appear on the cover but are not strictly subtitles or do not appear on the title page.

  <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’ as prefixes at all. Note that many languages use suffixes for articles.
  In languages where the practice is to ignore prefixes such as definite and indefinite articles such as ‘A’ or ‘The’ for alphabetic sorting of titles, use of <TitleWithoutPrefix> plus one of <TitlePrefix> or <NoPrefix/> is strongly preferred, and <TitleText> is deprecated. In languages (such as Scandinavian languages) where there are no articles (or more specifically, where they are suffixes), <TitleText> is preferred. In languages where local practice is not to ignore articles for sorting, either method is acceptable.

  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 &amp; A</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `</TitleDetail>` |

  using Short tags |
  --- | ---
  `<!-- Group P.5 -->` |
  `<x411/>` |
  `<!-- Group P.6 -->` |
  `<titledetail>` |
  `<b202>01</b202>` | Distinctive title
  `<titleelement>` |
  `<x409>01</x409>` | Product level
  `<x501/>` |
  `<b203 textcase="02">Slumdog Millionaire</b203>` |
  `</titleelement>` |
  `</titledetail>` |
  `<titledetail>` |
  `<b202>08</b202>` | Former title
  `<titleelement>` |
  `<x409>01</x409>` | Product level
  `<x501/>` |
  `<b031 textcase="02">Q &amp; A</b031>` | Must use entity for ‘&’
  `</titleelement>` |
  `</titledetail>` |

  product that is part of a collection specified in Group P.5
  using Reference names |
  --- | ---
  `<!-- Group P.5 -->` |
  `<Collection>` |
  `<CollectionType>10</CollectionType>` |
  `<TitleDetail>` |
  `<TitleType>01</TitleType>` |
  `<TitleElement>` |
  `<TitleElementLevel>02</TitleElementLevel>` |
  `<NoPrefix/>` |
  `<TitleWithoutPrefix textcase="02">Larousse Petits Classiques​</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `</TitleDetail>` |
  `</Collection>` |
  `<!-- Group P.6 -->` |
  `<TitleDetail>` |
  `<TitleType>01</TitleType>` |
  `<TitleElement>` |
  `<TitleElementLevel>01</TitleElementLevel>` |
  `<TitlePrefix textcase="02">Les</TitlePrefix>` |
  `<TitleWithoutPrefix textcase="02">Misérables</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `</TitleDetail>` |

  using Short tags |
  --- | ---
  `<!-- Group P.5 -->` |
  `<collection>` |
  `<x329>10</x329>` | Publisher collection
  `<titledetail>` |
  `<b202>01</b202>` | Distinctive title
  `<titleelement>` |
  `<x409>02</x409>` | Collection level
  `<x501/>` |
  `<b031 textcase="02">Larousse Petits Classiques</b031>` |
  `</titleelement>` |
  `</titledetail>` |
  `</collection>` |
  `<!-- Group P.6 -->` |
  `<titledetail>` |
  `<b202>01</b202>` | Distinctive title
  `<titleelement>` |
  `<x409>01</x409>` | Product level
  `<b030 textcase="02">Les</b030>` |
  `<b031 textcase="02">Misérables</b031>` |
  `</titleelement>` |
  `</titledetail>` |

  omnibus edition of three novels, without a distinctive title of its own (basic method)
  using Reference names |
  --- | ---
  `<!-- no Group P.5 -->` |
  `<!-- Group P.6 -->` |
  `<TitleDetail>` |
  `<TitleType>01</TitleType>` |
  `<TitleElement>` |
  `<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>` |
  `<x409>01</x409>` |
  `<x501/>` |
  `<b031 textcase="02">Sense and Sensibility / Pride and Prejudice / Northanger Abbey</b031>` |
  `</titleelement>` |
  `</titledetail>` |

  omnibus edition of three novels, without a distinctive title of its own (improved method using multiple Title elements)
  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</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `<TitleElement>` |
  `<SequenceNumber>2</SequenceNumber>` |
  `<TitleElementLevel>01</TitleElementLevel>` |
  `<NoPrefix/>` |
  `<TitleWithoutPrefix>Pride and Prejudice</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `<TitleElement>` |
  `<SequenceNumber>3</SequenceNumber>` |
  `<TitleElementLevel>01</TitleElementLevel>` |
  `<NoPrefix/>` |
  `<TitleWithoutPrefix>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</b031>` |
  `</titleelement>` |
  `<titleelement>` |
  `<b034>2</b034>` |
  `<x409>01</x409>` |
  `<x501/>` |
  `<b031 textcase="02">Pride and Prejudice</b031>` |
  `</titleelement>` |
  `<titleelement>` |
  `<b034>3</b034>` |
  `<x409>01</x409>` |
  `<x501/>` |
  `<b031 textcase="02">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 / Pride and Prejudice / Northanger Abbey</Subtitle>` |
  `</TitleElement>` |
  `<TitleStatement>The Jane Austen Omnibus, Part One: Sense and Sensibility / Pride 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 / Pride and Prejudice / Northanger Abbey</b029>` |
  `</titleelement>` |
  `<x478>The Jane Austen Omnibus, Part One: Sense and Sensibility / Pride 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 (improved method, but not recommended unless the individual novel titles are printed 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 / Pride 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 / Pride 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 if the individual novel titles are not printed 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>` |
  `<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>` | First 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>` | Second 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.

In the simplest cases, for example where a product has a title and a subtitle, both title and subtitle should be included in the same <TitleElement> composite. But there are exceptions to this.

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/>` |
  `<TitleWithoutPrefix textcase="02">Descent</TitleWithoutPrefix>` |
  `</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>.

  multiple title elements at the same level: a bilingual book
  using Reference names |
  --- | ---
  `<TitleDetail>` |
  `<TitleType>01<TitleType>` |
  `<TitleElement>` |
  `<TitleElementLevel>01</TitleElementLevel>` |
  `<TitlePrefix language="eng" textcase="02">The</TitlePrefix>` |
  `<TitleWithoutPrefix language="eng" textcase="02">Day of the Dead</TitleWithoutPrefix>` |
  `<Subtitle language="eng">a bilingual celebration</Subtitle>` |
  `</TitleElement>` |
  `<TitleElement>` |
  `<TitleElementLevel>01</TitleElementLevel>` |
  `<TitlePrefix language="spa" textcase="01">El</TitlePrefix>` |
  `<TitleWithoutPrefix language="spa" textcase="01">dia de los muertos</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `<TitleStatement>El dia de los Muertos / The Day of the Dead: a bilingual celebration</TitleStatement>` |
  `</TitleDetail>` |

  using Short tags |
  --- | ---
  `<titledetail>` |
  `<b202>01<b202>` |
  `<titleelement>` |
  `<x409>01</x409>` | Product-level title
  `<b030 language="eng" textcase="02">The</b030>` | in English
  `<b031 language="eng" textcase="02">Day of the Dead</b031>` |
  `<b029 language="eng">a bilingual celebration</b029>` |
  `</titleelement>` |
  `<titleelement>` |
  `<x409>01</x409>` | Product level title
  `<b030 language="spa" textcase="01">El</b030>` | in Spanish
  `<b031 language="spa" textcase="01">dia de los muertos</b031>` |
  `</titleelement>` |
  `<x478>El dia de los Muertos / The Day of the Dead: a bilingual celebration</x478>` |
  `</titledetail>` |

  multiple title elements at the same level: a bilingual book with multiple scripts
  using Reference names |
  --- | ---
  `<TitleDetail>` |
  `<TitleType>01<TitleType>` |
  `<TitleElement>` |
  `<SequenceNumber>3</SequenceNumber>` |
  `<TitleElementLevel>01</TitleElementLevel>` |
  `<NoPrefix/>` |
  `<TitleWithoutPrefix language="eng" textcase="02">Life Cycles of Caribou</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `<TitleElement>` |
  `<SequenceNumber>2</SequenceNumber>` |
  `<TitleElementLevel>01</TitleElementLevel>` |
  `<NoPrefix/>` |
  `<TitleWithoutPrefix language="iku" textscript="Latn" textcase="02">Tuktut Innaruqpallianingit</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `<TitleElement>` |
  `<SequenceNumber>1</SequenceNumber>` |
  `<TitleElementLevel>01</TitleElementLevel>` |
  `<NoPrefix/>` |
  `<TitleWithoutPrefix language="iku" textscript="Cans">ᑐᒃᑐᑦ ᐃᓐᓇᕈᖅᐸᓪᓕᐊᓂᖕᒋᑦ</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `<TitleStatement>ᑐᒃᑐᑦ ᐃᓐᓇᕈᖅᐸᓪᓕᐊᓂᖕᒋᑦ / Tuktut Innaruqpallianingit / Life Cycles of Caribou</x478></TitleStatement>` |
  `</TitleDetail>` |

  using Short tags |
  --- | ---
  `<titledetail>` |
  `<b202>01<b202>` |
  `<titleelement>` |
  `<b034>3</b034>` | Third part of
  `<x409>01</x409>` | product-level title
  `<x501/>` |
  `<b031 language="eng" textcase="02">Life Cycles of Caribou</b031>` | English language
  `</titleelement>` |
  `<titleelement>` |
  `<b034>2</b034>` | Second part of title
  `<x409>01</x409>` | (at product level)
  `<x501/>` |
  `<b031 language="iku" textscript="Latn" textcase="02">Tuktut Innaruqpallianingit</b031>` | Inuktitut language, Latin script
  `</titleelement>` |
  `<titleelement>` |
  `<b034>1</b034>` | First part of
  `<x409>01</x409>` | product-level title
  `<x501/>` |
  `<b031 language="iku" textscript="Cans">ᑐᒃᑐᑦ ᐃᓐᓇᕈᖅᐸᓪᓕᐊᓂᖕᒋᑦ</b031>` | Inuktitut language, Unified Canadian Aboriginal Syllabics script, text case not relevant
  `</titleelement>` |
  `<x478>ᑐᒃᑐᑦ ᐃᓐᓇᕈᖅᐸᓪᓕᐊᓂᖕᒋᑦ / Tuktut Innaruqpallianingit / Life Cycles of Caribou</x478>` | Suggested title for display
  `</titledetail>` |

  In this case, notice the publisher is emphasizing (with <SequenceNumber>) that the Inuktitut title should be listed first. If supplied, the sequence number is more important than the order in which the three title elements appear in the ONIX file. Contrast this with the previous example, which lacks Sequence numbers to emphasize that The Day of the Dead and El dia de los muertos are of equal importance and can be cataloged or displayed in any order.

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.

Title statement has the additional benefit that it can contain HTML or XHTML markup (see P.7.42 Biographical note below) – which may be important if the title contains some text that must be rendered differently. As an example, the Title statement ‘Günter Grass and his critics: from <cite>The Tin Drum</cite> to <cite>Crabwalk</cite>’, which includes two other book titles within the title of the book. Note the whole title is in italics, because in this document the title is enclosed within invisible HTML <cite> tags. But the two titles within the title are rendered differently (in roman characters) because they are also surrounded by <cite> tags within the <TitleStatement> data (in this document, these tags are deliberately made visible, and one cite within another is deliberately rendered in roman, just as italic within italic is normally rendered in roman).

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> (though this is deprecated)

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 current supply chain IT systems yet 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 or they incorporate them as suffixes (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 bicameral (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 Ⅲ</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

Alongside the title, the authorship of a book is one of the most visible and memorable pieces of bibliographic metadata, and in many cases is the most important in generating sales. It is a key access point in libraries, and of course is one of the most-searched fields in online stores. Fiction, at least, is usually shelved by author name in physical stores and public libraries, and in many respects it is the ‘brand’ most strongly associated with the product (while the imprint represents the publisher’s brand, the author’s name is often more prominent). Therefore, providing complete and accurate authorship is clearly critical for discoverability in many different contexts.

It’s common for products to have multiple contributors with different roles – not just ‘authors’, but illustrators, editors and compilers, translators and others. It is best practice to name in the metadata at least all those named on the book itself.

Contributor names are commonly both displayed and sorted. It is best practice to provide the various parts of a name in a granular fashion (using <KeyNames>), not just as a simple text string that might be used for display, because personal naming and sorting conventions vary greatly between cultures. Picking out the part of a name used first for sorting purposes from a simple text string is nigh impossible.

Increasingly, a rich range of information beyond the contributor name is helpful, eg to allow an online retailer to compile ‘author pages’ – with a biography, any professional positions and affiliations and a bibliography (plus potentially, links to promotional events from Group P.27). This encourages wider reader exploration and discovery. When compiling author pages, a name identifier such as ISNI can be used to eliminate any ambiguity (and consequent reputational risk) between contributors of the same name.

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’). <UnnamedPersons> should also used to list ‘contributors’ who are neither natural persons nor corporate, for example synthesized voices for audiobooks, or ‘AI’ translators;
- 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.

For contributions to the book content that are created or subtantially aided by artificial intelligence, it is good practice for responsible publishers to disclose this, primarily using <UnnamedPersons>. For more details see EDItEUR’s application note Aspects of AI in ONIX (doi:10.4400/sfar).

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:

- incorrect use of <SequenceNumber>;
- listing a contributor twice when they perform two roles (use a single <Contributor> composite and repeat <ContributorRole>);
- 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>;
- use of personal name fields to hold corporate names;
- 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 the meaning of particular contributor roles – for example the reader of an audiobook should use the role code E07 (Read by), not E03 (Narrator) – the latter should only used within dramatized audio. 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 by using &gt; instead of >, double-escaping of character entities or through failure to include the textformat attribute), or 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 ONIX validation errors – or 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’ (according to the author’s wishes, not ‘Stanton 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 together 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>` |
  `<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 ID</b233>` |
  `<b244>01381</b244>` |
  `</nameidentifier>` |
  `<b036>Nele Neuhaus</b036>` |
  `<b037>Neuhaus, Nele</b037>` |
  `<b039>Nele</b039>` |
  `<b040>Neuhaus</b040>` |
  `<b044 textformat="05"><p><strong>Nele Neuhaus</strong> wurde 1967 als zweites von vier Kindern der Familie Löwenberg in Münster/Westfalen geboren. Sie wuchs in Paderborn auf, bevor sie im Alter von 11 Jahren mit ihrer Familie in den Taunus zog, als ihr Vater Landrat wurde. Schon seit frühester Kindheit schrieb Nele Neuhaus, zuerst handschriftlich in Schulhefte, später mit Reiseschreibmaschine und Computer.</p><p>Durch ihre Leidenschaft für Pferde lernte sie auf einem Reitturnier ihren Mann kennen, mit dem sie heute in Kelkheim/Taunus lebt.</p></b044>` | Text uses XHTML markup, and message uses UTF‑8 encoding so non-ASCII characters such as ‘ü’ need not be expressed as numerical character references (and must not be carried as HTML entities such as ‘&uuml;’)
  `</contributor>` |

  single corporate contributor, name provided in both normal and inverted form
  using Reference names |
  --- | ---
  `<Contributor>` |
  `<SequenceNumber>1</SequenceNumber>` |
  `<ContributorRole>A09</ContributorRole>` |
  `<CorporateName>CLAMP</CorporateName>` |
  `<CorporateNameInverted>CLAMP</CorporateNameInverted>` |
  `<BiographicalNote textformat="05"><p><strong>CLAMP</strong> is a renowned all-female mangaka collective. Over more than 20 years, it has created many internationally successful series, including <cite>xxxHolic</cite>, <cite>Tsubasa Reservoir Chronicles</cite>, <cite>Card Captor Sakura</cite>, <cite>Magic Knight Rayearth</cite>, <cite>Chobits</cite> and <cite>Tokyo Babylon</cite>.</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 <cite>xxxHolic</cite>, <cite>Tsubasa Reservoir Chronicles</cite>, <cite>Card Captor Sakura</cite>, <cite>Magic Knight Rayearth</cite>, <cite>Chobits</cite> and <cite>Tokyo Babylon</cite>.</p></b044>` |
  `</contributor>` |

  single contributor with alternative name (and proprietary 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, with additional ISNI and NACO identifiers |
  --- | ---
  `<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>` |
  `<nameidentifier>` |
  `<x415>16</x415>` | ISNI
  `<b244>0000000366130900</b244>` |
  `</nameidentifier>` |
  `<nameidentifier>` |
  `<x415>18</x415>` | NACO number
  `<b244>no89013215</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>` |
  `<nameidentifier>` |
  `<x415>16</x415>` | ISNI
  `<b244>0000000121022127</b244>` |
  `</nameidentifier>` |
  `<nameidentifier>` |
  `<x415>18</x415>` | NACO number
  `<b244>n79038407</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>` |
  `<AffiliationIdentifier>` |
  `<AffiliationIDType>40</AffiliationIDType>` |
  `<IDValue>02jx3x895</IDValue>` |
  `</AffiliationIdentifier>` |
  `<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>5</SequenceNumber>` |
  `<ContributorRole>B15</ContributorRole>` |
  `<PersonNameInverted>Bunney, Sarah</PersonNameInverted>` |
  `</Contributor>` |
  `<Contributor>` |
  `<SequenceNumber>4</SequenceNumber>` |
  `<ContributorRole>A24</ContributorRole>` |
  `<PersonNameInverted>Dawkins, Richard</PersonNameInverted>` |
  `</Contributor>` |
  `<Contributor>` |
  `<SequenceNumber>6</SequenceNumber>` |
  `<ContributorRole>Z04</ContributorRole>` |
  `<UnnamedPersons>02</UnnamedPersons>` |
  `</Contributor>` |
  `<ContributorStatement>Edited by Steve Jones, Robert Martin and David Pilbeam, with an Introduction by Richard Dawkins. Editorial coordination by Sarah Bunney<ContributorStatement>` |

  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>` |
  `<affiliationidentifier>` |
  `<x580>40</x580>` | ROR
  `<b244>02jx3x895</b244>` |
  `</affiliationidentifier>` |
  `<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>5</b034>` | Contributor 5
  `<b035>B15</b035>` | Editorial coordination by
  `<b037>Bunney, Sarah</b037>` |
  `</contributor>` |
  `<contributor>` |
  `<b034>4</b034>` | Contributor 4
  `<b035>A24</b035>` | Introduction by
  `<b037>Dawkins, Richard</b037>` |
  `</contributor>` |
  `<contributor>` | Contributor 6
  `<b034>6</b034>` |
  `<b035>Z04</b035>` | Peer reviewed…
  `<b249>02</b249>` | anonymously
  `</contributor>` |
  `<b049>Edited by Steve Jones, Robert Martin and David Pilbeam, with an Introduction by Richard Dawkins. Editorial coordination by Sarah Bunney<b049>` |

  Note the <SequenceNumber> of the contributors does not necessarily match the message order – it matches the order of precedence used on the book and in the Contributor statement.
  The ISNI and ROR identifiers within the first <Contributor> composite refer to different entities – the ISNI identifies Steve Jones, the ROR identifies his affiliated organization (in this case, a university).
  Contributor 6 indicates this is a peer-reviewed publication. Presence of the role acts as a ‘flag’ to indicate the publication is peer reviewed. Peer reviewers are typically anonymous, using <UnnamedPersons>, but the same Contributor role code Z04 may be used with a named contributor where ‘open identity’ reviewing is used.
  It is normal to provide a combined biographical note for multiple contributors in Group P.14 (<TextType> code 12 from List 153). This may be in addition to individual biographical notes within each <Contributor> composite, or may be provided instead of individual biographies.

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

  ‘assisted by’
  using Reference names |
  --- | ---
  `<Contributor>` |
  `<SequenceNumber>2</SequenceNumber>` |
  `<ContributorRole>A12</ContributorRole>` |
  `<PersonNameInverted>Kundu, Saraswati</PersonNameInverted>` |
  `</Contributor>` |
  `<Contributor>` |
  `<SequenceNumber>3</SequenceNumber>` |
  `<ContributorRole>Z01</ContributorRole>` |
  `<UnnamedPersons>09</UnnamedPersons>` |
  `</Contributor>` |
  `<ContributorStatement>AI-assisted illustration by Saraswati Kundu<ContributorStatement>` |

  using Short tags names |
  --- | ---
  `<contributor>` |
  `<b034>2</b034>` |
  `<b035>A12</b035>` | Illustrated by
  `<b037>Kundu, Saraswati</b037>` |
  `</contributor>` |
  `<contributor>` |
  `<b034>3</b034>` |
  `<b035>Z01</b035>` | Assisted by
  `<b249>09</b249>` | AI
  `</contributor>` |
  `<b049>AI-assisted illustrations by Saraswati Kundu<b049>` |

  Note that ‘assisted by’ is a role that can be associated with any other role, and thus the sequence number is important to make clear the contributor to whom the assistance is rendered – ie to the contributor with the preceding sequence number. In this case, the assistant is some generative AI technology, but of course named assistants can also be credited.

  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 across all the contributors – and this may mean the order contributors occur within the XML file is not their correct collation order. Note however that contributors listed in Block 3 are not part of the same sequence. Each <ContentItem> supports an independent sequence applicable to that Content item only.

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

  multiple roles for a single contributor
  using Reference names |
  --- | ---
  `<Contributor>` |
  `<SequenceNumber>1</SequenceNumber>` |
  `<ContributorRole>A24</ContributorRole>` | Introduced and
  `<ContributorRole>B06</ContributorRole>` | translated by…
  `. . .` |
  `</Contributor>` |

  using Short tags |
  --- | ---
  `<contributor>` |
  `<b034>1</b034>` |
  `<b035>A01</b035>` | Written and
  `<b035>A12</b035>` | illustrated by…
  `. . .` |
  `</contributor>` |

  Repetition of roles can on occasion 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.

A handful of Contributor role codes do not, in fact, directly specify a role – they specify a relationship to another contributor and their role. The most common example is ‘assisted by’, where the nature of the assistance depends on the preceding contributor.

  using Reference names |
  --- | ---
  `<Contributor>` |
  `<SequenceNumber>1</SequenceNumber>` |
  `<ContributorRole>A01</ContributorRole>` |
  `. . .` |
  `</Contributor>` |
  `<Contributor>` |
  `<SequenceNumber>2</SequenceNumber>` |
  `<ContributorRole>B01</ContributorRole>` |
  `. . .` |
  `</Contributor>` |
  `<Contributor>` |
  `<SequenceNumber>3</SequenceNumber>` |
  `<ContributorRole>Z01</ContributorRole>` |
  `. . .` |
  `</Contributor>` |
  `<Contributor>` |
  `<SequenceNumber>4</SequenceNumber>` |
  `<ContributorRole>A51</ContributorRole>` |
  `. . .` |
  `</Contributor>` |

  using Short tags |
  --- | ---
  `<contributor>` |
  `<b034>1</b034>` |
  `<b035>A01</b035>` | Written by
  `. . .` |
  `</contributor>` |
  `<contributor>` |
  `<b034>2</b034>` |
  `<b035>B01</b035>` | Edited by
  `. . .` |
  `</contributor>` |
  `<contributor>` |
  `<b034>3</b034>` |
  `<b035>Z01</b035>` | Assisted by
  `. . .` |
  `</contributor>` |
  `<contributor>` |
  `<b034>4</b034>` |
  `<b035>A51</b035>` | Research by
  `. . .` |
  `</contributor>` |

  In this example, the third contributor specifically assisted the second in editing the work. It is not possible to list the same contributor as providing assistance to both the author and the editor – again, judicious use of <ContributorStatement> is important to provide guidance in such rare cases.

##### 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 https://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).

  ISNI or ORCID? They’re both sixteen digit numbers, they use the same check digit calculation, and they ‘look’ the same. Can you tell them apart? One clue can be that an ISNI is often displayed in text as 0000 0001 2345 6789, whereas an ORCID is usually 0000-0002-1345-6782 – spaces for ISNI, hyphens for ORCID – though note that in ONIX, both should appear without spaces or hyphens. The real differentiator is that all ORCIDs lie in the range 0000-0001-5000-0000 to 0000-0003-4999-9999. ISNIs lie outside that range.

Over fifteen 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, TV and movies, 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, Ngaio, Dame |
  Henry of Huntingdon | Huntingdon, Henry of |
  Henriette d’Angeville | Angeville, Henriette d’ |
  Mary O’Connor | O’Connor, Mary |
  Máire ní Conchobhair | Conchobhair, Máire ní |
  Gabriel Garcia Márquez | Garcia Márquez, Gabriel |
  Megan Lloyd George | Lloyd George, Megan |
  Andre Dubus Ⅲ | Dubus, Andre, Ⅲ |
  Dr. Shobna Khatri | Khatri, Shobna, Dr. |
  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 Ⅲ) 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. (The various name fields here do not.) Where phonetics are needed for both human reading and for sorting purposes, both a collationkey and a ruby text should be included.

  `<b037 collationkey="むらかみ はるき">&#xfff9;村上春樹&#xfffa;むらかみ はるき&#xfffb;</b037>`

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

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

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

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

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

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

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

##### P.7.11 Titles before names

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

  Pope Benedict XVI |
  His Holiness the Dalai Lama |
  HRH Prince Charles |
  Dame Ngaio Marsh |
  General Sir Peter de la Billière |

##### P.7.12 Names before key names

  Dame Ngaio Marsh |
  General Sir Peter de la Billière |
  Henriette d’Angeville |
  Gabriel Garcia Márquez |
  Robert Louis Stephenson |
  Megan Lloyd George |
  Фёдор Достоевский | (Fyodor Dostoyevsky)
  Haruki Murakami | (when name is Westernized)
  علاء الأسواني | (Alaa al-Aswany)
  שפרה הורן | (Shifra Horn)

##### P.7.13 Prefix to key names

  His Holiness the Dalai Lama |
  General Sir Peter de la Billière |
  Henriette d’Angeville |
  Máire ní 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 ní 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 ní 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 Ⅱ of Spain
  Philip Ⅱ, 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.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.

  name with a prefix
  `<CorporateName>The editors of Rolling Stone Magazine</CorporateName>`
  `<CorporateNameInverted>Rolling Stone Magazine, The editors of</CorporateNameInverted>`

  no prefix (on the product)
  `<CorporateName>World Health Organization</CorporateName>`
  `<CorporateNameInverted>World Health Organization</CorporateNameInverted>`

  multilingual name (on the product)
  `<CorporateName language="eng">World Health Organization</CorporateName>`
  `<CorporateName language="fre">Organisation mondiale de la santé</CorporateName>`

  Where an organization has an official name in more than one language, Corporate names are repeatable to provided in multiple languages in parallel. If repeated, the language attribute is required. Note that this is an alternative to the use of <AlternativeName> (see below example with RATP), and should only be used for organizations which have official names in more than one language.

##### 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 pre-recorded 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>.

  crediting an AI translation
  using Reference names |
  --- | ---
  `<Contributor>` |
  `<SequenceNumber>1</SequenceNumber>` |
  `<ContributorRole>A01</ContributorRole>` |
  `<PersonNameInverted>Angeville, Henriette d’</PersonNameInverted>` |
  `</Contributor>` |
  `<Contributor>` |
  `<SequenceNumber>2</SequenceNumber>` |
  `<ContributorRole>B06</ContributorRole>` |
  `<FromLanguage>fre</FromLanguage>` |
  `<UnnamedPersons>09</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>B06</b035>` | Translated
  `<x412>fre</x412>` | from French
  `<b249>09</b249>` | by AI
  `</contributor>` |

  <ToLanguage> may also be included, but is normally unnecessary here since it should be included in <Language>.

  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 <i>et al</i></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 <i>et al</i></p></b049>` |

  Compare this example with the previous multiple contributor example.

  use of AI-based synthesized voice in audiobook narration
  using Reference names |
  --- | ---
  `<Contributor>` |
  `<SequenceNumber>3</SequenceNumber>` |
  `<ContributorRole>E07</ContributorRole>` |
  `<UnnamedPersons>08</UnnamedPersons>` |
  `<AlternativeName>` |
  `<NameType>04</NameType>` |
  `<PersonName>Amina Qhanna</PersonName>` |
  `</AlternativeName>` |
  `</Contributor>` |

  using short tags |
  --- | ---
  `<contributor>` |
  `<b034>3</b034>` |
  `<b035>E07</b035>` | Read by
  `<b249>08</b249>` | Synthesized voice based on real voice actor
  `<alternativename>` |
  `<x414>04</x414>` | Real name
  `<b036>Amina Qhanna</b036>` |
  `</alternativename>` |
  `</contributor>` |

  This type of synthesized voice based directly on (trained on) the voice of a real person is sometimes known as a ‘cloned’ voice or (where properly licensed) an authorized voice replica.
  Other elements of a contributor name – including for example a Name identifier or contributor biography – can be included with the Alternative name.
  Synthesized voices not based on a real voice may also be specified, using Unnamed persons codes 05–07. These should not have an associated Alternative name, unless to specify some fictional character name or ‘brand name’ for a particular voice (eg Google’s Archie or Santiago auto-narration voices).

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, use of an alternative script, 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.

Another potential use of <AlternativeName> is when a contributor chooses to change name as part of a broader change of identity, for example by transitioning their gender, rejecting a ‘slave name’ or ‘deadname’, or taking a new name as a result of religious conversion. Publishers are increasingly adopting policies on this, covering whether existing books are reissued with the new identity, whether new books should also carry details of the previous identity, and how changes should be reflected in the metadata. One option for the metadata which maximizes discoverability, notifies trading partners of the changes and enables continuity within metadata records is that the Product records for existing books are updated to add the new identity as an Alternative name, and that new books list the old identity as an Alternative name. However, given the sensitive nature of such changes, publisher’s policies rightly focus on the consent of the contributor, and this approach to metadata updates may not always be appropriate.

While the primary contributor name (in P.7.9 to P.7.20) should generally 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.

  updated metadata for a pre-existing book published before a gender transition
  using Reference names |
  --- | ---
  `<Contributor>` |
  `<ContributorRole>A01</ContributorRole>` |
  `<PersonNameInverted>Morris, James</PersonNameInverted>` |
  `<NamesBeforeKey>James</NamesBeforeKey>` |
  `<KeyNames>Morris</KeyNames>` |
  `<AlternativeName>` |
  `<NameType>06</NameType>` |
  `<PersonNameInverted>Morris, Jan</PersonNameInverted>` |
  `<NamesBeforeKey>Jan</NamesBeforeKey>` |
  `<KeyNames>Morris</KeyNames>` |
  `</AlternativeName>` |
  `</Contributor>` |

  using Short tags |
  --- | ---
  `<contributor>` |
  `<b035>A01</b035>` |
  `<b037>Morris, James</b037>` |
  `<b039>James</b039>` |
  `<b040>Morris</b040>` |
  `<alternativename>` |
  `<x414>06</x414>` | Later name
  `<b037>Morris, Jan</b037>` |
  `<b039>Jan</b039>` |
  `<b040>Morris</b040>` |
  `</alternativename>` |
  `</contributor>` |

  metadata for a new book published after a gender transition
  using Reference names |
  --- | ---
  `<Contributor>` |
  `<ContributorRole>A01</ContributorRole>` |
  `<PersonNameInverted>Morris, Jan</PersonNameInverted>` |
  `<NamesBeforeKey>Jan</NamesBeforeKey>` |
  `<KeyNames>Morris</KeyNames>` |
  `<alternativename>` |
  `<NameType>04</NameType>` |
  `<PersonNameInverted>Morris, James</PersonNameInverted>` |
  `<NamesBeforeKey>James</NamesBeforeKey>` |
  `<KeyNames>Morris</KeyNames>` |
  `</alternativename>` |
  `</Contributor>` |

  using Short tags |
  --- | ---
  `<contributor>` |
  `<b035>A01</b035>` |
  `<b037>Morris, Jan</b037>` |
  `<b039>Jan</b039>` |
  `<b040>Morris</b040>` |
  `<alternativename>` |
  `<x414>04</x414>` | Earlier name
  `<b037>Morris, James</b037>` |
  `<b039>James</b039>` |
  `<b040>Morris</b040>` |
  `</alternativename>` |
  `</contributor>` |

  Given the importance of consent, the approach above may not be acceptable in cases of complete rejection of the former identity (a ‘deadname’).

  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, personal contributor names are generally not ‘in’ a particular language. However, names can still be expressed in different scripts – فيودور دوستويفسكي and Фёдор Достоевский and Fyodor Dostoyevsky. So while <BiographicalNote> may carry a language attribute (see below), <PersonName> more frequently 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.

  There is an acknowledged inconsistency between provision of the ‘same’ corporate name in multiple languages by repetition of <CorporateName> and provision of the ‘same’ personal names in multiple scripts via <AlternativeName>. This may be addressed in a future revision of ONIX.

  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.

  translated version of the primary name (alternative version)
  using Reference names |
  --- | ---
  `<Contributor>` |
  `<ContributorRole>A01</ContributorRole>` |
  `<CorporateName language="fre">Régie autonome des transports parisiens</CorporateName>` |
  `<AlternativeName>` |
  `<NameType>05</NameType>` |
  `<CorporateName language="eng">Autonomous Parisian Transportation Administration</CorporateName>` |
  `</AlternativeName>` |
  `</Contributor>` |

  using Short tags |
  --- | ---
  `<contributor>` |
  `<b035>A01</b035>` |
  `<b047 language="fre">Régie autonome des transports parisiens</b047>` | RATP
  `<alternativename>` |
  `<x414>05</x414>` | Translation of primary name
  `<b047 language="eng">Autonomous Parisian Transportation Administration</b047>` | RATP translated into English
  `</alternativename>` |
  `</contributor>` |

  Where an organization’s name is officially specified in multiple languages, and particularly when it is listed in multiple languages on the book itself, repetition of <CorporateName> is preferred to use of <AlternativeName> (see above example with World Health Organization / Organisation mondiale de la santé). The <AlternativeName> method is preferred when the translated name is not an official name and not on the book itself. It is good practice to label both the primary name and any translated alternatives with the language attribute. <AlternativeName> should also be used for former corporate names etc.

##### 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>` |
  `<AffiliationIdentifier>` |
  `<AffiliationIDType>40</AffiliationIDType>` |
  `<IDValue>052gg0110</IDValue>` |
  `</AffiliationIdentifier>` |
  `<AffiliationIdentifier>` |
  `<AffiliationIDType>16</AffiliationIDType>` |
  `<IDValue>0000000419368948</IDValue>` |
  `</AffiliationIdentifier>` |
  `<Affiliation>School of Geography and the Environment, University of Oxford</Affiliation>` |
  `</ProfessionalAffiliation>` |
  `<ProfessionalAffiliation>` |
  `<ProfessionalPosition>Professor of Social Geography</ProfessionalPosition>` |
  `<AffiliationIdentifier>` |
  `<AffiliationIDType>40</AffiliationIDType>` |
  `<IDValue>027m9bs27</IDValue>` |
  `</AffiliationIdentifier>` |
  `<Affiliation>Institute of Social Change, Manchester University</Affiliation>` |
  `</ProfessionalAffiliation>` |

  using Short tags |
  --- | ---
  `<professionalaffiliation>` |
  `<b045>Emeritus Professor of Social Geography</b045>` |
  `<affiliationidentifier>` |
  `<x580>40</x580>` | ROR
  `<b244>052gg0110</b244>` | University of Oxford
  `</affiliationidentifier>` |
  `<affiliationidentifier>` |
  `<x580>16</x580>` | ISNI
  `<b244>0000000419368948</b244>` | University of Oxford
  `</affiliationidentifier>` |
  `<b046>School of Geography and the Environment, University of Oxford</b046>` |
  `</professionalaffiliation>` |
  `<professionalaffiliation>` |
  `<b045>Professor of Social Geography</b045>` |
  `<affiliationidentifier>` |
  `<x580>40</x580>` | ROR
  `<b244>027m9bs27</b244>` | University of Manchester
  `</affiliationidentifier>` |
  `<b046>Institute of Social Change, Manchester University</b046>` |
  `</professionalaffiliation>` |

Affiliation identifiers help remove ambiguity in naming of affiliations – there is an Institute for Social Change within the University of Hobart, Tasmania, as well as a similarly-named institute in Manchester, England. In this case, two identifiers are provided for the University of Oxford, and an ISNI could also be added for the University of Manchester.

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

1. <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;
2. 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 &lt;. 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 XSD schema will not validate the structure of the HTML, so some other method to check the HTML is correct HTML is required;
3. 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;
   - a major difference between HTML and XHTML – in HTML, closing </p> and </li> tags are optional, whereas they are mandatory in XHTML;
   - one other very minor between HTML and XHTML – <br> (without the slash) is recommended in HTML contexts, but <br /> is mandatory in XHTML;
   - if your HTML uses only lower case tags (ie <p> and not <P>), if you use <br /> (with the /), and if optional </p> and </li> tags are never omitted, then it is likely that your HTML can be treated as XHTML;
4. 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 or XSD schema will also validate the structure of the XHTML;
5. whether HTML or XHTML, it is best practice to use only a small selection of simple tags – <p>, <br /> (or just <br> in HTML), <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;
6. do not include headings, tables, links, images, etc, or obsolete HTML tags such as <font>;
7. and do not use (X)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;
8. 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>;
9. do not include named character entities (eg &hellip;, &ndash; or &ouml;) in the HTML or XHTML (they aren’t valid in either ONIX 3.1 or 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;
10. if the & and < characters are supposed to appear in the text itself – not as part of the HTML markup – replace them with &amp; and either &lt; or &#60; (use &#60; if you’re using the escaping method with HTML – and be prepared for the occasional issue);
11. 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:

- a missing textformat attribute;
- an inconsistent mix of some CDATA, some escaped markup within the same data element – it might start with <![CDATA[&lt;p>… or something similar;
- &gt; – escaping > is neither necessary nor recommended;
- going beyond the simple set of recommended markup tags in 5. above, for example by including the <u> tag for underline – this isn’t a valid tag with XHTML in ONIX, and is not recommended in HTML – or an <h1> tag for a heading;
- using <br /><br /> when what you want is a new paragraph – use proper <p> tags;
- something like &amp;ouml; – double-escaping of named character entities – is poor practice for two separate reasons;
- unnecessary use of CDATA for data elements that do not (and possibly cannot) 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, and to reliance on style attributes and stylesheets that cannot be interpreted properly by 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 within the text of the note 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 (will not usually display as two paragraphs) |
  --- | ---
  `<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 <i>The Name Of The Rose</i> and <i>Foucault’s Pendulum</i>, is one of the world’s bestselling novelists.</p><p>As well as novels, he also writes children’s books and academic works.</p></b044>` | XHTML markup should ensure paragraphs remain separate as data is processed by the recipient
  improved, semantically richer XHTML markup |
  `<b044 textformat="05"><p>Umberto Eco, professor of semiotics at the University of Bologna, and author of <cite>The Name Of The Rose</cite> and <cite>Foucault’s Pendulum</cite>, is one of the world’s bestselling novelists.</p><p>As well as novels, he also writes children’s books and academic works.</p></b044>` |

  Compare the ‘improved’ example with the previous examples, and note the use of <cite> instead of <i> or <em>. By default, the <cite> XHTML tag has the same typographic effect as <i> or <em> – it italicizes the titles of the two books – but the markup is semantically richer. Modern web practice stresses the value of such semantic markup.

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

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

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

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

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

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

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

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

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

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

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

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

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

  In ONIX 3.1, where markup is used in an element with a length limit, it is not included in any character count. This is a change from earlier releases of ONIX.

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

  embedding HTML markup
  using Reference names – HTML in CDATA option |
  --- | ---
  `<BiographicalNote textformat="02"><![CDATA[<p>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.<p>As well as novels, he also writes children’s books and academic works.</p>]]></BiographicalNote>` |
  escaped HTML option |
  `<BiographicalNote textformat="02">&lt;p>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.&lt;p>As well as novels, he also writes children’s books and academic works.&lt;/p></BiographicalNote>` |

  using Short tags – HTML in CDATA option |
  --- | ---
  `<b044 textformat="02"><![CDATA[<p>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.<p>As well as novels, he also writes children’s books and academic works.</p>]]></b044>` | Enclose HTML within CDATA
  escaped HTML option |
  `<b044 textformat="02">&lt;p>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.&lt;p>As well as novels, he also writes children’s books and academic works.&lt;/p></b044>` | Replace < character with &lt; (and avoid also replacing > with &gt; or ‘double-escaping’ other characters)

  The CDATA method is strongly preferred over escaped HTML, though neither is a best practice and XHTML (without either CDATA or escaping of the markup) is preferred to both. HTML markup should be limited to a similar set of simple tags as XHTML – and also limited to those data elements where XHTML is an option. CDATA should never be used except to embed HTML markup.

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

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

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

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

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

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

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

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

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

  providing personal identity details (with the involvement of the contributor)
  using Reference names |
  --- | ---
  `<BiographicalNote textformat="05"><p><strong>ALOK</strong> (they/them) is an internationally acclaimed writer, performer, and public speaker. As a mixed-media artist their work explores themes of trauma, belonging, and the human condition. They are the author of <cite>Femme In Public</cite>, <cite>Beyond the Gender Binary</cite> and <cite>Your Wound/My Garden</cite>. They are the creator of #DeGenderFashion: a movement to degender fashion and beauty industries and have been honored as one of HuffPo’s Culture Shifters, NBC’s Pride 50, and Business Insider’s Doers. Over the past decade they have presented at more than 600 venues in 40 countries.</p></BiographicalNote>` |

  using Short tags |
  --- | ---
  `<b044 textformat="05"><p><strong>ALOK</strong> (they/them) is an internationally acclaimed writer, performer, and public speaker. As a mixed-media artist their work explores themes of trauma, belonging, and the human condition. They are the author of <cite>Femme In Public</cite>, <cite>Beyond the Gender Binary</cite> and <cite>Your Wound/My Garden</cite>. They are the creator of #DeGenderFashion: a movement to degender fashion and beauty industries and have been honored as one of HuffPo’s Culture Shifters, NBC’s Pride 50, and Business Insider’s Doers. Over the past decade they have presented at more than 600 venues in 40 countries.</p></b044>` |

  Statements of personal identity – of gender, of race, of ethnicity etc – should be included in the Biographical note only with the involvement or at least the permission of the contributor themselves.

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

  Issues of contributor privacy can be important, and Contributor place relator codes 04 or 08 may be inappropriate – particularly with very specific Location names. The less specific code 11 may be a better way of indicating eligibility for national, regional or local marketing programs and promotions.

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 an edited volume containing the proceedings of a conference, a book linked to an artistic event, or a program 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

When the product is related to or about an event such as an academic conference, a distinct artistic exhibition or major sporting fixture, <Event> metadata can enable linking to other products about the same event, boosting discoverability and providing an opportunity for more integrated merchandising of a range of relevant products.

The <Event> composite specifies an event related to a product. If used, the composite:

- must specify the relationship between the product and the event;
- must include the event name;
- should include an acronym or other short name, if such a shortened name is commonly used for the event;
- should include the event date(s) and location.

A website for the event can also be useful for potential readers seeking more details of the event itself.

Contrast <Event> with <PromotionalEvent> in Block 7 – put at its simplest, the former is for books about events, the latter is for events about books.

Note that in earlier versions of ONIX this Group contained the <Conference> composite, but this has been replaced by the compatible <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>` |

  Cave temples of Dunhuang exhibition
  using Reference names |
  --- | ---
  `<Event>` |
  `<EventRole>22</EventRole>` |
  `<EventName language="eng">Cave Temples of Dunhuang: Buddhist art on China’s Silk Road</EventName>` |
  `<EventName language="chi">敦煌莫高窟 中國絲綢之路上的佛教藝術</EventName>` |
  `<EventDate dateformat="06">2016050720160904</EventDate>` |
  `<EventPlace>Getty Center, Los Angeles, USA</EventPlace>` |
  `<EventSponsor>` |
  `<CorporateName>The Robert H. N. Ho Family Foundation</CorporateName>` |
  `</EventSponsor>` |
  `<EventSponsor>` |
  `<CorporateName>East West Bank</CorporateName>` |
  `</EventSponsor>` |
  `<!-- further sponsors omitted for brevity -->` |
  `<Website>` |
  `<WebsiteRole>00</WebsiteRole>` |
  `<WebsiteDescription>Web page for exhibition</WebsiteDescription>` |
  `<WebsiteLink>https://www.getty.edu/​research/​exhibitions_events/​exhibitions/​cave_temples_dunhuang/​index.html</WebsiteLink>` |
  `</Website>` |
  `<Website>` |
  `<WebsiteRole>00</WebsiteRole>` |
  `<WebsiteDescription>Mogao Grottoes conservation project</WebsiteDescription>` |
  `<WebsiteLink>https://www.getty.edu/​projects/​wall-paintings-​conservation-​mogao-grottoes/</WebsiteLink>` |
  `</Website>` |
  `</Event>` |

  using Short tags |
  --- | ---
  `<event>` |
  `<x515>22</x515>` | Book is guide to the event
  `<x516 language="eng">Cave Temples of Dunhuang: Buddhist art on China’s Silk Road</x516>` | Title of exhibition
  `<x516 language="chi">敦煌莫高窟 中國絲綢之路上的佛教藝術</x516>` | …in two languages
  `<x520 dateformat="06">2016050720160904</x520>` | 7 May–4 Sept 2016
  `<x521>Getty Center, Los Angeles, USA</x521>` |
  `<eventsponsor>` | Exhibition sponsors
  `<b047>The Robert H. N. Ho Family Foundation</b047>` |
  `</eventsponsor>` |
  `<eventsponsor>` |
  `<b047>East West Bank</b047>` |
  `</eventsponsor>` |
  `<!-- further sponsors omitted for brevity -->` |
  `<website>` | Exhibition website
  `<b367>00</b367>` |
  `<b294>Exhibition web page</b294>` |
  `<b295>https://www.getty.edu/​research/​exhibitions_events/​exhibitions/​cave_temples_dunhuang/​index.html</b295>` |
  `</website>` |
  `<website>` | Conservation project website
  `<b367>00</b367>` |
  `<b294>Mogao Grottoes conservation project</b294>` |
  `<b295>https://www.getty.edu/​projects/​wall-paintings-​conservation-​mogao-grottoes/</b295>` |
  `</website>` |
  `</event>` |

  The example above includes the event name in two languages, and credits two of the sponsors of the 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 (that are manifestations of the same work);
  - facsimile, special, international or airside, 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 the product is a manifestation of a different but closely-related derived work);
  - abridged, illustrated, annotated, enlarged, revised, enhanced, student and teacher’s editions, where editions generally 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 ‘parent works’;
  - reprints or reissues that incorporate only trivial 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 therefore are always a manifestation of a different work);
  - in <EditionVersionNumber>, minor revisions (of a digital product) that denote mostly technical fixes or minor updates that do not significantly revise the content. This is usually treated as the same product as the earlier version number.

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.

In many sectors of publishing – among them textbooks, academic and scholarly works, manuals, directories and reference material – works are regularly revised to create new and often numbered or dated editions. It is critical for end-customers to be able to distinguish between older and newer editions to ensure they purchase the most up to date, or the correct specific edition. In other sectors, edition information conveys some special feature – large print, for example, or a teacher’s edition that contains the answers to questions in the student’s edition – which is integral to the buying decision.

Because of the long history of abridged audio content, audio products (including digital audio) should always include an Edition type of either ABR or UBR to avoid uncertainty;

It is also good practice to specify when there is no particular edition information, using <NoEdition>, particularly for non-fiction when such information might be expected.

The Product record:

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

Common issues in Group P.9:

- an edition number of 1 should almost always be omitted, unless there is a risk of confusion – for example when the first and second editions are available in the market at the same time, or when the first edition is made available again as a facsimile first edition;
- use of ‘enhanced’ edition for e‑publications including video and audio material, when there is no matching basic or unenhanced edition;
- uncertainty over the abridged nature of an audio product;
- confusion between a ‘digital original’ or ‘paperback original’ (both edition types and permanent attributes of the product), and a ‘digital exclusive’ (ie the non-availability of any print version) which can be flagged with a digital exclusivity statement in <TextContent>, or a product that is currently only available as a paperback. These are not necessarily anything more than temporary attributes of the product.

  Abridged edition
  using Reference names |
  --- | ---
  `<EditionType>ABR</EditionType>` |

  using Short tags |
  --- | ---
  `<x419>ABR</x419>` |

  Ⅳth edition
  using Reference names |
  --- | ---
  `<EditionNumber>4</EditionNumber>` |
  `<EditionStatement>Ⅳth edition</EditionStatement>` |

  using Short tags |
  --- | ---
  `<b057>4</b057>` |
  `<b058>Ⅳth 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.
  Data recipients – particularly retailers – should take care with NUM or UNN editions, as the limited number of copies available may not be sufficient to fulfill pre-orders, leading to customer dissatisfaction.

##### P.9.1 Edition type code

Most edition type codes from List 21 are self-explanatory. However, some imply the existence (or previous or potential existence) of other editions. An illustrated or enhanced edition is not merely a book with illustrations or ‘enhancements’ – they imply a non-illustrated or un-enhanced edition. Do not use these Edition type codes simply to specify the type of content. Use codes ILL (illustrated) or ENH (enhanced, for digital products) only to avoid doubt.

The same applies to codes ABR (abridged) and UBR (Unabridged) – and in particular with audio products, always use either UBR or ABR when doubt might be expected to exist. Because so many audiobooks on CD are abridged, it is good practice with an unabridged product to specify 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 in the belief it indicates ‘digital only’ or ‘digital exclusive’. ‘Digital original’ is a permanent feature of a product – if the digital version was published before a physical version, it remains the original even after publication of the physical version, but is no longer digital exclusive. For products that are true digital exclusives, see Group P.14. and <TextType> code 21 – and note that any exclusivity statement may need to be updated or deleted in the future.

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 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 (Ⅱ, Ⅲ, Ⅳ…) 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

In many countries, there is a market for books in multiple languages – in Spanish or French within primarily-Anglophone North America, books in English in many countries, and books that cater to the language preferences of minority populations, immigrants and diasporas. In an increasingly international supply chain, it's imperative that purchasers are aware of the language of the content of the book.

This information can be supplied using a default in the message Header, but this default is deprecated and it is best practice to omit the default and provide language data explicitly in every Product record.

The <Language> composite should be used:

- to specify the language of the main text used in the product;
- for works in translation, to specify the original language from which the text has been translated;
  - ideally, the translator should be named as a contributor in Group P.7;
- most particularly though not exclusively with audio, use a <CountryCode> for language variants (eg codes ES, MX and either AT or UY for Castilian, Mexican and Rioplatense Spanish);
- for bilingual and multilingual books of one form or another, specify the two or more languages, and make use of the various Language role codes available to clarify the role each language plays;
  - set the Edition type appropriately with codes BLP, BLL and MLL;

Common issues in Group P.10:

- for phrasebooks, language studies and (unidirectional) bilingual dictionaries, confusion over the language a book is in, and the language it is about. For the latter, use <Subject>;
- language teaching or learning material is often in a language that’s distinct from the language of instruction. Use Language role code 14 to clarify the language being taught or learned;
- missing language variety or script information, where this is important (for example, Latin-American varieties of Spanish, Québécois French etc, traditional or simplified script for Chinese, Latin or Cyrillic for several central-Asian languages).

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. Note that where a translator is listed as a contributor in Blocks 5 or 6, the language they translate from can be listed there too.

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 – at least not with Language role code 01. The key question is ‘would the book be useful to a reader of the other language?’ However, use of <LanguageRole> code 15 (or codes 12–14, whichever is appropriate) can make the limited role of the second language evident.

But if a product contains significant content in more than one language (eg a bidirectional 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 bidirectional 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). It could then specify English as the target language of teaching or learning using a second <Language> composite with <LanguageRole> code 14. 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 with Language role code 01. If it’s about a language, it should not – although the secondary language may be indicated using some subject classification schemes or another Language role code. 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. Kazakh has switched between Arabic, Cyrillic and Latin scripts within the last 100 years.) 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>` |
  `<Language>` |
  `<LanguageRole>14</LanguageRole>` |
  `<LanguageCode>jpn</LanguageCode>` |
  `</Language>` |

  using Short tags |
  --- | ---
  `<language>` |
  `<b253>01</b253>` | Language of text
  `<b252>ger</b252>` | German
  `</language>` |
  `<language>` |
  `<b253>14</b253>` | Language of teaching / learning
  `<b252>jpn</b252>` | Japanese
  `</language>` |

  Where possible, also use <Subject> to specify Japan and/or Japanese – this can be done in Thema, but not necessarily in other subject category schemes. The book is (largely) in German and is intended for readers of German, while Japan and Japanese is the subject and the target language of teaching or learning.

  There many circumstances where <Subject> should be used without using Language role code 14 – a book about the Japanese language itself – its grammar, phonology or history – might be written in German, without there being any intent to teach or learn the language.

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

  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.
  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. These should be used in preference to chi, and chi should be reserved for Chinese languages other than Mandarin and Cantonese.
  Although code chi denotes a macrolanguage, there are many variants of ‘Chinese’ that are outside of this group. The wider Chinese language family – less closely related – can be specified using the zhx code that covers all Sinitic languages.

  multilingual book with parallel text in three languages
  using Reference names |
  --- | ---
  `<EditionType>MLL</EditionType>` |
  `<Language>` |
  `<LanguageRole>06</LanguageRole>` |
  `<LanguageCode>ger</LanguageCode>` |
  `</Language>` |
  `<Language>` |
  `<LanguageRole>07</LanguageRole>` |
  `<LanguageCode>eng</LanguageCode>` |
  `</Language>` |
  `<Language>` |
  `<LanguageRole>07</LanguageRole>` |
  `<LanguageCode>fre</LanguageCode>` |
  `</Language>` |

  using Short tags |
  --- | ---
  `<x419>MLL</x419>` | Multilingual edition
  `<language>` |
  `<b253>06</b253>` | Original language of text
  `<b252>ger</b252>` | German
  `</language>` |
  `<language>` |
  `<b253>07</b253>` | …translated into English
  `<b252>eng</b252>` |
  `</language>` |
  `<language>` |
  `<b253>07</b253>` | …and French
  `<b252>fre</b252>` |
  `</language>` |

  Note the use of Language role codes 06 for the original language and 07 for the two translated languages. Use of code 01 on multiple languages is also acceptable, either when the relationship between the languages is unknown, or where they were written simultaneously.
  For a bilingual book, the BLL Edition type should be used.

  audiobook in Spanish
  using Reference names |
  --- | ---
  `<Language>` |
  `<LanguageRole>08</LanguageRole>` |
  `<LanguageCode>spa</LanguageCode>` |
  `</Language>` |

  using Short tags, Neutral Latin American Spanish |
  --- | ---
  `<language>` |
  `<b253>08</b253>` | Language of audio track
  `<b252>qls</b252>` | Neutral Latin American Spanish
  `</language>` |

  For simple audiobooks, Language role 01 (Language of text) and Language role 08 (Language of audio track) should be treated as synonymous.
  <ScriptCode> is clearly not relevant for audio products, and also note that ‘Neutral Latin American Spanish’ cannot be used with textual material – it is a purely spoken variant of Spanish.

There is a small range of pictorial ‘languages’ in List 74 – for example Bliss, Widgit or Pictorial Communication System (PCS) symbols. These can be treated as languages or as scripts. The best practice is dependent on whether these symbols are accompanied by conventional text in the product. When used to support or augment conventional text – symbols plus textual equivalents of the symbols – they should be treated as a script (see List 121). There would in this case be two <Language> composites, specifying the same language but different scripts. When the symbols are used alone, without accompanying conventional text, they should be treated as a language in a single <Language> composite.

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

Consumers often judge a book by its length – and while it’s self-evident when the physical book is on the shelf, this information needs to be provided numerically in the metadata if the book is sold online, or is a digital product.

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.

Common issues in Group P.11:

- mismatches between the product form and the extent – for example providing a fixed page extent for a reflowable e‑publication;
- in the <AncillaryContent> composite, mixing production-led and editorially-led ancillary content counts.

  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. It does not apply to many non-book products, although there are specialized Extent type codes that apply for example to packs of cards. 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 <IllustrationsNote>, descriptive text about the product that might be included in the <TextContent> composite within Block 2: Marketing collateral. <IllustrationsNote> 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, or more likely the multiple subject categories it falls into. This is because the subject of a book is the key to retailer’s stock planning, to libraries’ collection management, and to end purchaser discoverability – physical retailers rely on subject categories for shelving and merchandising, online retailers for sitewide structure, for Browse by subject and for Search. Statistical market analysis relies on subject metadata too.

There are many subject classification and category schemes, often endemic to a particular territory: none is both commercially-focused and globally-accepted – although this is the explicit aim of EDItEUR’s Thema subject scheme, and its growing global adoption is gradually reducing 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 subject scheme or controlled vocabulary used:

- the data should conform to the best practices established for that scheme;
- if classification within a particular scheme makes use of multiple categories or category codes, and therefore more than one <Subject> composite, one should be flagged as being the primary category for that scheme with the <MainSubject/> empty element.

In addition, the subject matter, theme or content should be indicated using a list of 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 (eg both PB, Mathematics, and PBKJ, Differential calculus in the Thema scheme);
- misapplication of <MainSubject/>, for example to indicate a broad general category – it should be used to indicate which of several specific codes is the most appropriate;
- 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’ or to gain a spurious ‘bestseller’ status in some rarely-used and irrelevant category;
- 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);
- provision of multiple subject codes in a single <SubjectCode> data element – each code should have its own repeat of <Subject>;
- in contrast, keywords supplied individually, each in its own repeat of <SubjectHeadingText> – they should be combined into a single semicolon-separated list;
- excessively long or repetitive lists of keywords. Around 250 characters is the practical maximum;
- 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 Thema and BISAC subject classification schemes, plus keywords
  using Reference names |
  --- | ---
  `<Subject>` |
  `<MainSubject/>` |
  `<SubjectSchemeIdentifier>93</SubjectSchemeIdentifier>` |
  `<SubjectSchemeVersion>1.6</SubjectSchemeVersion>` |
  `<SubjectCode>AMX</SubjectCode>` |
  `</Subject>` |
  `<Subject>` |
  `<SubjectSchemeIdentifier>99</SubjectSchemeIdentifier>` |
  `<SubjectSchemeVersion>1.6</SubjectSchemeVersion>` |
  `<SubjectCode>6AF</SubjectCode>` |
  `</Subject>` |
  `<Subject>` |
  `<SubjectSchemeIdentifier>94</SubjectSchemeIdentifier>` |
  `<SubjectSchemeVersion>1.6</SubjectSchemeVersion>` |
  `<SubjectCode>1DDU-GB-E</SubjectCode>` |
  `</Subject>` |
  `<Subject>` |
  `<MainSubject/>` |
  `<SubjectSchemeIdentifier>96</SubjectSchemeIdentifier>` |
  `<SubjectSchemeVersion>1.6</SubjectSchemeVersion>` |
  `<SubjectCode>3MNQ</SubjectCode>` | c. 1850–1899
  `</Subject>` |
  `<Subject>` |
  `<SubjectSchemeIdentifier>96</SubjectSchemeIdentifier>` |
  `<SubjectSchemeVersion>1.6</SubjectSchemeVersion>` |
  `<SubjectCode>3MPBA</SubjectCode>` | c. 1900–1909
  `</Subject>` |
  `<Subject>` |
  `<SubjectSchemeIdentifier>96</SubjectSchemeIdentifier>` |
  `<SubjectSchemeVersion>1.6</SubjectSchemeVersion>` |
  `<SubjectCode>3MPBF</SubjectCode>` | c. 1910–1919
  `</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>93</b067>` | Thema subject category
  `<b068>1.6</b068>` | (latest as of Oct 2024)
  `<b069>AMX</b069>` | History of architecture
  `</subject>` |
  `<subject>` |
  `<b067>99</b067>` | Thema style qualifier
  `<b068>1.6</b068>` |
  `<b069>6AF</b069>` | Arts and Crafts
  `</subject>` |
  `<subject>` |
  `<b067>94</b067>` | Thema place qualifier
  `<b068>1.6</b068>` |
  `<b069>1DDU-GB-E</b069>` | England
  `</subject>` |
  `<subject>` |
  `<b067>96</b067>` | Thema time period qualifier
  `<b068>1.6</b068>` |
  `<b069>3MNQ-NL-B</b069>` | Belle Époque (c. 1871–1914)
  `</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 category
  `<b068>2009</b068>` | (new versions released annually)
  `<b069>ARC005070</b069>` | Architecture / History / Modern (late 19th Century to 1945)
  `</subject>` |
  `<subject>` |
  `<b067>10</b067>` | BISAC subject category
  `<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. Note that Thema qualifiers each count as separate schemes in this context (see the <MainSubject> flag for multiple time period qualifiers in the Reference names example).
  Note also in Thema the use of a national extension 3MNQ-NL-B (Belle Époque) in the Short tag example to cover a time period equivalent to three time period qualifiers used in the Reference names example. While the national extension is labelled ‘Belle Époque’ and is apparently Dutch in origin, its meaning does not extend beyond the years themselves. Despite it referencing a different artistic movement, the years bracket the Arts and Crafts movement accurately.
  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).
  The BIC subject category scheme will be obsoleted in February 2024. BIC (the organization) recommends current users of the BIC scheme to adopt Thema as soon as possible.

  using the 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; Finistère; Brittany; Musée des Beaux Arts; Post-impressionism; Symbolism</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; Finistère; Brittany; Musée des Beaux Arts; Post-impressionism; Symbolism</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, multilingual subject classification for a global book trade. For further details, see the EDItEUR website. It is available in around 25 languages including Arabic, Danish, English, Finnish, French, German, Italian, Japanese, Korean, Polish, Portuguese, Spanish, Norwegian, Swedish, Turkish, Welsh, 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 (obsolete from Feb 2024)
  BISAC | 2025 | 2024, 2011, 2010, 2.9, 2.6 etc
  CCE | 2.0 |
  Thèmes CLIL | 2024 | 2014, 2010, 2006 etc
  Dewey | 23 | 22, 21 etc
  Thema | 1.6 | 1.4, 1, 1.2 etc
  Warengruppen-Systematik neu | 2.1 | 2.0

It is common to provide two, three or more subject classifications from a single scheme. Where classification schemes allow multiple classifications or categories 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).

<MainSubject/> is sometimes misused to indicate a broad category where a detailed category is also supplied, for example Thema code Y as the Main subject and YFJ as an additional subject. ‘Main’ does not mean ‘broad’ – it should be used to indicate the most relevant detailed category.

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 math’ (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 math 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 math’ and ‘any books about all aspects of math’.

  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 most ONIX recipients will not accept that many – they may truncate the list at 250 characters (or even fewer), or accept only a certain number of words, so put your ‘best’ keywords first. Evidence shows there is little practical value in long lists of more than around 25–30 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 / Math
  `</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 math 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, with additional Thema qualifier |
  --- | ---
  `<subject>` |
  `<b067>86</b067>` | GeoNames ID
  `<b069>2260535</b069>` |
  `<b070>Brazzaville​</b070>` |
  `</subject>` |
  `<subject>` |
  `<b067>94</b067>` | Thema geographical qualifier
  `<b068>1.3</b068>` |
  `<b069>1HFJC-CG-A</b069>` |
  `<b070>Brazzaville​</b070>` |
  `</subject>` |

  With coded schemes such as GeoName IDs or Thema, providing the heading text is optional – but unnecessary in the case of well-known schemes like Thema. Note also that Thema qualifiers cannot be used alone – there must be an accompanying Thema subject code that the qualifier qualifies.

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) German or English – so <Subject> would specify Japanese, and <Language> would specify German or 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 0000 0003 6864 5684 and 0000 0001 2144 1305.

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.

Consumers, educators, librarians and specialist retailers select books based on their intended audience – whether that be ‘a book for a seven year-old’, or a textbook for grade 7, a Masters-level treatise or a book suitable for someone with a reading age of 7. For many bricks-and-mortar retailers, there’s a primary divide in their shelving scheme between books for adults and children.

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 schemes incorporate limited audience details, for example by having categories for ‘young adult’ or children’s books.) 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 where necessary, 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. However, in many territories, using the ONIX audience codes will be sufficient.

Some books whose content is sensitive or potentially offensive might need special treatment. Trade titles aimed at the general adult audience should ideally include an ONIX Adult audience rating, to allow retailers to treat those products with potentially offensive or extreme content appropriately.

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 or even worse, 0–99 – is positively misleading and unlikely to be useful. Broad age ranges do not increase discoverability: parents and teachers need precise and relevant age ranging information, and audience ranges for young children should specify a narrow range of interest and reading ages. Appropriate ranges tend to get narrower as the target readership gets younger;
- 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>` |

  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, or when the publisher wishes to make it clear the content is inoffensive. 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 child or teenage audience (termed juvenile and ‘young adult’ audiences in codelists before Issue 55) – 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.

  book coded for multiple audiences, with a <MainAudience> flag
  using Reference names |
  --- | ---
  `<Audience>` |
  `<MainAudience/>` |
  `<AudienceCodeType>01</AudienceCodeType>` |
  `<AudienceCodeValue>01</AudienceCodeValue>` |
  `</Audience>` |
  `<Audience>` |
  `<AudienceCodeType>01</AudienceCodeType>` |
  `<AudienceCodeValue>03</AudienceCodeValue>` |
  `</Audience>` |
  `<AudienceRange>` |
  `<AudienceRangeQualifier>17</AudienceRangeQualifier>` |
  `<AudienceRangePrecision>03</AudienceRangePrecision>` |
  `<AudienceRangeValue>15</AudienceRangeValue>` |
  `</AudienceRange>` |

  using Short tags |
  --- | ---
  `<audience>` |
  `<x583/>` | Main audience
  `<b204>01</b204>` | ONIX audience code
  `<b206>01</b206>` | Non-specialist adult audience
  `</audience>` |
  `<audience>` |
  `<b204>01</b204>` | Second ONIX audience code
  `<b206>03</b206>` | Teenage
  `</audience>` |
  `<audiencerange>` |
  `<b074>17</b074>` | Interest age in years
  `<b075>03</b075>` | From
  `<b076>15</b076>` |
  `</audiencerange>` |

  The ONIX ‘Teenage’ audience was previously termed a ‘Young adult’ audience (see the notes associated with code 03 in List 28 – the label associated with the code was clarified to ‘Teenage’, but the meaning of the code has not changed). Despite the term ‘Young adult’, it’s not a subsection of the General adult audience (code 01). As such, an audience range – giving a suitable minimum age – should be included. The example above describes a product suitable for adults and teens from about the age of 15 – but one where the main audience is adults.

  A <MainAudience/> flag should be included whenever two Audience code values with the same Audience code type are specified.

  In a similar manner, a ‘whole family’ audience should be indicated using ONIX Audience codes 01, 02 and 03 in three repeats of the <Audience> composite, possibly with a minimum age if the content of the product is unsuitable for the youngest family members.

  describing an audience using multiple audience coding schemes
  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>` |
  `<AudienceHeadingText>Middle school language learners</AudienceHeadingText>` |
  `</Audience>` |

  using Short tags |
  --- | ---
  `<audience>` |
  `<b204>01</b204>` | ONIX audience code
  `<b206>03</b206>` | Teenage
  `</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>` |
  `<x578>Middle school language learners</x578>` | Proprietary heading text
  `</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 secondary/high school education product
  using Reference names |
  --- | ---
  `<Audience>` |
  `<AudienceCodeType>01</AudienceCodeType>` |
  `<AudienceCodeValue>13</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>13</b206>` | Lower secondary/junior high (ISCED level 2)
  `</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 recommended. Use <AudienceCodeType> code 01 from List 29, and the relevant value from the ONIX Audience code list, List 28. The <Audience> composite is repeatable if there are two or more separate audiences, and if there are two <Audience> composites with the same Audience code type, one may be marked as the Main audience using the empty <MainAudience/> tag.

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 teenagers, 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. Audience ranges are not usually applied to adult audiences.

<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 old readers. 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 even younger adult subject matter, but using language that is more normally appropriate for say, an eleven-year old. The use of <AudienceRange> to express the differential between reading age and interest age is critical – particularly in education. See the extended example of a ‘high-low’ book above.

General products (not specifically educational) aimed at a children’s or teenage 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 older teens and younger adults 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.

  Potential arrangement of Audience range precision (1) and (2) – no other arrangements are valid
  Range precision 1 | Range precision 2 | Example uses
  --- | --- | ---
  Exact… | – | For Grade 7
  From… | – | For interest age 9+
  To… | – |
  From… | To… | From Grades 6 to 7

##### P.13.10 Audience description

Ideally, the intended audience for each product should be coded, to allow automated product selection, placement within a bookstore and merchandising. In a small number of cases, where a coded audience is inadequate, an additional short free text description of the audience can be used. This description is not an adequate replacement for a coded audience. The text should be strictly limited to a description of the expected readership, and should not extend to describing the product.

  description of technical audience
  using Reference names |
  --- | ---
  `<AudienceDescription textformat="05"><p>Intended for advanced metadata practitioners with extensive pre-existing knowledge of the topic</p></AudienceDescription>` |

  using Short tags |
  --- | ---
  `<b207 textformat="05"><p>Intended for advanced metadata practitioners with extensive pre-existing knowledge of the topic</p></b207>` |

#### 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 deprecated in some revisions of ONIX 3.0, but that deprecation was later 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–8 are unnecessary;
- the Notification type is 05 (a record deletion), in which case Blocks 1–8 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

Publishers expend marketing effort to reach both resellers in the trade – wholesalers, jobbers, booksellers etc – and librarians and educators with business-to-business marketing collateral, advertising and promotion. And with the continued growth on online bookselling, directly reaching out to end purchasers and readers with business-to-consumer promotion has become increasingly important. All need to be informed about the nature and content of the book, usually with at least a succinct ‘short description’ and a longer more detailed description.

However, business-to-business and business-to-consumer messaging must often be differentiated: in many cases, the style and even the content of any descriptive text differs, while both might take the form of a ‘short description’.

And as online bookselling of both physical and digital products has become more sophisticated, there’s an increasing demand for a wider range of collateral text – tables of contents, sample chapters, review snippets and so on.

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 45 words, or a maximum of 350 characters) description that might be displayed alongside the product in a list or group of search results;
  - the 350 character maximum does not include any HTML or XHTML markup characters within the short description, so the actual length of the data may be larger;
- 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, any additional cover lines (<TextType> code 37), the table of contents (<TextType> code 04, particularly valuable for non-fiction), and one or more short quotations from product reviews (<TextType> code 06). In general, each of the text types above would be aimed at the general ‘unrestricted’ Content audience, but certain types of text may be aimed at specific audiences.

In particular, text supplied for commercial reasons such as a list of key selling points is another type of short or long description – but supplied in a repeat of <TextContent> specifically aimed at the book trade using <ContentAudience> code 02.

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;
- should use a <SequenceNumber> to indicate priority if there is more than one text of a specific type (and not otherwise distinguishable by audience or language) – for example if there are several quotations from product reviews;
- 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. HTML markup is less preferred. 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. Use repeats of <TextContent> instead;
- 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 contributor’s 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 (<TextType> code 10) 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 &gt; 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 endorsement
  using Reference names |
  --- | ---
  `<TextContent>` |
  `<SequenceNumber>1</SequenceNumber>` |
  `<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>` |
  `<SequenceNumber>2</SequenceNumber>` |
  `<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>` |
  `<SequenceNumber>3</SequenceNumber>` |
  `<TextType>09</TextType>` |
  `<ContentAudience>00</ContentAudience>` |
  `<Text textformat="05"><p>‘There no better quick reference guide for UML modelers.’​</p>​</Text>` |
  `<TextAuthor>Richard Ayton</TextAuthor>` |
  `<TextSourceDescription>CEO, Universal Consulting LLP</TextSourceDescription>` |
  `</TextContent>` |

  using Short tags |
  --- | ---
  `<textcontent>` |
  `<b034>1</b034>` |
  `<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>` |
  `<b034>2</b034>` |
  `<x426>05</x426>` | Primary 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
  `<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>` |
  `<b034>3</b034>` |
  `<x426>09</x426>` | Endorsement
  `<x427>00</x427>` | For any audience
  `<d104 textformat="05"><p>‘There no better quick reference guide for UML modelers.’​</p>​</d104>` |
  `<d107>Richard Ayton</d107>` |
  `<x557>CEO, Universal Consulting LLP</x557>` |
  `</textcontent>` |

  The provided Sequence numbers are redundant in this example. They are only meaningful when there are multiple text resources of the same type – for example in the case of multiple reviews.
  The short description and endorsement could have been provided without a textformat attribute – they contain (effectively) no markup, and the default is unformatted text. However, the cover copy requires markup such as the XHTML shown to format the multiple paragraphs and bulleted list, so the attribute must be specified.
  The XHTML content in the Short tags example is formatted with extra line breaks and indented for clarity only – the unbroken XHTML in the Reference names example is exactly equivalent, except that extra white space characters (line breaks, tabs or spaces) have been added to the content of the <d104> tag. The XHTML tags and any extra white space are treated as data content by recipients, not as markup and will therefore count against any limitations on the length of text that can be stored by the recipient. As a result, the unbroken form used in the Reference example is preferred.
  Although XHTML itself allows the use of named character entities like &eacute; or &euro; (for é and €), they are not allowed within ONIX textual data with textformat 05. You can use the native characters (providing they are available in whatever encoding you declared at the top of the ONIX file) or equivalent numeric entities &#233; and &#8364; (or the hexadecimal equivalents &#xe9; or &#x20ac;).

##### Text content composite

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

##### P.14.1 Sequence number

The sequence number is a simple integer, with a sequence starting at 1 and incrementing for each additional numbered repeat of <TextContent>. It is only relevant where there are multiple repeats of <TextContent> of the same Text type and Content audience (and optionally, <Territory>): a Sequence number does not need to be added to any <TextContent> which is unique in respect to its type, audience and territory.

So for example, where there are is a single short description, two long descriptions – one aimed at a trade audience and one aimed at the consumer – plus three review extracts, a table of contents and a couple of endorsements, only the reviews and endorsements need be numbered. And they should be numbered 1–5, not 1–3 and (separately) 1–2. The numbered repeats of <TextContent> should form a single sequence.

For a recipient which can only display two reviews, this means selecting the reviews with the two lowest Sequence numbers. Recipients must assume neither the highest priority review occurs first in the XML file, nor that it carries Sequence number 1. In this example case, it could be Sequence number 3 (or even 2).

  In the example, if there were four reviews, but only three were numbered, the unnumbered review has the lowest priority. It does no harm if the short description and two long descriptions also carry Sequence numbers, and the order of various repeats of <TextContent> in the XML file carries no particular significance. A recipient should select all the reviews first, then sort them by sequence number, then choose those with the lowest sequence numbers.

##### P.14.1a 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 (with the relevant non-breaking spaces for correct French orthography), „…“ 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 review quotations are provided, the order of the quotations in the XML file is not significant. While data recipients have little reason to change the order deliberately, those that accept only a limited number may ignore those provided last – or equally, they might use those provided last. To avoid this uncertainty, the order of precedence of reviews should be indicated with a <SequenceNumber>;
  - 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 often 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 book trade audience. In these cases, a <SequenceNumber> should be included to indicate the order that the various repeats should be selected or displayed in. This would apply to text types 06, 07, 08, 09, 11, 13, 14, 18, 22, 37.

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 45 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 is technically part of the data – but the markup does not count against the 350 character limit for short descriptions. For example:

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

  contains 10 characters, not 17. But depending on details of the recipient’s system, any leading or trailing spaces may count, 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 about the same or even slightly fewer bytes for some 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 – which in turn implies the whole HTML page should be encoded using Unicode and you need to be very careful to avoid character set issues if JSON data is included in ONIX that is not itself using Unicode.

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

  The schema.org JSON syntax can be tested with Google’s Structured Data Testing Tool (https://developers.google.com/search/docs/appearance/structured-data).
  Another potential use for a JSON-LD snippet is previewing the JSON-LD accessibility metadata that can be embedded within an EPUB document.

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

  The pattern above – with Content audience code 02 – is commonly used to deliver more extensive text aimed at the book trade that consists of a list of key selling points like this:

  Exciting 96-page storybook aimed at girls and boys aged around 7–8 who are fans of the Tractor Tales TV series, written with clear, age-appropriate language.

  - Published to coincide with promotion around release of the Tractor Tales animated movie
  - Colorful imagery ties in with scenes from the movie
  - Includes activity material and puzzles with characters from the TV series and movie
  - Pocket-friendly price point for under-pressure parents

  Bullet point list of key selling points
  using Reference names |
  --- | ---
  `<!-- end-customer description not shown -->` |
  `<TextContent>` |
  `<TextType>03</TextType>` |
  `<ContentAudience>02</ContentAudience>` |
  `<Text textformat="05"><p>Exciting 96-page storybook aimed at girls and boys aged around 7–8 who are fans of the <cite>Tractor Tales</cite> TV series, written with clear, age-appropriate language.</p><ul><li>Published to coincide with promotion around release of the <cite>Tractor Tales</cite> animated movie</li><li>Colorful imagery ties in with scenes from the movie</li><li>Includes activity material and puzzles with characters from the TV series and movie</li><li>Pocket-friendly price point for under-pressure parents</li></ul></Text>` |
  `</TextContent>` |

  using Short tags |
  --- | ---
  `<!-- end-customer description not shown -->` |
  `<textcontent>` |
  `<x426>03</x426>` | (Longer) Description
  `<x427>02</x427>` | For book trade
  `<d104 textformat="05">` | XHTML split over several lines for clarity
  `<p>Exciting 96-page storybook aimed at girls and boys aged around 7–8 who are fans of the <cite>Tractor Tales</cite> TV series, written with clear, age-appropriate language.</p>` |
  `<ul>` |
  `<li>Published to coincide with promotion around release of the <cite>Tractor Tales</cite> animated movie</li>` |
  `<li>Colorful imagery ties in with scenes from the movie</li>` |
  `<li>Includes activity material and puzzles with characters from the TV series and movie</li>` |
  `<li>Pocket-friendly price point for under-pressure parents</li>` |
  `</ul>` |
  `</d104>` |
  `<textcontent>` |

  Key selling points (KSPs, sometimes loosely termed USPs or UVPs) can also be delivered in the same way as the example above, but using Text type code 11 (Feature) instead of code 03 (Long description), and similar HTML or XHTML markup.

  Key selling points can also be delivered as a sequence of individual ‘features’ of the product (targeted at the book trade with Content audience code 02), as below, and recipients should make use of these after any short or long description aimed at the book trade. Features are listed one per repeat of <TextContent>.

  However, it is also common for data senders to limit themselves to only a single feature – which they view as the one unique selling proposition (USP) or unique value proposition (UVP) of the product.

  Key selling points as a series of product features
  using Reference names |
  --- | ---
  `<!-- end-customer description not shown -->` |
  `<TextContent>` |
  `<SequenceNumber>1</SequenceNumber>` |
  `<TextType>02</TextType>` |
  `<ContentAudience>02</ContentAudience>` |
  `<Text textformat="05"><p>Exciting 96-page storybook aimed at girls and boys aged around 7–8 who are fans of the <cite>Tractor Tales</cite> TV series, written with clear, age-appropriate language.</p></Text>` |
  `</TextContent>` |
  `<TextContent>` |
  `<SequenceNumber>2</SequenceNumber>` |
  `<TextType>11</TextType>` |
  `<ContentAudience>02</ContentAudience>` |
  `<Text>Published to coincide with promotion around release of the Tractor Tales animated movie</Text>` |
  `</TextContent>` |
  `<TextContent>` |
  `<SequenceNumber>3</SequenceNumber>` |
  `<TextType>11</TextType>` |
  `<ContentAudience>02</ContentAudience>` |
  `<Text>Colorful imagery ties in with scenes from the movie</Text>` |
  `</TextContent>` |
  `. . .` |

  using short tags names, with additional new feature |
  --- | ---
  `<!-- end-customer description not shown -->` |
  `<textcontent>` |
  `<b034>1</b034>` |
  `<x426>02</x426>` | Short description
  `<x427>02</x427>` | for book trade
  `<d104 textformat="05"><p>Exciting 96-page storybook aimed at girls and boys aged around 7–8 who are fans of the <cite>Tractor Tales</cite> TV series, written with clear, age-appropriate language.</p></d104>` |
  `</textcontent>` |
  `<textcontent>` |
  `<b034>2</b034>` |
  `<x426>11</x426>` | Feature
  `<x427>02</x427>` | for book trade
  `<d104>Published to coincide with promotion around release of the Tractor Tales animated movie</d104>` |
  `</textcontent>` |
  `<textcontent>` |
  `<b034>3</b034>` |
  `<x426>11</x426>` | Second feature
  `<x427>02</x427>` | for book trade
  `<d104>Colorful imagery ties in with scenes from the movie</d104>` |
  `</textcontent>` |
  `. . .` |
  `<textcontent>` |
  `<b034>5</b034>` |
  `<x426>18</x426>` | New feature
  `<x427>02</x427>` | for book trade
  `<d104>NEW Lower, more pocket-friendly price point for under-pressure parents</d104>` |
  `</textcontent>` |

  New features can be highlighted using Text type code 18 – for a new edition, for example, or after a price change (as shown in the short tags example above).

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 language="spa">… Ellos usan la computadora…</Text>` |
  `<Text language="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 language="spa">… Ellos usan la computadora…</d104>` | Latin-American Spanish
  `<d104 language="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, since that is the only option for that territory. 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 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 Ⅰ – Living things</li>` |
  `<li>Chapter Ⅱ – The plant kingdom</li>` |
  `<li>Chapter Ⅲ – Historical survey</li>` |
  `<li>Chapter Ⅳ – The flowering plant</li>` |
  `<li>Chapter Ⅴ – Special forms and functions of plant organs</li>` |
  `<li>Chapter Ⅵ – Food of living things</li>` |
  `<li>Chapter Ⅶ – Some other plant products</li>` |
  `<li>Chapter Ⅷ – Enzyme action and digestion</li>` |
  `<li>Chapter Ⅸ – Protoplasm and the colloidal state</li>` |
  `<li>Chapter Ⅹ – Internal organization of living things</li>` |
  `<li>. . .</li>` |
  `<li>Chapter ⅩⅩⅩ – Classification of angiosperms</li>` |
  `<li>Index</li>` |
  `</ul>` |
  `</Text>` |
  `</TextContent>` |

  using Short tags – XHTML-formatted, and compacted for space efficiency |
  --- | ---
  `<textcontent>` |
  `<x426>04</x426>` | Table of contents
  `<x427>00</x427>` | For any audience
  `<d104 textformat="05">​<ul>​<li>Preface​</li>​<li>Chapter Ⅰ – Living things​</li>​<li>Chapter Ⅱ – The plant kingdom​</li>​<li>Chapter Ⅲ – Historical survey​</li>​<li>Chapter Ⅳ – The flowering plant​</li>​<li>Chapter Ⅴ – Special forms and functions of plant organs​</li>​<li>Chapter Ⅵ – Food of living things​</li>​<li>Chapter Ⅶ – Some other plant products​</li>​<li>Chapter Ⅷ – Enzyme action and digestion​</li>​<li>Chapter Ⅸ – Protoplasm and the colloidal state​</li>​<li>Chapter Ⅹ – Internal organization of living things​</li>​<li>. . .​</li>​<li>Chapter ⅩⅩⅩ – Classification of angiosperms​</li>​<li>Index​</li>​</ul>​</d104>` |
  `</textcontent>` |

  providing a nested table of contents (with automatic numbering)
  using Reference names – HTML-formatted and expanded |
  --- | ---
  `<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-formatted and compacted |
  --- | ---
  `<textcontent>` |
  `<x426>04</x426>` |
  `<x427>00</x427>` |
  `<d104 textformat="05"><ol type="I"><li>Introduction</li><li>Context and objectives<ol><li>The skills gap</li><li>The technological environment</li><li>Providing the means</li></ol></li><li>Methodology<ol start="4"><li>Defining terminologies</li><li>The semantic web</li></ol></li><li>. . .</li></ol></d104>` |
  `</textcontent>` |

  The table of contents should render like this:

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

  Note the use of the type attribute to control the use of upper-case Roman numerals in the outer ordered list, and the start attribute to avoid restarting the minor numbering at 1 in the second inner ordered list. 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 (and later) 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 or new line characters can also be removed if desired.

  Listing the dramatis personae of a dramatization
  using Reference names |
  --- | ---
  `<TextContent>` |
  `<TextType>28</TextType>` |
  `<ContentAudience>00</ContentAudience>` |
  `<Text textformat="05">` |
  `<p>Cast:</p>` |
  `<dl>` |
  `<dt>Becky Sharp</dt><dd>Emma Fielding</dd>` |
  `<dt>Amelia Sedley</dt><dd>Katy Cavanagh</dd>` |
  `<dt>Joseph Sedley</dt><dd>Toby Jones</dd>` |
  `<dt>Narrator</dt><dd>Stephen Fry</dd>` |
  `<dt>Adapted and directed by</dt><dd>Stephen Wyatt</dd>` |
  `<dl>` |
  `</Text>` |
  `</TextContent>` |

  using Short tags |
  --- | ---
  `<textcontent>` |
  `<x426>28</x426>` | Full cast and credits
  `<x427>00</x427>` | For any audience
  `<d104 textformat="05">` |
  `<p>Cast:</p>` |
  `<dl>` |
  `<dt>Becky Sharp</dt><dd>Emma Fielding</dd>` |
  `<dt>Amelia Sedley</dt><dd>Katy Cavanagh</dd>` |
  `<dt>Joseph Sedley</dt><dd>Toby Jones</dd>` |
  `<dt>Narrator</dt><dd>Stephen Fry</dd>` |
  `<dt>Adapted and directed by</dt><dd>Stephen Wyatt</dd>` |
  `<dl>` |
  `</d104>` |
  `</textcontent>` |

  Cast lists should always be marked up using the (X)HTML <dl> tag to create a two-column list.

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

  providing the same <TextContent> in multiple languages
  using Reference names |
  --- | ---
  `<TextContent>` |
  `<TextType>02</TextType>` |
  `<ContentAudience>00</ContentAudience>` |
  `<Text language="eng" textformat="05"><p>On the eve of his death, Dr. Watson feels a duty to set down the last adventure of Sherlock Holmes…</p></Text>` |
  `<Text language="fre" textformat="05"><p>A la veille de sa mort, le docteur Watson se sent le devoir de coucher sur le papier la dernière aventure de Sherlock Holmes…</p></Text>` |
  `</TextContent>` |

  using Short tags |
  --- | ---
  `<textcontent>` |
  `<x426>02</x426>` | Short description
  `<x427>00</x427>` | For any audience
  `<d104 language="eng" textformat="05"><p>On the eve of his death, Dr. Watson feels a duty to set down the last adventure of Sherlock Holmes…​</p>​</d104>` | In English
  `<d104 language="fre" textformat="05"><p>A la veille de sa mort, le docteur Watson se sent le devoir de coucher sur le papier la dernière aventure de Sherlock Holmes…​</p>​</d104>` | …and in French
  `</textcontent>` |

  If there is more than one repeat of the <Text> element within a <TextContent> composite, every one must carry a language attribute, and each should be unique.
  It is not currently possible to target the text more precisely than by language (for example, it is not possible to list one text for Castilian Spanish and another for Latin American Spanish, since both would use code spa for the language attribute).

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

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

##### Review rating composite

Where the descriptive text in the <Text> element is a short extract from a review, it can be useful to provide any ‘star rating’ from the review as structured data, rather than 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.6a Text source

here 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 in particular 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. Where available, a URL for the full text of the review or endorsement may also be included.

  providing multiple review quotes, naming the review authors and publications
  using Reference names |
  --- | ---
  `<TextContent>` |
  `<SequenceNumber>1</SequenceNumber>` |
  `<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>` |
  `<SequenceNumber>2</SequenceNumber>` |
  `<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>` |
  `<b034>1</b034>` |
  `<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>` |
  `<b034>2</b034>` |
  `<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>` |

  In the case of multiple reviews, Sequence number should be used to indicate the order of precedence for display, and – where the recipient can use only a limited number – can also be used to select only the most important.
  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 text, for example a jointly-written review.
  Where the text author is a corporate author, <TextSourceCorporate> should 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).
  Reviews would normally be short extracts from a longer review. A URL linking to the full original source of the text can be provided using <TextSourceLink>. And since URLs linking to reviews might often contain multiple query parameters (the parts after any ? in a URL), note that using CDATA to surround such a link can be useful – it avoids having to escape the & separator to &amp;. CDATA is unnecessary and should not be used with links that have no query parameters or only a single parameter.

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

##### Usage constraint and Digital license composites

The primary use of these composites is to express a limitation on the rights to use the supplied supporting text – for example to limit or prohibit the use of the supporting text in text and data mining (TDM).

  EU-style TDM opt-out
  using Reference names |
  --- | ---
  `<Text> . . . </Text>` |
  `. . .` |
  `<EpubUsageConstraint>` |
  `<EpubUsageType>11</EpubUsageType>` |
  `<EpubUsageStatus>03</EpubUsageStatus>` |
  `</EpubUsageConstraint>` |

  using short tags
  `<d104> . . . </d104>` | Text to which the reservation of rights applies
  `. . .` |
  `<epubusageconstraint>` |
  `<x318>11</x318>` | TDM is
  `<x319>03</x319>` | prohibited
  `</epubusageconstraint>` |

  The prohibition in <EpubUsageConstraint> here applies to the supporting text – for example a long description – and should be interpreted as ‘prohibited to the full extent allowed by the law’ or otherwise expressly reserved by the rightsholder, since with EU-style opt-outs, the rightsholder cannot opt out of the TDM copyright exception for scientific research and cultural heritage purposes.

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

  Reissuing a product may occur after a temporary period of unavailability, or the product may have been available throughout – it is primarily the process of refreshing the marketing collateral, perhaps creating a new cover or jacket – but not after changing the ISBN or declaring the original out of print.

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

While descriptive text in Group P.14 can include a quote from a review or reference to a published bestseller list, publishers may need to include direct citations of online reviews, or links to the bestseller listing website or a third-party podcast episode. These links could be used by resellers to enrich their websites and encourage greater customer engagement and sales.

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;
- both data sender and data recipient should ensure that the content reachable at the URL is legitimate and does not pose a security risk to the end user.

Common issues in Group P.15:

- URLs that require a login or authentication to access. It is very unlikely that resources that are not publicly available could be used;
- outdated URLs that return a ‘Page not found’ error or some new but irrelevant content.

  citing a review and a bestseller list
  using Reference names |
  --- | ---
  `<CitedContent>` |
  `<SequenceNumber>1</SequenceNumber>` |
  `<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>` |
  `<SequenceNumber>2</SequenceNumber>` |
  `<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>` |
  `<b034>1</b034>` |
  `<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>` |
  `<b034>2</b034>` |
  `<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.

  citing a podcast that discusses the book
  using Reference names |
  --- | ---
  `<CitedContent>` |
  `<SequenceNumber>1</SequenceNumber>` |
  `<CitedContentType>06</CitedContentType>` |
  `<SourceType>05</SourceType>` |
  `<SourceTitle>In our Time: The Moon</SourceTitle>` |
  `<ResourceLink>https://podcasts.apple.com/gb/podcast/in-our-time/id73330895?i=1000730979244</ResourceLink>` |
  `<ContentDate>` |
  `<ContentDateRole>04</ContentDateRole>` |
  `<Date>20111103</Date>` |
  `</ContentDate>` |
  `</CitedContent>` |

  using short tags |
  --- | ---
  `<citedcontent>` |
  `<b034>1</b034>` |
  `<x430>06</x430>` | Commentary / dicussion
  `<x431>05</x431>` | Podcast
  `<x428>In our Time: The Moon</x428>` |
  `<x435>https://podcasts.apple.com/gb/podcast/in-our-time/id73330895?i=1000730979244</x435>` |
  `<contentdate>` |
  `<x429>04</x429>` | Broadcast date
  `<b306>20111103</b306>` |
  `</contentdate>` |
  `</citedcontent>` |

  The <ContentDate> examples above give the date of publication of the list or review, or of broadcast or publication date of a radio programme or podcast, and not the date of publication of the product.

  citing a soundtrack to accompany the book
  using Reference names |
  --- | ---
  `<CitedContent>` |
  `<SequenceNumber>1</SequenceNumber>` |
  `<CitedContentType>08</CitedContentType>` |
  `<SourceType>07</SourceType>` |
  `<SourceTitle>Atmospheric sci-fi soundtracks</SourceTitle>` |
  `<ResourceLink>https://open.spotify.com/​playlist/​37i9dQZF1DXbIeCFU20wRm</ResourceLink>` |
  `</CitedContent>` |

  using short tags |
  --- | ---
  `<citedcontent>` |
  `<b034>1</b034>` |
  `<x430>08</x430>` | Soundtrack
  `<x431>07</x431>` | Playlist
  `<x428>Atmospheric sci-fi soundtracks</x428>` |
  `<x425>https://open.spotify.com/​playlist/​37i9dQZF1DXbIeCFU20wRm</x425>` |
  `</citedcontent>` |

##### 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 explicitly 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 Trade 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 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, images of the contributor, audio or video extracts from the product, 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.

A cover image is known to be among the most powerful data elements to encourage online sales. Failure to provide an image reduces conversion in the customer journey – put bluntly, even if they discover it, many fewer people will buy the book.

And as online bookselling of both physical and digital products has become more sophisticated, there’s an increasing demand for a wider range of collateral images – photos of contributors, sample spreads for illustrated books – and other marketing resources. These might for example include samples from an audio version of the book, or reading group guides.

Offline, the same cover images and other resources are required by resellers for use in their own catalogs and promotions.

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, or a filename and the file itself provided;
- 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.

Where multiple resources of the same type are provided – for example multiple sample spreads, <SequenceNumber> should be used to indicate the order of importance of each resource;

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.

Common issues in Group P.16:

- failure to deliver a cover image, or delivery of only a ‘small’ image with too few pixels;
- provision of a URL to which the recipient does not have access, perhaps because of a failure to share authentication credentials for the relevant server, or because of authorization issues;
- failure to update the resource when a new version is available;
  - data senders should provide details of the updated resource and relevant <ContentDate> composites (most often, the ‘last updated’ date), and recipients should monitor those dates and ensure any updates are reflected in their own systems;
- failure by recipients to use any required credits that are supplied.

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);
  - primary cover images should be flat (not 3D perspective views), cropped so that no background is shown (though perspective views of the product can be supplied in addition to a primary cover image);
  - 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 at which it is reproduced 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 gray blur in a thumbnail);
- the high-quality JPEG, a TIFF and the thumbnail JPEG files (of the front cover) should be treated as versions of the same resource, using <ResourceContentType> code 01 from List 158;
  - there should be only one <SupportingResource> composite with a Resource content type code 01;
  - if a 3D perspective view of the book showing the cover is also provided, use code 03 – but this would be a version of a different resource;
- 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, FLAC 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:

- 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, or an audio video player for example). 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 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 (two versions of same resource), plus embargoed audio excerpt of author reading content from the product
  using Reference names |
  --- | ---
  `<SupportingResource>` |
  `<SequenceNumber>1</SequenceNumber>` |
  `<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>` |
  `<SequenceNumber>2</SequenceNumber>` |
  `<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 <cite>A régi, jó Gvadányi</cite> (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
  `<b034>1</b034>` |
  `<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
  `<b034>2</b034>` |
  `<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 <cite>A régi, jó Gvadányi</cite> (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.
  If the URL in <ResourceLink> contains multiple query parameters (the bits after an & in the URL), it may be useful to use CDATA to surround the URL. This avoids the need to encode the & in the URL as &amp;. However, CDATA is unnecessary and should be avoided if there are no query parameters or only one.

  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" target="_blank">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 multi-language caption and additional required credit
  `<resourcefeature>` |
  `<x438>02<x438>` | Caption
  `<x440 language="eng">Michael Marshall, left, with agent Jonny Geller</x440>` |
  `<x440 language="por">Michael Marshall, à esquerda, com agente literário 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.

  Alternative description of image resource, for vision-impaired readers
  using Reference names |
  --- | ---
  `<ResourceFeature>` |
  `<ResourceFeatureType>07<ResourceFeatureType>` |
  `<FeatureNote>Steeply-sloping moorland, with a rocky cliff about ten metres high running across the top of the slope. A female climber is ascending the cliff, attached by rope to her climbing partner at the top. Above the cliff, boggy peatland stretches to the horizon.</FeatureNote>` |
  `</ResourceFeature>` |

  using Short tags
  `<resourcefeature>` |
  `<x438>07<x438>` | Alternative description
  `<x440>Steeply-sloping moorland, with a rocky cliff about ten metres high running across the top of the slope. A female climber is ascending the cliff, attached by rope to her climbing partner at the top. Above the cliff, boggy peatland stretches to the horizon.</x440>` | …could be used by screen-reading software to describe the content of the image resource
  `</resourcefeature>` |

If required, alternative descriptions, captions and credits can carry XHTML markup, but this is rarely necessary. Each can also be delivered in multiple languages.

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

This can be powerful: a single cover image resource (ie a single <SupportingResource> composite) can contain several ‘versions’ of the cover, each distinctive because of a different file type, resolution or image quality, or even a specific combination of Content dates – one Resource version for use until a date, and another Resource version for use from a date (usually the following day). Thus Resource versions can support reissues of the book with revised covers. The structure could look like the example below.

  `<SupportingResource>`
  `<!-- front cover -->`
  `<ResourceVersion>`
  `<!-- current large version of cover -->`
  `</ResourceVersion>`
  `<ResourceVersion>`
  `<!-- current thumbnail version of cover -->`
  `</ResourceVersion>`
  `<ResourceVersion>`
  `<!-- future large version of cover -->`
  `</ResourceVersion>`
  `<ResourceVersion>`
  `<!-- future thumbnail version of cover -->`
  `</ResourceVersion>`
  `</SupportingResource>`

##### 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. The <ResourceLink> element is repeatable – with the language attribute – if the resource is available in multiple languages at different addresses. It may also be repeated if the same resource can be linked in more than one way (eg via different protocols).

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, with both ‘relative’ and ‘absolute’ URIs |
  --- | ---
  `<x435>covers/9780007232833-fc500.jpeg</x435>` |
  `<x435>ftp://publisher.com/onix/covers/9780007232833-fc500.jpeg</x435>` |

  In this example, if the ONIX message itself is at the address
  `ftp://publisher.com/onix/130719.xml`
  then the cover image file must be found (by appending its relative URI to the directory location of the ONIX file, and by using the same protocol) at
  `ftp://publisher.com/onix/covers/9780007232833-fc500.jpeg`
  The additional absolute URI in the short tags example points to this same resource, although it uses a different protocol.

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

Occasionally URIs contain spaces. Spaces are not allowed in URIs in ONIX, but if they cannot be avoided, they must be replaced with ‘%20’ in <ResourceLink> and similar ‘link’ fields (this is termed ‘percent encoding’ or ‘URL encoding’).

Some URIs contain ‘query parameters’, which are used to pass data to the target server – for example, in https://ns.editeur.org/thema/en?utf8=✓&search=bicycle the utf8 and search parameters that follow the ? mean the web page returned is the result of a search on the target server. Since it is part of the ‘data’ within the <ResourceLink> field, the & separator between parameters must normally be encoded as &amp;. This can prove confusing to data recipients, as the &amp; must be decoded to & when used as a link, whereas other ‘HTML’ or ‘XHTML’ data taken from the ONIX can be used as-is (without decoding). Using CDATA with <ResourceLink> – and other …Link> tags – may avoid such confusion.

  using CDATA when <ResourceLink> includes multiple query parameters
  using Reference names |
  --- | ---
  `<ResourceLink><![CDATA[https://ns.editeur.org/thema/en?utf8=✓&search= bicycle]]></ResourceLink>` |

  using Short tags |
  --- | ---
  `<x435><![CDATA[https://ns.editeur.org/thema/en?utf8=✓&search=bicycle]]></x435>` |

CDATA is unnecessary and should be avoided if there are no query parameters or only one.

Instead of the URI carrying a link to the image data, it is technically 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>` |

##### Usage constraint and Digital license composites

The primary use of these composites is to express a limitation on the rights to use the linked supporting resource – for example to limit or prohibit the use of a cover image or an audio extract of the product content in text and data mining (TDM).

  EU-style TDM opt-out
  using Reference names |
  --- | ---
  `<ResourceLink> . . . </ResourceLink>` |
  `<EpubUsageConstraint>` |
  `<EpubUsageType>11</EpubUsageType>` |
  `<EpubUsageStatus>03</EpubUsageStatus>` |
  `</EpubUsageConstraint>` |

  using short tags
  `<x435> . . . </x435>` | URL of the resource version to which the reservation of rights applies
  `<epubusageconstraint>` |
  `<x318>11</x318>` | TDM is
  `<x319>03</x319>` | prohibited
  `</epubusageconstraint>` |

  The prohibition in <EpubUsageConstraint> here applies to the supporting text – for example a long description – and should be interpreted as ‘prohibited to the full extent allowed by the law’ or otherwise expressly reserved by the rightsholder, since with EU-style opt-outs, the rightsholder cannot opt out of the TDM copyright exception for scientific research and cultural heritage purposes.

##### 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.
  Where there are multiple versions of the same resource, each version should normally include the same dates in any <ContentDate> composites.

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

The <Prize> composite should be used to specify any prize or award gained by the product or the work. Information about literary prizes that a book has won can be an influence on potential readers’ purchasing decision, and providing that information in structured form in P.17 (rather than in simple text within a long description, for example), gives resellers the choice about how to display or highlight it. Each repeat of the composite:

- must list the name of the prize or award;
- should list the year for awards given annually (or biennially, etc), and the level of achievement (winner, runner-up, shortlisted etc) using <PrizeCode>;
- should use <PrizeStatement> to indicate the exact terminology used by the specific prize.

Common issues within Group P.17:

- prizes awarded to different books by the same author, as well as prizes awarded to the author on the basis of a body of work should use <Prize> in Group P.7 instead.

  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 sequence number, prize identifier, country and alternative language prize statements |
  --- | ---
  `<prize>` |
  `<b034>2</b034>` | Second in sequence
  `<prizeidentifier>` |
  `<x589>01</x589>` | Proprietary
  `<b233>BPAPrizeID</b233>` |
  `<b244>7e077694-ec01-4a16-a372-62e21eb066eb</b244>` | UUID
  `</prizeidentifier>` |
  `<g126>Prix Renaudot</g126>` |
  `<g127>2010</g127>` |
  `<g128>FR</g128>` |
  `<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>` |

  Although it’s technically optional, <PrizeCode> should always be included, even if the particular prize does not explicitly 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.
  For some prizes, winning books carry special stickers on their cover or jacket. These can be specified using <ProductFormDetail> in P.3.

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 particularly significant: however, it is best practice to list them in order of prestige using <SequenceNumber> – 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.

A proprietary or standardized prize identifier can be used to guard against confusion caused by changes in the name of the prize – changes which might be dictated by a change in sponsorship, for example. There is no ‘standard’ so such identifiers are inevitably proprietary, but they could be collated by a publisher’s association for use in a particular market.

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

Note that Block 7 follows Block 2 and precedes Block 3 in message order. Since Block 7 is newly introduced as of late 2019, its use is not supported by all ONIX data suppliers or recipients. However, recipients should at least be able to confirm its validity and then ignore it if provided. Discuss Block 7 with your data partners before use.

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, public appearances 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–8 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.

Author ‘tours’ – signings, readings, festival appearances and interviews – are frequent and important ingredients of a publicity campaign for a book. A single high-profile book might be supported by several tens of individual event occurrences, and they are an increasingly important part of the marketing mix for many publishers and types of book. Yet they are often poorly promoted in themselves: the events are not always easily discoverable. Block 7 is intended to make promotional events easier to integrate into other communication about the book, and to enable central compilation of event schedules.

The intent of the composite is to describe in detail an event such as an author appearance, signing, reading, interview and so on. 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</SequenceNumber>` |
  `<ContributorRole>A01</ContributorRole>` |
  `<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</IDTypeName>` |
  `<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</IDTypeName>` |
  `<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>A01</b035>` | Author and
  `<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>` |

  Listing an online book reading event
  using Reference names |
  --- | ---
  `<PromotionDetail>` |
  `<PromotionalEvent>` |
  `<EventType>02</EventType>` |
  `<EventStatus>A</EventStatus>` |
  `<ContentAudience>00</ContentAudience>` |
  `<EventName>Poetry Online: Jeff Gibson on Nature</EventName>` |
  `<ContributorReference>` |
  `<ContributorRole>A01</ContributorRole>` |
  `<ContributorRole>E99</ContributorRole>` |
  `<NameIdentifier>` |
  `<NameIDType>01</NameIDType>` |
  `<IDTypeName>Poetry365</IDTypeName>` |
  `<IDValue>JG-1982-04</IDValue>` |
  `</NameIdentifier>` |
  `</ContributorReference>` |
  `<EventOccurrence>` |
  `<OccurrenceDate>` |
  `<OccurrenceDateRole>01</OccurrenceDateRole>` |
  `<Date>20200621T1930</Date>` |
  `</OccurrenceDate>` |
  `<EventStatus>A</EventStatus>` |
  `<EventDescription>A unique online live streamed poetry performance of Jeff Gibson’s work on the theme of the natural world.</EventDescription>` |
  `<Website>` |
  `<WebsiteRole>26</WebsiteRole>` |
  `<WebsiteLink>https://poetry365.com/event/2061</WebsiteLink>` |
  `</Website>` |
  `</EventOccurrence>` |
  `<PromotionalEvent>` |
  `</PromotionDetail>` |

  using Short tags |
  --- | ---
  `<promotiondetail>` |
  `<promotionalevent>` |
  `<x548>02</x548>` | Book reading
  `<x549>A</x549>` | Announced
  `<x427>00</x427>` | For any audience
  `<x516>Poetry Online: Jeff Gibson on Nature</x516>` |
  `<contributorreference>` |
  `<b035>A01</b035>` | Author and
  `<b035>E99</b035>` | Performer
  `<nameidentifier>` |
  `<x415>01</x415>` |
  `<b233>Poetry365</b233>` | Proprietary, matches ID
  `<b244>JG-1982-04</b244>` | in contributor
  `</nameidentifier>` |
  `</contributorreference>` |
  `<eventoccurrence>` | Sole occurrence
  `<occurrencedate>` |
  `<x554>01</x554>` |
  `<b306>20200621T1930</b306>` | Jun 21st at 7:30pm
  `</occurrencedate>` |
  `<x549>A</x549>` |
  `<x550>A unique online live streamed poetry performance of Jeff Gibson’s work on the theme of the natural world.</x550>` |
  `<website>` |
  `<b367>26</b367>` | Author reading
  `<b295>https://poetry365.com/ event/2061</b295>` |
  `</website>` |
  `</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.

  Note that the Contributor role need not match that used in the referenced instance of <Contributor>. Here it refers to the role within the Promotional event.

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 program of such occurrences, each in a different bookstore, and should be described as a single Promotional event with multiple 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 recognized. Inevitably, since there is no standardized 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 additional 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 specified 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>` | Canceled

  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 canceled 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–8 are unnecessary;
- the Notification type is 05 (a record deletion), in which case Blocks 1–8 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).

One potentially interesting benefit of managing Product metadata at this granular content item level is that if a product is divided up and made available as individual chapters, each a product in its own right, then the Block 3 data for the combined ‘all in one’ product will form the basis of the full ONIX record for each smaller product. So a monograph with ten chapters may be sold as a single complete book and as ten small chapter-sized products. There would be eleven ONIX records, and many of the product-level metadata elements in ten of them would be duplicates of elements in ten Content items within Block 3 of the eleventh.

The same would apply to a multi-volume set, when sold as a single product (three books in a slipcase, for example) and when each volume is sold as an individual product – there would be four Products, with product-level data from three encapsulated within Block 3 of the fourth.

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 when parts in a multi-component product, or articles or chapters from a book are also sold individually), a <ContentItem> composite 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>;
  - or <AVItem> composite – nature of the content item, including any identifiers for the item, and the duration;
    - <AVItemType>;
    - <AVItemIdentifier> composite;
    - <TimeRun> composite;
    - <AVDuration>;
  - licensing details using <EpubUsageConstraint> and <EpubLicense> for hybrid open access content items – see Group P.3;
  - <ComponentTypeName> (eg Chapter, Part, Article);
  - <ComponentNumber> (eg a chapter or article number);
  - and / or <TitleDetail> composite, for the title of the content item – see Group P.6;
  - authorship details of the content item in the <Contributor> composite – see Group P.7;
  - <Subject> composite – see Group P.12;
  - and <NameAsSubject> composite for the aboutness of the content item – see Group P.12;
  - <TextContent> composite – see Group P.14;
  - <CitedContent> composite – see Group P.15;
  - and <SupportingResource> composite for collateral supporting the content item – see Group P.16;
  - <Publisher> composite, used here only for hybrid open access funder details – see Group P.19;
  - <CopyrightStatement> for the content item – see Group P.20;
  - <RelatedWork> and <RelatedProduct> composites to specify links to other works and products – see Group P.22 and Group P.23.

The primary intent of the composite is to specify detailed information about each part of the product that is included in neither the description of the product as a whole nor in a <ProductPart> composite in Group P.4. This is often termed ‘chapter-level metadata‘, though each Content item need not necessarily be a formal chapter of a book.

Chapter-level metadata can be used to describe individual chapters in an academic monograph or conference proceedings, for example, where each is the work of different contributors, where each has a different subject or has different supporting resources. Exposing the chapter-level metadata increases discoverability of the chapter and of the book as a whole, and is valuable information for librarians and researchers.

Content items may also be volumes in a multi-volume set when sold as a single product (say, three books in a slipcase), or the various parts of an omnibus or anthology. Providing granular metadata for each Content item increases discoverability. In addition, retailers, librarians and readers need to know the relationships between the parts and the whole. In these cases, note also the importance of the Contains / Is part of relationships in <RelatedProduct> in Block 5.

Chapter-level metadata has become important for digital audio, to deliver a time-based rather than page-based table of contents, enabling digital audio integrators and resellers to make audio more easily navigable. Note that the chapter-based structure of this table of contents is linked via time-based bookmarks – timings measured from the beginning of the product – which can be matched to the cumulative duration of the files, and is not necessarily tied to individual audio files within the product (such as might be listed in Block 8).

Each <ContentItem> composite:

- should contain a level sequence number if the order of the items is significant;
- must contain a <TextItem> composite (or, for audio and 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;
- may – if the licensing details for the item are relevant – contain <EpubUsageConstraint> and <EpubLicense> composites, for example for hybrid open access monographs;
  - funding for open access content items can be specified in <Publisher>;
- 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.

Common issues in Group P.18

- for audio chapter timings, a confusion between the start time or duration of a particular chapter or content item, and the order and duration of the data file as it is delivered;
  - durations of delivery files may be provided in Block 8. A single delivery file may include more than one chapter or content item, and a single content item may span more than a single delivery file;
  - in Group P.18, all start times are measured from the beginning of the product;
- confusion over the role of <LevelSequenceNumber>. It is solely for the purpose of ensuring that Content items can be easily sorted into the order they appear in the book, it does not have to match the actual numbering of items within the book, and should never be displayed by a recipient;
- confusion over the use of <ComponentTypeName> and <ComponentNumber>, and <TitleDetail> – for example, putting ‘Chapter 7’ in <TitleDetail>;
  - use Component type name and number for numbered content items (whether they are parts, chapters, sections or whatever), and Title detail for textual titles. Use both where a component name has both number and title, eg ‘Chapter 7: Old Magic’.

  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>ⅸ​</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 Ⅰ​</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 Ⅱ​</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>ⅸ</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 Ⅰ</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 Ⅱ</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 Ⅰ – 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 Ⅱ – 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 Ⅰ – 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 Ⅱ – 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.

  Differing copyright statements for each part of an audio omnibus
  using Reference names |
  --- | ---
  `<DescriptiveDetail>` | Block 1
  `<ProductComposition>00</ProductComposition>` |
  `<ProductForm>AO</ProductForm>` |
  `. . .` |
  `<NoCollection/>` |
  `<TitleDetail>` |
  `<TitleType>01</TitleType>` |
  `<TitleElement>` |
  `<TitleElementLevel>01</TitleElementLevel>` |
  `<NoPrefix/>` |
  `<TitleWithoutPrefix>Worlds of Exile and Illusion</TitleWithoutPrefix>` | Title of omnibus
  `</TitleElement>` |
  `</TitleDetail>` |
  `. . .` |
  `<EditionType>CMB</EditionType>` |
  `. . .` |
  `</DescriptiveDetail>` |
  `. . .` |
  `<ContentDetail>` | Block 3
  `<ContentItem>` | First content item within omnibus — Rocannon’s World
  `<LevelSequenceNumber>1</LevelSequenceNumber>` |
  `<AVItem>` |
  `<AVItemType>01</AVItemType>` |
  `. . .` | Could add timing for audio content item here
  `</AVItem>` |
  `<TitleDetail>` |
  `<TitleType>01</TitleType>` |
  `<TitleElement>` |
  `<TitleElementLevel>04</x409>` |
  `<NoPrefix/>` |
  `<TitleWithoutPrefix>Rocannon’s World</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `</TitleDetail>` |
  `. . .` |
  `<CopyrightStatement>` | Copyright details for first content item
  `<CopyrightType>C</CopyrightType>` |
  `<CopyrightYear>1966</CopyrightYear>` |
  `<CopyrightOwner>` |
  `<CorporateName>Ace Books, Inc.</CorporateName>` |
  `</CopyrightOwner>` |
  `</CopyrightStatement>` |
  `<CopyrightStatement>` |
  `<CopyrightType>C</CopyrightType>` |
  `<CopyrightYear>1994</CopyrightYear>` |
  `<CopyrightOwner>` |
  `<PersonName>Ursula K. Le Guin</PersonName>` |
  `</CopyrightOwner>` |
  `</CopyrightStatement>` |
  `. . .` |
  `</ContentItem>` |
  `<ContentItem>` | Second content item — Planet of Exile
  `<LevelSequenceNumber>2</LevelSequenceNumber>` |
  `<AVItem>` |
  `<AVItemType>01</AVItemType>` |
  `</AVItem>` |
  `<TitleDetail>` |
  `<TitleType>01</TitleType>` |
  `<TitleElement>` |
  `<TitleElementLevel>04</TitleElementLevel>` |
  `<NoPrefix/>` |
  `<TitleWithoutPrefix>Planet of Exile</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `</TitleDetail>` |
  `. . .` |
  `<CopyrightStatement>` | Copyright details for second content item
  `<CopyrightType>C</CopyrightType>` |
  `<CopyrightYear>1966</CopyrightYear>` |
  `<CopyrightYear>1994</CopyrightYear>` |
  `<CopyrightOwner>` |
  `<PersonName>Ursula K. Le Guin</PersonName>` |
  `</CopyrightOwner>` |
  `</CopyrightStatement>` |
  `. . .` |
  `</ContentItem>` |
  `<ContentItem>` | Third content item — City of Illusions
  `<LevelSequenceNumber>3</LevelSequenceNumber>` |
  `<AVItem>` |
  `<AVItemType>01</AVItemType>` |
  `</AVItem>` |
  `<TitleDetail>` |
  `<TitleType>01</TitleType>` |
  `<TitleElement>` |
  `<TitleElementLevel>04</TitleElementLevel>` |
  `<NoPrefix/>` |
  `<TitleWithoutPrefix>City of Illusions</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `</TitleDetail>` |
  `. . .` |
  `<CopyrightStatement>` | Text copyright details for third content item
  `<CopyrightType>C</CopyrightType>` |
  `<CopyrightYear>1967</CopyrightYear>` |
  `<CopyrightYear>1995</CopyrightYear>` |
  `<CopyrightOwner>` |
  `<PersonName>Ursula K. Le Guin</PersonName>` |
  `</CopyrightOwner>` |
  `</CopyrightStatement>` |
  `. . .` |
  `</ContentItem>` |
  `. . .` |
  `</ContentDetail>` |
  `<PublishingDetail>` | Block 4
  `. . .` |
  `<Publisher>` |
  `<PublishingRole>01</PublishingRole>` |
  `<PublisherName>Recorded Books Inc</PublisherName>` |
  `</Publisher>` |
  `. . .` |
  `<CopyrightStatement>` |
  `<CopyrightType>P</CopyrightType>` |
  `<CopyrightYear>2024</CopyrightYear>` |
  `<CopyrightStatement>` |
  `<CorporateName>Recorded Books, Inc</CorporateName>` |
  `</CopyrightOwner>` |
  `</CopyrightStatement>` |
  `. . .` |
  `</PublishingDetail>` |

  using Short tags |
  --- | ---
  `<descriptivedetail>` | Block 1
  `<x314>00</x314>` |
  `<b012>AO</b012>` | Streamed audiobook
  `. . .` |
  `<x411/>` | Omnibus is not part of a collection
  `<titledetail>` | Title of the omnibus
  `<b202>01</b202>` |
  `<titleelement>` |
  `<x409>01</x409>` |
  `<x501/>` |
  `<b203>Worlds of Exile and Illusion</b203>` |
  `</titleelement>` |
  `</titledetail>` |
  `. . .` |
  `<x419>CMB</x419>` | Omnibus edition
  `. . .` |
  `</descriptivedetail>` |
  `. . .` |
  `<contentdetail>` | Block 3
  `<contentitem>` | First content item within omnibus — Rocannon's World
  `<b284>1</b284>` |
  `<avitem>` |
  `<x540>01</x540>` | Complete work (as a content item)
  `. . .` | Could add timing for audio content item here
  `</avitem>` |
  `<titledetail>` | Title of first content item
  `<b202>01</b202>` |
  `<titleelement>` |
  `<x409>04</x409>` |
  `<x501/>` |
  `<b203>Rocannon’s World</b203>` |
  `</titleelement>` |
  `</titledetail>` |
  `. . .` |
  `<copyrightstatement>` | Copyright details for first content item
  `<x512>C</x512>` | Text copyright
  `<b087>1966</b087>` |
  `<copyrightowner>` |
  `<b047>Ace Books, Inc.</b047>` | © 1966
  `</copyrightowner>` |
  `</copyrightstatement>` |
  `<copyrightstatement>` |
  `<x512>C</x512>` | Text copyright
  `<b087>1994</b087>` |
  `<copyrightowner>` |
  `<b036>Ursula K. Le Guin</b036>` | © renewed 1994
  `</copyrightowner>` |
  `</copyrightstatement>` |
  `. . .` |
  `</contentitem>` |
  `<contentitem>` | Content item 2 — Planet of Exile
  `<b284>2</b284>` |
  `<avitem>` |
  `<x540>01</x540>` | Complete work (as a content item)
  `</avitem>` |
  `<titledetail>` | Title of second content item
  `<b202>01</b202>` |
  `<titleelement>` |
  `<x409>04</x409>` |
  `<x501/>` |
  `<b203>Planet of Exile</b203>` |
  `</titleelement>` |
  `</titledetail>` |
  `. . .` |
  `<copyrightstatement>` | Copyright details for second content item
  `<x512>C</x512>` | Text copyright
  `<b087>1966</b087>` | © 1966, renewed 1994
  `<b087>1994</b087>` |
  `<copyrightowner>` |
  `<b036>Ursula K. Le Guin</b036>` |
  `</copyrightowner>` |
  `</copyrightstatement>` |
  `. . .` |
  `</contentitem>` |
  `<contentitem>` | Content item 3 — City of Illusions
  `<b284>3</b284>` |
  `<avitem>` |
  `<x540>01</x540>` | Complete work (as a content item)
  `</avitem>` |
  `<titledetail>` | Title of third content item
  `<b202>01</b202>` |
  `<titleelement>` |
  `<x409>04</x409>` |
  `<x501/>` |
  `<b203>City of Illusions</b203>` |
  `</titleelement>` |
  `</titledetail>` |
  `. . .` |
  `<copyrightstatement>` | Text copyright details for third content item
  `<x512>C</x512>` | Text copyright
  `<b087>1967</b087>` | © 1967, renewed 1995
  `<b087>1995</b087>` |
  `<copyrightowner>` |
  `<b036>Ursula K. Le Guin</b036>` |
  `</copyrightowner>` |
  `</copyrightstatement>` |
  `. . .` |
  `</contentitem>` |
  `. . .` |
  `</contentdetail>` |
  `<publishingdetail>` | Block 4
  `. . .` |
  `<publisher>` | (of the audio omnibus)
  `<b291>01</b291>` |
  `<b081>Recorded Books Inc</b081>` |
  `</publisher>` |
  `. . .` |
  `<copyrightstatement>` |
  `<x512>P</x512>` | Phonogram right (for the whole omnibus)
  `<b087>2024</b087>` |
  `<copyrightowner>` |
  `<b047>Recorded Books, Inc</b047>` |
  `</copyrightowner>` |
  `</copyrightstatement>` |
  `. . .` |
  `</publishingdetail>` |

  The omnibus (Worlds of Exile and Illusion) contains three works, each with different title and copyright details in Block 3. The audio publisher owns or licenses the phonogram right for the recording of the entire omnibus, detailed in Block 4. The textual copyrights are specific to each book in the omnibus (ie to each content item).

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

Recipients should use the Level sequence number to order the various content items for display, and should as far as possible ensure the nesting or indentation of content items also follows the Level sequence – but the Level sequence number itself should not be displayed. The displayed numbering or naming of each content item should use <ComponentTypeName> and <ComponentNumber>, or <TitleDetail> (or both).

##### Text item composite

<ContentItem> must include either a <TextItem> composite or an <AVItem> composite. The former is used for paged media (but including reflowable text, where there is no clear pagination), and the latter for time-based, audio and audiovisual media.

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

  For reflowable text, a <TextItem> composite should not usually include the <PageRun>, <FirstPageNumber> and <LastPageNumber> elements unless the numbering can be taken from the print-equivalent page numbering (see List 196 code 19) and an identifier of the print-equivalent product is specified in <RelatedProduct> using Product relation code 13 from List 51. This is equivalent to specifying a page extent in <Extent> using Extent type code 08 from List 23. Note that the use of a Notional page count (equivalent to <Extent> using Extent type code 10) makes little sense with <FirstPageNumber> and <LastPageNumber>, but could be used with <NumberOfPages> to indicate the relative size of chapters.

##### Audiovisual item composite

<ContentItem> must include either a Text item or an Audiovisual item. The latter is used for time-based media such as audiobooks or video material.

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 within 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 time-based bookmarks and durations for each chapter or section can also be included within <AVItem>.

  Chapter level metadata for a digital audiobook
  using Reference names |
  --- | ---
  `<ContentDetail>` |
  `<ContentItem>` |
  `<LevelSequenceNumber>1</LevelSequenceNumber>` |
  `<AVItem>` |
  `<AVItemType>02</AVItemType>` |
  `<TimeRun>` |
  `<StartTime>000000000</StartTime>` |
  `</TimeRun>` |
  `<AVDuration>000011810</AVDuration>` |
  `</AVItem>` |
  `<TitleDetail>` |
  `<TitleType>01</TitleType>` |
  `<TitleElement>` |
  `<TitleElementLevel>04</TitleElementLevel>` |
  `<NoPrefix/>` |
  `<TitleWithoutPrefix textcase="02">Opening Credits​</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `</TitleDetail>` |
  `</ContentItem>` |
  `<ContentItem>` |
  `<LevelSequenceNumber>2</LevelSequenceNumber>` |
  `<AVItem>` |
  `<AVItemType>03</AVItemType>` |
  `<TimeRun>` |
  `<StartTime>000011810</StartTime>` |
  `</TimeRun>` |
  `<AVDuration>000001350</AVDuration>` |
  `</AVItem>` |
  `<ComponentTypeName>PART</ComponentTypeName>` |
  `<ComponentNumber>1</ComponentTypeName>` |
  `<TitleDetail>` |
  `<TitleType>01</TitleType>` |
  `<TitleElement>` |
  `<TitleElementLevel>04</TitleElementLevel>` |
  `<TitlePrefix textcase="03">THE</TitlePrefix>` |
  `<TitleWithoutPrefix textcase="03">REIGN OF TERROR ON THE STEPPE: 1162–1206</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `</TitleDetail>` |
  `</ContentItem>` |
  `<ContentItem>` |
  `<LevelSequenceNumber>2.1</LevelSequenceNumber>` |
  `<AVItem>` |
  `<AVItemType>03</AVItemType>` |
  `<TimeRun>` |
  `<StartTime>000013160</StartTime>` |
  `</TimeRun>` |
  `<AVDuration>001264640</AVDuration>` |
  `</AVItem>` |
  `<ComponentTypeName>Chapter</ComponentTypeName>` |
  `<ComponentNumber>1</ComponentTypeName>` |
  `<TitleDetail>` |
  `<TitleType>01</TitleType>` |
  `<TitleElement>` |
  `<TitleElementLevel>04</TitleElementLevel>` |
  `<TitlePrefix textcase="02">The</TitlePrefix>` |
  `<TitleWithoutPrefix textcase="02">Blood Clot​</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `</TitleDetail>` |
  `</ContentItem>` |
  `<ContentItem>` |
  `<LevelSequenceNumber>2.2</LevelSequenceNumber>` |
  `<AVItem>` |
  `<AVItemType>03</AVItemType>` |
  `<TimeRun>` |
  `<StartTime>001281800</StartTime>` |
  `</TimeRun>` |
  `<AVDuration>001113070</AVDuration>` |
  `</AVItem>` |
  `<ComponentTypeName>Chapter</ComponentTypeName>` |
  `<ComponentNumber>2</ComponentTypeName>` |
  `<TitleDetail>` |
  `<TitleType>01</TitleType>` |
  `<TitleElement>` |
  `<TitleElementLevel>04</TitleElementLevel>` |
  `<NoPrefix/>` |
  `<TitleWithoutPrefix textcase="02">Tale of the Rivers​</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `</TitleDetail>` |
  `</ContentItem>` |
  `<ContentItem>` |
  `<LevelSequenceNumber>2.3</LevelSequenceNumber>` |
  `<AVItem>` |
  `<AVItemType>03</AVItemType>` |
  `<TimeRun>` |
  `<StartTime>002394870</StartTime>` |
  `</TimeRun>` |
  `<AVDuration>001105950</AVDuration>` |
  `</AVItem>` |
  `<ComponentTypeName>Chapter</ComponentTypeName>` |
  `<ComponentNumber>3</ComponentTypeName>` |
  `<TitleDetail>` |
  `<TitleType>01</TitleType>` |
  `<TitleElement>` |
  `<TitleElementLevel>04</TitleElementLevel>` |
  `<NoPrefix/>` |
  `<TitleWithoutPrefix textcase="02">War of the Khans​</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `</TitleDetail>` |
  `</ContentItem>` |
  `<ContentItem>` |
  `<LevelSequenceNumber>3</LevelSequenceNumber>` |
  `<AVItem>` |
  `<AVItemType>03</AVItemType>` |
  `<TimeRun>` |
  `<StartTime>003504820</StartTime>` |
  `</TimeRun>` |
  `<AVDuration>000001150</AVDuration>` |
  `</AVItem>` |
  `<ComponentTypeName>PART</ComponentTypeName>` |
  `<ComponentNumber>2</ComponentTypeName>` |
  `<TitleDetail>` |
  `<TitleType>01</TitleType>` |
  `<TitleElement>` |
  `<TitleElementLevel>04</TitleElementLevel>` |
  `<TitlePrefix textcase="03">THE</TitlePrefix>` |
  `<TitleWithoutPrefix textcase="03">MONGOL WORLD WAR: 1211–1261</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `</TitleDetail>` |
  `</ContentItem>` |
  `<ContentItem>` |
  `<LevelSequenceNumber>3.1</LevelSequenceNumber>` |
  `<AVItem>` |
  `<AVItemType>03</AVItemType>` |
  `<TimeRun>` |
  `<StartTime>003505970</StartTime>` |
  `</TimeRun>` |
  `<AVDuration>001193320</AVDuration>` |
  `</AVItem>` |
  `<ComponentTypeName>Chapter</ComponentTypeName>` |
  `<ComponentNumber>4</ComponentTypeName>` |
  `<TitleDetail>` |
  `<TitleType>01</TitleType>` |
  `<TitleElement>` |
  `<TitleElementLevel>04</TitleElementLevel>` |
  `<NoPrefix/>` |
  `<TitleWithoutPrefix textcase="02">Spitting on the Golden Khan​</TitleWithoutPrefix>` |
  `</TitleElement>` |
  `</TitleDetail>` |
  `</ContentItem>` |
  `. . .` |
  `</ContentDetail>` |

  using Short tags |
  --- | ---
  `<contentdetail>` |
  `<contentitem>` |
  `<b284>1</b284>` | First item in TOC
  `<avitem>` |
  `<x540>02</x540>` |
  `<timerun>` |
  `<x542>000000000</x542>` | Starts at beginning
  `</timerun>` |
  `<x544>000011810</x544>` | 78.1 seconds long
  `</avitem>` |
  `<titledetail>` |
  `<b202>01</b202>` |
  `<titleelement>` |
  `<x409>04</x409>` |
  `<x501/>` |
  `<b031 textcase="02">Opening Credits​</b031>` |
  `</titleelement>` |
  `</titledetail>` |
  `</contentitem>` |
  `<contentitem>` |
  `<b284>2</b284>` | Second top-level item in TOC
  `<avitem>` |
  `<x540>03</x540>` |
  `<timerun>` |
  `<x542>000011810</x542>` | Starts 78.1 seconds from beginning
  `</timerun>` |
  `<x544>000001350</x544>` | 13.5 seconds long
  `</avitem>` |
  `<b288>PART</b288>` |
  `<b289>1</b289>` |
  `<titledetail>` |
  `<b202>01</b202>` |
  `<titleelement>` |
  `<x409>04</x409>` |
  `<b030 textcase="03">THE</b030>` | Note use of textcase
  `<b031 textcase="03">REIGN OF TERROR ON THE STEPPE: 1162–1206​</b031>` |
  `</titleelement>` |
  `</titledetail>` |
  `</contentitem>` |
  `<contentitem>` |
  `<b284>2.1</b284>` | First sub-item of second item
  `<avitem>` |
  `<x540>03</x540>` |
  `<timerun>` |
  `<x542>000013160</x542>` | Starts 1m 31.6s from beginning (ie 78.1s + 13.5s)
  `</timerun>` |
  `<x544>001264640</x544>` | 1hr 26m 46.4s long
  `</avitem>` |
  `<b288>Chapter</b288>` |
  `<b289>1</b289>` |
  `<titledetail>` |
  `<b202>01</b202>` |
  `<titleelement>` |
  `<x409>04</x409>` |
  `<b030 textcase="02">The</b030>` |
  `<b031 textcase="02">Blood Clot</b031>` |
  `</titleelement>` |
  `</titledetail>` |
  `</contentitem>` |
  `<contentitem>` |
  `<b284>2.2</b284>` | Second sub-item of second item
  `<avitem>` |
  `<x540>03</x540>` |
  `<timerun>` |
  `<x542>001281800</x542>` | Starts 1m 31.6s + 1hr 26m 46.4s from beginning (ie at 1hr 28m 18s)
  `</timerun>` |
  `<x544>001113070</x544>` |
  `</avitem>` |
  `<b288>Chapter</b288>` |
  `<b289>2</b289>` |
  `<titledetail>` |
  `<b202>01</b202>` |
  `<titleelement>` |
  `<x409>04</x409>` |
  `<x501/>` |
  `<b031 textcase="02">Tale of the Rivers</b031>` |
  `</titleelement>` |
  `</titledetail>` |
  `</contentitem>` |
  `<contentitem>` |
  `<b284>2.3</b284>` | Third sub-item of second item
  `<avitem>` |
  `<x540>03</x540>` |
  `<timerun>` |
  `<x542>002394870</x542>` |
  `</timerun>` |
  `<x544>001105950</x544>` |
  `</avitem>` |
  `<b288>Chapter</b288>` |
  `<b289>3</b289>` |
  `<titledetail>` |
  `<b202>01</b202>` |
  `<titleelement>` |
  `<x409>04</x409>` |
  `<x501/>` |
  `<b031 textcase="02">War of the Khans</b031>` |
  `</titleelement>` |
  `</titledetail>` |
  `</contentitem>` |
  `<contentitem>` |
  `<b284>3</b284>` | Third top-level item in TOC
  `<avitem>` |
  `<x540>03</x540>` |
  `<timerun>` |
  `<x542>003504820</x542>` |
  `</timerun>` |
  `<x544>000001150</x544>` |
  `</avitem>` |
  `<b288>PART</b288>` |
  `<b289>2</b289>` |
  `<titledetail>` |
  `<b202>01</b202>` |
  `<titleelement>` |
  `<x409>04</x409>` |
  `<b030 textcase="03">THE</b030>` |
  `<b031 textcase="03">MONGOL WORLD WAR: 1211–1261</b031>` |
  `</titleelement>` |
  `</titledetail>` |
  `</contentitem>` |
  `<contentitem>` |
  `<b284>3.1</b284>` | First sub-item of third item
  `<avitem>` |
  `<x540>03</x540>` |
  `<timerun>` |
  `<x542>003505970</x542>` |
  `</timerun>` |
  `<x544>001193320</x544>` | Ends at 5h 10m 32.9s
  `</avitem>` |
  `<b288>Chapter</b288>` |
  `<b289>4</b289>` |
  `<titledetail>` |
  `<b202>01</b202>` |
  `<titleelement>` |
  `<x409>04</x409>` |
  `<x501/>` |
  `<b031 textcase="02">Spitting on the Golden Khan</b031>` |
  `</titleelement>` |
  `</titledetail>` |
  `</contentitem>` |
  `. . .` |
  `</contentdetail>` |

  The Level sequence number is used to ensure the various <ContentItem> composites are used by the data recipient in the right order. As with <SequenceNumber> within <Contributor>, do not rely on the order the <ContentItem> composites appear in the XML file. The Level sequence number also indicates the structure of the various entries in the table of contents – and this is often displayed by the recipient using indentation.

  The table of contents above should look like this:

  - Opening Credits
  - PART 1: THE REIGN OF TERROR ON THE STEPPE: 1162–1206
    - Chapter 1: The Blood Clot
    - Chapter 2: Tale of the Rivers
    - Chapter 3: The War of the Khans
  - PART 2: THE MONGOL WORLD WAR: 1211–1261
    - Chapter 4: Spitting on the Golden Khan
    - . . .

  and each item in the table of contents has a time-based bookmark – in fact a start time and a duration. The durations for PART 1 and PART 2 above only include the title announcement.

  Detailed timing data extracted from the above example
  Level seq num | Title (comprising Component type and number and Title detail) | Start | Duration | End (calculated)
  --- | --- | --- | --- | ---
  1 |  | Opening credits | 0:00:00.00 | 0:01:18.10 | 0:01:18.10
  2 |  | PART 1: THE REIGN OF TERROR ON THE STEPPE: 1162–1206 | 0:01:18.10 | 0:00:13.50 | 0:01:31.60
  | 2.1 |  | Chapter 1: The Blood Clot | 0:01:31.60 | 1:26:46.40 | 1:28:18.00
  | 2.2 |  | Chapter 2: Tale of the Rivers | 1:28:18.00 | 1:11:30.70 | 2:39:48.70
  | 2.3 |  | Chapter 3: War of the Khans | 2:39:48.70 | 1:10:59.50 | 3:50:48.20
  3 |  | PART 2: MONGOL WORLD WAR: 1211–1261 | 3:50:48.20 | 0:00:11.50 | 3:50:59.70
  | 3.1 |  | Chapter 4: Spitting on the Golden Khan | 3:50:59.70 | 1:19:33.20 | 5:10:32.90

  Note that in the example above, the numbering of each chapter and part is made explicit in the <ComponentTypeName> and <ComponentNumber> fields, and this combines with the chapter and part titles in <TitleDetail> – this is best practice. If this cannot be supported, a simpler approach would be to include the chapter and part numbering within <TitleDetail>, using <PartNumber> However, the ordering and indentation structure of the chapters and parts should always follow <LevelSequenceNumber>.

  As noted, the durations of PART 1 and PART 2 are just a few seconds each, because the durations consists only of the Part number announcement itself. It may appear more natural for the duration of each part to include the total of the durations of the chapters within that part. So in this alternative approach, the <AVDuration> for PART 1 could be 13.5s (for the Part number announcement) plus 1hr 26m 14.4s, 1hr 11m 30.7s and 1h 10m 59.5s (for the durations of its three constituent chapters), a total of 3h 49m 30.1s:

  `<AVDuration>003493010</AVDuration>` |

  There is no strong technical reason to prefer the method used in the example to this alternative approach, and the only likely visible effect would be when a duration from the ONIX is displayed. However, the sum of the durations will no longer be the same as the total duration of the complete audiobook recorded in <Extent> – including the durations of the chapters within each part runs the risk of double-counting – and so this alternative approach is not recommended. As a matter of best practice, the listed durations should never ‘overlap’ or include sub-items. The duration of a content item with sub-items, like the PARTs above, should consist of only the duration of any announcement plus any content that is outside of the sub-items (eg a part introduction or part summary, separate from the chapters themselves). Note that in any case, the duration is optional and – if not provided, or if ignored – could be calculated by the ONIX recipient.

  AV timing counts from the beginning of the product. It is common to split audio or video material into files or ‘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 at best, and may be meaningless unless accompanied by a manifest detailing each chunk – and this manifest would in turn need to be kept up to date during any audio editing or re-chunking.

  Block 8 can include such a manifest. However, timings are measured from the beginning of the product and are independent of the details of the files or chunks, and therefore Block 3 can be used without prior knowledge of the chunking details and without worry that those details will change, and is entirely independent of Block 8. Block 3 supports navigation within an AV product, whereas Block 8 concerns production and packaging of a digital AV product.

  Timings for chapter three (when there is no chapter title)
  using Reference names |
  --- | ---
  `<ContentItem>` |
  `<LevelSequenceNumber>4</LevelSequenceNumber>` |
  `<AVItem>` |
  `<AVItemType>03</AVItemType>` |
  `<TimeRun>` |
  `<StartTime>0010721</StartTime>` |
  `<EndTime>0013214</EndTime>` |
  `</TimeRun>` |
  `<AVDuration>0002453</AVDuration>` |
  `</AVItem>` |
  `<ComponentTypeName>Chapter</ComponentTypeName>` |
  `<ComponentNumber>3</ComponentNumber>` |
  `. . .` |
  `</ContentItem>` |

  using Short tags |
  --- | ---
  `<contentitem>` |
  `<b284>4</b284>` |
  `<avitem>` |
  `<x540>03</x540>` |
  `<timerun>` |
  `<x542>0010721</x542>` | 67 mins 21 secs from beginning
  `<x543>0013214</x543>` |
  `</timerun>` |
  `<x544>0002453</x544>` | 24 mins 52 secs long
  `</avitem>` |
  `<b288>Chapter</b288>` | Generic TOC entry
  `<b289>3</b289>` |
  `. . .` |
  `</contentitem>` |

##### P.18.9, P.18.10 Component type name and number

Note the contrast with <LevelSequenceNumber>. The Level sequence number is concerned only with the ordering and hierarchy of Content items within <ContentDetail> – the logical structure of the table of contents, whereas <ComponentTypeName> and <ComponentNumber> must match the naming and numbering scheme used within the product itself. So Chapter 2 would be Component type name ‘Chapter’ and Component number 2, but could have the Level sequence number 2.2 – or 3, or 3.2, or something else – depending on the number of preceding Content items and its hierarchical position (3.2 indicates the second subitem of the third top level item of the table of contents).

Note also the potential overlap between Component type name and number and data elements within <TitleDetail>: in general, use <ComponentTypeName> and <ComponentNumber> 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. Prefer <TitleDetail> instead for the titles of each content item. But often, the Component name and number should be combined, where for example the book includes chapter headings of the form ‘Chapter 7: Crack propagation in concrete’ – it is good practice to use Component type name and number rather than including ‘Chapter 7’ within <TitleDetail>.

##### Title detail composite (content item)

Within the <ContentItem> context, <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 (content item) to Related product composite (content item)

These composites are identical to those in Groups P.7, P.10, P.12, P.14, P.15, P.16, P.19, P.20 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.

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

- the Notification type is 04 (a block-level partial update) and no data elements in Block 4 have been updated since a previous message;
- the Notification type is 05 (a record deletion), in which case Blocks 1–8 are wholly unnecessary.

When present, the Block must include, at minimum, either an <Imprint> or <Publisher> composite, and should normally contain both. In most circumstances, it should also specify the global Publishing status, Publication date and Sales rights.

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

The publisher is legally responsible for a product, and the identity of the publisher is an important data point in commercial transactions concerning that product. It may also be important to resellers and end-customers – although the imprint (the branding the publisher affixes to the product) might be more recognizable to booksellers, librarians and readers. Both publisher and imprint are used industry-wide for marketing, sales reporting and analysis.

For open access publishing, the <Publisher> composite can also name the body funding publication. For non-book products, the principle that the ‘publisher’ is the organization responsible for making the product available should be followed.

The <PublishingDetail> composite must include details of imprint or publisher. It should include both – even if they appear to be the same. It is good practice to also provide the city and country of publication.

Some countries and agencies maintain formal identifier schemes for imprints or publishers. Where such identifiers are used, they should be included in the <Imprint> and <Publisher> composites.

Common issues in Group P.19:

- confusion between imprint and publisher – an imprint is a ‘brand name’ and a publisher is a legal entity.

<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, customer service contact detail
  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>` |
  `<ProductContact>` |
  `<ProductContactRole>99</ProductContactRole>` |
  `<ProductContactName>Abteilung Kundenanfragen, Gabler Verlag</ProductContactName>` |
  `<ContactName>Erika Mustermann</ContactName>` |
  `<EmailAddress>e.mustermann@gabler.de</EmailAddress>` |
  `</ProductContact>` |

  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>` |
  `<b081>Gabler Verlag</b081>` |
  `<website>` |
  `<b367>18</b367>` | Publisher’s consumer website
  `<b295>http://www.​gabler.​de/​</b295>` |
  `</website>` |
  `</publisher>` |
  `<b209>Wiesbaden</b209>` |
  `<b083>DE</b083>` |
  `<productcontact>` |
  `<x482>99</x482>` | Customer services general enquiries
  `<x484>Abteilung Kundenanfragen, Gabler Verlag</x484>` |
  `<x299>Erika Mustermann</x299>` |
  `<j272>e.mustermann@gabler.de</j272>` |
  `</productcontact>` |

  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>` |
  `<Supplier>` |
  `. . .` |
  `</Supplier>` |
  `<ReturnsConditions>` |
  `. . .` |
  `</ReturnsConditions>` |
  `<ProductAvailability>51</ProductAvailability>` |
  `<SupplyDate>` |
  `. . .` |
  `</SupplyDate` |
  `<NewSupplier>` |
  `. . .` |
  `</NewSupplier>` |
  `</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>` |
  `<supplier>` | Old supplier
  `. . .` |
  `</supplier>` |
  `<returnsconditions>` | Returns conditions
  `. . .` |
  `</returnsconditions>` |
  `<j396>51</j396>` | Publisher no longer sells product in market
  `<supplydate>` | Last date for returns
  `. . .` |
  `</supplydate` |
  `<newsupplier>` | Refer to new supplier
  `. . .` |
  `</newsupplier>` |
  `</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 ID may give
  `<b233>HCP UK List Codes</b233>` | more granular details
  `<b244>HCUKCNF</b244>` | of sub-brands where
  `</imprintidentifier>` | necessary
  `<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 – are unnecessary unless used to disambiguate several organizations with similar names.

In some countries, national libraries or other agencies maintain authoritative publisher identifiers (for example the Deutsche Nationalbibliothek publisher identifier). Many publishers already have ISNIs (International Standard Name Identifiers). 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 a GLN or a SAN (of course, a location identifier like 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>` |

  Publisher, with identification of internal divisions or business units
  using Reference names |
  --- | ---
  `<Publisher>` |
  `<PublishingRole>01</PublishingRole>` |
  `<PublisherIdentifier>` |
  `<PublisherIDType>07</PublisherIDType>` |
  `<IDValue>0095397</IDValue>` |
  `</PublisherIdentifier>` |
  `<PublisherIdentifier>` |
  `<PublisherIDType>16</PublisherIDType>` |
  `<IDValue>0000000122929185</IDValue>` |
  `</PublisherIdentifier>` |
  `<PublisherIdentifier>` |
  `<PublisherIDType>01</PublisherIDType>` |
  `<IDTypeName>OUP division ID</IDTypeName>` |
  `<IDValue>0095397-ELT</IDValue>` |
  `</PublisherIdentifier>` |
  `<PublisherName>Oxford University Press</PublisherName>` |
  `</Publisher>` |

  using Short tags |
  --- | ---
  `<publisher>` |
  `<b291>01</b291>` |
  `<publisheridentifier>` |
  `<x447>07</x447>` |
  `<b244>0095397</b244>` | SAN
  `</publisheridentifier>` |
  `<publisheridentifier>` |
  `<x447>16</x447>` | ISNI
  `<b244>0000000122929185</b244>` |
  `</publisheridentifier>` |
  `<publisheridentifier>` |
  `<x447>01</x447>` | Proprietary
  `<b233>OUP division ID</b233>` |
  `<b244>0095397-ELT</b244>` |
  `</publisheridentifier>` |
  `<b081>Oxford University Press</b081>` |
  `</publisher>` |

  The example above shows how a proprietary identification scheme can be used where it is necessary to provide extra information about internal business units within the publisher, particularly where business units and imprints or brands do not align (eg where different business units use the same imprint, or where a single business unit uses a mix of imprints). This same technique can also be used within <Imprint> (see the example example above). The proprietary Publisher ID method is preferred to differentiate business units that share use of the same imprints or branding, whereas the proprietary Imprint ID method is preferred to identify multiple imprints, brands and sub-brands within a single small publisher or within a business unit of a larger publisher. For a large publisher with a complex mix of imprints or brands and business units, both methods might be necessary.

##### 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>;
- within <Publisher>;
- within <PromotionalEvent>;
- within <PublisherRepresentative>;
- within <NewSupplier>;
- 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 perhaps on occasion the www part are 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>` |

Another use for the Website composite – most particularly for academic and scholarly publishing – is to indicate that a digital product has been lodged with a long-term preservation service such as CLOCKSS or Portico. These services store digital resources such as e‑books or research data in a ‘dark archive’ that seeks to preserve the scholarly record for posterity. Archives are not accessible to readers, but may be made accessible in the future in response to some catastrophic ‘trigger event’ that prevents access to ordinary copies held in libraries. Preservation in such an archive is increasingly important for publishers, as it becomes a prerequisite for sales to libraries.

Similar preservation may also be a feature of national digital legal deposit schemes.

Preservation can be indicated using the Website composite in the context of the entity responsible for lodging a copy with the archive service - so typically in the <Publisher> context – and using Website role code 48. There are separate role codes for first-party archiving and legal deposit schemes.

  book lodged by the publisher with a digital preservation service
  using Reference names |
  --- | ---
  `<Publisher>` |
  `<PublishingRole>01</PublishingRole>` |
  `<PublisherName>Wouters Kluwer</PublisherName>` |
  `<Website>` |
  `<WebsiteRole>18</WebsiteRole>` |
  `<WebsiteLink>https://www.wolterskluwer.com</WebsiteLink>` |
  `</Website>` |
  `<Website>` |
  `<WebsiteRole>48</WebsiteRole>` |
  `<WebsiteLink>https://clockss.org</WebsiteLink>` |
  `</Website>` |
  `</Publisher>` |

  using Short tags |
  --- | ---
  `<publisher>` |
  `<b291>01</b291>` |
  `<b081>Wolters Kluwer</b081>` |
  `<website>` |
  `<b367>18</b367>` |
  `<b295>https://www.wolterskluwer.com</b295>` |
  `</website>` |
  `<website>` |
  `<b367>48</b367>` | Third-party digital preservation service
  `<b295>https://clockss.org</b295>` |
  `</website>` |
  `</publisher>` |

  The preservation link serves both as a flag that indicates the product is preserved, and a locator for where it is preserved. The context in which the link is provided – in this case within <Publisher> – suggests who lodged it in the preservation service, so the Website composite may be provided within <Contributor> if the author is responsible for lodging the copy with a preservation service.
  The URL is normally a link to the top level of the archiving service’s website (ie to https://clockss.org in the example). However, a deeper link may link directly to metadata about the preservation – date, status and so on – if this is exposed publicly by the archive.

##### 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 or legal entity that produced the product is based, and this should usually also be the country from whose ISBN agency allocation 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.

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.

  Note that the <ProductContactIdentifier> and <ProductContactName> refer to an organization, not to a specific person. The contact name and e‑mail address refer to a person or department within that organization.

A direct contact like this might help facilitate particular retail promotions, author tours, rights deals or access to the publisher’s production files to meet the needs of print-impaired readers. Such contact details are often business-to-business contacts, and data recipients must not use them in consumer-facing contexts unless this is the clear intention of the data sender.

A recipient might reasonably treat accessibility, evaluation copy and safety contacts as public. A data sender might well use departmental rather than personal contact details for contacts that are intended to be made public, for example by using ‘dipartimento di sicurezza’ and ‘sicurezza@mondadorilibri.it’ in the second example.

  providing promotional contact details
  using Reference names |
  --- | ---
  `<ProductContact>` |
  `<ProductContactRole>02</ProductContactRole>` |
  `<ProductContactName>Effectiv Promos LLC</ProductContactName>` |
  `<ContactName>Georgia Fremont</ContactName>` |
  `<TelephoneNumber>+1 212 555 0123</TelephoneNumber>` |
  `<EmailAddress>gfremont@effectiv.com</EmailAddress>` |
  `</ProductContact>` |

  using Short tags |
  --- | ---
  `<productcontact>` |
  `<x482>02</x482>` | Promotional contact
  `<x484>Effectiv Promos LLC</x484>` |
  `<x299>Georgia Fremont</x299>` |
  `<j270>+1 212 555 0123</j270>` |
  `<j272>gfremont@effectiv.com</j272>` |
  `</productcontact>` |

  providing product safety contact details, to comply with EU GPSR regulations
  using Reference names |
  --- | ---
  `<ProductContact>` |
  `<ProductContactRole>10</ProductContactRole>` |
  `<ProductContactName>Mondadori Libri SpA</ProductContactName>` |
  `<ContactName>Giacinta Zampa</ContactName>` |
  `<EmailAddress>g.zampa@mondadorilibri.it</EmailAddress>` |
  `<StreetAddress>Via Mondadori 1</StreetAddress>` |
  `<LocationName>Segrate</LocationName>` |
  `<PostalCode>MI 20090</PostalCode>` |
  `<CountryCode>IT</CountryCode>` |
  `</ProductContact>` |

  using Short tags |
  --- | ---
  `<productcontact>` |
  `<x482>10</x482>` | Product safety contact
  `<x484>Mondadori Libri SpA</x484>` |
  `<x299>Giacinta Zampa</x299>` |
  `<j272>g.zampa@mondadorilibri.it</j272>` |
  `<StreetAddress>Via Mondadori 1</StreetAddress>` | Street, location (town or city),
  `<LocationName>Segrate</LocationName>` | postal code and either
  `<PostalCode>MI 20090</PostalCode>` | region or country form a
  `<CountryCode>IT</CountryCode>` | postal address
  `</productcontact>` |

  For most types of contact, the postal address (<StreetAddress> to <CountryCode>) is optional and usually omitted.

  For GPSR purposes with publishers based within the EU, the Product contact name should be the full legal name of the organization, even though a less formal name (eg without SPA, Inc, SA or GmbH) might be provided in <PublisherName>. E‑mail address and a postal address are also required. Care should be taken to ensure that the Product contact name, Contact name, Street address, Location name, Postal code, region and country can be assembled into a complete postal address, without repetition. Include a Region code if the state, province or territory is necessary and not already encoded in the Postal code.

  For publishers based outside but selling products within the EU, the Product safety contact should be the full legal name of an authorized representative within the EU, for example a subsidiary company or a sales agent / ‘local publisher’ – for which use <PublisherRepresentative> and <ProductContact> within Block 6 – or the distributor responsible for the EU market – for which use <Supplier> and <SupplyContact> within Block 6.

#### 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 (though P.20 is generally preferred). 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.

Group P.20 contains metadata describing the lifecycle of the book, as seen from the publisher’s point of view: is the book yet to be published, has it been published and is now commercially active or was it abandoned before publication, or has it reached the end of its life and declared out of print? Each of these statuses – with relevant dates – is critical to distributors, wholesalers, libraries and retailers, in order to plan for and manage expectations of forthcoming publications, and to provide good customer service until and beyond the end of each product’s commercial life.

And the most relevant date is the publication date – essentially all planning for production, marketing, advertising and promotion, distribution, retail purchasing – and often end purchaser sales – revolves around the nominal publication date (even if this is not the exact date on which the product becomes available for retail sale). This date is critical to every party in the supply chain.

For more detail on this and other key dates, see EDItEUR’s application note Lifecycle dates in ONIX (doi:10.4400/nxak).

The <PublishingDetail> composite should include a ‘global’ status in the <PublishingStatus> data element. Why ‘global’? This is to differentiate the publisher’s singular view of the publishing status from any market-specific or ‘local’ status provided in Block 6 that might override the global status in a particular market. It does not imply the product is or must be on sale in every country – it is the <SalesRights> that describe the various countries the product is intended to be on sale.

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

As for the publishing status, these are ‘global’ dates which may sometimes be overridden for individual markets in Block 6. If there are multiple, market-specific publication dates, the ‘global’ date is the earliest – from the publisher’s point of view, the product is published as soon as it is published in any of several markets. And a product is out of print ‘globally’ when it is out of print in all of several markets.

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 sales 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 – the relationship is somewhat approximate. If a publisher wishes to control the exact date a book goes on sale, a sales embargo date (sometimes termed an ‘on sale date’) must be specified separately. 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;
- similarly, publishers sending a ‘canceled’ or ‘abandoned before publication’ (<PublishingStatus> code 01) after products have been published;
- use of dummy dates such as 31/12/2099 with ‘special’ meanings;
- use of the term ‘on sale date’. <OnSaleDate> was introduced in ONIX 2.0, and was always defined as an embargo. Unfortunately, the term was widely misunderstood. Use ‘sales embargo date’ instead;
- confusion between publication date and date of first publication (the former is the publication date of this manifestation, the latter is the publication date of the very first manifestation of the work);
- data recipients who cannot or do not respect Public announcement and Trade announcement dates. These affect when a Product record can re-distributed to other organizations, or can be added to a public-facing website;
- never sending <PublishingStatus> codes 01 (Cancelled) or 03 (Postponed indefinitely). This can happen where the publisher sends ONIX record for ‘products due to be published in the next 8 months’ – because the publication date for the abandoned or postponed product no longer exists or falls outside of the ‘window’. Metadata for newly-abandoned or newly-postponed products should be sent once so the new status can be recorded by data recipients, and only subsequently removed from the data feed.

  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.

  publication significantly or indefinitely postponed
  using Reference names |
  --- | ---
  `<PublishingStatus>03</PublishingStatus>` |
  `<!-- publication date must not be included -->` |

  using Short tags |
  --- | ---
  `<b394>03</b394>` | Postponed indefinitely
  `<!-- publication date must not be included -->` |

  It is reasonable for data senders to treat ‘postponed by a year’ as ‘postponed indefinitely’. If a data sender typically sends metadata for products planned to be published within, say, 8 months, and planned publication of a product that has already been announced is postponed beyond 8 months, the data sender should send an update using Publishing status code 03 (and no publication date – even though the new date might well be known). No further update is then necessary until the new date falls within the 8-month window again or the planned publication is abandoned. (This may not be worth doing if the postponement puts publication only just outside the window.)

##### P.20.1 Publishing status

This is the product’s global status as defined by the publisher. ‘Global’ here serves to differentiate the Publishing status from a Market publishing status in Block 6, which may override the global status in a specific market.

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

For e‑books and other digital products, code 17 indicates ‘permanently withdrawn from sale’ – the digital equivalent of ‘out of print’. The distinction is that for physical products, an Out of print status implies that business-to-business trading and retail sales of any copies already n the supply chain (eg of stock held at a wholesaler) may continue, whereas for digital products there is no stock and thus no further sales after the product is permanently withdrawn.

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.

The dates here are ‘global’, in the sense that they are viewed from the publisher’s point of view (and without any implication that the product will be available in all countries), and where there are multiple markets in Block 6, they can be overridden by Market dates provided for a specific market.

  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 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 between (and even within) publishers, libraries and resellers 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’) for 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;
  - note – almost all ONIX Product records should include a publication date, except where the <PublishingStatus> precludes it (eg if a planned product has been cancelled or abandoned prior to publication);
  - 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 a sales embargo date has been set. In the absence of an embargo, fulfillment to consumers may begin as soon as stock is available;
  - 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;
  - but 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;
  - some publishers choose to term the earliest date on which a consumer may take possession of a product as a ‘publication date’ in their internal terminology. 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;
  - librarians often view the Date of first publication as the ‘publication 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, and in reality represent delayed availability in those markets;
  - 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 – if supplied, the sales embargo date is the earliest date on which a customer can take possession of a product (ie it is the date the embargo expires). In general – and in the absence of a sales embargo date – 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 more precisely, 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;
  - note – almost all products have a publication date (specifically in ONIX, all except those that are cancelled or abandoned before publication and those that are postponed indefinitely), whereas only some have a sales embargo date;
  - publication date is sometimes described as a ‘soft’ date, in contrast to a ‘hard’ sales embargo date;
  - embargoes are set by the publisher, so they are normally carried in <PublishingDate>. Occasionally, embargoes apply only within one of several markets, or they differ across markets, so a market-specific embargo may be carried in <MarketDate>;
    - as with publication dates, a global embargo would be the earliest of any market-specific embargoes (unless there is a market in which the product is not embargoed at all, in which case no global embargo should be set). Occasionally, the embargo in a particular market may be 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 rarely, a special embargo might apply only to copies sourced from a specific supplier;
    - data recipients should take care to obey the most specific embargo that applies, global, market or even supplier-specific. An embargo in Supply date 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, any 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’, ‘street 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, but which the publisher nevertheless expects retailers to honor. In ONIX, they are treated the same as strict dates: retailers are expected to honor strict and non-strict sales embargoes identically (ie whether an affidavit exists or not), and retail fulfillment should only begin when the sales embargo expires. Other North American publishers consider a non-strict on sale date as the absence of an embargo, in which case, no sales embargo date should be set on ONIX;
  - 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 sales 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 – stock is released from the warehouse and shipping to the customer begins. 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 then immediately be placed on sale to end-customers;
  - 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 warehouse ‘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. The ‘work’ here should be understood as being a distinct intellectual property from which any number of products (or manifestations) can be made, and which can be modified to create other ‘derived works’. The work in question may be identified in Group P.22;
  - for a typical hardback, in many cases, the Publication date and the Date of first publication may be identical, since the hardback is the first publication of the content. For a typical mass-market paperback – which is not the first publication of the content, the Date of first publication is the Publication date of the original equivalent hardback. For a contemporary copy of Pride and Prejudice, the Date of first publication is 1813;
  - for an e‑book, the Date of first publication 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 a second or subsequent edition, the Date of first publication refers to earliest publication of this second or subsequent edition, not the earliest publication of the first edition, since each new edition is a new work (albeit derived from the previous edition);
  - for works in translation, the Date of first publication refers to the first publication of this particular translation;
  - for works in translation only, the Date of first publication in original language is the Date of first publication, as above, for the ‘grandparent work’ from which the current ‘parent’ 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 (in English) is 2008, but the Date of first publication in the 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);
  - for unabridged audio products, the Date of first publication may refer to the earliest publication of a print product if it was published earlier than the audio. However, abridged versions constitute a new (derived) work, so the Date of first publication would be the first publication of the abridged audio;
  - some librarians consider the Date of first publication to be the ‘publication date’, but in ONIX it is important to distinguish between the Publication date of this manifestation and the Date of first publication (ie the Publication date of the first manifestation);
  - 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);
- Launch date – this term is not used in ONIX as there is no widely-agreed definition. For some, this is a synonym for publication date, particularly where this is marked by some promotional event (a product’s ‘launch party’), whereas for others, ‘launch’ refers to some internal or even external ‘product reveal’ announcement that takes place several months prior to publication.

Some of these dates should be provided whether they are in the future or in the past – a publication date or any out of print/withdrawal from sale or ‘deletion’ date, for example. Others such as a passed sales embargo or announcement date have no relevance, and need 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’ and completion of any necessary testing. 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 precise 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 most dates have 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 in August, New York is four hours behind UTC on that particular date), and sales can begin in London and Seattle at exactly the same instant (ie at 8pm in London, because in August, 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. That is, of 20120815T1500-0400, 20120815T2100+0200 and 20120815T1900Z – which all represent the same instant in time – the last is preferred.

  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, rather than the last day on which sales are embargoed, so it is best viewed as 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). Similarly, in order to avoid mis-interpretation, use 00:01 rather than 00:00. 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.

##### Latest reprint number

For some books, there are significant differences between different reprints (different impressions) – for example the first and second impressions may be manufactured (printed and bound) in different countries, or on different paper stock, while still being the same product with the same ISBN. In this case, a few parts of the metadata might apply only to one specific impression.

Taking Country of manufacture as an example, it is not unusual to arrange for a first impression to be printed in a location chosen for speed of delivery, while for a later impression, lead time is less of an issue and it can printed in a location chosen to minimize cost. ONIX cannot carry information about the two different impressions at the same time, so best practice is to distribute an update to the ONIX Product record immediately before the publisher or distributor begins fulfillment to downstream resellers using copies from the second impression.

Where the distinction between the two impressions is important, the Latest reprint number can be used to clarify which of the two impressions the Product record refers to. When the Latest reprint number changes, the ONIX update should be timed to maximize the likelihood that a data recipient will receive data that describes the stock they will receive should an order be placed. This would be no more than a couple of days before the publisher or primary distributor expects to run out of stock of copies from the first impression.

  Some distributors and wholesalers will implement lot control and a first in-first out stock rotation policy to ensure the oldest copies are sold first. However this may not always work particularly well if returns are used to fulfill new orders. Many resellers do not implement lot control at all, which means that stock from multiple impressions, and returned copies, are comingled.

  For the avoidance of doubt, in ONIX, the reprint number and impression number are the same, even though in the strictest sense, the second impression is the first reprint.

  Reprint numbers and dates are not relevant to digital products or to print-on-demand.

  Original data, sent prior to and at publication
  using Reference names |
  --- | ---
  `<CountryOfManufacture>IT<CountryOfManufacture>` |
  `. . .` |
  `<PublishingDate>` |
  `<PublishingDateRole>01<PublishingDateRole>` |
  `<Date>20230620</Date>` |
  `</PublishingDate>` |
  `<PublishingDate>` |
  `<PublishingDateRole>12<PublishingDateRole>` |
  `<Date>20230620</Date>` |
  `</PublishingDate>` |
  `<LatestReprintNumber>1<LatestReprintNumber>` |

  using short tags |
  --- | ---
  `<x316>IT<x316>` | Printed and bound in Italy
  `. . .` |
  `<publishingdate>` |
  `<x448>01<x448>` | Publication date
  `<b306>20230620</b306>` |
  `</publishingdate>` |
  `<publishingdate>` |
  `<x448>12<x448>` | Latest reprint date
  `<b306>20230620</b306>` |
  `</publishingdate>` |
  `<x446>1<x446>` | Metadata applies to first impression

  Updated data, sent immediately prior to release of third impression stock
  using Reference names |
  --- | ---
  `<CountryOfManufacture>CN<CountryOfManufacture>` |
  `. . .` |
  `<PublishingDate>` |
  `<PublishingDateRole>01<PublishingDateRole>` |
  `<Date>20230620</Date>` |
  `</PublishingDate>` |
  `<PublishingDate>` |
  `<PublishingDateRole>12<PublishingDateRole>` |
  `<Date>20240111</Date>` |
  `</PublishingDate>` |
  `<LatestReprintNumber>3<LatestReprintNumber>` |

  using short tags |
  --- | ---
  `<x316>CN<x316>` | Printed and bound in China
  `. . .` |
  `<publishingdate>` |
  `<x448>01<x448>` | Publication date
  `<b306>20230620</b306>` |
  `</publishingdate>` |
  `<publishingdate>` |
  `<x448>12<x448>` | Latest reprint date
  `<b306>20240111</b306>` |
  `</publishingdate>` |
  `<x446>3<x446>` | Metadata applies to third impression

  In English language publishing at least, the reprint number (impression number) is often given on the title verso or imprint page. In former times when printing plates were stored between impressions rather than being remade, it might have been presented something like this:

  3 5 7 9 10 8 6 4

  which indicates the copy is from the third impression (look for the lowest number). There are historical reasons for this presentation, dating from when physical printing plates were kept, and modified by scratching off a number for each reprinting. Modern printing plates are usually recycled and remade anew for each print run.

  In other national supply chains, the reprint number is not shown on the book, but a reprint date may be included on the title verso or imprint page.

##### Copyright statement composite

This composite can be used to record details of any copyrights or neighboring rights (for example the phonogram or database rights) owned 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.

Sometimes, it is the publisher who owns these rights. Other times, the publisher is a licensee of the rights owner.

  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>` |
  `<CopyrightStatementText>© 2004–2013 Amelia Winstanley and General Text Inc.</CopyrightStatementText>` |

  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>` |
  `<x588>© 2004–2013 Amelia Winstanley and General Text Inc.</x588>` |

  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>` |
  `<CopyrightStatementText>© 1924, 1936, 1979, 1983 King’s College, Cambridge. Ⓟ 2008 Canongate Books</CopyrightStatementText>` |

  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>` |
  `<x588>© 1924, 1936, 1979, 1983 King’s College, Cambridge. Ⓟ 2008 Canongate Books</x588>` |

  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’, as shown in the <CopyrightStatementText>.
  Note that the Copyright date should be the same as – or a little earlier than – the Date of first publication or Date of first publication in original language (see Publishing date in Group P.20), as copyright persists from the moment of ‘fixing’ the work (eg in a finished manuscript, or in the first published version), not from the moment of publication of a specific product. Occasionally, publishers specify a later copyright date, particularly on annual publications – the 2022 edition with a © date of 2022 even though it was published in mid- to late-2021, but this practice is mostly a marketing ploy (magazine publishers do something similar as a May issue is routinely published in April).
  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.

The act of publication of a product implies the publisher claims it owns or licenses at least those rights sufficient to do so, covering the countries or regions specified in <SalesRights>. The ‘right of reproduction’, the ‘right of distribution’ and the ‘right to make available’ – three of the constituent parts of ‘copyright’ – are exercised directly or indirectly by the publisher, its printer and distributor, and by retailers. The other constituent rights – to translation, performance, adaptation and so on – may or may not also be owned or licensed by the publisher. Copyright also includes various moral rights such as the ‘right of attribution’ and the ‘right to integrity’ of the work, which in many legal jurisdictions are inalienable (ie cannot be sold or licensed by the original creator).

In general, ONIX does not attempt to cover all these details. The aim is to reproduce the simplified ‘© Canongate Books’ or ‘© Amelia Winstanley’ copyright statement often found on the title verso.

However, for certain uses, the ability to specify these more granular aspects of copyright can be useful.

  specifying more granular rights – broadcast and translation rights
  using Reference names |
  --- | ---
  `<CopyrightStatement>` |
  `<CopyrightType>B</CopyrightType>` |
  `<CopyrightOwner>` |
  `<CorporateName>Big Chicken Books</CorporateName>` |
  `</CopyrightOwner>` |
  `</CopyrightStatement>` |
  `<CopyrightStatement>` |
  `<CopyrightType>L</CopyrightType>` |
  `<CopyrightOwner>` |
  `<CorporateName>Big Chicken Books</CorporateName>` |
  `</CopyrightOwner>` |
  `</CopyrightStatement>` |

  using Reference names |
  --- | ---
  `<copyrightstatement>` |
  `<x512>B</x512>` | Broadcast rights
  `<copyrightowner>` |
  `<b047>Big Chicken Books</b047>` |
  `</copyrightowner>` |
  `</copyrightstatement>` |
  `<copyrightstatement>` |
  `<x512>L</x512>` | Translation rights
  `<copyrightowner>` |
  `<b047>Big Chicken Books</b047>` |
  `</copyrightowner>` |
  `</copyrightstatement>` |

These rights generally pertain to the work rather than to a specific product or manifestation – or to the content of the product rather than to the product itself. They may be constrained by geography, or apply for only a limited time etc, but ONIX cannot capture such detail. And the Copyright statement should never be interpreted as being comprehensive – there may be other rights exercised in the product that are not listed, for example various third-party image rights, over and above any specified text copyright.

In the absence of a specific use case, there is generally no need to specify these granular rights – a statement covering the © and Ⓟ right is usually enough, and even in the absence of a Copyright statement, the fact the publisher places the product on the market implies it owns or licences rights sufficient to do so. Rights types other than C, P and D imply ownership of rights beyond those necessary to publish and sell the product – so for example Copyright type code L (the ‘right to translate’) specifies the publisher holds (at least some) translation rights in the work, and could therefore create a translation of the work into another language, or license the right to do so to another publisher.

#### P.21 Territorial sales rights and other sales restrictions

ONIX is product-focused: although certain aspects of the publisher’s rights to publish can be inferred from a Product record and from P.21 in particular, it is not primarily concerned with the publishing rights in a work held by a publisher – 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.

Why a subset? Because a publisher may choose not to exploit all the rights it owns. For example, a publisher holding global publishing rights may choose to make a product available only in North America, or may choose to make a product unavailable in the EU.

And why a superset? Where there is a single ‘market’ for the book (typically with a single exclusive distributor), the sales rights and distribution rights are the same. Where there are multiple distributors, each with an exclusive distribution territory, the sales rights are the sum of all the distributon territories.

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 senders or 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, despite its focus on a product’s sales rights, ONIX can communicate something about the underlying 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’. An ONIX Product record can also state where a publisher explicitly lacks the relevant publishing rights.

Additional guidance on the description of sales rights in ONIX 3.1 and 3.0 will be found in a separate document ONIX for Books Product Information Message: How to Specify Markets and Suppliers in ONIX 3.

Distributors, wholesalers and retailers rely on accurate and comprehensive sales rights information to gauge whether a product is available to them to purchase, and where they have the right to resell that product. Given the increasingly globalized nature of the book business, and the reality of internet bookselling of both physical and digital product, it is imperative that this information is provided explicitly, and in full, in <SalesRights>.

The sales rights represent the global position, without regard to distribution – it’s fairly common for the distribution arrangements to vary across the territories where the product is for sale, and these differing distribution arrangements (ie sales into different markets) can be described in Block 6.

Sales rights are those rights granted to resellers. Note that the sales rights may be a subset of the publisher’s publishing rights – there is no obligation on a publisher to make the product available everywhere it has the right to do so, and the publisher may make a commercial decision to restrict those Sales rights.

For more details on sales rights, see EDItEUR’s application note Sales rights in ONIX (doi:10.4400/kpxc).

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, using Sales rights type codes 01 or 02;
- 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 rights 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 also 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;
- only positive ‘for sale’ sales rights supplied – with the assumption that the product must be ‘not for sale’ everywhere that it is not ‘for sale’. This is an error;
- 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’ for Kosovo – use region RS-KM instead). These are sometimes added as proprietary codes within internal systems, but must be ‘translated’ into the correct ONIX codes for data exchange between organizations;
- invalid ONIX caused by placing <SalesRestriction> outside of the <SalesRights> composite. This was valid (although deprecated, and in some circumstances very difficult to interpret) in ONIX 3.0;
- ‘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);
- 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. This is critical as when present, Sales restrictions completely change the interpretation of the Sales rights – for example when the product is a retailer- or channel-exclusive within a Sales rights territory.

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) formerly included in List 49 – the list of regions used in <RegionsIncluded> and <RegionsExcluded> – is not valid in either ONIX 3.0 or 3.1. 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 (Sales rights type code 00), or where the product is not for sale (Sales rights type codes 03–06). In addition, code ECZ (Eurozone) is not valid in ONIX 3.1. In 3.0, it is not used in <SalesRights>, and its use is strongly discouraged elsewhere – use an explicit list of countries instead.

  exclusive world sales rights excluding India (recommended version)
  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>` |
  `<!-- no 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>` |
  `<salesrights>` |
  `<b089>06</b089>` | Not for sale (no rights)
  `<territory>` |
  `<x449>BD BT IN LK MV NP PK</x449>` |
  `</territory>` |
  `</salesrights>` |
  `<!-- no x456 -->` |

  This example (above) illustrates a common idiom – the use of ‘complementary territories’. 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’ because the two territories are exactly complementary. However, <ROWSalesRightsType> could be used in place of either of the composites to convey exactly the same meaning, as below. As a matter of good practice, where the sales rights can be expressed as ‘world excluding a few countries’, the version above is preferred, although there are circumstances where the version below is necessary (eg where the sales rights in some or all of the excluded countries are unknown).

  exclusive world sales rights excluding India (less preferred version)
  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 UK and Switzerland, no rights in North America, non-exclusive rights in the rest of the world
  using Reference names (recommended version) |
  --- | ---
  `<SalesRights>` |
  `<SalesRightsType>01</SalesRightsType>` |
  `<Territory>` |
  `<CountriesIncluded>AT BE BG CY CZ DE DK EE ES FI FR GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK GB CH IS LI NO</CountriesIncluded>` |
  `</Territory>` |
  `<SalesRights>` |
  `<SalesRightsType>06</SalesRightsType>` |
  `<Territory>` |
  `<CountriesIncluded>CA MX US</CountriesIncluded>` |
  `</Territory>` |
  `</SalesRights>` |
  `<SalesRights>` |
  `<SalesRightsType>02</SalesRightsType>` |
  `<Territory>` |
  `<RegionsIncluded>WORLD<RegionsIncluded>` |
  `<CountriesExcluded>AT BE BG CY CZ DE DK EE ES FI FR GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK GB CH IS LI NO CA MX US</CountriesIncluded>` |
  `</Territory>` |
  `</SalesRights>` |
  `<!-- no ROWSalesRightsType -->` |

  using Short tags (less preferred version with <ROWSalesRightsType)
  `<salesrights>` |
  `<b089>01</b089>` | For sale (exclusive)
  `<territory>` |
  `<x449>AT BE BG CY CZ DE DK EE ES FI FR GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK GB CH IS LI NO</x449>` | EU, UK and 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 sales 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 GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK GB 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 GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK GB CH IS LI NO</x449>` | EU, UK and EFTA
  `</territory>` |
  `</salesrights>` |
  `<x456>00</x456>` | ROW rights unknown or unstated

  exclusive world sales 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) – although the presence of <SalesRestriction> can change this.

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 (code 01 from ONIX codelist 46) – 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 (code 02) – 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;
  - most commonly, code 03 is used to specify not for sale. But although the net effect for the retailer is the same – the product is not for sale – codes 04, 05 and 06 are more meaningful and 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.

It is worth emphasizing a matter of ‘preferred style’ in the expression of sales rights. The three examples below are all technically correct and are exactly synonymous, but there is a strong preference for the second or – even better – the third option. Use of <ROWSalesRightsType> with codes 01 or 02 is not recommended practice.

  Style options for expression of sales rights
  option 1 – not recommended |
  --- | ---
  `<SalesRights>` |
  `<SalesRightsType>06</SalesRightsType>` |
  `<Territory>` |
  `<CountriesIncluded>CA MX US</CountriesIncluded>` |
  `</Territory>` |
  `</SalesRights>` |
  `<ROWSalesRightsType>01</ROWSalesRightsType>` |
  `<!-- ROWSalesRightsType used to specify ‘for sale’ – poor practice -->` |

  option 2 |
  --- | ---
  `<SalesRights>` |
  `<SalesRightsType>01</SalesRightsType>` |
  `<Territory>` |
  `<RegionsIncluded>WORLD</RegionsIncluded>` |
  `<CountriesExcluded>CA MX US</CountriesExcluded>` |
  `</Territory>` |
  `</SalesRights>` |
  `<ROWSalesRightsType>06</ROWSalesRightsType>` |
  `<!-- ROWSalesRightsType used to specify ‘not for sale’ -->` |

  option 3 – recommended |
  --- | ---
  `<SalesRights>` |
  `<SalesRightsType>01</SalesRightsType>` |
  `<Territory>` |
  `<RegionsIncluded>WORLD</RegionsIncluded>` |
  `<CountriesExcluded>CA MX US</CountriesExcluded>` |
  `</Territory>` |
  `</SalesRights>` |
  `<SalesRights>` |
  `<SalesRightsType>06</SalesRightsType>` |
  `<Territory>` |
  `<CountriesIncluded>CA MX US</CountriesIncluded>` |
  `</Territory>` |
  `</SalesRights>` |
  `<!-- no ROWSalesRightsType necessary -->` |

All three examples indicate the book is for sale everywhere except three countries in North America, and that it’s not for sale in those three countries because the publisher lacks the rights. But use of <ROWSalesRightsType> with positive sales rights (codes 01 or 02) as shown in option 1 is not recommended, and option 3 is slightly preferred over option 2 as it uses the common idiom of two complementary territories.

The fourth option below is also technically correct and exactly synonymous with options 1–3 as of Issue 65 of the Codelists – but it would need correction should any change be made to List 74 (the list of country codes). It is for this reason that <ROWSalesRightsType> is required with this option even if you believe you have listed every possible country code (see the three-step test in P.21.10 below). It is also difficult to check that the two territories are properly complementary. For these reasons, option 4 is not recommended.

  Style options for expression of sales rights (continued)
  option 4 – not recommended |
  --- | ---
  `<SalesRights>` |
  `<SalesRightsType>01</SalesRightsType>` |
  `<Territory>` |
  `<CountriesIncluded>AD AE AF AG AI AL AM AO AQ AR AS AT AU AW AX AZ BA BB BD BE BF BG BH BI BJ BL BM BN BO BQ BR BS BT BV BW BY BZ CC CD CF CG CH CI CK CL CM CN CO CR CU CV CW CX CY CZ DE DJ DK DM DO DZ EC EE EG EH ER ES ET FI FJ FK FM FO FR GA GB GD GE GF GG GH GI GL GM GN GP GQ GR GS GT GU GW GY HK HM HN HR HT HU ID IE IL IM IN IO IQ IR IS IT JE JM JO JP KE KG KH KI KM KN KP KR KW KY KZ LA LB LC LI LK LR LS LT LU LV LY MA MC MD ME MF MG MH MK ML MM MN MO MP MQ MR MS MT MU MV MW MY MZ NA NC NE NF NG NI NL NO NP NR NU NZ OM PA PE PF PG PH PK PL PM PN PR PS PT PW PY QA RE RO RS RU RW SA SB SC SD SE SG SH SI SJ SK SL SM SN SO SR SS ST SV SX SY SZ TC TD TF TG TH TJ TK TL TM TN TO TR TT TV TW TZ UA UG UM UY UZ VA VC VE VG VI VN VU WF WS YE YT ZA ZM ZW</CountriesIncluded>` |
  `</Territory>` |
  `</SalesRights>` |
  `<SalesRights>` |
  `<SalesRightsType>06</SalesRightsType>` |
  `<Territory>` |
  `<CountriesIncluded>CA MX US</CountriesIncluded>` |
  `</Territory>` |
  `</SalesRights>` |
  `<ROWSalesRightsType>00</ROWSalesRightsType>` |

In addition to the usual <SalesRightsType> element and <Territory> composite, any <SalesRights> composites within which <SalesRightsType> codes 03, 04, 05 or 06 (or the deprecated codes 07 and 08) indicate that the product is not for sale (or is restricted to particular outlets or channels) may include an identifier for an equivalent product that may be available as an alternative. 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 alternative 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` (regions excluded must be regions within the included countries)
  - `CI RI —— ——` (only where RI ≠ WORLD, and regions included must be outside
    `` the countries included)
  - `CI RI —— RX` (only where RI ≠ WORLD, regions included must be outside the
    `` countries included, and regions excluded must be regions
    `` within the included countries)
  - `—— RI —— ——`
  - `—— RI —— RX` (only where RI = WORLD)
  - `—— RI CX ——` (only where RI = WORLD)
  - `—— RI CX RX` (only where RI = WORLD, and regions excluded must be outside
    `` the countries excluded)

  Other combinations do not make sense, and most will not validate.

ONIX uses country codes in List 91 which is based on the ISO 3166‑1 list. 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, subdivisions, outlying territories and dependencies with their own codes within ISO 3166-1 are not considered part of the larger country for sales rights, market or pricing purposes. For example, in ONIX, the country code FR is considered to apply only to metropolitan France (including Corsica) plus Clipperton Island (which does not have its own ISO 3166-1 code), and not to include the overseas departments and territories which have their own codes (codes BL, GF, GP etc) ¹. So if rights are held throughout the broader country, include both the main country code and the country codes for the smaller subdivisions, outlying or overseas territories and dependencies.

  Country ² | Subdivision, outlying or overseas territory or dependency with independent code in List 91 ³ ⁴
  --- | ---
  Australia | AU | CC | Cocos (Keeling) Islands
  CX | Christmas Island
  HM | Heard Island and McDonald Islands
  NF | Norfolk Island
  China | CN | HK | Hong Kong
  MO | Macao
  TW | Taiwan
  Denmark | DK | FO | Faroe Islands
  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
  SJ | Svalbard and Jan Mayen
  United Kingdom | GB | AI | Anguilla
  BM | Bermuda
  FK | Falkland Islands
  GI | Gibraltar
  GG | Guernsey
  GS | South Georgia and South Sandwich Islands
  JE | Jersey
  IM | Isle of Man
  IO | British Indian Ocean Territory
  KY | Cayman Islands
  MS | Montserrat
  PN | Pitcairn Islands
  SH | Saint Helena, Ascension and Tristan da Cunha
  TC | Turks and Caicos Islands
  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 defined or interpreted in different ways when used in other standards

  ² this list is not necessarily exhaustive

  ³ the degree of independence or self-government of these various subdivisions, outlying or overseas territories and dependencies varies greatly

  ⁴ note that some of these subdivisions, outlying or overseas territories and dependencies 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.

  There is occasionally some confusion over use of the codes GB and IE. In the ISO list and in ONIX, GB indicates the United Kingdom – that is, the combined nations of England, Wales, Scotland and Northern Ireland. The code IE refers to the Republic of Ireland. If necessary, the entire island of Ireland may be specified using IE and additionally including the region code GB-NIR. The combination of England, Wales and Scotland may be specified using GB and excluding the region GB-NIR, or by including the three regions GB-ENG, GB-SCT and GB-WLS (note that use of the ‘combined’ region GB-EWS is deprecated). The Republic of Ireland is a member of the European Union, the United Kingdom is not, and neither is the United Kingdom a member of the EEA or EFTA. Although it forms part of the United Kingdom, Northern Ireland is treated as within the scope of some EU Regulations.

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

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 UK and Switzerland, no rights in North America, non-exclusive rights elsewhere – but within the EEA and UK, 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 GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK GB 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 GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK GB CH IS LI NO CA MX US</CountriesExcluded>` |
  `</Territory>` |
  `</SalesRights>` |

  using Short tags (less preferred 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 (excl UK)
  `</territory>` |
  `</salesrights>` |
  `<salesrights>` |
  `<b089>01</b089>` | For restricted sale (exclusive)
  `<territory>` |
  `<x449>AT BE BG CY CZ DE DK EE ES FI FR GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK GB CH IS LI NO</x449>` | EU, UK and EFTA
  `</territory>` |
  `<salesrestriction>` | (applies in EU, UK 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.

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

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

  exclusive world rights, but the product is not for sale to libraries in some countries
  using Reference names |
  --- | ---
  `<SalesRights>` |
  `<SalesRightsType>01</SalesRightsType>` |
  `<Territory>` |
  `<CountriesIncluded>GB US CA AU NZ ZA</CountriesIncluded>` |
  `</Territory>` |
  `<SalesRestriction>` |
  `<SalesRestrictionType>99</SalesRestrictionType>` |
  `</SalesRestriction>` |
  `</SalesRights>` |
  `<SalesRights>` |
  `<SalesRightsType>01</SalesRightsType>` |
  `<Territory>` |
  `<RegionsIncluded>WORLD</RegionsIncluded>` |
  `<CountriesExcluded>GB US CA AU NZ ZA</CountriesExcluded>` |
  `</Territory>` |
  `<SalesRestriction>` |
  `<SalesRestrictionType>09</SalesRestrictionType>` |
  `</SalesRestriction>` |
  `</SalesRights>` |
  `<!-- optional and not recommended for general use -->` |
  `<SalesRights>` |
  `<SalesRightsType>04</SalesRightsType>` |
  `<Territory>` |
  `<RegionsIncluded>WORLD</RegionsIncluded>` |
  `<CountriesExcluded>GB US CA AU NZ ZA</CountriesExcluded>` |
  `</Territory>` |
  `<SalesRestriction>` |
  `<SalesRestrictionType>06</SalesRestrictionType>` |
  `</SalesRestriction>` |
  `</SalesRights>` |

  using Short tags |
  --- | ---
  `<salesrights>` |
  `<b089>01</b089>` | For sale (exclusive)
  `<territory>` |
  `<x449>GB US CA AU NZ ZA</x449>` |
  `</territory>` |
  `<salesrestriction>` |
  `<b381>99</b381>` | No restrictions
  `</salesrestriction>` |
  `</salesrights>` |
  `<salesrights>` |
  `<b089>01</b089>` | For sale (exclusive)
  `<territory>` |
  `<x450>WORLD</x450>` |
  `<x451>GB US CA AU NZ ZA</x451>` |
  `</territory>` |
  `<salesrestriction>` |
  `<b381>09</b381>` | Except libraries
  `</salesrestriction>` |
  `</salesrights>` |
  `<!-- optional and not recommended for general use -->` |
  `<salesrights>` |
  `<b089>04</b089>` | Not for sale (exclusive)
  `<territory>` |
  `<x450>WORLD</x450>` |
  `<x451>GB US CA AU NZ ZA</CountriesExcluded>` |
  `</territory>` |
  `<salesrestriction>` |
  `<b381>06</b381>` | To libraries only
  `</salesrestriction>` |
  `</salesrights>` |

  Note that when sales rights are limited by territory, the complement (the opposite – eg where the product is not for sale) must be stated, either explicitly or via <ROWSalesRightsType>. When the sales rights are limited by a sales restriction, the complement of the sales restriction need not (and in general should not) be stated.

  In the above, there are two complementary territories – one of six countries, and one of everywhere except those six countries. The product is ‘for sale’ in both, but in the second the sales rights are restricted. Note that the extra detail in the third (optional) repeat of <SalesRights> is unnecessary: it should for most purposes be omitted. The addition of restrictions to <SalesRights> composites where the product is ‘not for sale’ is not recommended for general ONIX use, and recipients uninterested in details of the underlying publishing rights should choose to ignore any <SalesRights> composites which specify ‘not for sale’ with a restriction. However, in specialized circumstances, the third composite may be included in order to state explicitly that the publisher holds the exclusive publishing rights that would cover the remaining library sales, but actively chooses not to exercise them.

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. Where this proves impractical, ROW sales rights type should only be used to express ‘not for sale’ – it is poor practice to use it with codes 01 or 02.

Since this data element relies on preceding <SalesRights> composites to define the extent of ‘the rest of the world’, it should never appear unless it is accompanied by one or more <SalesRights> composites. And if the <SalesRights> composites unequivocally cover the whole world, then the <ROWSalesRightsType> element should be omitted.

Whether Group P.21 requires a <ROWSalesRightsType> element must be checked on a case-by-case basis:

1. is the WORLD region associated with a sales rights type code?
   - if no, <ROWSalesRightsType> is required, even if you believe you have exhaustively listed all ISO country codes separately. It will act as a fallback if you have inadvertently omitted a country, or if a new country is created (eg South Sudan was created in 2011);
   - if yes, see question 2;
2. within the <SalesRights> composite that includes WORLD, are there any <CountriesExcluded> or <RegionsExcluded> elements?
   - if no, <ROWSalesRightsType> should be omitted;
   - if yes, see Question 3;
3. are all those excluded countries and regions included in other <SalesRights> composites, in accordance with best practice?
   - if no, <ROWSalesRightsType> is required. It may be used to specify the rights that apply in the remaining countries or regions, or specify that those rights are unknown or unstated;
   - if yes, <ROWSalesRightsType> should be omitted.

Note that the above is a ‘rule of thumb’ rather than being definitive. In particular, it does not take account of any Sales restrictions or of the inclusion or exclusion of any Regions.

  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’, as otherwise they risk infringing the sales rights of other resellers.

### 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–8 are unnecessary;
- the Notification type is 05 (a record deletion), in which case Blocks 1–8 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 former ISTC or a similar work 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 standard itself has been withdrawn, although something similar may be re-specified in the future. Some of the affordance of the former ISTC can be delivered using proprietary work identifiers, particularly when combined with use of the extended Work relation codes (codes 21 and upwards).

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 former ISTC and similar work identifiers which incorporate work-to-work links is that they create ‘family trees’ of works, and allows publishers and retailers to create groupings of products based on the relationships between their work IDs – collocating products manifesting a parent work alongside the manifestations of a grandparent work and child works. For example, a novel in translation can be linked to its work, to its grandparent work in the original language, and to an abridged, adapted or enhanced ‘derived’ or 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.

Relationships between the work manifested by the product and other works – and to an even greater extent, relationships between this product and other closely-related products in Group P.23 – are valuable to retailers and librarians as they provide a basis for improving customer service and retaining sales that might otherwise be lost. They allow alternatives to be offered, either as an upsell or when the desired product is out of stock or not immediately available. They provide a way to ensure the customer gets the most up-to-date edition, and they improve discoverability for the same work in other formats – in audio, as a deluxe edition, as part of an omnibus or set – that could otherwise be lost in a mass of ‘lowest cost’ search results.

Where a legacy ISTC or similar work identifier has been registered for the work embodied in the product, it should be specified in a <RelatedWork> composite. However, work identifiers are more likely to be proprietary identifiers (such as a UUID) or proxy identifiers (such as the ISBN of the first manifestation of the work). If a publisher uses a reliable but proprietary internal work identifier, and a public work identifier is not available, the internal identifier should be used to specify these works.

- For ‘derived’ works (eg a work in translation, or an abridged version), work identifiers for any source works should also be included wherever possible (eg the original language version and the unabridged ‘grandparent works’, where the product is a manifestation of a translated work or an abridged work). 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.

Common issues in Group P.22:

- confusion between codes 01 and 02 in <WorkRelationCode>. The common case – where a product is a manifestation of a work – is code 01;
- code 02 might be used occasionally, for example to describe the relationship between an abridged audiobook product and the grandparent unabridged work (between the two is the parent abridged work, which might or might not be separately identified).

  this product is a manifestation of a particular work identified by a work identifier (a legacy ISTC). The ‘grandparent’ work identifier is also specified
  using Reference names |
  --- | ---
  `<RelatedWork>` |
  `<WorkRelationCode>01</WorkRelationCode>` | Is manifestation of parent work
  `<WorkIdentifier>` |
  `<WorkIDType>11</WorkIDType>` | Former ISTC of parent work
  `<IDValue>A02200900000A654</IDValue>` |
  `</WorkIdentifier>` |
  `</RelatedWork>` |
  `<RelatedWork>` |
  `<WorkRelationCode>02</WorkRelationCode>` | Is manifestation of a work which was itself derived from grandparent work
  `<WorkIdentifier>` |
  `<WorkIDType>11</WorkIDType>` | Former ISTC of grandparent work
  `<IDValue>A02200900000ECDE</IDValue>` |
  `</WorkIdentifier>` |
  `</RelatedWork>` |

  using Short tags (and using proprietary work IDs) |
  --- | ---
  `<relatedwork>` |
  `<x454>01</x454>` | Is manifestation of
  `<workidentifier>` |
  `<b201>01</b201>` | Proprietary ID of this work
  `<b233>MyPublisher WorK ID</b233>` | Proprietary IDs require an ID type name
  `<b244>ca0a23a0-d0df-41ff-a23a-ae9bad16d7c9</b244>` | UUID (type 4) used as proprietary ID
  `</workidentifier>` |
  `</relatedwork>` |
  `<relatedwork>` |
  `<x454>02</x454>` | Is manifestation of work derived from
  `<workidentifier>` |
  `<b201>01</b201>` | Proprietary ID of the grandparent work
  `<b233>MyPublisher WorK ID</b233>` |
  `<b244>b5e3a2c8-61b0-40d1-8144-bf9af4cb7751</b244>` | UUID (type 4)
  `</workidentifier>` |
  `</relatedwork>` |

  In this example, the grandparent (former ISTC A02-2009-00000ECD-E) is an original work, and the product is a manifestation of a work derived from that grandparent (former A02-2009-00000A65-4): in this case, that parent work is an abridged edition derived from the grandparent. Equally, the grandparent work could be the Sixth edition, and the product a manifestation of the Seventh edition, a derived work. Note that the ISTC standard has been withdrawn, but other work identifiers can be used in a similar way.

  supplying multiple grandparent work identifiers 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 (and using detailed Work relation codes to specify the method of derivation of the parent work from the grandparent works)
  `<relatedwork>` |
  `<x454>23</x454>` | Is manifestation of work derived (by compilation) from
  `<workidentifier>` |
  `<b201>11</b201>` | Former ISTC
  `<b244>A022009000000951</b244>` | of Sense and Sensibility
  `</workidentifier>` |
  `</relatedwork>` |
  `<relatedwork>` |
  `<x454>23</x454>` | Is manifestation of work derived (by compilation) from
  `<workidentifier>` |
  `<b201>11</b201>` | Former ISTC
  `<b244>A022009000000964</b244>` | of Pride and Prejudice
  `</workidentifier>` |
  `</relatedwork>` |
  `<relatedwork>` |
  `<x454>23</x454>` | Is manifestation of work derived (by compilation) from
  `<workidentifier>` |
  `<b201>11</b201>` | Former ISTC
  `<b244>A0220090000009B3</b244>` | of Northanger Abbey
  `</workidentifier>` |
  `</relatedwork>` |

  The omnibus edition does not (yet) have a work identifier of its own (it could be registered as a work derived by compilation of the three grandparent works). Note the ISTC standard has been withdrawn, but another work identifier may be used.

  specifying 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 in the example 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

It is best practice to supply a work identifier assigned to the parent work manifested in the product (ie work X in the diagram below), with a <WorkRelationCode> of 01 from List 164. Any grandparent or source works (W in the diagram below), or known child or derived works (Z in the diagram) should also be specified, with <WorkRelationCode> codes 02 and 03 respectively – the supply of parent and child work IDs 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.

  The work relationships that can be specified using Work relation code always relate the product (Product A in the diagram) to a work – either directly to Work X, or indirectly to W, Y or Z via X.

  The simplest code, 01, states that Product A – the subject of the Product record – is a manifestation of Work X. There may of course be many other manifestations of Work X – if Product A is a hardback, there may be paperback, e‑book and unabridged audio manifestations too. One of these other manifestations is shown as Product B. The work identifier for X is shared across all those manifestations, and may be used to group them together unambiguously. Note that Products A and B may also be directly linked using Product relation code 06 (Alternative format).

  Work relation codes 02 and 03 allow identification of works W or Y – each being related indirectly to Product A via X, either as a parent or child of X (thus work W is often termed the ‘grandparent’ work of Product A). Work X was derived from W in some way – for example, W could be a novel in its original language and X a translated version, or W may be a third edition and X the fourth, or W may be complete and X abridged. Similarly, Y could be a fifth edition, or be adapted from X into a playscript.

  Note that use of codes 02 and 03 do not require a Work identifier for X. The common case is for Product A – which is an abridged, translated or adapted product – to be linked to W, the unabridged, original language or unadapted grandparent, thus implying the existence of but not explicitly identifying the abridged work X.

  But codes 02 and 03 do not specify the method of derivation. For this, there is a range of codes (20 and above) which can be used both to identify W and specify the method of derivation of X from W. By translation, by revision, by abridgement, by adaptation and so on. Similar codes (40 and above) relate Product A to Work Y, via X.

  For recipients who do not track the method of derivation, codes 20 and above can be treated as simply synonyms of code 02, and codes 40 and above as synonyms of code 03.

  Work Z represents works with a much looser connection to Work X and Product A, for example using Work relation code 04, where Work X and Work Z are in the same collection, or code 05, where Work X and Work Z have at least one contributor in common.

  A, W, X, Y and Z are used in the notes attached to each of the codes in List 164.

However, it is recognized that the ISTC, the international standard identifier for textual works, has been withdrawn by ISO, and no equivalent standard identifier is available for works. While it was active, only a small number of publishers ever started registering ISTCs. Where an ISTC has not been registered, proxy work identifiers or reliable internal work 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. Proxy identifiers are identifiers for a product (usually the first product) that’s a manifestation of a work, used as a proxy for the work itself.

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 former ISTC. Since the scope of the proprietary identifier is unknown, it is difficult to interpret relationships between works expressed with proprietary identifiers, whereas with the former ISTC these relationships were closely defined and were 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 former ISTC. That is, it should identify the intellectual property 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’) as a proxy identifier 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 in strict usage, 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 a proxy or 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 proxy 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 reasons for including links to related products are the same as those for links to related works (see Group P.22), though product links are much more frequently implemented by data recipients and can sometimes extend beyond a small group of closely-related works. Wholesalers and retailers generally express a need for a wider range of links to boost customer service and ensure sales are not lost during stockouts.

The <RelatedProduct> composite should be used to link to alternative and related products:

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

Common issues in Group P.23:

- paired product relation codes the wrong way around (eg implying a 3rd edition replaces the 4th);
- repeating the entire <RelatedProduct> composite to specify two types of relation with the same related product. Instead, only <ProductRelationCode> should be repeated.

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>` | E‑publication 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 work ID, which could be specified more succinctly in <RelatedWork>. However, it is good practice to include both <RelatedWork> and <RelatedProduct> composites whenever possible: not all ONIX recipients are able to make use of <RelatedWork>, and each composite adds different detail to the relationship between two products.

<RelatedProduct> might in principle also duplicate information provided in <ProductPart> in Group P.4, particularly when using the <ProductRelationCode> 02 (Product includes related product). It is good practice to include identifiers for multi-component and multi-item products in <ProductPart> and not to repeat them in <RelatedProduct>. ONIX recipients should make use of identifiers listed in <ProductPart> in addition to those in <RelatedProduct>.

  The most important relationships from List 51 include:

  code | relation
  --- | ---
  06 | <Product> is available in an alternative format as <RelatedProduct>
  use to link hardback, paperback, e‑book versions, where the content is essentially identical. Linking two products implies they are the same work, and they may also be linked through sharing a single work identifier (that is, in <RelatedWork>, each product would specify that they are manifestations of the same work using <WorkRelationCode> 01)
  01 02 | <Product> includes <RelatedProduct> <Product> is included within <RelatedProduct>
  use for multi-component and multi-item products which include items that are themselves available individually, where the component or item identifiers cannot be included in <ProductPart> for any reason. Also use where the content from one product is included in another product – for example with an omnibus edition, or where a chapter of a book is also made available as an independent product. This latter relationship also implies that the two products may be linked through <RelatedWork> using codes 02 and 03 too (they are not manifestations of the same work, but one work may be derived from the other, for example by compilation)
  41 | <Product> includes some content shared with <RelatedProduct>
  use where products share some content – but where that shared content does not form the whole of either product. Note the contrasts between codes 06, 01, 02 and 41: code 06 means the content is essentially identical (ie the shared content forms the whole of both products), codes 01 and 02 means the shared content forms the whole of one product but only part of the other, and code 41 means that each product also contains some content that is not shared with the other. None of these relationships imply anything about whether one or other product is the ‘primary’ source of the shared content
  03 05 | <Product> replaces <RelatedProduct> <Product> is replaced by <RelatedProduct>
  use to link new and previous editions, or whenever one product completely supersedes another. The two products would generally be manifestations of different works, but one work would often be derived from the other, and this implies they may also be linked using codes 02 and 03 in <RelatedProduct>. Do not use for ‘paperback replaces hardback’ – for that, use code 06 instead. Note that a particular Product record might well have related products with both codes 03 and 05 – a sixth edition replaces the fifth, and towards the end of its life is itself replaced by the seventh edition (and the sixth edition work would be derived from the fifth, and would in turn have the seventh derived from it). 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>
  use to link normal with tie-in, gift, illustrated or similar types of ‘special’ editions (generally of the same work – though if extra content is included in the special edition, it may represent a derived work). Do not use for ordinal numbered editions (use codes 03 and 05 instead), or for facsimile editions (use codes 24 and 25 instead), or for enhanced e‑books (use 28 and 29);
  30 | <Product> is a member of a collection which also includes <RelatedProduct>
  use to link together all products in a collection, particularly useful if there is no collection identifier supplied in Group P.5. The members of the collection would generally not have particular work relationships to each other
  13 27 | <Product> is an e‑book based on the print version <RelatedProduct> <Product> is the print version on which <RelatedProduct> is based
  use to link an e‑book and its previously-published paper equivalent – when paper and e‑book version are published contemporaneously, then the e‑book is ‘just another format’ and 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 relationships 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>
  use to link basic and enhanced e‑books. The enhanced e‑book is a manifestation of a new work derived from the basic work (or possibly the other way around, if the basic version were created by removal of material from the enhanced version)
  26 | <Product> is a separate license that covers usage of <RelatedProduct>
  use when <RelatedProduct> is digital, and available separately
  07 08 | <Product> has ancillary or supplementary <RelatedProduct> <Product> is ancillary or supplementary to <RelatedProduct>
  use for example to link a promotional poster to the product it is promoting, or where general merchandise (t-shirt, mug, tote-bag) is linked to a particular product
  22 23 42 | <Product> is by the same author as <RelatedProduct> if you liked <RelatedProduct>, you’ll love <Product> (or vice versa) <Product> is a later edition of first edition <RelatedProduct>
  these relationships normally apply at work level. When relating products, ensure <Product> and <RelatedProduct> appeal to the same market – for example, both <Product> and <RelatedProduct> are mass market paperbacks, or both are audiobooks
  | Note that this table contains only some of the potential relationships from List 51. Note also the direction of these relationships. Many come in pairs: if one is used in a particular Product record, then the ‘opposite’ or inverse relationship is used in the ‘other’ Product record (the record for the related product). Others, including codes 06, 22, 30 and 41, are their own opposites. A few, like code 42, apply in only one direction – there is no opposite relationship in the ONIX list.
  | In cases where a relationship is paired with its inverse (for example, codes 03 and 05 in the table above), or when a relationship is its own inverse (eg code 06 or code 41) then a recipient may assume the inverse relationship exists even if not explicitly stated in the ONIX record for the ‘other’ product. Thus if the record for product Y states that it replaces product X, but the record for product X does not state that it has replaced Y, then such an inverse relationship can be assumed. However, data providers should be explicit in both records.

  In the table above, for example with code 01, the phrase ‘<Product> includes <RelatedProduct>’ should be read as ‘the product which is the subject of the ONIX record as a whole includes the related product whose ISBN is listed in the <RelatedProduct> composite’. That is, code 01 should be used in the ONIX record for the larger product, and it should carry the ISBN (or another identifier) of the smaller product in the <RelatedProduct> composite . Conversely, code 02 should be used in the ONIX record for the smaller product, and list the ISBN for the larger product.

  The diagram illustrates the way a fourth edition (in the example, ISBN 978-0-00-123457-4) replaces a third edition, and conversely the third edition (in the example, ISBN 978-0-00-123456-7) is replaced by the fourth, and how the relationships are specified in the two ONIX records.

  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 8: Production detail

#### Production detail composite

Block 8 – the <ProductionDetail> block – is intended to carry detail relating to intermediary services within the supply chain, for example manufacturing on demand, e‑book conversion services or distribution of digital audio. In these cases, there are publishers and service providers who make use of ONIX to exchange bibliographic, marketing and commercial metadata, and they can use Block 8 to eliminate the use of additional ‘sidecar’ files that might otherwise need to be distributed by the publisher alongside the ONIX and the various content files.

It is not expected that all, or even a large proportion, of ONIX files will contain Block 8 – most will omit it, and data senders who choose to use Block 8 may in fact omit it from ONIX sent to conventional data recipients. Only a few ONIX messages – predominantly those targeted at POD, e‑book and audio service providers – might be expected to include it. However, all ONIX recipients should be prepared to receive Block 8: even if they have no interest in the data it can contain, the Block as a whole can be ignored.

Product records should not include a <ProductionDetail> composite which comprises Block 8 without prior agreement between parties in the print-on-demand, digital audio or e‑book supply chains to exchange manufacturing specifications and file manifests in this way. The entire Block should be omitted if there is no relevant data to be exchanged this way.

<ProductionDetail> should also be omitted if:

- the Notification type is 04 (a block-level partial update) and no data elements in Block 8 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–8 are unnecessary;
- the Notification type is 05 (a record deletion), in which case Blocks 1–8 are wholly unnecessary.

However, in the interest of interoperability, data recipients should still be able to ignore any <ProductionManifest> composite supplied in which they have no interest.

#### P.28 Production manifest

##### Production manifest composite

The <ProductionManifest> composite carries manufacturing details for a product. Where the product consists of multiple components which are listed as Product parts (see Group 4), the composite is repeatable for each part. Manifests for supplements which are not treated as Product parts can also be included.

Block 8 is intended to avoid the need for extra spreadsheets (so-called ‘sidecar files’) alongside the ONIX data in workflows that involve print-on-demand, or integration of e‑book content and digital audio files into packaged product files for delivery to the end purchaser – simplifying the production workflow and reducing the scope for manufacturing error. It ensures publishers can deliver the necessary data in a single data file to intermediary service providers.

<ProductionManifest> consists of a ‘manifest’ containing details needed for manufacture or assembly of a product.

- there may be multiple Production manifests where a product consists of multiple components (and thus the Product record contains multiple <ProductPart> composites);
- each manifest contains details for the main body of a product or part, and may include additional details for cover, inserts (eg a plate section or advertising material) or even a supplement or component that is not itself listed as a Product part (eg a small PDF booklet accompanying a digital audiobook);
- the detailed manifest for a cover, for the main content or for an insert includes specifications of the final manufactured or assembled product and details of one of more files supplied that should be used to manufacture the product. It’s important to differentiate between the two – the former may for example specify the final audiobook package for delivery to the consumer as a W3C Audiobook package containing numerous .mp3 files with a minimum bitrate (quality) of 128kbits/s, and the latter might list multiple CD-quality WAV audio files provided by the publisher or recording studio which are to be converted to .mp3;
- inserts additionally include details of where within the main body of the product they should be inserted;
- covers and insert manifests may list file resources that are vendor specific. A complete insert may consist of both generic and vendor-specific resources, so minor variants of the product can be manufactured;
- supplements can be structured with body, cover and insert manifest details.

Common issues in Group P.28:

- insert locations specified by page number always refer to body pages before any inserts are added – the page numbering for location of a second insert is not affected by the insertion of the first. To avoid confusion, it may be simplest to do the insertions from back to front;

  Sample Production manifest for a POD book
  using Reference names |
  --- | ---
  `<Production​Detail>` |
  `<Production​Manifest>` |
  `<Cover​Manifest>` |
  `<Specification​Description>Ordinary CMYK cover on standard cover card</Specification​Description>` |
  `<Cover​Resource>` |
  `<Resource​Identifier>` |
  `<Resource​IDType>01</Resource​IDType>` |
  `<IDTypeName>MyPub_UUID</IDTypeName>` |
  `<IDValue>922491f9-f15b-4a17-88ca-940929e0f243</IDValue>` |
  `</Resource​Identifier>` |
  `<Resource​File​Detail>B001</Resource​File​Detail>` |
  `<Resource​File​Link>https://secur_xfers.net/1230.pdf</Resource​File​Link>` |
  `<Resource​File​Date>` |
  `<Resource​File​Date​Role>17</Resource​File​Date​Role>` |
  `<Date>20200521</Date>` |
  `</Resource​File​Date>` |
  `<Resource​File​Date>` |
  `<Resource​File​Date​Role>28</Resource​File​Date​Role>` |
  `<Date dateformat="00">20200621</Date>` |
  `</Resource​File​Date>` |
  `</Cover​Resource>` |
  `</Cover​Manifest>` |
  `<Body​Manifest>` |
  `<Specification​Bundle​Name>` |
  `<Specification​Bundle​Name​Type​Name>IngramPOD</Specification​Bundle​Name​Type​Name>` |
  `<Specification​Bundle​Name​Value>Type B</Specification​Bundle​Name​Value>` |
  `</Specification​Bundle​Name>` |
  `<Specification​Bundle​Name>` |
  `<Specification​Bundle​Name​Type​Name>Amazin’</Specification​Bundle​Name​Type​Name>` |
  `<Specification​Bundle​Name​Value>31</Specification​Bundle​Name​Value>` |
  `</Specification​Bundle​Name>` |
  `<Specification​Detail>B001</Specification​Detail>` |
  `<Specification​Feature>` |
  `<Specification​Feature​Type>41</Specification​Feature​Type>` |
  `<Specification​Feature​Description language="ger">Holzhaltig, hohes spezifisches Volumen</Specification​Feature​Description>` |
  `<Specification​Feature​Description language="eng">Bulky mechanical</Specification​Feature​Description>` |
  `<Specification​Feature​Description language="swe">Mekaniskt, hög bulk</Specification​Feature​Description>` |
  `</Specification​Feature>` |
  `<Specification​Feature>` |
  `<Specification​Feature​Type>42</Specification​Feature​Type>` |
  `<Specification​Feature​Value>60</Specification​Feature​Value>` |
  `</Specification​Feature>` |
  `<Body​Resource>` |
  `<Sequence​Number>1</Sequence​Number>` |
  `<Resource​File​Link>https://secur_xfers.net/1234.pdf</Resource​File​Link>` |
  `</Body​Resource>` |
  `<Body​Resource>` |
  `<Sequence​Number>2</Sequence​Number>` |
  `<Resource​File​Link>https://secur_xfers.net/1235.pdf</Resource​File​Link>` |
  `</Body​Resource>` |
  `</Body​Manifest>` |
  `<Insert​Manifest>` |
  `<Specification​Detail>B004</Specification​Detail>` |
  `<Specification​Description>First color insert on heavier paper</Specification​Description>` |
  `<Specification​Feature>` |
  `<Specification​Feature​Type>41</Specification​Feature​Type>` |
  `<Specification​Feature​Description>Coated mechanical</Specification​Feature​Description>` |
  `</Specification​Feature>` |
  `<Specification​Feature>` |
  `<Specification​Feature​Type>42</Specification​Feature​Type>` |
  `<Specification​Feature​Value>90</Specification​Feature​Value>` |
  `</Specification​Feature>` |
  `<Specification​Feature>` |
  `<Specification​Feature​Type>43</Specification​Feature​Type>` |
  `<Specification​Feature​Value>WHI</Specification​Feature​Value>` |
  `</Specification​Feature>` |
  `<InsertPoint>` |
  `<Insert​Point​Type>ALP</Insert​Point​Type>` |
  `<Insert​Point​Value>65</Insert​Point​Value>` |
  `</Insert​Point>` |
  `<Insert​Resource>` |
  `<Sequence​Number>1</Sequence​Number>` |
  `<Resource​Identifier>` |
  `<Resource​IDType>09</Resource​IDType>` |
  `<IDValue>CCgQtRrfyeorp-CTWPsEfB7epkk-CD3a6B6kovUpj-CRX4sSi2iC9U8</IDValue>` |
  `</Resource​Identifier>` |
  `<Resource​File​Link>https://secur_xfers.net/1236.pdf</Resource​File​Link>` |
  `</Insert​Resource>` |
  `</Insert​Manifest>` |
  `<Insert​Manifest>` |
  `<Specification​Detail>B004</Specification​Detail>` |
  `<Specification​Description>Second color insert on heavier paper</Specification​Description>` |
  `<Specification​Feature>` |
  `<Specification​Feature​Type>41</Specification​Feature​Type>` |
  `<Specification​Feature​Description>Coated mechanical</Specification​Feature​Description>` |
  `</Specification​Feature>` |
  `<Specification​Feature>` |
  `<Specification​Feature​Type>42</Specification​Feature​Type>` |
  `<Specification​Feature​Value>90</Specification​Feature​Value>` |
  `</Specification​Feature>` |
  `<Specification​Feature>` |
  `<Specification​Feature​Type>43</Specification​Feature​Type>` |
  `<Specification​Feature​Value>WHI</Specification​Feature​Value>` |
  `</Specification​Feature>` |
  `<InsertPoint>` |
  `<Insert​Point​Type>ALP</Insert​Point​Type>` |
  `<Insert​Point​Value>192</Insert​Point​Value>` |
  `</Insert​Point>` |
  `<Insert​Resource>` |
  `<Sequence​Number>1</Sequence​Number>` |
  `<Resource​File​Detail>B001</Resource​File​Detail>` |
  `<Resource​File​Link>https://secur_xfers.net/1237.pdf</Resource​File​Link>` |
  `</Insert​Resource>` |
  `<Insert​Resource>` |
  `<Sequence​Number>2</Sequence​Number>` |
  `<Resource​File​Detail>B001</Resource​File​Detail>` |
  `<Resource​File​Link>https://secur_xfers.net/1239.pdf</Resource​File​Link>` |
  `</Insert​Resource>` |
  `</Insert​Manifest>` |
  `</Production​Manifest>` |
  `</Production​Detail>` |

  using Short tags |
  --- | ---
  `<production​detail>` |
  `<production​manifest>` |
  `<cover​manifest>` | Cover with…
  `<x564>Ordinary CMYK cover</x564>` |
  `<cover​resource>` | …only one resource
  `<resource​identifier>` |
  `<x565>01</x565>` | Proprietary resource ID
  `<b233>MyPub_UUID</b233>` |
  `<b244>922491f9-f15b-4a17-88ca-940929e0f243</b244>` |
  `</resource​identifier>` |
  `<x567>B001</x567>` | With crop marks
  `<x572>https://secur_xfers.net/​1230.pdf</x572>` |
  `<resource​file​date>` |
  `<x573>17</x573>` | Last updated
  `<b306>20200521</b306>` |
  `</resource​file​date>` |
  `<resource​file​date>` |
  `<x573>28</x573>` | Available until
  `<b306 dateformat="00">2020​0621</b306>` |
  `</resource​file​date>` |
  `</cover​resource>` |
  `</cover​manifest>` |
  `<body​manifest>` | Body
  `<specification​bundle​name>` | Spec bundle for manufacturer A
  `<x558>IngramPOD</x558>` |
  `<x559>Type B</x559>` |
  `</specification​bundle​name>` |
  `<specification​bundle​name>` | Spec bundle for manufacturer B
  `<x558>Amazin’</x558>` |
  `<x559>31</x559>` |
  `</specification​bundle​name>` |
  `<x560>B001</x561>` | Printed long-grain
  `<specification​feature>` |
  `<x561>41</x561>` | Paper type
  `<x563 language="ger">Holzhaltig, hohes spezifisches Volumen</x563>` |
  `<x563 language="eng">Bulky mechanical</x563>` |
  `<x563 language="swe">Mekaniskt, hög bulk</x563>` |
  `</specification​feature>` |
  `<specification​feature>` | Paper gsm
  `<x561>42</x561>` |
  `<x562>60</x562>` |
  `</specification​feature>` |
  `<body​resource>` | First body resource
  `<b034>1</b034>` |
  `<x572>https://secur_xfers.net/​1234.pdf</x572>` |
  `</body​resource>` |
  `<body​resource>` | Second body resource
  `<b034>2</b034>` |
  `<x572>https://secur_xfers.net/​1235.pdf</x572>` |
  `</body​resource>` |
  `</body​manifest>` |
  `<insert​manifest>` | First insert
  `<x560>B004</x560>` |
  `<x564>First color insert on heavier paper</x564>` |
  `<specification​feature>` |
  `<x561>41</x561>` | Paper type
  `<x563>Coated mechanical</x563>` |
  `</specification​feature>` |
  `<specification​feature>` |
  `<x561>42</x561>` | Paper gsm
  `<x562>90</x562>` |
  `</specification​feature>` |
  `<specification​feature>` |
  `<x561>43</x561>` | Paper color
  `<x562>WHI</x562>` |
  `</specification​feature>` |
  `<insertpoint>` |
  `<x564>ALP</x564>` | Adjacent to logical page
  `<x565>65</x565>` |
  `</insert​point>` |
  `<insert​resource>` |
  `<b034>1</b034>` |
  `<resource​identifier>` |
  `<x565>09</x565>` |
  `<b244>CCgQtRrfyeorp-CTWPsEfB7epkk-CD3a6B6kovUpj-CRX4sSi2iC9U8</b244>` |
  `</resource​identifier>` |
  `<x572>https://secur_xfers.net/​1236.pdf</x572>` |
  `</insert​resource>` |
  `</insert​manifest>` |
  `<insert​manifest>` | Second insert
  `<x560>B004</x560>` |
  `<x564>Second color insert on heavier paper</x564>` |
  `<specification​feature>` |
  `<x561>41</x561>` | Paper type
  `<x563>Coated mechanical</x563>` |
  `</specification​feature>` |
  `<specification​feature>` | Paper gsm
  `<x561>42</x561>` |
  `<x562>90</x562>` |
  `</specification​feature>` |
  `<specification​feature>` | Paper color
  `<x561>43</x561>` |
  `<x562>WHI</x562>` |
  `</specification​feature>` |
  `<insertpoint>` |
  `<x564>ALP</x564>` |
  `<x565>192</x565>` |
  `</insert​point>` |
  `<insert​resource>` | First resource (for this second insert)
  `<b034>1</b034>` |
  `<x567>B001</x567>` | With crop marks
  `<x572>https://secur_xfers.net/​1237.pdf</x572>` |
  `</insert​resource>` |
  `<insert​resource>` | Second resource (for this insert)
  `<b034>2</b034>` |
  `<x567>B001</x567>` | With crop marks
  `<x572>https://secur_xfers.net/​1239.pdf</x572>` |
  `</insert​resource>` |
  `</insert​manifest>` |
  `</production​manifest>` |
  `</production​detail>` |

  Sample Production manifest for a digital audiobook
  using Reference names |
  --- | ---
  `<ProductionDetail>` |
  `<ProductionManifest>` |
  `<BodyManifest>` |
  `<SpecificationDetail>A425</SpecificationDetail>` |
  `<SpecificationFeature>` |
  `<SpecificationFeatureType>21</SpecificationFeatureType>` |
  `<SpecificationFeatureValue>-14</SpecificationFeatureValue>` |
  `</SpecificationFeature>` |
  `<BodyResource>` |
  `<SequenceNumber>1</SequenceNumber>` |
  `<ResourceFileDetail>A412</ResourceFileDetail>` |
  `<ResourceFileFeature>` |
  `<ResourceFileFeatureType>06</ResourceFileFeatureType>` |
  `<ResourceFileFeatureValue>79054025255fb1a2​6e4bc422aef54eb4</ResourceFileFeatureValue>` |
  `</ResourceFileFeature>` |
  `<ResourceFileLink>https://audiophiles.co.uk/​9780001234567/​intro.mp3</ResourceFileLink>` |
  `</BodyResource>` |
  `<BodyResource>` |
  `<SequenceNumber>2</SequenceNumber>` |
  `<ResourceFileDetail>A413</ResourceFileDetail>` |
  `<ResourceFileDetail>A416</ResourceFileDetail>` |
  `<ResourceFileFeature>` |
  `<ResourceFileFeatureType>06</ResourceFileFeatureType>` |
  `<ResourceFileFeatureValue>d51e3e6acd441499​db775707ea617a09</ResourceFileFeatureValue>` |
  `</ResourceFileFeature>` |
  `<ResourceFileLink>https://audiophiles.co.uk/​9780001234567/​chs1-7.wav</ResourceFileLink>` |
  `</BodyResource>` |
  `<BodyResource>` |
  `<SequenceNumber>3</SequenceNumber>` |
  `<ResourceFileDetail>A413</ResourceFileDetail>` |
  `<ResourceFileDetail>A416</ResourceFileDetail>` |
  `<ResourceFileFeature>` |
  `<ResourceFileFeatureType>06</ResourceFileFeatureType>` |
  `<ResourceFileFeatureValue>fc9b1e59efde1f69​8e07be56fddda445</ResourceFileFeatureValue>` |
  `</ResourceFileFeature>` |
  `<ResourceFileLink>https://audiophiles.co.uk/​9780001234567/​chs8-12.wav</ResourceFileLink>` |
  `</BodyResource>` |
  `</BodyManifest>` |
  `</ProductionManifest>` |
  `</ProductionDetail>` |

  using Short tags |
  --- | ---
  `<productiondetail>` |
  `<productionmanifest>` |
  `<bodymanifest>` |
  `<x560>A425</x560>` | Product includes ID3v2 tags
  `<specificationfeature>` |
  `<x561>21</x561>` | Loudness (for normalization…
  `<x562>-14</x562>` | of the audio resources)
  `</specificationfeature>` |
  `<bodyresource>` | First resource
  `<b034>1</b034>` |
  `<x567>A412</x567>` | 44.1kHz
  `<resourcefilefeature>` |
  `<x568>06</x568>` | MD5 hash
  `<x569>79054025255fb1a2​6e4bc422aef54eb4</x569>` |
  `</resourcefilefeature>` |
  `<x572>https://audiophiles.co.uk/​9780001234567/​intro.mp3</x572>` |
  `</bodyresource>` |
  `<bodyresource>` | Second resource
  `<b034>2</b034>` |
  `<x567>A413</x567>` | 48kHz
  `<x567>A416</x567>` | 16-bits per sample
  `<resource​file​feature>` |
  `<x568>06</x568>` | MD5 hash
  `<x569>d51e3e6acd441499​db775707ea617a09</x569>` |
  `</resourcefilefeature>` |
  `<x572>https://audiophiles.co.uk/​9780001234567/​chs1-7.wav</x572>` |
  `</bodyresource>` |
  `<bodyresource>` | Third resource
  `<b034>3</b034>` |
  `<x567>A413</x567>` | 48kHz
  `<x567>A416</x567>` | 16-bits per sample
  `<resourcefilefeature>` |
  `<x568>06</x568>` | MD5 hash
  `<x569>fc9b1e59efde1f69​8e07be56fddda445</x569>` |
  `</resourcefilefeature>` |
  `<x572>https://audiophiles.co.uk/​9780001234567/​chs8-12.wav</x572>` |
  `</bodyresource>` |
  `</bodymanifest>` |
  `</productionmanifest>` |
  `</productiondetail>` |

  Note that the above specifications are for illustrative purposes and are not necessarily realistic: some necessary details may be missing. The sample book has a cover, body and two inserts, with the cover and one insert being composed of just one resource file each, and the body and the other insert each comprising two resources. The audiobook consists of three resources, and the specification indicates that some resources must be resampled and compressed (some resources are WAV, which is generally not suitable for delivery to the end-customer). It also specifies that ID3 tags must be added to the final audio product.
  Note also that some ‘missing’ details such as the physical size or the digital file format of the product are defined in Block 1.

##### Product identifier composite (product part)

The <ProductIdentifier> composite is included within the Production manifest only when there are several repeats of the <ProductionManifest> composite relating to specific repeats of <ProductPart>. If there is only a single Production manifest, there is no need for a Product identifier, and it must be omitted.

Any Product identifier used must exactly match an identifier listed within an instance of <ProductPart> in Group P.4. Note that for Product parts that are not themselves products in their own right, it is common to use a proprietary ID (for example a UUID).

##### Cover manifest composite

The cover manifest consists of various specifications for the product cover, and at least one ‘resource’ (or file) for manufacture or digital packaging of the cover.

Of course, a bundle might also cover specifications for the body of the product too, but these are ignored here. (The same bundle would be named inside <BodyManifest>, where those parts of the bundle are taken into account.)

##### Specification bundle name composite

A specification bundle is a proprietary ‘product type’ that specifies all details of the cover of the product, for example a POD manufacturer’s ‘standard Type A paperback’, which is always a specific size, on a specific type of paper, and bound and covered in a specific way. This specification bundle may be something the manufacturer advertises, or something agreed in advance between publisher and manufacturer.

For example, if a POD manufacturer offers the choice of only two weights of cover card stock, 240 or 320gsm, and either an overall glossy or matte finish (a varnish or laminate), then there are only four possible cover option combinations. These could be bundled, and publishers could then choose one of bundles A–D – A being 240gsm with gloss varnish, B being 240gsm matte, C 320gsm gloss, and so on. Manufacturers may find it simpler to express their various offerings and options in this bundled way.

A set of bundles can be used to limit choices. In the above example with bundles A–D, if for technical reasons the lighter 240gsm card cannot be combined with a matte finish, then only bundles A, C and D need be offered. The bundles made available need not express every theoretical combination of options, only the limited set the manufacturer wishes to offer.

Separate bundles may be defined for cover, body and inserts, or a single, more comprehensive bundle may cover all the available options. It may be possible for publishers to specify a manufacturer’s bundle A for the various cover specifications in <CoverManifest> and to specify the manufacturer’s bundle #3 for the body specifications in <BodyManifest>. Alternatively the POD manufacturer may define a single range of bundles combining both cover and body specifications – that is, one particular named bundle would specify 320gsm cover card, an overall glossy cover finish, cream 80gsm paper for the interior and so on. In the latter case, the same bundle should be specified in both <CoverManifest> and <Bodymanifest>.

Often, a publisher will work with only a single POD manufacturer. But <SpecificationBundleName> is repeatable, so a publisher working with multiple manufacturers can specify one POD supplier’s Bundle C and Bundle #5 from another supplier (where C and #5 result in an almost identical final product).

Manufacturers should document clearly the specification options and bundles they offer and a specific <SpecificationBundleNameTypeName> to use for their bundles.

Bundling of specifications can be applied in the same way within digital audio and e‑book supply chains.

  Proprietary specification bundle
  using Reference names |
  --- | ---
  `<SpecificationBundleName>` |
  `<SpecificationBundleNameTypeName>Ingram POD ProdType<SpecificationBundleNameTypeName>` |
  `<SpecificationBundleNameValue>Type A</SpecificationBundleNameValue>` |
  `</SpecificationBundleName>` |

  using Short tags |
  --- | ---
  `<specificationbundlename>` |
  `<x558>Ingram POD ProdType<x558>` |
  `<x559>Type A</x559>` | Name of bundle of specifications
  `</specificationbundlename>` |

In general, either a specification bundle or a set of individual specifications in <SpecificationDetail> and <SpecificationFeature> would be used. Where both are provided, a manufacturer that recognizes their particular proprietary bundle should use the bundled specification. That is, the bundled specs take precedence over any individual specification details. However, it’s possible that a particular bundle might not define everything – the bundle can be augmented with individual <SpecificationDetail> elements and <SpecificationFeature> composites. And for manufacturers who do not define bundles, or who do not recognize a particular bundle, the detailed specifications in <SpecificationDetail> and <SpecificationFeature> should provide complete information.

##### Cover resource composite

A ‘resource’ is a file that should be used to manufacture or package the product – it might be a PDF for print-on-demand manufacture, audio as a WAV or other uncompressed audio file for conversion into an mp3 or AAC file, an HTML file for packaging up as an EPUB e‑book, or even a high-quality video file – though obviously the first is the most likely for a cover resource. <CoverResource> specifies various details of the file, and where it should be obtained by the manufacturer.

There can of course be many resources used to create the cover, and each must have its own repeat of <CoverResource>.

Each repeat can include a sequence number, 1, 2, 3 etc. For a cover, the main function of the sequence number is to indicate alternative resources, where one resource may be vendor-exclusive – the specific vendor is indicated in the <SalesOutlet> composite – and another resource used for other vendors. This approach can be used when a publisher creates an exclusive cover for copies sold through a specific retailer. Alternative resources share a sequence number – so where there are alternative resources, Sequence number is – effectively – mandatory. The <NoResource/> empty element can be used when a vendor-specific resource has no alternative to be used with other vendors.

When used in <InsertResource>, the Sequence number indicates the spine order of multiple insert resources, as well as being used for alternative resources.

When used in <BodyResource>, the Sequence number should indicate the spine order of multiple resources (alternative resources are not allowed in the Body manifest).

Note that <ResourceFileLink> is mandatory for each resource, and at least one <CoverResource> is mandatory within <CoverManifest>. <CoverResource> and <ResourceFileLink> are required even if the POD manufacturer defines a filenaming convention that renders them redundant. In such a circumstance, use <ResourceFileLink> to confirm the filename (even if the manufacturer does not need such confirmation).

##### Sales outlet composite

The Sales outlet composite is used an a way analogous to its use in the <SalesRestriction> composite, as a way of listing a resource that is exclusive to one or more retail outlets or retail platforms – for example a vendor-specific cover variation.

Note that by combining <SalesOutlet> with <NoResource/> it is also possible to specify absence of a resource for a specific outlet.

  Vendor-exclusive resource
  using Reference names |
  --- | ---
  `<SequenceNumber>3</SequenceNumber>` |
  `<SalesOutlet>` |
  `<SalesOutletIdentifier` |
  `<SalesOutletIDType>03</SalesOutletIDType>` |
  `<IDValue>AMZ</IDValue>` |
  `</SalesOutletIdentifier` |
  `<SalesOutletName>Amazon</SalesOutletName>` |
  `</SalesOutlet>` |

  using Short tags |
  --- | ---
  `<b034>3</b034>` |
  `<salesoutlet>` |
  `<salesoutletidentifier` |
  `<b393>03</b393>` | ONIX retail sales outlet ID
  `<b244>AMZ</b244>` | Amazon
  `</salesoutletidentifier` |
  `<b382>Amazon<b382>` |
  `</salesoutlet>` |

  With the above, there should be another <CoverResource> composite with the same Sequence number, for use with retail outlets other than Amazon. Where there is no alternative resource, a <CoverResource> composite containing the <NoResource/> empty element should be used.

##### Resource identifier composite

##### Resource file feature composite

##### Resource file date composite

##### Body manifest

##### Insert manifest

##### Supplement manifest

### Block 6: Product supply

#### Product supply composite

The <ProductSupply> composite is intended to carry commercial 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 in which the product is available. However, in many circumstances, it’s best to consider Block 6 of a Product record as consisting of a single, non-repeatable block that comprises all the <ProductSupply> composites in the record together. For block update purposes, and only when a consistent set of <MarketReference> labels are attached to each market, it may be treated as a truly repeatable block, with each repeat separately updateable via a block update.

ONIX 3.1 and 3.0 use 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. Markets are defined by the distribution arrangements the publisher has put in place – typically, each market has a different distributor, though markets can also be distinguished by sales agent or by customer type (eg where distribution to trade and education markets are treated differently). 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.

  Where a specific list of countries or regions that define the geographical extent of the market, or of price applicability, 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 in <Market> must be assumed to mean that the market is the totality of the area with positive <SalesRights>.
  Of course, not every market need be listed in a particular ONIX record. It may be that the sender of the ONIX message organizes its ONIX feeds so that details of only the market within which the message is distributed are specified, each message omitting irrelevant information about other markets. So the market territories listed in a message may be a subset of the sales rights territories, and other market(s) exist by implication only. In this case, the geographical extent of the market must be explicit in Block 6, even though there is no other market in the ONIX message – as otherwise, the broader <SalesRights> would be inherited.
  This multi-market structure in ONIX 3.1 and 3.0 is significantly different from ONIX 2.1. In 3.1 and 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.1 and 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.
  Although the four-level structure is the same in 3.0 as in 3.1, the <MarketReference> data element is not present in 3.0. In the absence of <MarketReference>, Block 6 must always be treated as a single non-repeatable block, and in block updates, all markets must be included in the update even if only one has been modified. With <MarketReference>, each market can be managed and updated individually via a Block update.

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, and the distinct market territories must ‘add up to’ the area covered by the positive sales rights;
  - 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.

The distinctive goals of the ONIX standard are overtly commercial – it aims to improve the efficiency of the supply chain and increase sales. Block 6 carries commercial information about markets, suppliers and prices, which is to some degree the raison d’être of the standard.

ONIX can describe one or more markets for the product – each <ProductSupply> composite describes an individual market. Most commonly, multiple markets are distinguished in geographical terms, based on exclusive distribution territories, for example, when one distributor operates in the Americas, another distributor in EMEA and a third in the Asia-Pacific market (see Group P.24). But markets might also be distinguished by having different market publication dates and publishing statuses within the market, or different sales restrictions (Group P.25). Finally, within each market, Group P.26 lists the various suppliers (distributors and wholesalers) that offer the product to that market, together with their prices.

See EDItEUR’s application note ONIX products in multiple markets (doi:10.4400/tkeq) for more details of how markets handled.

In principle, Block 6 consists of descriptions of all the separate markets, together ‘adding up’ to the Sales rights as stated in Group P.20. But it’s also common for an ONIX record to describe only the market within which the metadata is circulated – ONIX distributed to recipients in the Asia-Pacific market need not describe the Americas or EMEA markets – which of course means that the market is only a subset of the Sales rights.

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 there is only a single market that mirrors the ‘global’ details in Block 4. It must normally include details of at least one <Supplier> in the market(s), and the prices the supplier(s) charge (which might be a range of conventional prices, ‘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 ‘personalized 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 personalized pricing is more efficient than sending complete tailored Product records.

When used as a Block update, either:

- all markets (ie all repeats of <ProductSupply>) should be included in the update even though some markets may not have any updated metadata; or
- each market must be labelled in advance with a <MarketReference>, in which case, only the updated markets need be specified in the Block update;
- in either case, a particular market may be empty (or may contain only a <MarketReference>) if the intent is to ‘delete’ all information about that market.

Common issues with Block 6:

- failure of recipients to select the correct <ProductSupply> composite when multiple repeats of <ProductSupply> are present. Each of these repeats represents a different ‘market’, and details in a particular market may not apply to the market the recipient operates in;
- creating multiple markets (through repeats of <ProductSupply>) unnecessarily. Multiple markets should be distinguished either by different details in <MarketPublishingDetail> or different exclusive territorial and distribution arrangements in <Market> and <Supplier>. Different pricing in different parts of a market should be dealt with by repeating <Price>, within the relevant <Supplier> composite, not by treating it as a new market.

<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.1 and 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) in a simple, single market arrangement
  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>` |
  `<!-- there is only one market, so P.24 and P.25 details are not stated here, and are instead ‘inherited’ from Block 4 -->` |
  `<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 offered by the supplier must be included here -->` |
  `</SupplyDetail>` |
  `<!-- other suppliers in the market must be included here -->` |
  `</ProductSupply>` |
  `<!-- other markets cannot exist -->` |
  `</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
  `<!-- there is only one market, so P.24 and P.25 details are not stated here, and are instead ‘inherited’ from Block 4 -->` |
  `<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 (ex-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 offered by the supplier must be included here -->` | Otherwise the block update would have the effect of deleting them from the recipient’s system
  `</supplydetail>` |
  `<!-- other suppliers in the market must be included here -->` | Otherwise the block update would have the effect of deleting them from the recipient’s system
  `</productsupply>` |
  `<!-- other markets cannot exist -->` | Otherwise market details could not be inherited from Block 4
  `</product>` |

  Some data elements that are normally included within the Product supply composite – such as the geographical extent of the market in <Market> and any market-specific details in <MarketPublishingDetail> that might be provided in P.24 and P.25 – are missing from the example above. In many circumstances, they can be ‘inherited’ from Block 4. Other elements – a supplier identifier, returns information, trade discounts, prices for countries other than USA, and so on – have been omitted from the example for simplicity.
  Special care is needed if the Product record is a partial (‘Block’) update and there are multiple markets (that is, repeats of <ProductSupply>. In the absence of a <MarketReference> within each <ProductSupply> composite, 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. Alternatively, if <MarketReference> elements are provided for each market, then markets can be updated individually using a Block update. Compare the example above with that below.

  block update, updating Block 6 (specifically, confirming a new lower price) in a complex, multiple market arrangement
  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>` |
  `<!-- multiple markets, so P.24 and P.25 details not all inherited from Block 4 -->` |
  `<MarketReference>Americas.Ex.FR</MarketReference>` |
  `<Market>` |
  `<Territory>` |
  `<CountriesIncluded>CA US MX GL GT HN CR NI PA BZ SV AI AG BS CU DO HT JM KN LC GD KY VG VI PR MF BB VC MS DM BM TC AW BQ CW TT SX BR AR CL PE EC CO VE BO PY UY SR GY FK GS</CountriesIncluded>` |
  `<RegionsExcluded>CA-QC</RegionsExcluded>` |
  `</Territory>` |
  `</Market>` |
  `<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 offered by the supplier must be included here -->` |
  `</SupplyDetail>` |
  `<!-- other suppliers in the market must be included here -->` |
  `</ProductSupply>` |
  `<!-- other markets may be included if they also need updating, but repeats of <ProductSupply> that do not require updating may be omitted -->` |
  `</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
  `<!-- multiple markets, so P.24 and P.25 details not all inherited from Block 4 -->` |
  `<x587>Americas.Ex.FR</x587>` | Market reference
  `<market>` |
  `<territory>` |
  `<x449>CA US MX GL GT HN CR NI PA BZ SV AI AG BS CU DO HT JM KN LC GD KY VG VI PR MF BB VC MS DM BM TC AW BQ CW TT SX BR AR CL PE EC CO VE BO PY UY SR GY FK GS</x449>` | Which comprises the Americas, excluding various French and Francophone countries and regions
  `<x452>CA-QC</x452>` |
  `</territory>` |
  `</market>` |
  `<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 offered by the supplier must be included here -->` | Otherwise the block update would have the effect of deleting them from the recipient’s system
  `</supplydetail>` |
  `<!-- other suppliers in the market must be included here -->` |
  `</productsupply>` |
  `<!-- other markets may be included if they also need updating, but repeats of <ProductSupply> that do not require updating may be omitted -->` |
  `</product>` |

The use of <MarketReference> – introduced in Release 3.1 – to include a persistent label for each market significantly changes the way that Block 6 price and availability Block updates are processed. Without <MarketReference>, Block 6 must be treated as a single, non-repeatable block that includes multiple <ProductSupply> composites. If one <ProductSupply> is updated, a Block update must include all repeats of <ProductSupply>. In contrast, with a <MarketReference> for each repeat of <ProductSupply> – established in a prior message – Block 6 may be treated as repeatable, with each <ProductSupply> being a separately updateable Block 6 in its own right.

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

Group P.24 may also include a <MarketReference>, which has specific utility in Block updates – see the extended examples above.

Resellers within the supply chain – wholesalers, retailers etc – need a clear indication of where they should place orders. Where the product is available in multiple markets, distributors are each likely to have exclusive distribution territories. Wholesalers and retailer must have this information so that orders are placed reliably with the appropriate vendor, without raising customer service issues. Understanding the territorial extent of each market is critical.

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 implication is that there is just a single market, and the ‘global’ sales rights information in Block 4 should be used by ONIX recipients to determine the geographical extent of that market plus any relevant sales restrictions within the market.

Common issues in Group P.24;

- invalid combinations of data elements within <Territory>, for example using both <CountriesIncluded> and <CountriesExcluded> in the same <Territory> composite;
- incompatible geographical markets where <SalesRights> shows the product is not for sale in countries for which market, supplier and price details are provided. The geographical extent of a market must not extend beyond the ‘for sale’ rights territories (Sales rights type codes 01 and 02 combined).

##### Market reference

The Market reference data element is intended to carry a persistent ‘label’ for the market. This label can be as simple as a textual name for the market – ‘Americas’ or ‘South Asia’ – or it can be a more complex proprietary identifier. The only important criteria are that it must be distinct, and consistently used within this particular record, from first time the record is supplied, through any subsequent updates and partial updates. It shows the continuity of the ‘same’ market, even while any minor details of that market may change. (In this respect it is somewhat like <RecordReference>, but the scope of a <MarketReference> is limited to a single product. That is, a market labelled ‘Americas’ used within one product record need not be the same as a similarly-labelled market within another product record.)

Market references are critical to Block updating. In the absence of a Market reference, any update of Block 6 must include all repeats of <ProductSupply> previously sent – a partial (‘Block’) update of one market among several (ie of one repeat of <ProductSupply> among several) isn’t possible, and is liable to cause recipients to ‘delete’ other markets. To avoid this, Block 6 must be treated as a single non-repeatable block that can contain multiple <ProductSupply> composites.

In contrast, in the presence of Market references, then Block 6 can be treated as a truly repeatable block, each repeat of the block containing a single market (ie a single <ProductSupply> composite). Each can be Block updated individually.

  using <MarketReference> labels with a sequence of conventional and block updates within an ongoing data feed
  initial supply of market data for three markets, using Reference names
  `<ProductSupply>` |
  `<MarketReference>HBG Mkt 101</MarketReference>` |
  `<!-- all details of the first market -->` |
  `</ProductSupply>` |
  `<ProductSupply>` |
  `<MarketReference>HBG Mkt 102</MarketReference>` |
  `<!-- all details of the second market -->` |
  `</ProductSupply>` |
  `<ProductSupply>` |
  `<MarketReference>HBG Mkt 103</MarketReference>` |
  `<!-- all details of the third market -->` |
  `</ProductSupply>` |

  subsequent conventional update for all markets (at least one market has updated details)
  `<ProductSupply>` |
  `<MarketReference>HBG Mkt 102</MarketReference>` |
  `<!-- all details of the second market -->` |
  `</ProductSupply>` |
  `<ProductSupply>` |
  `<MarketReference>HBG Mkt 101</MarketReference>` |
  `<!-- all details of the first market -->` |
  `</ProductSupply>` |
  `<ProductSupply>` |
  `<MarketReference>HBG Mkt 103</MarketReference>` |
  `<!-- all details of the third market -->` |
  `</ProductSupply>` |

  subsequent partial (‘block’) update of data for one of the three markets
  `<ProductSupply>` |
  `<MarketReference>HBG Mkt 103</MarketReference>` |
  `<!-- all details of the updated third market -->` |
  `</ProductSupply>` |

  partial (‘block’) update of data for one of the three markets, using short tags
  `<productsupply>` |
  `<x587>HBG Mkt 103</x587>` |
  `<!-- all details of the updated third market -->` |
  `</productsupply>` |

  Neither the nature of the Market reference (it is inevitably proprietary and need not be used consistently across different products), nor the order of the <ProductSupply> composites within a Product record is significant. Market ‘103’ in another Product record (even from the same data supplier) may have a different geographical territory, different restrictions, different sales agent or market date details, different distribution arrangements and so on.

##### Market composite

The <Market> composite carries details of the geographical extent of a market, together with any Sales restrictions that apply in that area.

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 stated 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, UK and EFTA)
  using Reference names |
  --- | ---
  `<Market>` |
  `<Territory>` |
  `<CountriesIncluded>AT BE BG CY CZ DE DK EE ES FI FR GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK GB 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 GR HR HU IE IT LT LU LV MT NL PL PT RO SE SI SK GB CH IS LI NO​</x449>` | 32 countries in the EU, UK 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>.

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

In general, if the product is available in only a single market (ie a single distributor supplies all the territories where the product is for sale, without any significant differences of availability date across the market), there is no need for Group P.23 – although even in this instance, if the publisher uses a sales agent or publisher representative, P.23 should specify the agent. And if the product is available in multiple markets, Group P.23 carries the market-specific status and date information required by resellers in that market.

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.

Common issues in Group P.25:

- confusion between the roles of distributor (which is primarily a warehousing, order administration and fulfillment role) and a sales agent or publisher representative, who acts as the publisher’s proxy in the market and has a broader remit, likely including marketing activity at the very least and possibly including more strategic issues. The publisher representative may carry out the distribution role as well, or may deal with a third-party distributor;
- confusion between a market-specific ‘publication date’ and the publication date given in Group P.20. The former can be the same as or later than the latter – but a market publication date cannot be earlier than the publication date of the product. The Group P.20 publication date is the earliest publication in any market.

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

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

##### Market date composite

Some Market publishing statuses require associated dates in <MarketDate>, and these can override Publishing dates provided in Block 4 for a specific market only.

  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 normally be at least one <SupplyDetail> composite within the <ProductSupply> composite. Each repeat of <SupplyDetail> describes one supplier and the pricing it offers, 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 at least one <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 excluding tax in North America, and in other territories where prices are normally advertised ex‑tax and where sales tax is applied only on the final sale to the consumer;
  - prices should normally be quoted including 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 ex-tax price must be calculated separately. This should be avoided wherever possible;
  - there should be no tax details for a price quoted ex-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.

<SupplyDetail> may be omitted in one specific circumstance, in a Block update, when a <MarketReference> for the product has been specified and when the intention is to make it clear the market has ‘disappeared’ – for example when the market territory has been absorbed into another market due to a change in distribution arrangements, or a market has been lost due to a change in the rights held by the publisher.

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 almost always country-specific);
- use of the <TaxExempt/> flag when in fact the product is taxable at a rate of zero percent – these are not the same;
- multiple prices lacking any indication of where each is applicable. This is often caused by specifying currency but not country;
  - currency does not imply country;
  - if a <Price> omits the <Territory> to which that price applies, then the price 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.1 and 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>` | Value added tax
  `<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>` | Value added tax
  `<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, ex-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, ex-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 ex-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 ex-tax
  `<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>` | Value added tax
  `<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>` | Value added tax
  `<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 ex-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>. For European Union GPSR purposes, safety and liability contacts require a full postal address.

  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 details for ordinary customer enquiries and for safety and liability issues (where the publisher’s distributor is the responsible organization on behalf of a publisher outside the EU)
  `<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<x299>` |
  `<j270>+44 1767 604800</j270>` |
  `<j272>custserv@turpin-distribution.com</j272>` |
  `</supplycontact>` |
  `<supplycontact>` |
  `<x537>10</x537>` | Safety enquiries
  `<supplycontactidentifier>` |
  `<x538>07</x538>` |
  `<b244>0155144</b244>` |
  `</supplycontactidentifier>` |
  `<x539>Turpin Distribution</x539>` |
  `<x299>Customer services<x299>` |
  `<j270>+44 1767 604800</j270>` |
  `<j272>safety@turpin-distribution.com</j272>` |
  `<x552>Stratton Business Park, Pegasus Drive</x552>` |
  `<j349>Biggleswade</j349>` |
  `<x590>SG18 8TQ</x590>` |
  `<b398>GB-ENG</b398>` | England
  `<b251>GB</b251>` | United Kingdom
  `</supplycontact>` |

  For UK addresses, the postcode does not (easily) identify England, Scotland, Wales or Northern Ireland, so a <RegionCode> is useful. For other countries, the postcode and country may be enough for a full address.
  The contact for safety purposes above is not compliant with the EU’s General Product Safety Regulation. For GPSR purposes, the contact for safety enquiries must be based within the European Economic Area (that is, the country code should be AT, BE, BG, HR, CY, CZ, DK, EE, FI, FR, DE, GR, HU, IE, IT, LV, LT, LU, MT, NL, PL, PT, RO, SK,Si, ES, SE [ie the European Union], IS, LI, NO [additional EEA countries], or GB [but only if the responsible party is based in Northern Ireland – region code GB-NIR]).

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

  Setting returns conditions and Last date for returns for an OP product
  using Reference names |
  --- | ---
  `<ReturnsConditions>` |
  `<ReturnsCodeType>04</ReturnsCodeType>` |
  `<ReturnsCode>05</ReturnsCode>` |
  `</ReturnsConditions>` |
  `<ProductAvailability>51</ProductAvailability>` |
  `<SupplyDate>` |
  `<SupplyDateRole>18</SupplyDateRole>` |
  `<Date>20220726</Date>` |
  `</SupplyDate>` |

  using Short tags, with additional Returns note |
  --- | ---
  `<returnsconditions>` |
  `<j268>04</j268>` | ONIX returns codes
  `<j269>05</j269>` | Sale or return (of saleable copies)
  `<x528>Obtain RMA from customer services</x528>` |
  `</returnsconditions>` |
  `<j396>51</j396>` | Unavailable, out of print
  `<supplydate>` |
  `<x461>18</x461>` | Last date for returns
  `<b306>20220726</b306>` |
  `</supplydate>` |

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. In general, this should be interpreted as ‘business days’.

  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>` |
  `<Proximity>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 in stock and available to fulfill orders – it does not include in-stock copies that have already been reserved for 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 retailer orders exceed the number of copies in stock and no further copies are on order from the distributor. But if further new copies are on order from upstream in the supply chain to cover those orders from downstream, 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.

How might the wholesaler’s stock change over time?

| OnHand | Reserved | OnOrder | CBO
--- | --- | --- | --- | ---
Prior to announcement of product | 0 | 0 | 0 | 0
Wholesaler has no stock, no retailer orders and no orders placed with the distributor
– initial order from wholesaler placed with distributor | 0 | 0 | 99 | 0
Wholesaler places order for 99 copies with distributor, but none of those copies are committed yet since no retailer orders received
– initial orders from retailers placed with wholesaler | −101 | 0 | 99 | 99
Wholesaler has recorded 200 orders from retailers, but still has only 99 copies on order from the distributor (all of which are committed to fulfilling the retailer orders). A further 101 copies will be required to meet outstanding retailer orders
– delivery of 99 copies from the distributor | −101 | 99 | 0 | 0
Initial copies delivered from the distributor, but all are immediately reserved to meet existing orders
– place order for 500 copies with distributor | 0 | 99 | 500 | 101
New order placed with distributor, of which 101 copies are committed to meet existing retailer orders
– fulfill backorders until stock is exhausted | 0 | 0 | 500 | 101
The 99 reserved copies in stock are dispatched to retailers
– accept new order for 48 copies from retailer A | 0 | 0 | 500 | 149
Further copies from the 500 on order are committed
– 500 copies delivered from distributor | 351 | 149 | 0 | 0
Of the 500, 149 copies are reserved to fulfill the existing orders, leaving 351 copies ‘free stock’
– fulfill outstanding backorders | 351 | 0 | 0 | 0
The 149 reserved copies are dispatched
– place order for 50 copies with distributor | 351 | 0 | 50 | 0
None of the 50 copies on order need to be committed, as there are no outstanding orders that cannot be fulfilled
– accept 10 saleable copies back as returns | 361 | 0 | 50 | 0
The 10 copies are returned to stock
– accept order for 75 copies from retailer B | 286 | 75 | 50 | 0
75 copies of the free stock is reserved…
– dispatch 75 copies to retail chain B | 286 | 0 | 50 | 0
…then dispatched
– accept order for 400 copies from retail chain C | −64 | 286 | 50 | 50
The 286 copies in free stock are reserved, the 50 on order are committed, and the wholesaler needs a further 64 copies before it can fulfill the retailer order in its entirety

Note the narrative above describes movements in a wholesaler’s stock. Distributors can use the same data structure, recording orders from wholesalers and expected deliveries from the printer.

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 and 3.1 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. The approximate weight of a carton – given by the weight of the product in <Measure> multiplied by the <PackQuantity> – can be important safety information for distributors, wholesalers, freight forwarders, carriers and other logistics organizations, and retailers.

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 <OrderQuantityMinimum> and <OrderQuantityMultiple>.

##### P.26.41b to P.26.41d 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 (in this location within the <SupplyDetail> composite) 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.70b). 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 – simple
  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>` |

  free of charge POS item – with non-zero value for customs purposes
  using Reference names |
  --- | ---
  `<SupplyDetail>` |
  `<Supplier>` |
  `. . .` |
  `</Supplier>` |
  `<ProductAvailability>21<ProductAvailability>` |
  `<Price>` |
  `<PriceType>37</PriceType>` |
  `<PriceAmount>5.00</PriceAmount>` |
  `<CurrencyCode>USD</CurrencyCode>` |
  `</Price>` |
  `<Price>` |
  `<PriceType>05</PriceType>` |
  `<UnpricedItemType>01</UnpricedItemType>` |
  `</Price>` |
  `</SupplyDetail>` |

  using Short tags |
  --- | ---
  `<supplydetail>` |
  `<supplier>` |
  `. . .` |
  `</supplier>` |
  `<j396>21</j396>` | In stock
  `<price>` |
  `<x462>37</x462>` | Nominal value for customs purposes, used when the product crosses customs borders within the market
  `<j151>5.00</j151>` |
  `<j152>USD</j152>` |
  `</price>` |
  `<price>` |
  `<x462>05</x462>` | Supplier’s net price
  `<j192>01</j192>` | FOC
  `</price>` |
  `</supplydetail>` |

  This item is free of charge to the retailer and not for sale to retail customers (note there is no retail price, and a net price is used instead). The FOC net price is accompanied by a nominal $5 value for customs purposes.

  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. In some countries – for example USA and the UK – virtually all prices are quoted as Recommended retail prices (Price type codes 01 or 02). In other countries such as France or Germany, retail prices for books are controlled legally or via a trade agreement and prices are usually quoted as Fixed retail prices (Price type codes 03 and 04). A discount is applied to these prices to calculate the ‘trade price’ for transactions within the book trade. In a few countries, it is common practice to quote prices as ‘net’ or Wholesale prices, which are not subject to trade discount, and retailers apply a mark-up to calculate their price to the end purchaser.

Price conditions and constraints 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. The same logic should be applied to Price constraints.

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 ex-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’ ex-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 ex-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 ex-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 ex-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 ex-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 ex-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 ex-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 ex-tax -->` |
  `</price>` |

  In addition to the different Price qualifiers on the two prices above, one is quoted inc-tax, the other ex-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) | ex-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 | ex-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) | ex-tax | inc-tax
  --- | --- | ---
  Publisher’s retail price | 41 | 42

  Special sales (generally non-returnable, often retailer-specific) ⁶ | ex-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 ex-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. However, in general, the application of the same type of constraint at both product level (in <EpubUsageConstraint>) and price level (in <PriceConstraint>) should be avoided as it may cause some confusion. A particular constraint type should be specified either at product level or at price level, and ideally not at both.

  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>` |
  `<PriceConstraintStatus>01</PriceConstraintStatus>` |
  `</PriceConstraint>` |
  `<PriceTypeDescription>Perpetual license option</PriceTypeDescription>` |
  `<PriceAmount>27.95</PriceAmount>` |
  `<CurrencyCode>EUR</CurrencyCode>` |
  `<Territory>` |
  `<CountriesIncluded>AT BE CY EE FI FR DE ES GR HR IE IT LT LU LV 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>` |
  `</PriceConstraintLimit>` |
  `</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>` | Ex-tax price
  `<x317>02</x317>` | Digital watermarking
  `<priceconstraint>` |
  `<x529>00</x529>` | No constraints (for confirmation)
  `<x530>01</x530>` | Required for validation (actual value is irrelevant)
  `</priceconstraint>` |
  `<j262>Perpetual license option</j262>` |
  `<j151>27.95</j151>` |
  `<j152>EUR</j152>` |
  `<territory>` |
  `<x449>AT BE CY EE FI FR DE ES GR HR IE IT LT LU LV MT NL PT SI SK AD MC SM VA ME</x449>` | Valid in 20 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. The preceding <UsageConstraint> composites and the specified license apply e‑publication when the product is purchased at the price in <PriceAmount>. Different constraints, and a different license, may apply when a different Price amount is paid. (The details in Group P.3 are used where a license applies to the product, irrespective of how it is purchased and how much is paid, and the similar details in Block 3 apply to individual Content items, again irrespective of how the product is purchased and how much is paid).

Note that the Digital product license composite within <Price> does not include <EpubLicenseDate>: if the license is only valid from or until a specific date, then the <Price> itself is only valid from or until that date – and therefore the <PriceDate> composite should be used.

##### 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 contained in the multi-pack. These packs should have a Product form code from List 150 beginning with X. 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 contained items.

The price of each individual retail item is usually detailed in a separate product record. For products that are only available to the trade in a multipack, there may not be a separate product record, though inclusion of a separate record is recommended. Examples include packs of low-value products such as cards, leaflets or small-extent books, gift items and so on. Ideally there should still be two ONIX Product records, one for the multi-pack and one for the individual item, but the Publishing status and Product availability for the individual item can be set to make it clear that the individual item cannot be ordered singly – using ‘Active but not sold separately’ in List 64 and ’Not sold separately’ in List 65.

The most common errors are of course to provide a price that relates to an individual copy within the Product record for the multipack, or to interpret the price of the multi-pack as the price of the individual contained item.

<PricePer> is also used to specify prices that are not based on ‘a copy of the whole product’, for example updates intended for loose-leaf products which are priced on a per-page basis.

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

  Only the rental extensions and convert-to-purchase options use Price conditions.

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

  Buy multiple copies of one product, get another product at a reduced price or free
  using Reference names |
  --- | ---
  `<Price>` |
  `<PriceTypeDescription>Buy ten copies of the linked product, qualify for purchase of one copy of this product at half price</PriceTypeDescription>` |
  `. . .` |
  `<PriceCondition>` |
  `<PriceConditionType>06</PriceConditionType>` |
  `<PriceConditionQuantity>` |
  `<PriceConditionQuantityType>03</PriceConditionQuantityType>` |
  `<Quantity>10</Quantity>` |
  `<QuantityUnit>00</QuantityUnit>` |
  `</PriceConditionQuantity>` |
  `<ProductIdentifier>` |
  `<ProductIDType>15</ProductIDType>` |
  `<IDValue>9780832423811</IDValue>` |
  `</ProductIdentifier>` |
  `</PriceCondition>` |
  `. . .` |
  `<PriceAmount>5.95</PriceAmount> <!-- ‘normal price’ is $11.95 -->` |
  `</Price>` |

  using Short tags |
  --- | ---
  `<price>` |
  `<j262>Buy ten copies of the linked product, qualify for *three* of this product free of charge</j262>` |
  `. . .` |
  `<pricecondition>` |
  `<x463>06</x463>` | Purchase of linked product
  `<priceconditionquantity>` |
  `<x464>03</x464>` | Number of copies of linked product
  `<x320>10</x320>` |
  `<x466>00</x466>` |
  `</priceconditionquantity>` |
  `<priceconditionquantity>` | Number of copies of this product
  `<x464>04</x464>` |
  `<x320>3</x320>` |
  `<x466>00</x466>` |
  `</priceconditionquantity>` |
  `<productidentifier>` | ISBN of linked product
  `<b221>15</b221>` |
  `<b244>9780832423811</b244>` |
  `</productidentifier>` |
  `</pricecondition>` |
  `. . .` |
  `<j192>01</j192>` | Free of charge
  `</price>` |

  Note that the above Price conditions appear in the Product record for the product that is free of charge or reduced in price, and there would usually be another price for that product that is not conditional on purchases of the other product. A <RelatedProduct> link can appear in the Product record for the ‘other’ product to highlight the offer and link the two products.

  Three-for-the-price-of-two offer (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 discounts. 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.5% 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, so 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, based on their retailer-specific lookup tables
  `</discountcoded>` |

Where discounts are not commercially sensitive, and do not vary from retailer to retailer – or where an ONIX message is exchanged solely in the context of a specific trading relationship – they can be expressed as plain percentages, and should be carried in a <Discount> composite instead, within the simple <DiscountPercent> data element. Repeated <Discount> composites can also be used to specify rising discounts based on order quantities.

  rising discount based on order quantity
  using Reference names |
  --- | ---
  `<Discount>` |
  `<DiscountPercent>36.5</DiscountPercent>` |
  `</Discount>` |
  `<Discount>` |
  `<Quantity>10</Quantity>` |
  `<DiscountPercent>41</DiscountPercent>` |
  `</Discount>` |

  using Short tags |
  --- | ---
  `<discount>` |
  `<j267>36.5</j267>` | No minimum order for 36.5% discount
  `</discount>` |
  `<discount>` |
  `<x320>10</x320>` |
  `<j267>41</j267>` | Additional 4.5% for orders of 10 copies or more
  `</discount>` |

  An order for 15 copies qualifies for the higher discount. If the list price of the book is €10, the retailer will pay €88.50 (10 × 15 – 41%).

  progressive discount based on order quantity
  using Reference names |
  --- | ---
  `<Discount>` |
  `<DiscountType>03</DiscountType>` |
  `<Quantity>1</Quantity>` |
  `<ToQuantity>10</ToQuantity>` |
  `<DiscountPercent>36.5</DiscountPercent>` |
  `</Discount>` |
  `<Discount>` |
  `<DiscountType>03</DiscountType>` |
  `<Quantity>11</Quantity>` |
  `<ToQuantity>0</ToQuantity>` |
  `<DiscountPercent>41</DiscountPercent>` |
  `</Discount>` |

  using Short tags |
  --- | ---
  `<discount>` |
  `<x467>03</x467>` | Progressive discount
  `<x320>1</x320>` | Effectively, no minimum order for 36.5% discount
  `<x514>10</x514>` | but 36.5% applies only to the first 10 copies
  `<j267>36.5</j267>` |
  `</discount>` |
  `<discount>` |
  `<x467>03</x467>` |
  `<x320>11</x320>` | From the 11th copy, 41% discount
  `<x514>0</x514>` | with no upper limit
  `<j267>41</j267>` |
  `</discount>` |

  Part of an order for 15 copies qualifies for the higher discount. If the list price of the book is €10, the retailer will pay €93.00 ( (10 × 10 – 36.5%) + (10 × 5 – 41%) ).

For products – particularly in the e‑book supply chain – that are traded under the Agency model (ie where the <PriceType> is 41 or 42), the <Discount> composite should be interpreted as the ‘commission composite’. A percentage specified in <DiscountPercent> indicates the commission that the agent earns for the sale. This percentage is usually fixed, but might vary from product to product. If the commission (on a particular product) varies between agents or is commercially sensitive for any other reason, the <DiscountCoded> composite may be used to specify the commission indirectly (using Discount code type 05 or 06).

Of course, if the price quoted in the enclosing <Price> composite is a wholesale price (a business-to-business price, <PriceType> codes 05, 07, etc) rather than one based on a retail price less a discount, then neither <DiscountCoded> nor <Discount> would normally be included at all. However, wholesale prices may sometimes be accompanied by additional discounts for volume purchases (ie by a <Discount> composite containing a <Quantity> data element as well as the percentage).

##### P.26.61 Price status

A product announced in an ONIX record several months before publication might go through the following stages prior to publication:

1. product announced, <UnpricedItemType> code 02 (price to be announced), no <Price> composite
2. price announced, <PriceStatus> code 01 (provisional)
3. price announced, <PriceStatus> code 02 (firm)

  Firm here does not imply ‘firm-sale’ (as contrasted with ‘sale or return’), but suggests that orders placed at that price will be honored, even if the price is revised prior to fulfillment of the order. Orders placed against a provisional price may be subject to price changes. Firm sales (in the sense of ‘not sale or return’) should be indicated using a Special Sales Price type.

##### P.26.62 Price amount

A price should be included for all products except those that are explicitly unpriced or free of charge (so a zero price should never be used). The price can be supplied either as an amount in a specified currency using <PriceAmount> or, in exceptional circumstances, as a price tier or code using <PriceCoded> (and again, a currency should be specified, unless the coding scheme makes it explicit that a tier relates to multiple prices in different currencies). The tier/code option should only be used when the product is retailer or at least retail platform-specific, and is only relevant when that retailer or platform sets a fixed set of price tiers for the products in its store. Each <Price> composite should contain only one price.

It is best practice to always provide the Price amount as a real number with the conventional number of explicit decimal digits, even when the digits are trailing zeros – so a price should typically be given as 3.00, not 3 or 3.0. Prices and other real numbers in ONIX must always use the period character ‘.’ as the decimal separator, not a comma or mid-dot, though recipients may display prices using the conventional decimal separator for the locale (for example, a price of 7.95 in the ONIX data, with a period, would be displayed in France with a comma, as ‘€7,95’ or ‘7,95€’ – even occasionally as ‘7€95’). And for very large numbers, there should be no ‘thousands separator’ in the ONIX data, even though the price might be displayed with a group separator (ie a price of 1275.00 with currency code MXN in the ONIX would be displayed as ‘$1,275.00’ in Mexico, with the Peso symbol, a comma as the group separator and a period as the decimal separator).

  List 96 indicates the conventional number of decimal places for each currency, taken from ISO 4217 and the Unicode Common Locale Data Repository. For most currencies, convention suggests two decimal places (eg 100 cents = 1 US Dollar). A handful of currencies use three decimal places (eg 1000 fils = 1 Jordanian Dinar), and List 96 indicates this. About 50 currencies are conventionally quoted as integers without any decimal places (eg Japanese Yen, Korean Won). For these currencies, either there are no subunits, or the previous subunits (eg the sen and jeon for the Yen and Won) are no longer in practical use, and this is also indicated in the codelist. However, while it is best practice to quote prices with the conventional number of decimal places, it is not an error – merely poor practice – to omit trailing zeros.
  A zero Price amount is not valid. This limitation has always been implicit in ONIX, but recent versions of the ONIX XSD and RNG schemas have explicitly disallowed a zero Price amount. The restriction was tightened because it is a common software error to confuse zero (free of charge) with blank (price is not yet set) or null (price is unknown), and this could lead to products being mistakenly advertised as free of charge.

##### Price coded composite

This composite is used only for supplying prices which are specified as tiers in a price list, rather than as absolute amounts. Some tiering systems use a single tier that translates into multiple prices in various currencies (so Tier 7 could mean $6.95, €4.95 and £4.45), and others use independent tiers for each currency or work in only a single currency. In either case, the currency is implicit within the tier definition, so <PriceCoded> should be used without <Tax>, <CurrencyCode> and usually without <Territory>. In contrast, <PriceCoded> does not prelude the use of <PriceDate> (eg to notify future changes in tier), <Discount> or <DiscountCoded> (for business-to-business discounts or agency commission rates), or other type- and status-related elements (eg <PriceType>, <PriceCondition> and <PriceStatus>).

<PriceCoded> can also be used to implement a ‘virtual currency’ or a points-based system, within for example a subscription scheme. An international reseller might define a proprietary ‘virtual currency’ with a dynamic exchange rate to the real currencies it charges purchasers, with the advantage that the publisher needs to manage the price in only a single currency (the virtual one) – real currency prices can then be presented to the potential purchaser, and those real prices can vary in real time.

Alternatively, in either prepay or subscription scenarios, a points-based system could be used, with consumers pre-purchasing or earning points to ‘spend’ on books – for example, a subscriber could receive ten points per month, and some books could ‘cost’ 2 points, some 3 points, some 5 points.

  Virtual currency pricing
  using Reference names |
  --- | ---
  `<Price>` |
  `<PriceType>01</PriceType>` |
  `<PriceCoded>` |
  `<PriceCodeType>01</PriceCodeType>` |
  `<PriceCodeTypeName>¥€$</PriceCodeTypeName>` |
  `<PriceCode>12.95</PriceCode>` |
  `</PriceCoded>` |
  `<!-- No Tax composite -->` |
  `<!-- No Territory composite -->` |
  `</Price>` |

  using Short tags |
  --- | ---
  `<price>` |
  `<x462>01</x462>` | Ex-tax price
  `<pricecoded>` |
  `<x465>01</x465>` |
  `<x477>¥€$</x477>` | Virtual currency name
  `<x468>12.95</x468>` |
  `</pricecoded>` |
  `<!-- No tax composite -->` | Reseller to add tax
  `<!-- No territory composite -->` | Virtual price applies throughout market
  `</price>` |

  Price is 12.95 in a virtual currency called ‘Yes’. The retailer could maintain dynamic exchange rates to real currencies used by consumers, and add local taxes. Publisher remuneration could be based on the virtual exchange rate or revenue share (fixed contractually rather than in the ONIX metadata).

  Price tier 7a
  using Reference names |
  --- | ---
  `<PriceCoded>` |
  `<PriceCodeType>01</PriceCodeType>` |
  `<PriceCodeTypeName>ebookvendor.com</PriceCodeTypeName>` |
  `<PriceCode>7a</PriceCode>` |
  `</PriceCoded>` |

  using Short tags |
  --- | ---
  `<pricecoded>` |
  `<x465>01</x465>` |
  `<x477>ebookvendor.com</x477>` | Tier type
  `<x468>7a</x468>` | Real-world price points for each tier based on a lookup table of tiers and currencies, which could be unique per publisher
  `</pricecoded>` |

Normal use would include a <PriceCodeTypeName> as the virtual currency or points basis, or the tier structure and the relationship of each tier to an actual price amount would most likely be unique to a particular retailer, and tier values could vary across publishers (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 ex-tax Price types in P.26.43.

The <Tax> composite should not be used with ex-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 ex-tax Price type indicates that these taxes are not included in the specified price.

Although every element in the <Tax> composite is optional, it is best practice to supply all elements of the composite, to make the tax calculation explicit and so the recipient can choose which elements to use or display. The exception to this is that the <TaxableAmount> and <TaxAmount> should be omitted when <PriceCoded> is used. In all other 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>. Note multiple tax rates cannot be used with <PriceCoded>.

  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>` | Ex-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 ex-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 ex-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>` | Value added tax
  `<x471>Z</x471>` | Zero rate
  `<x472>0</x472>` | Percent
  `<x473>7.99</x473>` | Ex-VAT price
  `<x474>0.00</x474>` | Tax amount
  `</tax>` |
  `<j152>GBP</j152>` | UK £
  `<territory>` |
  `<x449>GB</x449>` | Price valid in UK only
  `</territory>` |
  `</price>` |

  In the UK, physical books and e‑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, and physical or digital audiobooks, are often not eligible for the zero rate, and are taxed at the standard rate of 20%. A few other countries have similar VAT arrangements. (The differentiation is usually driven by the product’s commodity code – see <ProductClassification> in Group P.3.)

  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>` | Value added tax
  `<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>` | Tax amount (on this portion)
  `</tax>` |
  `<tax>` |
  `<x470>01</x470>` | Value added tax
  `<x471>Z</x471>` | Zero rate
  `<x472>0</x472>` | Percent
  `<x473>2.93</x473>` | Ex-VAT price (of this portion)
  `<x474>0.00</x474>` | Tax amount (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>` |
  `<ProductFormDetail>B418</ProductFormDetail>` |
  `</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>` |
  `<b333>B418</b333>` | Paper cover
  `</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>` | TVA on base price
  `</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>` | Euro
  `<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 Tax exempt

The <TaxExempt/> empty element is only used where the product is statutorily exempted from Value added and Sales taxes. It is important not to confuse this with items that are taxed at a rate of zero percent – several countries maintain a zero rate of VAT for books, but these are not ‘exempt’.

Clearly, <TaxExempt/> should only be used with Price types that exclude tax.

  A Korean product – fixed price and tax exempted
  Using Reference names |
  --- | ---
  `<Price>` |
  `<PriceType>03</PriceType>` |
  `. . .` |
  `<PriceAmount>14900<PriceAmount>` |
  `<TaxExempt/>` |
  `<CurrencyCode>KRW</CurrencyCode>` |
  `<Territory>` |
  `<CountriesIncluded>KR</CountriesIncluded>` |
  `</Territory>` |
  `<PrintedOnProduct>02</PrintedOnProduct>` |
  `<PositionOnProduct>01</PositionOnProduct>` |
  `</Price>` |

  using Short tags |
  --- | ---
  `<price>` |
  `<x462>03</x462>` | Fixed retail price ex-tax
  `. . .` |
  `<j151>14900<j151>` |
  `<x546/>` | Tax-exempted
  `<j152>KRW</j152>` | South Korean Won
  `<territory>` |
  `<x449>KR</x449>` | Price valid in South Korea
  `</territory>` |
  `<x301>02</x301>` | Price printed…
  `<x313>01</x313>` | On back cover
  `</price>` |

  Under Korean law, books are exempted from VAT, rather than being taxed at 0%. This contrasts with the way books are taxed in most EU countries.

##### P.26.70b Unpriced item type

The <UnpricedItemType> element may be used in either of two places in ONIX 3.1: first, see P.26.42, for products that are entirely unpriced, and second at P.26.70b, 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 specified, but there should be a conventional, non-free 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. A third option is to use <UnpricedItemType> to indicate that a particular supplier does not (for whatever reason) supply to the whole of the market.

Other uses, much less common, include specifying that, although the supplier has the right to supply the product throughout the market, it declines to supply to a specific country or group of countries, or that, although other prices have been set, some specific price is yet to be announced.

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

  Priced in part of market, supplier does not supply in remainder of market
  using Reference names |
  --- | ---
  `<Market>` |
  `<Territory>` |
  `<CountriesIncluded>CA US MX PM GL GT HN CR NI PA BZ SV AI AG BS CU DO HT JM KN LC GD KY VG VI MQ PR MF BL GP BB VC MS DM BM TC AW BQ CW TT SX BR AR CL PE EC CO VE BO PY UY SR GF GY FK GS</CountriesIncluded>` |
  `</Territory>` |
  `</Market>` |
  `. . .` |
  `<SupplyDetail>` |
  `. . .` |
  `<Price>` |
  `<PriceType>01</PriceType>` |
  `<PriceAmount>7.95</PriceAmount>` |
  `<CurrencyCode>USD</CurrencyCode>` |
  `<Territory>` |
  `<CountriesIncluded>US PR VI</CountriesIncluded>` |
  `</Territory>` |
  `</Price>` |
  `<Price>` |
  `<PriceType>01</PriceType>` |
  `<PriceAmount>9.95</PriceAmount>` |
  `<CurrencyCode>CAD</CurrencyCode>` |
  `<Territory>` |
  `<CountriesIncluded>CA</CountriesIncluded>` |
  `</Territory>` |
  `</Price>` |
  `<Price>` |
  `<PriceType>03</PriceType>` |
  `<PriceAmount>195.00</PriceAmount>` |
  `<CurrencyCode>MXN</CurrencyCode>` |
  `<Territory>` |
  `<CountriesIncluded>MX</CountriesIncluded>` |
  `</Territory>` |
  `</Price>` |
  `<Price>` |
  `<UnpricedItemType>08</UnpricedItemType>` |
  `<Territory>` |
  `<CountriesIncluded>PM GL GT HN CR NI PA BZ SV AI AG BS CU DO HT JM KN LC GD KY VG MQ MF BL GP BB VC MS DM BM TC AW BQ CW TT SX BR AR CL PE EC CO VE BO PY UY SR GF GY FK GS</CountriesIncluded>` |
  `</Territory>` |
  `</Price>` |
  `</SupplyDetail>` |

  using Short tags |
  --- | ---
  `<market>` |
  `<territory>` |
  `<x449>CA US MX PM GL GT HN CR NI PA BZ SV AI AG BS CU DO HT JM KN LC GD KY VG VI MQ PR MF BL GP BB VC MS DM BM TC AW BQ CW TT SX BR AR CL PE EC CO VE BO PY UY SR GF GY FK GS</x449>` | Market is North America, Central America, Caribbean and South America
  `</territory>` |
  `</market>` |
  `. . .` |
  `<supplydetail>` |
  `. . .` | Name of supplier etc
  `<price>` |
  `<x462>01</x462>` | Supplier’s RRP for US (inc Puerto
  `<j151>7.95</j151>` | Rico and American Virgin Islands)
  `<j152>USD</j152>` |
  `<territory>` |
  `<x449>US PR VI</x449>` |
  `</territory>` |
  `</price>` |
  `<price>` |
  `<x462>01</x462>` | Supplier’s RRP for CA
  `<j151>9.95</j151>` |
  `<j152>CAD</j152>` |
  `<territory>` |
  `<x449>CA</x449>` |
  `</territory>` |
  `</price>` |
  `<price>` |
  `<x462>03</x462>` | Supplier’s fixed retail price for MX
  `<j151>195.00</j151>` |
  `<j152>MXN</j152>` |
  `<territory>` |
  `<x449>MX</x449>` |
  `</territory>` |
  `</price>` |
  `<price>` |
  `<j192>08</j192>` | Supplier does not supply
  `<territory>` |
  `<x449>PM GL GT HN CR NI PA BZ SV AI AG BS CU DO HT JM KN LC GD KY VG MQ MF BL GP BB VC MS DM BM TC AW BQ CW TT SX BR AR CL PE EC CO VE BO PY UY SR GF GY FK GS</x449>` | Explicit indication that the supplier is unable or unwilling to supply to the remaining parts of the market (even though it may have the right to do so)
  `</territory>` |
  `</price>` |
  `</supplydetail>` |

  The market consists of ‘the Americas’ – North, Central, South America and the Caribbean. However, this particular supplier – most likely a wholesaler rather than the publisher’s primary distributor in the market – does not supply outside of the main three countries of North America (for whatever reason) and ‘advertises’ only US, Canadian and Mexican price. Of course, there would normally be another supplier – the publisher’s primary distributor, for example – in a separate <ProductSupply> composite, which distributes to the whole market.

  supplier unwilling to supply to part of market (while still providing prices for other parts of the market)
  using Reference names |
  --- | ---
  `<Price>` |
  `<PriceType>01</PriceType>` |
  `<UnpricedItemType>08</UnpricedItemType>` |
  `<Territory>` |
  `<CountriesIncluded>PM</CountriesIncluded>` |
  `</Territory>` |
  `</Price>` |

  using Short tags |
  --- | ---
  `<price>` |
  `<x462>01</x462>` |
  `<j192>08</j192>` | Supplier does not supply
  `<territory>` | to
  `<x449>PM</x449>` | St. Pierre and Miquelon
  `</territory>` |
  `</price>` |

  In this example, the book is for sale throughout North America (as indicated by <Market> or as implied by <SalesRights>) – but the supplier is unwilling for whatever reason to supply to resellers in St Pierre and Miquelon (a part of France, near the southern coast of Newfoundland). There would be conventional prices applicable to other territories in the market (CA, US, MX).

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

  Two special cases – first, prices quoted using <PriceCoded> which specify a price tier should usually omit <CurrencyCode>, and any default currency provided in the message header should also be ignored. This is because price codes often have the currency ‘baked into’ the code or code scheme, or the codes act as a kind of virtual currency that is then converted into real currencies by the data recipient. Second, prices using <UnpricedItemType> may omit the Currency code.

##### 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 in ONIX 3.0 and is disallowed in 3.1 – use <CountriesIncluded> with ‘AT BE BG CY DE EE ES FI FR GR HR IE IT LT LU LV MT NL PT SI SK’ (the 21 Eurozone countries), plus possibly ‘AD MC SM VA’ (non-EU countries with a formal agreement to use the Euro as their currency), and maybe ME plus the region RS-KM (non-EU countries or regions that have unilaterally adopted the Euro) instead. Note that non-European but Euro-using dependencies of the 21 (eg ‘GF GP MQ PM RE’) are not automatically included in ECZ and may also need to be listed separately.

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.

##### Comparison product price composite

##### 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, but is generally less 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 preferred, clearer and more explicit three-price method (which does not need to use price qualifiers and can be used in a wider range of circumstances) allows the post-offer price to be different from the pre-offer price.

Technically, it is possible to specify any number of future price changes – for example a price that fluctuates weekly ($9.99 on weekdays, $13.99 at weekends, implying two price changes per week), using either a two-price or a multi-price method, but it is unreasonable to expect data recipients to cope with a large number of price changes ‘queued up’ in advance. Recipients should be able to accept at least one current price and two future price changes to cope with closed-end price promotions.

  closed-end price promotion, 8th–22nd May (preferred 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>` |

  In general, this explicit three-price method is very strongly preferred to the two-price method below.
  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 – not recommended)
  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>` | Concise From … to format
  `<b306 dateformat="06">2015052520150525</b306>` | 25th May to 25th May
  `</pricedate>` |
  `</price>` |

  For a single-day promotion, the start and end dates for the promotional price are the same date. The concise format used in the short tag example above is used only for convenience – its use is not directly linked to the duration of the price being a single day.

  product fluctuates between two prices (multi-price method – not recommended)
  using Reference names |
  --- | ---
  `<Price>` |
  `<!-- First weekend -->` |
  `<PriceType>01</PriceType>` |
  `. . .` |
  `<PriceAmount>13.99</PriceAmount>` |
  `. . .` |
  `<PriceDate>` |
  `<PriceDateRole>14</PriceDateRole>` |
  `<Date>20230401</Date>` |
  `</PriceDate>` |
  `<PriceDate>` |
  `<PriceDateRole>15</PriceDateRole>` |
  `<Date>20230402</Date>` |
  `</PriceDate>` |
  `</Price>` |
  `<Price>` |
  `<!-- First weekdays -->` |
  `<PriceType>01</PriceType>` |
  `. . .` |
  `<PriceAmount>13.99</PriceAmount>` |
  `. . .` |
  `<PriceDate>` |
  `<PriceDateRole>14</PriceDateRole>` |
  `<Date>20230403</Date>` |
  `</PriceDate>` |
  `<PriceDate>` |
  `<PriceDateRole>14</PriceDateRole>` |
  `<Date>20230407</Date>` |
  `</PriceDate>` |
  `</Price>` |
  `<Price>` |
  `<!-- Second weekend -->` |
  `<PriceType>01</PriceType>` |
  `. . .` |
  `<PriceAmount>13.99</PriceAmount>` |
  `. . .` |
  `<PriceDate>` |
  `<PriceDateRole>14</PriceDateRole>` |
  `<Date>20230408</Date>` |
  `</PriceDate>` |
  `<PriceDate>` |
  `<PriceDateRole>14</PriceDateRole>` |
  `<Date>20230409</Date>` |
  `</PriceDate>` |
  `</Price>` |
  `<Price>` |
  `<!-- Second weekdays -->` |
  `<PriceType>01</PriceType>` |
  `. . .` |
  `<PriceAmount>9.99</PriceAmount>` |
  `. . .` |
  `<PriceDate>` |
  `<PriceDateRole>15</PriceDateRole>` |
  `<Date>20230410</Date>` |
  `</PriceDate>` |
  `<PriceDate>` |
  `<PriceDateRole>14</PriceDateRole>` |
  `<Date>20230414</Date>` |
  `</PriceDate>` |
  `</Price>` |
  `<Price>` |
  `<!-- Third weekend -->` |
  `<PriceType>01</PriceType>` |
  `. . .` |
  `<PriceAmount>9.99</PriceAmount>` |
  `. . .` |
  `<PriceDate>` |
  `<PriceDateRole>15</PriceDateRole>` |
  `<Date>20230415</Date>` |
  `</PriceDate>` |
  `<PriceDate>` |
  `<PriceDateRole>14</PriceDateRole>` |
  `<Date>20230416</Date>` |
  `</PriceDate>` |
  `. . .` |
  `</Price>` |
  `. . .` |

  using short tags (two-price method – very strongly not recommended)
  `<price>` |
  `<x462>01</x462>` |
  `. . .` |
  `<j151>13.99</j151>` | Weekend price
  `. . .` |
  `<pricedate>` | Weekend – week 1
  `<x476>14</x476>` |
  `<b306>20230401</b306>` |
  `</pricedate>` |
  `<pricedate>` |
  `<x476>15</x476>` |
  `<b306>20230402</b306>` |
  `</pricedate>` |
  `<pricedate>` | Weekend – week 2
  `<x476>14</x476>` |
  `<b306>20230408</b306>` |
  `</pricedate>` |
  `<pricedate>` |
  `<x476>14</x476>` |
  `<b306>20230409</b306>` |
  `</pricedate>` |
  `<pricedate>` | Weekend – week 3
  `<x476>14</x476>` |
  `<b306>20230415</b306>` |
  `</pricedate>` |
  `<pricedate>` |
  `<x476>14</x476>` |
  `<b306>20230416</b306>` |
  `</pricedate>` |
  `. . .` |
  `</price>` |
  `<price>` |
  `<x462>01</x462>` |
  `. . .` |
  `<j151>9.99</j151>` | Weekday price
  `. . .` |
  `<pricedate>` | Weekdays – week 1
  `<x476>15</x476>` |
  `<b306>20230403</b306>` |
  `</pricedate>` |
  `<pricedate>` |
  `<x476>14</x476>` |
  `<b306>20230407</b306>` |
  `</pricedate>` |
  `<pricedate>` | Weekdays – week 2
  `<x476>15</x476>` |
  `<b306>20230410</b306>` |
  `</pricedate>` |
  `<pricedate>` |
  `<x476>14</x476>` |
  `<b306>20230414</b306>` |
  `</pricedate>` |
  `. . .` |
  `</price>` |

  The above example is valid, but not recommended because it is likely that most data recipients are at present unable to deal with more than three prices (one current, two future). Regular price updates are likely to be more widely acceptable.

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

##### P.26.149 “No product” indicator

The ‘empty tag’ indicator is used – as an alternative to one or more <Product> records – in order to send a message that positively indicates there are no updates to any metadata records.

Most ONIX messages are ‘delta files’ (see Organization of data delivery). Each message indicates changes to the metadata for one or more products since the previous message. In many cases, these delta files are regularly scheduled, perhaps daily or weekly. A ‘no product’ message can be used when there are no product updates to include in a scheduled delta. This avoids any ambiguity (‘did a message get missed?’).

However, a ‘no product’ message has an important but often overlooked meaning in more sophisticated implementations – it reconfirms the existing data. A recipient that maintains datestamps on key data fields such as Publishing Status or Product availability should update the datestamps to reflect this reconfirmation.

  This reconfirmation applies in the same way to products that are omitted from a delta file, and to blocks omitted from a block update record.
  Note that although <NoProduct/> is documented as P.26.149, apparently part of Group P.26, it lies outside of the <Product> composite, and thus does not form part of P.26, Block 6 or of any other block.

## Appendix

#### A.1 Glossary of terms

2D barcode
  See matrix barcode.
3PL, 4PL
  See third-party logistics, fourth-party logistics.
A0, A4 etc
  See A series paper sizes. A0 is 1m² in area with an aspect ratio of √2 (1189 × 841mm), A1 is half that in each dimension, A2 is half again and so on. A4 is 1⁄16m², and 297 × 210mm.
A11y
  See accessibility.
AA
  Author’s alteration, correction made on proofs by the author or publisher, traditionally in blue ink. cf PE, printer’s error or literal, which are errors made by the typesetter, traditionally marked on proofs with red ink by the publisher, or green if the typesetter spotted the error themselves.
AAC
  In audio production, see Advanced audio coding.
  In education, see Augmentative and alternative communication.
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).
AAM
  See author-accepted manuscript.
AAP
  Association of American Publishers, whose Digital Issues Working Party in 1999 drew up guidelines for ‘ONline Information eXchange’. These formed the basis of today’s ONIX standard.
AB
  Abandoned, previously planned publication later canceled without ever having been published. cf NYP.
Aboutness
  Broadly, the subject of a book or other text – what the book is about.
Abridged
  Content shortened by removal of text and minimal re-writing, occasionally termed condensed (the latter implies a greater degree of re-writing). cf adapted.
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. cf an entity-relationship model. See <indecs>, FRBR, BIBFRAME.
AC
  Author’s corrections, see AA.
Academic and scholarly
  Publishing, library and bookselling sector concerned mostly with the university market, academic research and scholarship.
Accent
  See diacritical mark.
Access
  Used in discussions about (for example) patron access to a book in a library. cf accessibility.
Accessibility
  A book can be accessible by print-impaired people (eg blind, partially sighted or dyslexic readers, or readers with a physical or neuro-developmental impairment). For print books, special accessible editions are often required – with differentiated typography and design, and sometimes even simplified text. 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 other modified edition (eg typography intended to mitigate dyslexia) or specially-formatted audiobook (DTB) that can be used by print-impaired people who cannot use a conventional physical book. Can also be applied to e‑books, which are generally more accessible than physical copies.
Accession number
  A unique identifier added to each item acquired by a library, archive or other collection, 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, or more loosely, two copies of the same book) would have distinct accession numbers. See also shelfmark.
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, works or (often) an entire list or imprint from one publisher by another. Note that post-acquisition, both publishers continue to exist. This is a transaction that transfers ownership of intellectual property from one publisher to another. For physical products, this usually also includes transfer of any existing stock of the affected products. Also, acquisition of an entire publishing company and its assets by another. This transaction changes ownership of the organization itself – post-acquisition, the acquired publisher no longer exists as an independent entity, although it may live on as a business unit within the acquiring publisher, and the smaller organization’s name is often used as an imprint or a brand by the larger publisher. cf divestment of a product, range, list, imprint or business unit by the selling publisher.
ACR
  Accessibility Conformance report, a completed VPAT, which documents self-assessed compliance with WCAG, US Section 508 or EN 301 549 accessibility requirements for a particular IT system or product.
Actual selling price, ASP
  See recommended retail price.
ACX
  Audiobook Creation Exchange, Audible-owned audiobook production platform for audiobook rightsholders and producers.
ADA
  Americans with Disabilities Act, US civil rights law that prohibits discrimination against people with disabilities in employment, in procurement and provision of facilities, goods and services, etc, and imposes a requirement (mostly upon various public bodies) to mitigate physical and digital accessibility issues as well as eliminate discriminatory policies and procedures. An update to Title II of the ADA in early 2026 will mandate broadly-accessible (WCAG v2.1-compatible) e‑books, particularly for procurement by public bodies. See also Section 508.
Adapted
  Content derived from another literary form or medium (eg a ‘novelization’ of a movie, or a playscript adapted from a novel), or modified for a different market (eg ‘adapted for the USA market’). cf Abridged.
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.
  Occasionally used to indicate uptake of ONIX (or Thema) across a market, in a country or by an organization.
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 expected 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 advance copies.
Advance copies
  (often just Advances), sometimes also known as a review copies: 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.
Advanced audio coding, AAC
  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.
Advance information sheet, AIS
  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.
Advance orders
  See pre-orders and subscription orders.
Affordance
  The use or purpose something provides to the user. For example, a door handle affords opening, or a DNS affords resolution of a web address.
AFNOR
  Association Française de Normalisation (website), body responsible for coordinating development of French national technical and other standards. See also ISO.
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.
AFP
  Announced first printing, purported number of copies in the first print run (first impression), made public for marketing purposes.
Age ranging
  Defining the intended age of readers for a book, by reading age, interest age or school grade (though calendar age is often used as a proxy measure). See also leveling.
Agent
  See literary agent.
  See sales agent.
  In some abstract models, equivalent to a party.
Against the grain
  See cross grain.
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 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. Under the agency model, the publisher can directly control the ‘street price’ or Actual selling price of a book and can maintain margins through the supply chain. However, agency models are more complex for the publisher, and may be viewed as anti-competitive.

Aggregator, metadata aggregator
  In metadata, an organization that collects metadata from many sources (mostly publishers and their distributors), and re-distributes the combined data to other metadata recipients – either unchanged or with a level of editorial control and value-added content. 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. In other contexts, content aggregators, review aggregators etc also collect and redistribute data of one sort or another.
AI
  See Advance information sheet.
  See Artificial intelligence.
AI assisted
  In copyright law, works with a human creator who makes use of a generative AI tool during ideation or creation, but where the creative essence arises from the human. These works are afforded copyright protection. cf wholly computer generated works where there is no human author. In some jurisdictions (eg UK, Ireland, Singapore, but not USA or most EU countries), these may be protected by copyright, with the copyright holder usually being the human who prompted the AI.
AIFF
  Audio interchange file format, an uncompressed audio file format, mostly used on Macs. See also FLAC, WAV.
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
  See Advance information sheet.
Alphanumeric
  Characters that may include both letters and digits. This usually excludes punctuation and other symbols.
Amazon Standard Identification Number, ASIN
  Proprietary identifier for products used internally within Amazon. The ASIN was originally the same digits as the ISBN-10, but this is no longer always true.
Ampersand
  The ‘ & ’ character, meaning ‘and’ when used in text (typographically, it is related to the Latin ‘et’). In XML data, an ampersand must be replaced by (‘escaped as’) ‘&amp;’. An unescaped & denotes a named character entity such as &amp; itself or &ndash;, or a numerical character reference such as &#x2013; or &#8211; (the numbers are the Unicode codepoints for particular characters).
ANSI
  American National Standards Institute (website), coordinating body responsible for voluntary standards in US business. See X.12, NISO, ISO.
Answer code
  Distributor or wholesaler’s brief response to an order or stock enquiry, for example indicating the product is NYP or OP, and normally used in the context of an EDI message. In ONIX, codes in List 65 (used in the <ProductAvailability> date element) are equivalent to answer codes.
Antiqua
  Style of typeface mimicking the Carolingian letterforms of late-medieval and early modern calligraphy of the 15th and 16th century, more rounded and flowing than blackletter. Originally also called roman type, but the latter now usually means upright type (to be contrasted with italic or oblique).
A&P
  Advertising and promotion, often the major concern of the marketing department. Not to be confused with P&A, price and availability.
APAC
  Asia-Pacific. See also EMEA.
APC
  See article processing charge.
Application programming interface, 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.
API
  See Application programming interface.
Application service provider, ASP
  Business that provides software as a service (SAAS) over the internet. The vendor operates and maintains the software, and rents it to the client on a per user or per usage basis. Product management applications are often offered to publishers in this way.
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.
Arabic numerals
  Conventional Indo-Arabic numerals, 0, 1, 2, 3 etc, with a base 10 positional value notation (423 is ‘four hundreds, two tens and three units’, 0.42 is zero units, four tenths of a unit and two hundredths of a unit). cf Roman numerals, hexadecimal.
ARC
  Advance Reading Copy, see Advance copies.
ARN
  See authorized returns note.
Article processing charge, APC
  Fee charged to the author by an open access publisher to cover the cost of editorial work, production and distribution of a work. Such charges are sometimes levied per page (so Page Processing Charges, PPC). More common for articles published in open access academic journals, but a similar business model is also used by some publishers for open access monographs, where the charges are termed BPCs (book processing charges).
Artificial intelligence, AI
  Or machine intelligence – broad term for the application of software to analyze data, learn, reason and make decisions based on that data aimed at achieving some predefined goal, in an apparently-humanlike way. 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 (recognizing names, places, concepts and so on) from the text of a book to create keyword lists, indexes or links to other books about the same entities, to sales prediction, to subject coding and sentiment analysis, to abstracting and summarization of the text of a book, or to generating new text or images (from a marketing description or a single illustration to the content of a whole new book). This last application – termed generative AI – is controversial due to the use of copyright material as training data. See also ML, LLM.
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 verification to guarantee successful delivery. Most used for EDI message delivery, but the content could be any standardized structured data (potentially including ONIX messages). AS3 uses the FTP protocol instead of HTTP.
Ascender
  Part of lower case letter that lies above the top of the lower case x (ie above the x-height of the text), in letters such as b or d. cf descender, part of a lower case letter that lies below the baseline of the text, in letters such as g or y. Note that the relative sizes of the ascenders, x-height and descenders varies in different typefaces.
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
  See Amazon Standard Identification Number.
ASN
  Advance Shipping Notice (or Notification), also Dispatch Advice, message sent by a printer, distributor etc, usually via EDI, to confirm imminent dispatch of books to the customer (ie to the distributor, wholesaler or retailer). cf GRN.
ASP
  See Application service provider.
  See Recommended retail price.
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
  See Automatic stock replenishment.
Assistive technology
  Software and devices such as text-to-speech (TTS) screen readers or refreshable 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.
AT
  See assistive technology.
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’.
Audiobook
  Recording of a book (or other book-like content) read aloud (usually by a single voice), or a recording of an audio dramatization (with a cast of audio actors).
Augmentative and alternative communication, AAC
  Methods used to supplement or replace text or speech – particularly in SEND education – for those with severe speech–language impairments that prevent expression or understanding of spoken or written language. It can encompass sign languages, use of symbol sets or speech synthesis.
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-accepted manuscript
  In scholarly publishing, the version of any published content after peer review but prior to final editing and formatting by the publisher – the content as accepted by the publisher for publication. Sometimes called a postprint (in contrast to a preprint). cf (author-submitted) manuscript, version of record. See also green OA.
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.
Authorized Returns Note, ARN
  Also termed RMA, Return Merchandise Authorization. Permission granted by the publisher or distributor to return books that were originally sold on Sale or return terms to the seller for credit. See also Returns.
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.
Automatic stock replenishment, ASR
  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’ inventory management process.
AV1
  Advanced video codec, comparable to HEVC, and like HEVC, not yet universally implemented in software systems and devices.
AVC
  Advanced Video Coding, a format for compressed video data, also termed H.264 or MPEG‑4 part 10, jointly developed by ISO and ITU-T. 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). Sometimes also termed DTC or 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 – for many publishers, the long-lasting core of their product range. 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. See also peritext.
Backorders
  Orders to a wholesaler or distributor which cannot be fulfilled immediately. 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.
Banderol
  An officially-issued holographic sticker affixed to a book (primariy in Türkiye) to prove authenticity and combat book piracy. Each carries a unique serial number for a specific copy of a particular ISBN.
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 (in human-readable form, and with hyphens) above the stripes, with the equivalent GTIN-13 printed at the bottom. The stripes represent the GTIN-13, not the ISBN (though for modern books, the two are the same number). Some book barcodes – particularly those on mass-market books – have a 5-digit price extension, extra stripes carrying the price or some publisher-specific code.

  Other types of barcode (ie 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). See also matrix barcode, QR code.

  Conventional dedicated barcode readers mostly use red light, so printing barcodes in color requires care to preserve adequate contrast.

Baseline
  Invisible line on which typeset upper case letters appear to lie. Descenders of lower case letters extend below the baseline.
Basis weight
  See paper weight.
BCP 47
  Coding scheme often used to identify languages (and their national, regional and script variations) in internet applications, standardized by the IETF.
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.
Best practice
  A process, method or technique that is accepted or demonstrated to be superior to any alternatives. The term ‘good practice’ is sometimes used because of the difficulty of quantifying that superiority. cf Common practice which is widely used, irrespective of good or poor results. A focus on common practice makes real improvements difficult.
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 FRBR’s manifestation and item. BIBFRAME version 2 introduced 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, and BIBFRAME works can be grouped into ‘hubs’ of closely-related works that are rough equivalents to FRBR works… it’s complicated…). BIBFRAME data is expressed in RDF using linked data principles.
BIC
  See Book Industry Communication.

  In the ONIX and metadata context, the subject categorization scheme developed by BIC (the organization) 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. The BIC subject category scheme has been obsolete since February 2024. cf BISAC, CLIL, WGS. See also Thema which has largely replaced the BIC scheme in the UK and is also in widespread international use.

  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 (DDC), UDC or LCSH (Library of Congress Subject Headings).

Bicameral
  See case.
BIC Basic
  A bare-bones set of required metadata elements enumerated by BIC and providing the basis for its data quality accreditation scheme now known as the Metadata Excellence Award (MEA). The elements may be communicated using ONIX, a flat file (eg CSV, tab-separated file), or another method, although the highest levels of accreditation are only available with use of ONIX.
Bill of lading
  Detailed list of the contents of a particular shipment of goods, issued to a manufacturer, publisher or freight forwarder to acknowledge receipt of the goods by a carrier.
Binary
  Numbers represented in base 2, and using only two digits 0 and 1 (where normal decimal numbers are in base 10 and use digits 0–9). See also bit, a single binary digit. Computers process and store data using binary. See encoding.
Binder’s pack
  See printer’s pack.
Binding
  See saddle-stitched, adhesive binding.
Binding tariff information, BTI
  Legal decision obtained from a national customs authority over which commodity code applies to a particular product, in order to reduce legal risk associated with goods where the commodity code is uncertain – for example diaries or calendars, where the code might begin either 48 or 49, or various multi-component products. This has implications for taxation and other regulations (eg EUDR).
BIP
  See books in print.
BISAC
  Former Book Industry Systems Advisory Committee. It was later incorporated into BISG, along with SISAC, its serials publishing counterpart (cf CISAC, the International Confederation of Societies of Authors and Composers). In the past, BISAC and SISAC have also been known as BASIC (Book and Serial Industry Communications).
  More frequently, the subject categorization scheme originally developed by the BISAC Subjects committee and now administered by BISG, and which used mostly in the North American book trade. cf BIC, see also Thema.
BISG
  See 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 4.5 megabytes (million bytes) of data.
Bit rate

  The number of bits of digital data stored or transmitted per second (often stated as Kbps or Mbps for thousands or millions of bits per second). The speed or data capacity of an internet connection might be measured in Mbps.

  In uncompressed audio and video, the bit rate is the product of the number of samples per second and the bit depth (the precision of each sample). The former limits the highest frequency of sound that can be reproduced, or the frame rate and number of pixels in video. The latter limits the number of distinct colors or distinct levels of loudness that can be recorded or reproduced. Together, they constrain the technical quality of the recording. In compressed audio and video contexts, the reduction of bit rate characterizes the degree of lossy compression used to make files smaller than the original uncompressed version, with the consequent tradeoff against quality – fewer bits per second implies a smaller file but lower quality (for a given codec).

BITS
  See Book Interchange Tag Suite.
Blackletter
  Style of script or typeface for the Latin alphabet, with angular, Gothic-style letterforms sometimes known as ‘old English’ but often giving a Germanic feel to text since its use in German typography lasted well into the modern period. Blackletter typefaces mimic ecclesiastic calligraphy of the High middle ages. See Fraktur. cf antiqua or roman, italic type.
Blad
  Sample pages of a book, produced in the form of a booklet for promotional purposes. See also dummy, media kit.
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. Ink bleed may refer to undesirable spread of ink across the surface of the paper as it is drying, losing the sharpness of type or of definition in halftones.
Block
  Term used within ONIX to refer to high-level composites used to arrange data functionally within a Product record. There are eight blocks – Block 1 is <DescriptiveDetail>, Block 2 is <CollateralDetail> and so on – preceded by an informal block zero comprising the record metadata and product identifiers. A Product record may contain all the relevant blocks, or for block updates, only those blocks that have changed since the previous ONIX message was sent.
  See book block.
Blocking, Foil blocking
  Metallic foil (often gold or silver colored) used to ‘print’ the title, logo or a decorative pattern on the spine or boards of a hardback book, or added for visual impact to a jacket or paperback cover. It is usually applied with a heated stamping die.
Block update
  Synonymous with ‘partial update’. See organization of data delivery.
Blu-ray disk
  Optical disk 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 paperboard used for the rigid covers of a hardback, or for the leaves of a ‘board book’, and sometimes termed binder’s board. Generally more than 400gsm and at least 500µm (or 20 mils) in bulk – stiffer and heavier than card.
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.
BOM
  See byte order mark.
Bond
  Good quality paper, generally greater than 50gsm. cf lighter weight bank paper, generally less than 50gsm.
Bonded leather
  A manufactured product used as a lower-cost alternative to real leather. Made from a mix of scraps and offcuts from real leather, shredded and ground up into loose fibres, then mixed with a latex or plastic binder and formed into sheets that simulate the look and texture of real leather. See also split leather.
Book
  ONIX does not explicitly define what a ‘book’ is, though see codex. Some legal systems set a minimum number of pages, below which a booklet or other low-extent publication is a pamphlet or similar, but within the ONIX framework this distinction is left to the data provider. In the context of ONIX, ‘book’ may also imply audiobook, in both physical and digital forms. More generally, ONIX is concerned with products.
Book block
  Part-bound book, with all the signatures gathered, bound and trimmed, but before the cover is added.
Book Industry Communication, BIC
  UK-based book trade organization (website), comprising members from printing, publishing, distribution, bookselling and libraries, and from various intermediaries and service providers. BIC provides standards (for example, see Tradacoms), training and best practice guidance for the book trade and library sector in the UK.
Book Industry Study Group, BISG
  US-based trade organization (website) that draws members from the printing, publishing, distribution, bookselling and library sectors, and from various intermediaries and service providers. BISG provides standards (for example, see BISAC), training and best practice guidance for the book trade in the USA.
Book Interchange Tag Suite, BITS
  XML-based markup scheme for book content and limited metadata, closely related to JATS, and usually only used by academic and scholarly publishers.
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 globally for ISBNs are notionally assigned. In this way, the range of ISBNs becomes a small subset of the larger GTIN numbering scheme.
Booklet
  Small book (in terms of extent or physical dimensions). cf book, pamphlet.
Book plate
  Decorative label tipped into a book during binding or added by the retail purchaser. It may carry an author’s signature, or the owner’s name.
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, BIP
  Reference catalog or service providing aggregated metadata – both bibliographic and commercial – aiming to cover all books available in the market (in commerce, or at least in print). 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.
BPC
  See APC.
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.
Brexit
  The withdrawal (after a 2016 referendum) of the United Kingdom from the EU and from the EEA.
B series
  See A series.
BSI
  British Standards Institution (website), the world’s first national standards-setting body, responsible for technical and other standards in the UK. See also ISO.
BTI
  See binding tariff information.
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.
Bundle
  A multi-item product made available to end customers – in effect, multiple different products sold as a single unit. The bundled products may be packaged together, or may simply exist as a pricing option when the individual products are purchased together. The related term Multipack is preferred for a retail product comprising multiple copies of the same product.
Byte
  See bit.
Byte order mark, BOM
  In the UTF‑16 encoding of Unicode characters, each character (or more strictly, each codepoint) is represented by either two or four bytes of information. But these pairs of bytes might be in either order – something like saying either ‘seventy three’ or ‘three and seventy’. The latter could easily be misinterpreted as 37. The special &#xfeff; codepoint – representing a zero width non-breaking space – may be inserted at the very beginning of a Unicode file. Here it functions as a byte order mark, a heuristic that indicates 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 encoding declaration in first line of the XML file. A byte order mark is valid in UTF‑8 too: it would be three bytes, &#xef;, &#xbb; then &#xbf; but it has no real meaning or utility, and again it should be omitted.
CA
  See CE.
Caliper
  See bulk.
Call number
  See shelfmark.
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.
Card
  Thicker paper-like material, intermediate in weight, thickness and stiffness between paper and board, used for the covers of paperback books. Cover card may be around 200–350gsm, and 150–250µm or so in bulk, but paper, card and board are not rigorously differentiated.
  Greeting card, playing card, recipe card etc, generally a small item made from heavy paper or card.
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 may depend on other data values on on separate business rules. In ONIX, <ROWSalesRightsType> has cardinality 0…1 (ie it is optional) in the sense that it may or may not be present in a Product record, but in many circumstances is actually mandatory and in others, it must be omitted (it is dependent on the data provided in various <SalesRights> composites). In a strict sense, it is never ‘optional’. Such contextual requirements cannot be expressed in an XML DTD or (usually) in the ‘classic’ XSD schema, but they can be tested in rule-based schema languages including Schematron and the ONIX ‘strict’ XSD.

Carrier, Freight carrier
  Organization that physically transports goods, on behalf of a manufacturer or publisher, for example a road haulier, or a ship or aircraft operator. Shipments are usually arranged and managed by a freight forwarder, rather than contracted directly between manufacturer or publisher and the carrier.
Carton
  Box made of paperboard or corrugated fiberboard, and used by manufacturers to pack multiple copies of a book ready for onward transport to a distributor. Often termed a printer’s pack or binder’s pack. Bulk shipments of books from manufacturers are packed in cartons and then stacked on pallets. Depending on the size of the book and of the carton, a carton might hold anything between four and 100 or more copies – the carton quantity (or occasionally, case quantity). Wholesalers and retailers can order in multiples of this carton quantity for convenience, though in general, orders for any number of copies are accepted by most distributors.
Cascading style sheets, CSS
  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.
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. Supposedly, 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 box or 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 – that is, they are unicameral as opposed to bicameral.
  The cover boards and spine of a case-bound book (a hardback). 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 of text and the line width, page height, typeface, point size and leading.
Catalog
  A publisher’s catalog is the complete list of products it has available in print (ie frontlist and backlist items, but not out of print products). May also refer to a document listing selected products for marketing and promotional purposes.
Cataloging in publication, CIP
  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 or referenced on the title verso page within the book itself.
Categorization
  See classification.
CC, CC-By, CC Zero etc
  See Creative Commons.
  See also closed captions.
CCE
  See BIC.
CCPA
  See GDPR.
CD, Compact disk
  Optical disk 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 1,411 kilobits per second. This type of CD carries the CD-Audio logo. cf compressed MP3 or AAC audio files at perhaps 128kbits/s which sacrifice a little fidelity for much lower file size. These MP3 or AAC files, uncompressed WAV or other audio files can be stored on a CD-Rom (which does not carry the CD-Audio logo). This alternative Yellow Book CD standard allows up to about 700MB of ordinary data files to be stored on a disk. 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 (conformité européenne) 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. The UK’s CA mark is similar.
  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 trade paperback in a size more typically used for trade hardbacks – or more generally in a larger in size. The book’s trimmed page size is often the same as that of a Demy or Royal hardback (around 216 × 135mm or 234 × 153mm respectively), but unlike A- and B-format, there is no agreement on the exact size C-format represents, and books are more typically just termed trade paperbacks.
CGW
  Computer generated work, see AI assisted.
Chapbook
  Originally a small book or pamphlet of popular, sensational, juvenile, moral, polemical or educational content once sold by street merchants or peddlers known as ‘chapmen’. In modern use, may be almost any short booklet. Not to be confused with a chapter book.
Chapter book
  A type of children’s illustrated storybook intended for intermediate readers. Compared with a picture book for younger children, a chapter book relies more on prose and contains fewer pictures.
Character
  In ONIX data, a character should be thought of broadly as a user-perceived character, which might be a single simple character like e, a character modified with a diacritic like é, or a pre-composed group of several individual characters like æ or 한 (the latter combines the three Hangul jamo ᄒ, ᄂ and ᅡ). This means that field length limits (eg a limit of 350 characters) must be expressed in characters, not storage units such as bytes, so that the limits are independent of the method of encoding and storing those characters – in most cases, the data storage required for 350 characters is greater than 350 bytes. cf codepoint. See https://unicode.org/reports/tr29/ and Appendix A.7 for further details.
Character encoding
  See character set.
Character entity, Named character entity
  Method of encoding non-ASCII characters in HTML and XML, for example ‘&hellip;’ for an ellipsis, now largely unnecessary with widespread use of Unicode characters. While named character entities were used with earlier versions of ONIX, they are not valid in ONIX 3.0 or 3.1. cf numerical character references.
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, backspace/delete and so on – and encodes them using the numbers 0–127 (or 00000000 to 01111111 in binary, or 00 to 7f in hexadecimal). Latin‑1 lists 191 characters, and encodes them using the numbers 0–255 (00000000 to 11111111 in binary, 00 to ff in hex). 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 140,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.
Chemical pulp
  Wood pulp made from wood that is broken down into its constituent fibres chemically, mostly by heating wood chips in water with Sodium hydroxide and various sulfide or sulfite compounds. This largely dissolves the lignin content of the wood while separating the cellulose fibres. Compared with mechanical pulping, it generally produces higher quality, stronger and longer-lasting paper stock with a high cellulose and low lignin content, and is sometimes termed wood-free paper.
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.
Choreography
  The ‘rules’ agreed between sender and recipient for exchanging messages – for example whether an acknowledgement message should be returned after receipt and processing of an ONIX message. The choreograhy for ONIX messages is typically very simple, compared with that for e‑commerce messages involving enquiries, orders, acknowlegements, dispatch notes, invoices and so on.
Choke
  In prepress, see trapping.
Chunking
  Informal term for splitting of an audio (or potentially, video) recording into multiple files for production and supply chain purposes. Audiobook chunks or files may or may not correspond to the logical arrangement of chapters or scenes in the audio or video – the size of a chunk may be informed or dictated by operational constraints. There may be multiple chapters per chunk, or several chunks per chapter.
CIE
  See Commission Internationale de l’Eclairage.
CIF
  Cost, insurance and freight. See INCO terms.
CIP
  See Cataloging in Publication.
  In international trade, Carriage and insurance paid – see INCO terms. cf CIF
CIP4
  International Cooperation for the Integration of Processes in Prepress, Press, and Postpress Organization (website), 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.
Circular economy, Circularity
  Economic model based on recycling of goods to create the raw materials for new goods (eg paper made from recycled paper waste), a key tenet of a sustainable economy.
Classification
  The process of arranging books into one of a number of alike groups or classes, according a particular attribute, and usually with each class in a particular classification scheme defined and arranged hierarchically. See for example subject classification, commodity classification. Categorization is similar, though a single book may be a member of more than one category in a particular category scheme, and categories may not always be defined in a hierarchical fashion. In practice, the terms are often used interchangeably. Dewey is a subject classification scheme, since a book can have only a single Dewey number, whereas BISAC is a category scheme since a book can be assigned more than one BISAC subject code.
CLC
  Chinese Library Classification, library subject classification scheme used in China. See also UDC, DDC, LCC.
CLIL
  Commission de Liaison Interprofessionnelle du Livre (website), a French book trade organization.
  In the context of ONIX and metadata, Classification CLIL is the subject classification scheme developed by the Commission and used widely in the French book trade. See also Thema.
CLOCKSS
  Controlled LOCKSS (where LOCKSS is ‘Lots of Copies Keep Stuff Safe’) (website), organization that maintains a secure digital archive of (usually) scholarly published content for long-term preservation. Ithaka provides the similar Portico service.
Closed captions
  Form of captioning or subtitling of audiovisual content, where display of the captions/subtitles can be switched on and off by the viewer. Captions and subtitles are sometimes treated as synonymous – essentially any on-screen text. At other times, subtitles are understood to include textual transcription (and possibly translation) of the speech, whereas captions aim to replace all aspects of the audio (including sound effects and background music cues as well as dialogue).
Cloth
  Term for a hardback/hardcover book, generally only used in a bookbinding, or specialist publishing or antiquarian bookselling context (‘…in cloth’). Also the textile (cotton or linen ‘bookcloth’) or faux material used to cover the boards of a hardback.
Cloth book
  See rag book. cf ‘cloth covered’, often referring to a hardback/hardcover.
CMO
  See collective management organization.
CMS
  See content management system.
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). Often termed Process color. In practice the range of printable colors is more limited than the full visible range. See also RGB.
CO₂e
  Carbon dioxide equivalent, unit of measurement of greenhouse gas emissions (or ‘carbon footprint’), for example as a result of the activities of an organization, or due to the production or use of a product, but accounting for the global warming effects of all greenhouse gases and aerosols, not Carbon dioxide (CO₂) alone. Many other emissions are more potent than CO₂. For example, burning 1kg of coal releases around 3.5kg CO₂ (depending on the quality of the coal and efficiency of the combustion). Releasing (not burning) 1kg of methane (CH₄ – natural gas) into the atmosphere has the global warming potential equivalent of around 80kg CO₂ (over a 20 year period – see Table 7.15 of Climate Change 2021: The Physical Science Basis. Contribution of Working Group I to the Sixth Assessment Report of the Intergovernmental Panel on Climate Change, doi:10.1017/9781009157896.009, also available from https://www.ipcc.ch/​report/​ar6/wg1/​downloads/​report/IPCC_AR6_WGI_Chapter07.pdf). Releasing 1kg of Sulfur hexafluoride (SF₆ – an insulating gas used in grid-scale electrical switchgear) equates to around 16,000kg CO₂e (over the next 20 years – and much more over 100 years since SF₆ is long-lived in the atmosphere).
Coated paper
  Paper with a thin coating of, for example, china clay (kaolin) or chalk with various additives, to smooth the suface texture of the paper, increase its lustre or brightness, and control the bleeding of ink during printing. Coating generally increases the density of the paper, and the smooth surface and reduced bleed increases the clarity of printed images. cf uncoated paper, which has a rougher texture and bleeds ink into the fibres.
Codec
  Coder–decoder. Loosely, a particular compressed file format used to store files containing image, audio or video data. Since such files can often be very large, the data is compressed mathematically for easier storage and faster transmission. Usually, significant compression is accompanied by a loss of quality in the image, audio or video. JPEG is a lossy format for image data, whereas TIFF is lossless but compresses the file much less. AAC and MP3 are two different lossy formats for audio data. These are referred to as ‘different codecs’. More strictly, the codec is the mathematical algorithm, and the device or software used to compress or decompress the data in a particular format.
Codelist
  Informal 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 code 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. cf keyword.
Codepoint
  Loosely, a ‘character number’. In Unicode, a number that maps to a specific character. That number may then be encoded in data using UTF-8, UTF-16 (etc) encoding. However, a specific character may sometimes also be represented by multiple codepoints – an é may be a single codepoint (233, or e9 in hexadecimal), or two codepoints, 101 (or 65 in hex) representing an unaccented e followed by 769 (or hex 301) representing an acute combining diacritic (oddly, they are often typed in the opposite order, diacritic first then letter). See Unicode normalization.
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.
Collateral
  Resources such as text or images used to support the marketing and sales of a product. This marketing collateral can be aimed at buyers within the trade, or at end-customers.
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 (the collection 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.
Collective management organization, CMO
  Or Copyright management organization, agency which manages intellectual property rights, including copyrights, licenses and permissions, on behalf of rightsholders. See also RRO.
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 idealized standard colorspaces like sRGB, Adobe RGB or CMYK. See also CIE.
Comic book
  A periodical or serial publication with mostly graphical narrative content, low extent, often self-covered, and simply bound with a wire stitch (stapled) and no distinct spine (ie <ProductForm> code BF). cf graphic novel, which may contain similar content but is monographic, in a more typical ‘book’ format. See also trade paperback.
Commission Internationale de l’Eclairage, CIE
  Body responsible for colorimetry standards, against which colorspaces such as Adobe RGB, sRGB or device-specific color profiles are characterized.
Commodity code
  Sometimes termed a tariff code or ‘customs code’. A code from any one of a range of coding schemes – including for example the WCO Harmonized System (HS), Schedule B in the USA, TARIC and CN for the EU, or the UK’s HMRC schemes – which are used to define the type of a product. The HS is a relatively simple scheme and is used almost universally in international trade. The various national schemes are (mostly) elaborations of the HS, and such schemes are used to administer local customs tariffs (‘customs duties’) and quotas for import and export, and for compilation of trade statistics. There are often slightly different national commodity code schemes for import into and export from a country – for example the 8- and 10-digit HMRC codes. HS or national commodity codes can also be used to define and administer internal tax rates and duties. See also BTI.
Comp
  In design and page layout, a draft or rough that closely mimics a final layout, but usually with dummy text and/or non-final illustrations. Approval of the comp (perhaps from ‘composition’ or ‘comprehensive layout’?) is followed by work on the final, fully-finished design.
  A person who works as a typesetter or compositor.
  See also comp title.
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.
Complexity
  More or less objective measure of the difficulty of comprehension of text, related to but distinct from the intended readership or audience for the text. See also leveling.
Compliance
  Adherence to legal requirements, or to internal organizational policies and procedures. In financial contexts, a department dedicated to ensuring such adherence.
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-disk audiobook, a book in a book plus toy bundle. cf item, though note that a trade pack containing multiple books (eg a shrinkwrapped pack of multiple copies) can be termed both a multi-component product and a multi-item product, depending whether it is broken up into individual copies 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, to indicate their semantic relationship and 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 digital 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. See also codec, bit rate.

  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, FLAC is losslessly-compressed 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…).

  In audio, the technique of boosting quiet sounds and reducing loud sounds, usually aimed at improving the quality of a recording (eg by reducing crackling sounds caused by clipping, where a loud sound exceeds the maximum that can be recorded – see dynamic range).
Comp title
  Comparison title, a similar book (in terms of its content, its theme, tone, audience or its expected sales), used to help describe a book’s genre, placement in the market or potential sales.
Computer to plate, CTP
  Prepress process whereby complete print-ready pages (often PDF/X files) are ‘drawn’ with a laser directly on to photo-sensitive printing plates, ready for physical litho printing. Pre-digital platemaking used purely photographic techniques. See also imposition.
Concept
  Abstract idea that corresponds to some distinct feature, entity or relationship. In ONIX codelists, each row represents a single concept. See also SKOS, notation.
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.
Consignment
  See sale or return.
Consignor
  The sender of a shipment of goods. See shipper. cf consignee, the recipient of a shipment.
Consolidation
  Practice in domestic transportation and international shipping of grouping several smaller shipments for transportation to similar destinations, for example combining several pallets into a single container-load destined for the same location. See carrier, freight forwarder.
Consumer direct fulfillment, CDF
  See drop shipment.
Content management system, CMS
  IT system used to manage the creation and editing of material destined for publication (in a book, or on a website).
Continuing resource
  See monograph.
Contone
  Image in which color or shade varies smoothly, for example a photograph. cf Halftoning, a process which aims to simulate a contone image.
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 contributor normally and automatically becomes the original copyright holder of the content (but note work for hire). The publisher acquires rights to exploit the intellectual or artistic content created by the contributor, in return for fees or a royalty.
Contributed volume
  See monograph.
Controlled vocabulary
  An exhaustive list of terms (or concepts) that can be used in a particular context or data element. Each term or concept in the vocabulary should have an unambiguous definition or explanation, and may include both preferred text labels and less-preferred synonyms. Controlled vocabularies may be a ‘flat’ list of terms, or the concepts may be arranged hierarchically – in which case the vocabulary is sometimes called a taxonomy. Some controlled vocabularies rely on language-dependent terms in the metadata, whereas others make use of language-independent codes or notations in the metadata, with preferred labels in multiple languages for each concept. See also codelist, authority file, SKOS.
Conversion
  The process that guides a potential customer to a purchase – from discovery through interest and consideration and finally to action – a purchase decision. This concept is often termed the marketing funnel. Different aspects of the product metadata are critical at each stage of the process. See also discoverability, which controls entry to the conversion process.
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.
Copy
  Editorial or promotional content (text and images), or alternatively, a single item or instance of a product.
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 display, perform, reproduce (‘the right of reproduction’), distribute and sell (‘the right to distribute’ and ‘the right to make available’), modify or adapt (‘the right of derivative works’) 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 initially 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. Copyright in a new textual work usually persists for 70 years after the death of the original creator (occasionally slightly more), and proscribes exploitation of the work by those other than the copyright holder, licensees or assignees (collectively, rightsholders). 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 – particularly the USA – registration can be highly beneficial and in others, the moral rights must be explicitly asserted (for example, within the work itself). A few countries require works to be ‘fixed’ in a tangible form (eg published or made available in some format) before copyright applies. In others, fixation is not required.

  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. After expiry (‘exhaustion’) of the commercial rights, the work passes into the public domain. In some countries, Moral rights expire alongside the commercial copyright. In others, they are perpetual.

  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 such as text and data mining (TDM) 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 infringement
  Use of a copyright work other than by – or without permission from – a rightsholder. This can range from large-scale counterfeiting and printing of pirated copies, to selling otherwise-legitimate new copies in a market beyond the scope of a publisher’s rights, the copying and sharing of e‑book files (beyond what’s allowed by the license), or unlicensed photocopying in a library setting. Note that not all unlicensed uses constitute infringement, as there are various provisions for fair use or fair dealing and other copyright exceptions.
Copyright page, 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.
Core stock
  A selection of products that a particular bookseller intends to keep in stock and available for immediate retail sale at all times – usually key backlist titles with a consistent sales record. Newly-published books may or may not earn a long-term place on the core stock list.
Corporate social responsibility, CSR
  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. See also DEI, GHG emissions accounting.
Cost price
  The net cost of a product to the retailer (or other reseller). This can be either a net or wholesale price, or it can be a fixed or recommended retail price less any business-to-business discount. The difference between the Cost price and the Actual selling price (ASP) is the reseller’s gross margin.
COTS
  Commercial off-the-shelf product, usually packaged software or a service made availalble by a commercial vendor, as an alternative to bespoke software development, and usually selected in order to lower costs. Occasionally stands for ‘configurable off-the-shelf’, highlighting that COTS products often allow post-purchase configuration to suit the needs of the customer.
COUNTER
  Project COUNTER (website) maintains a Code of Practice and a reporting format that enables compliant publishers and vendors to report usage statistics for digital resources (eg number of reads of a journal article or downloads of a book, consultations of reference material or uses of a database) in a consistent and comparable way, thus providing librarians with a credible way to demonstrate the value of those resources. For example, OAPEN provides COUNTER-compliant counts of downloads of its open access books.
Counterpack
  Box containing multiple books or other products, often decorative and intended for POS display in a retail environment. Generally used to promote relatively small items, gifts etc.
Country code
  Alphanumeric code used to identify a sovereign country (eg GB for the United Kingdom), for example in <CountryOfManufacture> or <CountriesIncluded> – see List 91. However some country codes in fact denote non-sovereign dependent parts of countries (eg HK for Hong Kong, which is a part of China). In ONIX, when part of a country has its own country code, the main country code (in this case, CN) is interpreted as meaning the country (China) without that dependent part. Thus the code GB (United Kingdom) includes England, Wales, Scotland and Northern Ireland, but not the Isle of Man, since the latter has its own country code, IM, and the FR country code does not include Martinique, which is denoted by country code MQ. The code US denotes the United States of America excluding Puerto Rico (country code PM) and other territories. See also Region code.
Country of exportation
  Country from which a specific shipment of goods is exported from. Similarly, the Country of importation is the country into which goods are imported.
Country of manufacture
  The country in which a product is physically manufactured (printed, bound etc), or very occasionally, the last country in which significant value was added (for example, if manufactured and packaged in different countries, it may be the country where the product is packaged). The country of manufacture is usually the country in which the HS commodity code last changed (eg when paper becomes printed books).
Country of origin

  Somewhat ambiguous term, frequently confused with or used as a synonym for country of manufacture or country of publication. As a result, the term is avoided in ONIX.

  Country of origin can refer to the ‘economic nationality’ of imported goods according to the Rules of origin applied by the importing country. Country of origin can also refer to the country of exportation, the source of a particular international shipment of product(s), rather than where those products were published or originally manufactured. For example for a physical book published in the United Kingdom, and manufactured in Germany, the country of origin when a shipment of copies arrives in the UK could be the Netherlands – copies might well be transferred by road from Germany to Rotterdam before onward shipment to the UK. Equally, the country of origin could be Germany according to the UK’s Rules of origin.

Country of publication
  The country in which the publisher is based, and by extension, the country of the national ISBN registration agency from which the ISBN should be obtained. Often also the country where legal deposit is mandated.
Courseware
  Package of educational software and associated material, from a single classroom lesson to an entire course: usually a mix of instructional content, reference material, quizzes, tests and assessments, delivered online or within a VLE. See also Edtech.
Cover
  Protective and often decorative outer part of a book’s binding that is attached to the book block – either card (for a paperback) or rigid board (for a hardback). Many hardbacks are also wrapped in a separate jacket.
Cover 1, 2 etc
  Outside front cover (1), inside front (2), inside back (cover 3) and outside back (cover 4). Generally refers to the cover proper rather than to a jacket, which would additionally have front and back flaps.
Cover line
  Text that is on the cover of a book but is not a part of the title, and is generally not on the title page. Often termed a reading line in the US. Cover lines are mostly ‘explanatory’ rather than promotional – ‘a novel’, ‘With 150 recipes’ or ‘fully illustrated in color’, for example – and are added by the publisher. cf subtitle (which is superficially similar but is part of the title, is on the title page, and is written by the author), ‘tag line’ or promotional headline (which are overtly promotional, written by the publisher and not necessarily on the book at all – certainly not on the title page), and ‘log line’ (which is akin to a short description).
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.
Credit note
  The opposite of an invoice, listing the amount to be credited to a customer account for goods returned, or for goods paid for but not supplied (or not satisfactorily supplied). Sometimes termed a negative invoice in North America.
Creative Commons, CC
  Not-for-profit organization (website) that develops copyright licenses that permit and encourage free sharing of creative works within the legal framework of copyright law. Some CC licenses are copyleft (in particular the SA ‘Share-alike’ variants), whereas others reserve some rights to the creator (eg CC-By reserves the specific 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
  See customer relationship management.
Crop marks, Cut marks
  Marks printed a little outside the page corners to indicate exactly where the page should be trimmed to size. See TLS. cf registration marks.
Cross-docking
  In logistics, the practice of unloading inbound goods and immediately reloading them on outbound transport, without any intermediate storage, in order to improve delivery times, reduce storage costs etc.
Cross grain
  In US, against the grain. See long grain.
Crossover
  Book primarily aimed at a teenage readership which also appeals to adult readers (or vice versa). More generally, a book with appeal to multiple distinct audiences.
Crossref
  Not-for-profit organization (website) providing digital infrastructure, particularly identifier services, to the research and scholarly publishing community. It is the largest of the various DOI registration agencies that comprise the International DOI Foundation.
CSR
  See corporate social responsibility.
CSS
  See cascading style sheets.
CSV

  A Comma-Separated Value data file consists of tabular 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.

CTP
  See computer-to-plate.
Customer relationship management, CRM
  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 analyze those business processes.
Customs broker
  Organization specializing in dealings between publishers (and other importers and exporters) and national customs, providing advice, obtaining clearances and facilitating payments of tariffs. See also shipper.
Cut marks
  See crop marks. cf regmarks
Cutter number
  In libraries, an alphanumeric code representing an author’s name (or less often, a subject heading), arranged so the numerical order of the code is the same as the (Latin) alphabetic order of the full name or heading. Typical three-character Cutter codes for the family names Bell, Benn and Berkeley are B45, B46 and B47, though a four-character code would be needed to differentiate Benn from Benson (B466 and B467), and the tables associating letters in the name to digits can sometimes vary between libraries.
D2C
  Direct to consumer. See B2C.
DAD
  See digital asset distributor.
Dagger
  Typographic symbol ‘ † ’ sometimes used to indicate footnotes in text. Also comes in double dagger (‘ ‡ ’) flavor.
DAISY
  Digital Accessible Information System, a type of digital audiobook with accesible navigation. DAISY audiobooks require specialized reading devices or software, and they have been partly superseded by standard EPUB e‑books with digital audio. See also DTB.
DAISY Consortium
  Organization (website) working to promote ‘inclusive publishing’ and the availability of DAISY and other accessible editions of books to all, including print-impaired readers.
DAM
  See digital asset management.
DAP
  Delivered at place. Commercial terms under which the seller delivers the goods but the buyer is responsible for unloading, import taxes and tariffs, and onward transportation. cf DPU, which basically DAP with unloading. See INCO terms.
Dark archive
  Archive or repository that is carefully managed to ensure preservation of the contents of the archive and the long-term viability of the organizational infrastructure that surrounds it. Access is usually limited only to the custodians of the archive. Dark archives are intended to safeguard the cultural or scholarly record, held against some future where the preserved material is not available elsewhere.
Darwin Information Typing Architecture, DITA
  Specification for XML document authoring including markup for structured text, mechanisms for content reuse and rules for conversion to HTML for publication. The core XML schema for DITA topic documents was originally developed by IBM, and the standard is now maintained by the OASIS consortium (Organization for the Advancement of Structured Information Standards). See also TEI, JATS, DocBook.
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 quotation dash ‘―’ (usually slightly longer than an em dash) are commonly used for dialogue, in place of opening quotation marks. And in typographically-correct math, the subtraction sign ‘−’ is about the size of an en dash, but is often matched to the widths of the digits in a particular font. Note that spreadsheet software, and XML itself, both use the hyphen for negative numbers and as a subtraction operator (and will generally not accept a typographically-correct subtraction sign).

Database
  An organized collection of data. Modern databases are normally electronic, often with tables of data arranged in columns and rows, 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 dictionary
  Set of names, definitions, relationships and other attributes of the data elements or fields used in a database, information system or field of study. (NB Sometimes, a data dictionary is described as ‘metadata’, in that it is ‘data about data’. In the context of ONIX, what is called metadata is ‘data about books’, and a data dictionary could be thought of as meta-metadata.) To some extent, ONIX itself is a data dictionary, since alongside the standardized file format, the framework provides a standardized lexicon, definitions, relationships etc for data about books.
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.
dB
  Decibel, a unit of relative loudness of audio, used as dBA when measured relative to a standard weighting for the sound sensitivity of the human ear. See also LUFS.
  As DB, see database.
DC
  In logistics, see distribution center.
  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.
DCMI
  Dublin Core Metadata Initiative, see Dublin core.
DDA
  See demand-driven acquisition.
DDC
  See Dewey Decimal Classification.
DDEX
  See Digital Data Exchange.
DDP
  Delivered, duty paid. Commercial terms under which the seller delivers the goods and is responsible for all transportation risks, taxes and tariffs to that point. cf DAP, DPU. See INCO terms.
DDS
  See Due diligence statement.
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.
Decolonization
  Challenging the cultural, social and economic effects of colonization, in particular relating to any assumed superiority of ‘Eurocentric’ or imperial knowledge, principles and perspectives, through a pluriversal approach. See also DEI.
Defamation
  Slander or libel – untrue statements damaging to the reputation of the victim.
DEI
  Diversity, Equity (or Equality) and Inclusion (or Inclusivity) – related principles and qualities which can be incorporated into a publisher’s commissioning and publishing program, as well as into any organization’s employment and CSR policies. Accessibility is usually subsumed into equity or inclusivity, but is occasionally also listed separately, eg as DEIA, and Justice is sometimes also included, eg as JEDI).
Delimiter
  Character or character sequence used in data files to separate one discrete data element from the next. CSV files use commas as delimiters. XML uses angle brackets (< and >) as separators between data and markup. Within a few ONIX data elements such as <CountriesIncluded>, a space is used as a delimiter in a list of country codes. There is a clear problem whenever a delimiter character occurs within the data itself – this is why XML data must use &lt; to represent the < symbol within the data.
Delivery note
  A manifest sent with a shipment of physical books to a retailer, detailing the books in the shipment and used to verify the completeness of the shipment as delivered or identifying shortages in the shipment. Sometimes termed a packing note. Note that a shipment may not include all the books from a single order placed with the supplier, and may include books from multiple orders.
Delta update
  See organization of data delivery.
Demand-driven acquisition, DDA
  Also termed Patron-driven acquisition or PDA. Acquisition process where libraries have instant access to a complete catalog of e‑books or other digital resources, 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).
Demy, Demi
  Common hardback book size in the UK, with a trimmed page size typically around 216 × 135mm. Originally derived from ‘Demy Octavo’, a traditional Demy paper size folded twice to form eight pages around 8¾ × 5¾in before trimming. The overall size of a Demy hardback is a few mm larger because of the overhang of the cover boards. Pronounced as in ‘deny’. See also Royal, C format, trade paperback.
Density
  See bulk.
Deprecate, Deprecation
  Deprecation implies near-obsolescence: the element or code remains technically valid, but is subject to removal from the next release of the format. 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. ONIX data senders should not implement deprecated codes, data elements or methods in new applications, and should eliminate them from existing implementations within a reasonable time (perhaps no more than a couple of years). ONIX data recipients should maintain support for deprecated codes and elements, but may choose not to do so indefinitely. Not to be confused with Depreciation, an accounting term for gradual reduction in the value of an asset over its assumed useful life.
Dereference
  To find the object identified by an identifier, for example finding a document identified by a DOI. Sometimes termed resolution of the identifier.
Derived work
  See work.
Descender
  See ascender.
Desk copy
  See approval copy.
Development lifecycle
  Development and support of successive versions of ONIX follows an orderly process. See the stages of the lifecycle in Appendix A.4.
Deutsches Institut für Normung, DIN
  Organization (website) responsible for coordinating development of German national technical and other standards. See also ISO.
Dewey Decimal Classification, DDC
  Common subject classification scheme used in libraries, named for its creator Melville Dewey with the current WebDewey version maintained by OCLC. See also UDC, LCC, LCSH, CLC.
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.
‘Diamond’ OA
  See open access.
Die
  Hard metal machine tool used in combination with a press for scoring, folding, cutting, stamping or embossing paper or card during manufacture.
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 sometimes used in ‘naïve’. A dieresis has roughly the opposite effect from a vowel ligature such as æ (which indicates they are pronounced as a single sound, as in ‘encyclopædia’), but both diereses and vowel ligatures 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, DAD
  Supply chain 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.
Digital asset management, DAM
  IT system manages the ingestion and storage of digital assets such as chunks of text, complete chapters and books, or individual images, audio or video files, 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.
Digital certificate
  In cryptography, 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 applications. See also AS2, AS3.
Digital Data Exchange, DDEX
  Standards organization (website) in the music industry. Specifically, DDEX’S ERN (Electronic Release Notification) is an analogue of ONIX for distribution of metadata about music releases.
Digital object identifier, DOI

  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 to 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 citation resolution service for online, mostly scholarly, material, 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).

Digital product passport
  EU-proposed documentation metaphorically ‘attached’ to each (physical) product, which covers basic product metadata, raw material traceability, manufacturing and sustainability data, and ownership and repairability information. Access to this data is enabled via an RFID chip or a 2D barcode. The framework for the introduction of Digital product passports (DPPs) is included in the EU’s Ecodesign for Sustainable Products Regulation (ESPR). Books are not included in the initial list of industries set to introduce DDPs, but the pulp and papermaking industry is.
Digital Rights Management, DRM
  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.
Digital single market
  EU policy, regulations and legislation to improve the digital economy and remove barriers (eg nationally-constrained licensing) to trade of digital goods and services across national boundaries within the European Union.
DIN
  See Deutsches Institut für Normung.
Directory of Open Access Books, DOAB
  Repository of metadata describing open access books, managed by the not-for-profit DOAB Foundation. Publishers of peer-reviewed OA books can add their metadata to the repository using ONIX. Many but not all books listed by DOAB are available from OAPEN.
Discount, 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 (business-to-consumer price) agreed by the parties. The trade 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 easily without revealing commercially-sensitive information. See the Discount coded composite.
Distribution center, DC
  Distributor’s or wholesaler’s warehouse holding copies of thousands of stock lines (individual SKUs), and fulfilling B2B orders. cf FC.
Discoverability
  The likelihood that a product comes to the attention of a potential buyer or reader who is not specifically searching for it, or the manner in which a product stands out from the mass of other available products, generally in an online context.
Distribution rights
  Rights to make a product available to customers 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. Granting exclusive distribution rights means no other suppliers may make the product available in that market. See sales rights.
Distributor

  Organization that holds the primary stock of books and is responsible for fulfillment (of trade orders, or of orders from a specific type of customer, eg education) 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. Some of the largest publishers own or operate their own distributor, and hold stocks themselves. Other publishers (a distributor’s ‘client publishers’) appoint a single, exclusive distributor per market or territory (and this exclusive distributor is sometimes termed the Vendor of record for that market). Some publishers prefer to appoint multiple non-exclusive distributors.

  In North America in particular, distributors may also have a role in marketing, promotion and sales of the book to wholesalers and retailers – that is they act as a sales agent – and in ONIX these distributors should be named both as <PublisherRepresentative> and <Supplier> in the relevant market. More generally, distributors frequently take on this broader role outside the home market of the publisher. In France, this distinction is expressed in the terms « diffuseur » which takes a role in marketing and sales, and « distributeur » which concentrates solely on fulfillment.

DITA
  See Darwin Information Typing Architecture.
Diversity
  Differences between people (in a society, in an organization etc) relating to particular facets of individual identity. Those facets include, inter alia, race, culture, ethnicity, age, sex, gender identity and expression, sexual orientation, neurotype, ability or disability, national origin, language, religion, citizenship, socioeconomic status and political opinion. See DEI.
Divestment
  See acquisition.
DNS
  See IP address.
DOAB
  See Directory of Open Access Books.
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, DITA.
Document Type Definition, DTD
  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. nb no DTD is provided for ONIX 3.1. See also schema.
DOI
  See digital object identifier.
DOIF
  See IDF.
Domain name
  ‘Friendly’ textual name for one or a group of computers on the internet which are controlled by a particular entity, for example ‘editeur.org’ is the domain name belonging to EDItEUR and ‘ns.editeur.org’ and ‘www.editeur.org’ are two specific computers within that domain. A Domain Name System (DNS) server converts these names into numerical IP addresses of a computer – for example ns.editeur.org is (currently) linked to the IP address 213.48.238.227.
Domain name system, DNS
  See domain name, IP address.
Download to own, 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 by the customer with a perpetual license. cf DTR, rental.
Download to rent, DTR
  Download To Rent. Business model whereby e‑book files are downloaded by the customer with a time-limited license. See also rental. cf DTO.
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 – and DPI is entirely meaningless if not linked to a physical size. 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).
DPP
  See digital product passport.
DPU
  Delivered at place, unloaded. Commercial terms under which the seller delivers and unloads the goods but the buyer is responsible for import taxes and tariffs, and onward transportation. cf DAP, which is DPU without unloading. See INCO terms.
Dramatized
  In audiobooks, a book or other text that has been adapted to be presented as a play, rather than simply read aloud, and usually featuring a cast of audio actors rather than a single reader.
DRM
  See Digital rights management.
Drop-in
  Late addition to a publisher’s programme, with metadata fed into the data supply chain close to publication date. ‘Instant publishing’.
Drop shipment, Consumer direct fulfillment, CDF
  In order to avoid the need for wholesalers and retailers to hold physical stock, while at the same time minimizing delivery time, wholesalers and retailers sometimes ‘drop ship’ or fulfill goods direct from a manufacturer or other stockholder (eg a distributor) to the retail customer. The retailer placing the order must pass the customer delivery address to the manufacturer 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.
DTC, D2C
  Direct to consumer – eg book sales from a publisher’s own website. See also B2C.
DTD
  See Document Type Definition.
DTO
  See download to own.
DTR
  See download to rent.
Dublin Core, DC
  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, in mostly non-commercial contexts, or with application-specific ‘profiles’ that prevent broad interoperability.
Due diligence statement, DDS
  In the context of EUDR, a Due diligence statement that confirms the required diligent scrutiny of the detail of the sources of raw materials for a particular product has been applied. DDSs are created and submitted in the EU’s Traces online registry of DDSs, and a DDS reference number from Traces (typically 14 alphanumeric characters) is often accompanied by a ‘verification code’ (DDS+VN).
Dues, Backorders
  Business-to-business orders taken by a publisher, distributor or wholesaler prior to publication (also known as subscription orders) or during a temporary period of unavailability (when they are more frequently termed backorders), for delivery when the book becomes available. cf pre-orders, which are consumer orders placed with a retailer prior to publication.
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 Disk or Digital Video Disk
  Optical disk 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.
Dynamic range
  For audio, the difference between the quietest and loudest sounds. The dynamic range of real-world sounds is generally larger than the maximum dynamic range that can be recorded on a CD or in an MP3 file, so sounds are often compressed (the quietest sounds are boosted, the loudest quietened) when mastering an audiobook. See dB, LUFS.
EAA
  See European Accessibility Act.
EAN
  Former European Article Number, later International Article Number (though still abbreviated as EAN). See GTIN.
  The barcode symbology used to encode EANs and GTIN-13s.
Each
  In logistics, a single unit of a product, for example an individual copy of a book.
Earn out
  See advance.
E-book
  Book content (text, images etc) made available in digital form – typically as a PDF or EPUB file, or in a proprietary format – and usually downloadable from an online retail platform or deilivered page-by-page in real time (‘streamed’) across the internet as the reader progresses through the book. They can be read using dedicated e‑book reading devices (such as a Kindle) or using software on a generic device such as a smartphone or laptop computer. So-called enhanced e‑books are similar but typically also contain embedded audio, video or interactive features.
Edge decoration
  Colored, marbled, illustrated 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.
  See DEI.
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 during the 1990s.
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 (former) 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 of the same work). Loosely, edition may also relate to a specific issue of a serial publication (‘the May edition of Refrigerated road haulier monthly magazine’). Differences in understanding of ‘edition’ frequently cause miscommunication.
Edition binding
  Archaic term for a hardback, covered in plain cloth (or faux), with or without a jacket.
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). A few EDItX messages can also be sent using JSON syntax.
EDRLab
  European Digital Reading Lab, a not-for-profit developer of open and interoperable software for e‑book reading systems, best known for Readium and the LCP DRM framework.
Edtech
  Also Edutech. Loose term encompassing the use of IT hardware, software, services and associated educational content in teaching and learning.
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
  See European Economic Area.
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
  Relative 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.
Embossing
  See stamping.
EMEA
  Europe, Middle East and Africa. See also APAC. The world might very roughly be divided into the Americas, EMEA and APAC for commercial purposes. Precise boundaries for these divisions vary according to context. cf the United Nations’ Regional Groups.
Emoji
  Small images or pictographs used in text to convey emotions or illustrate simple concepts, for example 🙂 and 😮. See Unicode. Emoticons or smileys are somewhat similar simple images composed of mostly punctuation marks: for example :-) and :-o have the same meaning as the two emoji above. Emoji and emoticons are not recommended for use in ONIX.
EN 301 549
  European standard that specifies accessibility requirements for IT products and services. It is a near-duplicate of WCAG 2.1 with some clarifications, and compliance with EN 301 549 is a requirement of the EAA.
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, many 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.

  Text encoding is just one example. More generally, an encoding is a set of rules for how a specific type of data – whether it be text, color, a date, etc – can be constructed and stored.

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 case. Also termed a capital band.
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.
Enterprise resource planning, ERP
  Integrated management 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.
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 in their own right. ONIX allows description of various types of entities and the relationships between them – products, contributors, locations etc. See also abstract model, relational database.
Entity-relationship model
  A model (often a diagram) listing various entities of interest with their properties or attributes, and linking them via their relationships with other entities. The model can be a very high-level conceptual or abstract model, or a more detailed but still largely abstract logical data model, or a practical entity-relationship model that maps directly to a database schema. See also relational database.
EORI number
  Economic Operator Registration and Identification Number, an identifier for businesses and individuals used for customs declarations and international trade with or within the European Union.
EPC
  Electronic product code, a GS1-defined identifier used in RFID tags to identify a particular physical object such as a single unit of a product (eg a particular copy of a book). One of several types of EPC can consist of a product identifier such as a GTIN-14 combined with a unique serial number for the particular product item. Such SGTINs are not often used with books, in part because of concerns over privacy and because individual copies of books are not usually serialized.
  European Publishers Council, a CEO-level advocacy group of European newspaper, magazine, book and journal publishers, internet media and broadcast organizations.
EPICS
  EDItEUR Product Information Communication Standard – a data dictionary that inspired many of the data element definitions of ONIX.
Epitext
  See peritext.
EPOS
  Electronic Point Of Sale, a retailer till or checkout system often also used for sales data and stock control.
EPPO
  European and Mediterranean Plant Protection Organization, a Paris-based intergovernmental organization responsible for cooperation in the field of plant protection in Europe.
EPUB

  Standard e‑book file format developed and maintained by the IDPF and more recently by the W3C. Internally, an EPUB file is actually a Zip file containing various other files – content documents, stylesheets, images, scripts, fonts and metadata about the structure of the e‑book. The latest EPUB 3 version of the format builds on HTML5 for content and CSS for styling, 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.

EPUB Accessibility Specification
  W3C standard for highly-accessible EPUB e‑books, which is based in part on WCAG.
Equalization, EQ
  Adjusting the qualities of a sound recording by boosting or fading specific frequency bands – for example boosting particular bass frequencies – to adjust the overall tonal balance. See audio mastering.
Equity
  The principle of just access to opportunities and resources, so that all people have access to what they need to succeed, contribute and be represented in society on a fair basis. Equity is neither about providing identical resources to everyone, nor about ensuring equality of outcomes, but to distributiong resources and decision-making power based on each individual’s circumstances. See DEI.
ERP
  See enterprise resource planning.
Errata
  Corrections to the content of a book, sometimes corrigenda printed on a separate sheet and inserted (tipped in) into finished copies as an addendum.
ESG
  Environmental, Social and Governance – collectively, factors that organizations must take into account when measuring the impact of their operations. See also CSR.
ESPR
  Eco-Design for Sustainable Products Regulation, EU legislation aiming to foster a more sustainable economy by improving products’ energy efficiency, durability, recyclability and circularity.
EST
  See DTO.
EU
  See European Union.
EUCU
  See European Union Customs Union.
EUDR
  See European Union Deforestation Regulation.
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.
European Accessibility Act, EAA
  An EU Directive which took effect in mid-2025. It mandates a uniform high level of accessibility for goods and services across the EU, including inter alia, e‑books and other digital products. See also EN 301 549.
European Economic Area, EEA
  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 30 countries. cf the more limited EUCU. In territorial rights contexts, ‘Europe’ often means the EEA – but at other times Europe implies the continent, which would additionally include the United Kingdom, Switzerland, the western Balkans, Ukraine, Belarus, Russia and (possibly) Türkiye and the trans-Caucasus (Georgia etc).
European Union, EU
  Political and economic union of 27 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). The United Kingdom is a former member. Most Balkan countries and Ukraine are ‘candidate members’ working towards full EU membership in the future. cf EEA.
European Union Customs Union, EUCU
  Free-trading bloc consisting of the countries of the EU (with the exception of some non-European territories of EU countries). Notably, Türkiye has a bilateral free-trade agreement with the bloc. cf EEA.
European Union Deforestation Regulation, EUDR
  The European Union Regulation on Deforestation-free Products, legislation that requires an organization placing a wood-derived product – such as a book – on the market in the EU to ensure it does not use raw materials that contribute to deforestation. The regulations replace the former EU Timber Regulation and will be enforced from the end of 2026. Compliance with the Regulation requires risk assessment and mitigation, and detailed recording of the geographical provenance of the raw materials for the product in a Due Diligence Statement (DDS) within the EU’s Traces data portal.
Eurozone
  Term covering the 21 countries of the EU that use the Euro as their currency – Austria, Belgium, Bulgaria, Croatia, Cyprus, Estonia, Finland, France, Germany, Greece, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Portugal, Slovakia, Slovenia and Spain. Andorra, Monaco, San Marino and the Holy See (Vatican City) also use the Euro via agreements with the EU, and Montenegro and Kosovo use it without an agreement with the EU.
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.
Expected ship date
  See Expected availability date in Group P.20.
Explicit
  See incipit.
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.
EXW
  Ex-works. See INCO terms.
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.
FC
  Fulfillment center, see DC, though FC is often used (notably by Amazon) for a retailer’s warehouse used to fulfill retail B2C customer orders.
Federation of European Publishers, FEP
  Publisher’s umbrella association focusing on legislative issues and advocating on behalf of national publishers’ associations in Europe.
Feed, data feed
  See ONIX feed.
FEP
  See Federation of European Publishers.
Field
  See data element. May also refer to a column in a database table, or a pre-defined data entry area in a form.
File Transfer Protocol, FTP
  Standard method of transferring files across the internet. cf HTTP.
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. Mathematical 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 – particularly similarity as perceived by a human – where hashes are used to detect differences. See ISCC. 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 publication. 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-layout
  For paginated e‑books, the opposite of reflowable: where the file format requires the reading system to present text and graphics at a fixed position on each page, giving pixel-perfect fidelity on-screen. PDF is a fixed-layout file format – reader software can zoom in, but not re-paginate the document.
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). This usually applies for a year or two following publication. The IPA publishes a report on the use of fixed book pricing across many countries. See also recommended retail price.
FLAC
  Free lossless audio codec, a lossless compression scheme for audio files. See also WAV, AIFF.
Flaps, Cover flaps
  Extra folds parallel to the spine in a jacket or cover creating panels that tuck inside the bound book – generally the flaps are less than the full width of the pages. Sometimes called French flaps. cf gatefold.
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.
‘Flavors of ONIX’
  Term describing a range of issues caused by differences in ONIX metadata requirements imposed by different recipients, for example only accepting an obsolete version of ONIX, not accepting a particular field (and requiring it be removed), mandating an otherwise-optional field, or interpreting the meaning of the data in a non-standard way. It leads to the creation of many ‘bespoke’ data feeds, and to increased costs across the metadata supply chain.
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.
Floppy
  Floppy disk, a largely-obsolete data storage device that held around 1MB of data or less.
  In comic books, a low-extent (usually 36 or 48 pages), self-covered and wire-stitched (stapled) product often sold like a magazine. Multiple floppies are often then collected and re-published as a trade paperback containing a complete story.
Flyleaf
  Loose half of the sheet of endpaper used to line the inside of the front cover of a hardback and attach it to the main book block, and which forms two pages before the first page of the book block proper. The flyleaf may be left blank, decorated, or on occasion, used as a half-title page. There is of course a flyleaf at the back of the book too.
FOB
  Free on board. See INCO terms.
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’. A few books have an illustrated, colored (sprayed edges), gilded or decorated foredge.
Forest Stewardship Council, FSC
  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.
Forward compatibility
  See compatibility.
Four-color
  See CMYK process color.
Fourth-party logistics, 4PL
  Organization providing a complete supply chain solution, often acting as a logistics broker or integrating its own services with those of other supply chain organizations to provide manufacturing, warehousing and logistics. See 3PL.
FRAD
  See FRBR.
Fraktur
  Subgroup of typefaces with angular Gothic-style or blackletter characters of the Latin alphabet (though much more modern than calligraphic blackletter used in medieval manuscripts or fonts mimicking calligraphic blackletter). The characters contrast strongly with antiqua-style roman or italic typefaces with more rounded letter forms.
FRBR
  (often pronounced ‘furber’) IFLA’s Functional Requirements for Bibliographic Records – more recently absorbed into and superseded by the Library Reference Model (LRM) – 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/LRM describe effectively identical manifestation and item or instance concepts, a work in <indecs>, ONIX and (formerly in) ISTC terms is roughly equivalent to an expression within the FRBR/LRM model. In addition to FRBR, LRM incorporates FRAD (Functional Requirements for Authority Data) and FRSAD (Functional Requirements for Subject Authority Data). See also RDA, BIBFRAME.
French fold
  Single sheet, printed one side and folded twice at right angles, eg used for some greeting cards. cf French flaps.
Freight forwarder
  Organization specializing in domestic and international transport and logistics, arranges transport of cargoes of products from manufacturer to distributor, wholesaler or retailer along the supply chain, on behalf of its client publishers or manufacturers (the shippers, who ultimately bear the costs of transport). A freight forwarder does not itself move goods, but contracts with carriers to do so, and is usually responsible for arranging customs clearance and other administration of the shipments. Freight forwarders may also arrange consolidation of individual small shipments into larger cargoes to reduce overall transport costs.
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. See also peritext.
FRP
  See fixed retail price.
FSC
  See Forest Stewardship Council.
FTP
  See file transfer protocol or FTPS.
FTPS
  Version of FTP in which the data transferred is securely encrypted while in transit across the network. FTPS (more properly ‘FTP over TLS’) uses a digital certificate for network authentication and for establishing the encrypted link to maintain the privacy and trust in the integrity of the data. SFTP or Secure FTP (more properly ‘SSH-FTP’) is a different approach to the same requirement, and SFTP and FTPS each has its own benefits. See also HTTP and HTTPS, which can also be used for file transfers. For EDI file transfer, see also AS2, AS3.
Fulfillment
  The process of transporting and delivering products that have been ordered, for example from a distributor or wholesaler warehouse to a retail store. See also logistics. Digital fulfillmentis the equivalent electronic service – distribution and delivry of digital goods.
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.
FXL
  See fixed layout.
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.
Gamut
  See color gamut.
Gatefold
  Binding arrangement where an extra page or panel is attached to a front or back cover or a page within the book block via a fold on the foredge parallel to the spine. Sometimes termed a throw-out. Occasionally used to bind in oversize diagrams, charts or maps that can then be unfolded outside the trimmed page size, or to extend cover art. cf flaps.
GDPR
  See the EU’s General Data Protection Regulation.
GDSN
  See Global Data Synchronization Network.
General Data Protection Regulation, GDPR
  EU Regulation covering privacy and security of personal and personally-identifying information, the rights of the data subject and the transfer of personal information between businesses or to countries outside the EEA. Many other countries have enacted laws similar to or based directly on the GDPR, including the UK, Türkiye, Japan, Korea and South Africa. The CCPA (California Consumer Privacy Act) is somewhat similar, and applies to organizations operating in California.
General Product Safety Regulation, GPSR
  Extension of previous EU legislation such as the Toy Safety Regulation to cover safety of almost all consumer products. From the end of 2024, the extended regulations require contact details and a postal address for the publisher or other organization placing the products on the market in the EU, as well as details of any safety warnings.
Generative AI
  See AI.
Generative engine optimization
  Optimizing website content to maximise its visibility in AI-driven search results or AI responses to prompts. The approach focuses on overall content quality, clarity of description, and authority rather than individual keywords and likely search terms. cf SEO.
Genre
  Books (usually fiction) of a particular style, literary form or subject matter – for example romance, crime, science fiction. Occasionally used in a perjorative sense, in contrast to ‘literary’ fiction.
GEO
  See Generative engine optimization.
Geographical information system, GIS
  Software for managing spatial information collected from the real world and visualizing it as a map.
GeoJSON
  Standard format of JSON data file carrying GIS data – information about spatial features and their attributes. GeoJSON files are used in the context of EUDR.
GEPIR
  See GLN.
GHG
  See greenhouse gases.
Ghostwriter
  Uncredited author hired to write on behalf of another (usually better known) person. True ghosts don’t appear in the metadata for a book. However, such writers are sometimes credited as a secondary author (eg celebrity-authored books ‘written with’).
GHS
  See Globally Harmonized System of Classification and Labelling of Chemicals.
GIF
  Graphics interchange format (surely pronounced as in ‘gift’, despite the humorous views of the deviser of the file format). Low-quality raster image file, suitable only for use on the web. See TIFF and JPEG for higher quality image file formats.
GIS
  See Geographical information system.
GLN
  See Global location number.
Global Data Synchronization Network, GDSN
  Database and global communication system administered by GS1 to pool and distribute metadata about all types of commercial products. Not widely used for books and allied products.
Global location number, GLN
  International standard identifier for a physical trading location or (loosely) for an organization at that location, administered by GS1. 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.
Globally Harmonized System of Classification and Labelling of Chemicals, GHS
  Standardized system of classification for hazards and hazardous materials, including hazard statements, warning pictograms, safety data sheets etc.
Global positioning system, GPS
  One of several global navigation satellite systems (GNSS) used for geolocation and navigation. Others include Galileo, GLONASS.
‘Global’ publication date, etc
  See publication date: ‘global’ publishing dates are those specified in Block 4. Note these are ‘global’ in the sense that they apply to the Product record as a whole, not that they necessarily apply globally in a geographical sense. They are distinct from ‘local’ or market-specific dates in Block 6, which may override the global dates in a particular market.
Global shipment identification number, GSIN
  Identifier for a specific shipment of goods. The shipment as a whole may comprise several logistics units (from a container to a pallet), with each logistics unit identified by an SSCC in turn containing tradeable items (ie products or cartons of products) identified by GTINs. Origin and destination of the shipment may be specified using GLNs.
Global Trade Item Number, GTIN
  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, but they can be prefixed with a zero to create a GTIN-13. 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 the ‘EAN-13’ symbology. Thirteen digit ISBNs are a small subset of the entire GTIN-13 numbering scheme (see Bookland). GTIN-13s can be prefixed with a zero to create a GTIN-14, which specifies a single unit of a product (an each). GTIN-14s not beginning with a zero are used to identify trade packs of items (from cartons to pallets). See also SGTIN.
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.
GMT
  See UTC.
‘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.
GPS
  See Global Positioning System.
GPSR
  See General Product Safety Regulation.
Grain, Paper grain
  See long grain.
Grammage
  See GSM.
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.
Graphic novel
  See comic book.
‘Green’ OA
  See open access.
Greenhouse gases, GHGs
  Gases such as Carbon dioxide and Methane which, when released into the atmosphere, tend to increase the average temperature of the planet surface by blocking longwave radiative cooling of the planet (while not blocking shortwave radiative heat from the sun). Aerosols such as Sulfur dioxide are often also included. See CO₂e.
Greenhouse gas emissions accounting
  Methodology used to measure, verify and report an organization’s emissions of greenhouse gases, usually in terms of kilograms or tonnes of Carbon dioxide equivalent (CO₂e). See Scopes 1, 2, 3. Organizations often report their emissions as part of their CSR policies.
GRN
  Goods Received Notification, message sent by a wholesaler or retailer to the supplier (eg the distributor), usually via EDI, to confirm receipt of books. cf ASN.
Groundwood
  See mechanical pulp.
GS1
  International standards organization responsible for a wide range of supply chain logistics standards, including the GSIN, SSCC, GLN and GTIN identifier schemes.
GSIN
  See Global shipment identification number.
GSM, grammage
  Grams per square metre, see paper weight.
GST
  See VAT.
GTIN
  See Global trade item number.
GTIN-13, -14 etc
  See GTIN.
GUID
  Globally Unique Identifier. See UUID.
Guillemets
  Arrow-shaped quotation marks ( « and » ) used in French and other languages.
Gutter
  Gap between columns of type on a page
  The blank 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 gray (or for color images, shades or tints of the CMYK process colors) are simulated by printing 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. Stochastic screening avoids the possibility of moiré that’s inherent in conventional halftoning. cf line art, which uses only ‘solid’ areas and lines of ink and does not use halftoning to simulate shading.
Harmonized System, HS, HS codes
  A set of six-digit codes defined by the World Customs Organization (WCO) for commercially-traded products. These commodity codes are based on the type of product and its component materials, and the codes are used for administration of taxes, tariffs, duties, quotas related to import and export of goods. Wood pulp, paper, books and periodicals are all found in Chapters 47, 48 and 49 of the WCO’s taxonomy, and most ordinary books are classified as 4901.99 within the Harmonized System. The HS is used as the basis for more elaborate national or multinational schemes such as the EU’s Common Nomenclature (CN) and TARIC codes, or the HTSUS and Schedule B codes used for imports and exports in the USA.
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.
Hardback
  Also hardcover, a ‘cased’ book. See paperback.
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.
HDPE, HDPP
  High density polyethlene, polypropylene, types of hydrocarbon polymer used to create paper alternatives like Yupo or Tyvek (among their many other applications).
HEIC
  High Efficiency Image Coding, a standard intended for compression and storage of still images. It is closely related to HEVC – both use the HEIF container format. 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, jointly developed by ISO and ITU-T. 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. See also AV1.
Hexadecimal
  Numbers in base 16. Hexadecimal notation is convenient for numbers that are actually stored by a computer as binary (base 2) numbers, as each hexadecimal digit represents four binary bits. 49 in ‘hex’ is 01001001 in binary (and 73 in ordinary base 10). Hexadecimal uses the digits 0–9 (the same as the Arabic numerals) and a–f (or A–F), so after 49, you get 4a (01001010), 4b–4f (01001011–01001111), then 50 (01010000). Hexadecimal numbers are sometimes prefixed by ‘0x’ or just ‘x’ to differentiate them from ordinary decimal (Arabic) numbers, so 0x49 is 49 in hex or 73 in decimal.
High-discount sales
  See royalties. Copies of a product sold by the publisher to retailers at an unusually high trade discount may earn the author a lower percentage royalty. See also special sales.
Hi-lo, High-low
  Book which combines a higher interest age with a lower reading age, for example a book containing content of interest to a 13-year old, but written using somewhat simplified text with a reading age of 10 or 11. Used by educators to encourage reluctant readers.
H&J
  See hyphenation and justification.
Honeycombing
  In logistics, the incomplete use of storage space in a warehouse, due to there being a mix of full, partially full and empty storage locations at any one time. Good inventory management and a flexible location strategy minimises honeycombing within the warehouse and maximises location utilisation, decreasing operational inefficiencies.
HS
  See Harmonized System
HSS
  Humanities and social sciences, a subset of academic and scholarly publishing. cf STM, STEM.
HTML
  Hypertext Markup Language, the markup system used for simple web pages. Sometimes refers to a specific version such as HTML version 4, standardized by the W3C in 1997, but in other contexts is more generic or encompasses HTML5 too. HTML 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 / character in <br />) and tags may be upper or lower case. See also XHTML. Along with CSS and JavaScript, HTML forms the core of the open web platform, the suite of royalty-free standards and technologies that underlie the World Wide Web.
HTML5, HTML living standard
  The latest version of HTML. HTML version 5 superseded version 4. Some old HTML tags were removed or redefined, some new tags added, the specification itself (technically a W3C ‘Recommendation’) was more rigorous, but it retained much of the familiarity of HTML version 4. However, the rigorously-defined HTML version 5 has been retired by the W3C, and itself superseded (or perhaps bypassed) by an HTML ‘living standard’ maintained and constantly updated by the WHATWG. The living standard is characterised by a focus on back-compatibility and pragmatic implementation of new features, and consensus among implementers, rather than conformance to pre-defined requirements (the WHTWG says, ‘Instead of ignoring what the browsers do, we fix the standard to match what the browsers do.’). As a result, HTML or HTML5 are an ever-evolving view of ‘whatever usually works’ rather than a conventional ‘standard’. Less formally, ‘HTML5’ may also encompass related standards used in modern web browsers and the open web platform – in particular CSS and JavaScript.
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 trust in the integrity of the data. The EDItEUR website https://www.editeur.org uses HTTPS.
Hybrid open access
  Published product containing some Open Access content, as well as some non-open content – for example a monograph within which some chapters are open and the remainder are not.
Hyphenation and justification
  Usually just H&J, typesetting procedures to arrange a paragraph of text so that the left and right margins of successive lines of text are straight rather than ragged. Lines of text are broken (‘wrapped’) at word spaces as usual, and both the spacing of letters and spacing 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 in justified text 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. In contrast, ragged right (or ‘ranged left’, ‘flush left’) text leaves the letter and word spacing unadjusted, and the right margin ragged. The opposite, ragged left, is common with right-to-left typesetting in Arabic or Hebrew. Occasionally, text is hyphenated even when only one margin is justified.
IANA
  See Internet Assigned Numbers Authority.
ID3 tag
  Basic set of audio metadata that can be embedded inside an MP3 audio file.
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, its persistence, and the likely future sustainability of the identifier scheme itself.

  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 such as the ISBN or ISNI, 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 or a publisher’s internal contributor ID may only be unique within a particular organization, and the exact nature of the entity identified is often not understood beyond the organization.

  ISO’s Principles of Identification (TS 22943), originally compiled by the Linked Content Coalition, is a technical specification that defines good practice for designing identifier schemes.

IDF
  See International DOI Foundation.
IDPF
  See International Digital Publishing Forum.
IETF
  See Internet Engineering Task Force.
IFC, IBC
  Inside front cover (cover 2), Inside back cover (cover 3). cf OFC, OBC.
IFRRO
  International Federation of Reproduction Rights Organizations. See RRO.
IFLA
  International Federation of Library Associations and Institutions, the global association respobnsible for the Library Reference Model for metadata.
ILS
  See LMS.
Imperial units
  See US customary units.
Impose
  To arrange artwork or film for individual pages into a particular imposition pattern ready for making printing plates.
Imposition
  The particular arrangement of a set of pages to be printed on a single sheet of paper, so that the pages appear in the correct order when the printed 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 be imposed side-by-side with page 2 only in a 4-page imposition with a single fold, but for other imposition patterns will appear adjacent only 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 on one side of the paper, with the spine between them in a 16-page, three fold imposition). Imposition patterns are specific to the number of pages in a signature and the intended folding pattern.
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, and therefore a new product, albeit a product that is closely linked to the earlier one). The impression number is usually noted on the copyright page. Note that in ONIX, the reprint number is synonymous with impression number, though in some other contexts the second impression may be viewed as the ‘first reprint’. Impressions are sometimes termed printings.
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 in order to target different sectors of the market. These imprints often more or less mirror the internal organization of business units within the publishing company. cf list.
Imprint page
  See copyright page.
Inalienable rights
  See moral rights.
Incipit
  The first few words of a work – ‘It was a dark and stormy night…’ is a widely-derided example. cf explicit, the last few words (eg, ‘Are there any questions?’).
Inclusion
  A deliberate effort to ensure that diverse individuals can participate equitably in decision-making (in society, in an organization etc). It requires respecting, valuing and supporting all individuals and groups for their unique contributions and perspectives so they can all share a sense of ‘belonging’. See DEI.
In commerce
  Commercially available – status of a product that’s either in print or out of print but still available in the supply chain. cf out of commerce.
INCO terms

  International Commercial Terms, a collection of pre-defined and widely accepted sets of commercial terms used for international trade, most recently updated in 2020. They divide the various costs of shipping physical goods between buyer and seller, and mark the point in the international journey at which responsibility (with its associated risks and liabilities) for the goods switches from seller to buyer. See freight forwarder.

  The INCO list includes terms like EXW (ex-works, meaning the buyer has to carry all costs of shipping and delivery except the cost of any loading goods at the seller’s premises – that is, the buyer pays for source country transport and international shipping, unloading, customs clearance, delivery to the destination, all import taxes, duties and insurance in addition to the quoted price of the goods), or its near opposite DDP (Delivered Duty Paid, meaning the seller's price includes all costs of delivery to the buyer’s location other than final unloading at the final destination), CIP (Carriage and Insurance Paid, meaning the quoted price for a shipment includes the cost of international shipping, delivery and of insuring the shipment while in international transit, but the buyer may need to pay for unloading at the international destination, any customs clearance, import duties, domestic transport and final delivery separately), and FOB (Free on Board, meaning the seller delivers on to a ship or aircraft, and the buyer has to pay for all costs after that – including the sea or air transportation, duties, unloading and delivery at the destination). See Publiship’s summary. Many of the terms have to be qualified with a location, for example ‘DDP Glasgow’.

Incunabula
  Early printed material, generally seen as material predating about 1500.
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.
Indigeneity
  Membership of or identification with an indigenous group of people – generally the earliest known inhabitants of an area, or their descendants who maintain aspects of the original culture – especially within the context of a wider dominating culture. See also decolonization, nation, people.
Industry Returns Initiative, IRI
  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. See Industry returns initiative. Many (but not all) UK distributors and wholesalers have adopted the IRI methodology for returns.
Inheritance
  Principle within ONIX whereby (for example) details not specified in Block 6 are taken from Block 4 – so for a Price, if no <Territory> composite specifies where that price is valid, then it must be valid across the whole of the market. And if no <Territory> is specified within <Market>, then the market must comprise the whole of the geographical area with positive Sales rights (ie the <Territory> with <SalesRightsType> code 01 plus the <Territory> with <SalesRightsType> code 02).
Ink
  Book printing uses different types of ink to form the text and images on paper. Toner used in some POD manufacturing is a fine, dry plastic powder, and heat is used to fuse it to the paper. Inkjet ink consists of a colored pigment or dye and a solvent (water or an organic solvent), and small droplets of ink are sprayed at the paper before the solvent evaporates. Ink used in large offset litho printing presses is often oil-based, with an organic solvent (see VOC) to thin the ink and a pigment to form the permanent image.
Inkjet
  Printing technique where microscopic droplets of liquid ink are fired at the paper, forming dots that build up the image.
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 – see in commerce. 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’.
  Occasionally used to indicate numbers of copies sold (‘4 billion copies in print’).
Insert
  See plate section. See also tip-in for a single-leaf insert. More generally, additional material included bound or loose within a book.
Inspection copy
  See approval copy.
Instance
  A single copy of a book, usually synonymous with item – a single retail copy of a 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 (at least prior to sale to an end-customer).
Institutional sales
  Book sales to schools, libraries, local authorities, academic institutions etc. cf sales to ordinary consumers.
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.
Integrating resource
  See monograph.
Intellectual property, IP, Intellectual property rights
  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 (IP) 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.
Interested Party Information, IPI
  Proprietary name identifier system administered by CISAC for creative parties, used largely for rights and royalties management. See also ISNI, VIAF.
International Digital Publishing Forum, IDPF
  Standards body that devised and maintained the EPUB file format for e‑books, now absorbed into the W3C.
International DOI Foundation, IDF
  The ISO-appointed not-for-profit registration authority (website) responsible for managing the DOI identifier system.
Internationalized Resource Identifier, IRI
  Like a URI or URL, but allowing the range of Unicode characters in the address – URIs and URLs are limited to ASCII. However, IRIs are criticized because of the confusion and risk presented by homographs – clicking on https://ns.edіteur.org/onix is different from the identical-looking https://ns.editeur.org/onix, because the former uses a Unicode Cyrillic і instead of the conventional Latin i used in the URL for the real website. IRIs should be converted into conventional URIs and URLs (eg by ‘percent-encoding’ the UTF-8 representation of the non-Ascii characters, or by using ‘Punycode’), which avoids these homograph issues.
International Organization for Standardization, ISO
  Non-governmental global standards setting body of which many national standards bodies – for example including ANSI, BSI, DIN, AFNOR, and JISC – are members. ISO Technical Committee 46 Subcommittee 9 (ISO/TC46/SC9) is ultimately responsible for many standardized publishing sector identifiers including the ISBN, DOI, ISNI, ISCC and the former ISTC, plus the foundational Principles of Identification standard, but ISO sets standards for many other aspects of the publishing industry too.
International Publishers Association, IPA
  Association of regional, national and specialist publishers’ associations which represents publishers worldwide and lobbies for freedom of expression and respect for copyright.
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. Or ‘a group of five websites, each consisting of screenshots of text from the other four’, Tom Eastman, Twitter, 3 Dec 2018. These are both really descriptions of the world wide web, just one of the systems built on top of the internet, the global collection of interconnected computer networks. It’s somewhat ironic that the widely-quoted link to the second definition is now broken (thanks, X), but a screenshot is available… E‑mail, FTP and numerous other services also use the internet.
Internet Assigned Numbers Authority, IANA
  Group that coordinates a central registry for DNS, protocols and MIME types for use on the internet.
Internet Engineering Task Force, IETF
  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.
Internet Protocol, IP
  Mechanism for data exchange across the Internet. Each computer attached to the internet has a unique IP address, and the protocol defines how the IP address is used in computer-to-computer communication. The Internet Protocol is often teamed with TCP (Transmission Control Protocol), a lower-level data exchange protocol.
Interoperability
  The ability of multiple systems, using different hardware or software platforms and data structures, to exchange or share data using a common interface.
Intersectionality
  Emphasizes the multiple and overlapping aspects of identity that might be the basis for empowerment, marginalization or oppression within society – among them, gender, caste, class, socio-economic status, sex, race, ethnicity, sexuality, religion, disability and physical appearance.
Inventory
  Copies of a product held by a publisher’s distributor or wholesaler, or more generally, stock of materials or finished products held. By extension, inventory might also apply to the publishing rights owned by a publisher.
Invoice, Pro forma invoice
  Document listing goods and services supplied (or to be supplied) by the supplier and the price to be paid to the supplier by the customer. Legal terms and conditions of supply – including whether the goods and services are to be supplied on credit terms or only after payment – are often printed on the back of a physical invoice, or linked from a digital invoice. However, an invoice marked Pro forma is merely a commitment by the seller to supply goods and services at the specified prices – in effect a quotation and not an actual invoice, since it is produced in advance of any confirmed order for the goods and services. Pro formas are commonly used to invite payment in advance, though in principle a pro forma may also quote credit terms like a normal invoice.
IP
  See Intellectual property.
  See Internet protocol.
  See also In print.
IPA
  See International Publishers Association.
  International Phonetic Alphabet, the notation devised by the International Phonetic Association and commonly used for phonetic representation of language sounds. The Association makes various charts and fonts available.
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 – 35.214.38.142 is (currently) linked to www.editeur.org. Computers use the IP address to communicate with other computers, and whenever necessary, they use a DNS service to convert (or resolve) any names entered by a human into the matching IP address.
IPI
  See Interested Party Information.
IPO
  Intellectual Property Office, a governmental institution responsible for administration of intellectual property rights, for example the UK IPO, EUIPO, USPTO (US Patents and Trademarks Office), JPO (Japan Patent Office).
IPR
  See intellectual property rights.
IRI
  See Industry Returns Initiative.
  See Internationalized Resource Identifier.
ISAN
  International Standard Audiovisual Number, a unique identifier for audiovisual material in the film, TV and video sectors. ISAN is an ISO standard (ISO 15706), 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, map 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.

  The system originated as the 9-digit SBN in 1967, at the instigation of W. H. Smith, then the largest UK book retailer. ISBN is an ISO standard (ISO 2108), an internationalized version of the SBN published in 1970. 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. Note that the check digit algorithm for 13-digit ISBNs is different from that used for ISBN-10. (There are several online converters which will do this conversion.) Any 978… ISBN-13 can be converted back into an ISBN-10 by removing the 978 and recalculating the check digit, 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 doi: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.
ISBN International Agency
  ISO-appointed registration authority (website) responsible for managing the ISBN identifier scheme globally. The Agency has appointed around 150 national and regional registration agencies to act on its behalf, assigning ISBNs and ranges of ISBNs to individual publications and publishers.
ISCC
  International Standard Content Code, an ISO ‘content-based identifier’ – an identifier for a chunk of text, an image, audio or a video file that is generated mathematically from the file itself (from the ‘digital media object’). It combines the ideas of a hash and a fingerprint, detecting both similarity and difference between different files. ISCCs are 52-characters in length, as four 13-character chunks separated by hyphens. The first two chunks are fingerprint-like and are intended to be shared by all manifestations or versions of a work, the latter two more hash-like and should differ for different manifestations and minor revisions.
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 ISO identifier (ISO 10957) 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 pseudonyms, fictional characters and brand names (eg imprints). 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 (ISO 27729), 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, IPI.
ISO
  See International Organization for Standardization.
ISO 3166‑2 etc
  Reference to one of ISO’s standards, eg for codes representing countries (3166‑1), languages (639‑2/B), currencies (4217). Any suffix indicates a particular part of a multi-part standard. These ISO standards are used as the basis for various ONIX codelists, but the ONIX lists are not necessarily identical to the ISO lists owing to differences in deprecation and removal policies, or – for the language code list in particular – the inclusion of extra codes not in the ISO lists but required for support of the commercial book trade. List 74 (codes for languages) is based on ISO 639‑2/B, but it includes extra codes taken from 639‑3 (a much larger list of language codes) and -5 (codes for language families), plus extra codes unique to ONIX for real-world languages that do not have ISO codes at all.
ISPM15
  One of a range of International Standard Phytosanitary Measures developed under the United Nations’ Food and Agriculture Organization (FAO) to protect agriculture and the environment and facilitate trade. ISPM15 specifically regulates the use of wooden packaging material, including pallets and crates.
ISRC
  International Standard Recording Code, an ISO standard (ISO 3901) 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, an ISO standard (ISO 3297) 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 is a check digit and may be ‘X’. ISSNs are usually presented with a hyphen separating two groups of four digits. 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 an EAN barcode using the prefix 977, the seven-digit ISSN (without its check digit), two digits with a publisher-defined function and a recalculated check digit.

ISTC
  Former International Standard Text Code, unique identifier for textual works. An ISTC consisted 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 were cross-publisher, and may also have been related to each other as when one work is derived from another (via translation, abridgement, compilation and so on). Like ONIX, ISTC drew upon the theoretical model provided by <indecs>. Note that the standard has been withdrawn by ISO, 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.
Italic
  Style of script or typeface for the Latin alphabet, with mostly flowing, cursive lower case characters slanted to the right, mimicking common late-medieval styles of handwriting used on official documents (so-called ‘chancery hand’). Originally, italic was a style of typeface separate from antiqua or roman, and from blackletter styles. In modern typographical usage, italic type is used in in conjunction with roman for emphasis, citations, foreign language words etc. A true italic uses letter shapes that vary from their roman (upright) equivalents, whereas oblique typefaces are slanted like italics, but the letterforms are otherwise unchanged.
Item
  A single copy of a product. See also instance. 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.
ITU, ITU-T
  International Telecommunication Union and its Telecommunication Standardization Sector, the body responsible (jointly with ISO) for standards such as H.264 and H.265, as well as networking and digital security standards. Formerly called CCITT.
Jacket, dust jacket
  Loose paper covering 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
  See Journal Article Tag Suite.
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.
JISC
  Japanese Industrial Standards Committee, body responsible for coordinating development of technical and other national standards in Japan. See also ISO.
  Jisc, UK not-for-profit organization that provides IT services and digital resources to the UK’s further and higher education sector.
Jobber
  See library supplier.
Journal Article Tag Suite, JATS
  Set of XML markup tags for tagging journal articles during the preparation, publishing and archiving processes, standardized by NISO. See also TEI, DocBook, DITA, BITS.
JPEG
  Joint Photographic Experts Group, a joint committee of ISO and ITU. 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 visual 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. See also MPEG.
JSON
  JavaScript Object Notation, a basic syntax for data files extended from JavaScript but now used in many contexts to communicate data consisting of a list of name-value pairs. JSON‑LD is a specialized ‘dialect’ of JSON used to carry Linked data. And just as XML schemas are tools to check the validity of XML data, JSON schema is a basic equivalent for JSON data.
Justification
  See hyphenation and justification.
KDP
  Kindle Direct Publishing, Amazon’s platform for self-published e‑books and print-on-demand paperbacks. KDP Select is an option whereby books are exclusive to the KDP platform.
KEP
  Similar to KDP, but intended for larger publishers.
Kerning
  Slight adjustment of the spacing between particular pairs of letters in typeset text 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 W A V E without kerning). Kerning occurs only between specific pairs of letters with sympathetic shapes (kerning pairs) to improve the readability and visual appearance of the type. cf tracking, also called ‘letterspacing’, which adjusts the spacing between all letters equally to adjust the length of a line of text (see justification).
Key title
  See lead title.
Keyword, Keywords
  A word or phrase – or a list of words and phrases – 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. They supplement rather than replace the use of controlled vocabularies such as Thema or BISAC.
Kindle
  Brand of dedicated e‑book reader devices by Amazon. Also, Kindle e‑book reader apps for use on other devices and platforms. Kindle devices support e‑books in proprietary Amazon formats (eg AZW, KF8, KFX) and PDFs, but not the standard EPUB format.
KSP
  See USP.
KU
  Kindle Unlimited, a service offering access to a library of Kindle e‑books on a subscription basis.
L1
  In language learning and teaching, a person’s first language (‘native’ language or ‘mother tongue’), normally acquired in the home during early childhood. L2, L3 etc are additional languages learned later.
Laid
  Laid paper shows a ribbed texture, imparted on the sheet by parallel wires as the paper dries during the manufacturing process. cf wove paper, which shows no ribbed texture (the wires are a much finer mesh which imparts no pattern). Sometimes, a laid finish is added artificially.
Lamination
  Thin plastic film applied to a printed sheet, for protection or to improve the appearance. The film can be glossy or matte, and is most often used decoratively on covers and jackets. cf UV-cured varnish. Thicker lamination film can be used to encapsulate a sheet or document entirely, for durability and waterproofing.
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.
Large language model, LLM
  A particular class of AI software which can be used to generate text. LLMs do this through statistical analysis of very large volumes of training text, and outputting the ‘most likely’ text in response to an initial prompt. See also ML. Use of LLMs is controversial because they may have been trained using copyright text without the permission of the rightsholder (via TDM), and because of their propensity for ‘hallucination’ errors (generation of plausible falsehoods). Some LLMs – termed ‘multimodal’ LLMs – also enable image and audio generation.
LaTeX
  (pronounced ‘la-tek’, as the X symbolises a Greek chi ‘Χ’) Markup language used to create complex technical or scientific documents, using plain text that can be post-processed (often with software called TeX) to create finished on-screen or fully-typeset documents.
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 very small 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 extra 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.
Launch date
  Loose term with highly variable meaning across different publishing companies. Sometimes synonymous with publication date, but equally often the date of some internal or public ‘product reveal’ several months prior to publication. See Publishing date composite in Group P.20.
Laydown
  See sales embargo date.
  In printing, is occasionally used to mean imposition.
LCC
  US Library of Congress Classification, book subject classification scheme used in some libraries. See also DDC, UDC, CLC, LCSH.
  Linked Content Coalition, former consortium of standards bodies and identifier registries that intended to – over time – increase interoperability between metadata, rights information and identifier standards across multiple media sectors. The same aim is now progressed more informally, though the LCC was the original source of what became ISO’s Principles of Identification (Technical Specification TS 22943).
LCCN
  Library of Congress Control Number, an identifier for a catalog record within the US national library.
LCP
  Licensed Content Protection (originally Lightweight Content Protection), a DRM scheme supported by the EDRLab which can be used to enforce usage restrictions on EPUBs, digital audio and other e‑publications, and which is implemented, for example in may Readium-based e‑book reading systems.
LCSH
  US Library of Congress Subject Headings, an immensely detailed book subject category scheme used in some libraries, and distinct from LCC. Aka ‘the red books’.
Leading
  (pronounced ‘ledding’) In typesetting and typography, extra space inserted between lines of typeset text, often to improve readability. So called because when setting moveable type, literal strips of lead were used to space out the type. A point size measurement like 10/12pt means 10pt text with 2pt extra spacing between lines. Typeset text without leading is ‘set solid’.
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).
Leaflet
  Small pamphlet with very few pages or panels, usually created by folding a single sheet and without distinct binding. cf pamphlet.
Learning Management System, LMS
  Integrated software application to support administration, delivery, tracking and reporting of digital educational resources or of complete courses. See also VLE.
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. In the UK, for example, a consortium of ‘copyright libraries’ may claim up to six copies of each published book, and in Ireland, a total of eight copies may be required. In most cases, this serves the dual purposes of ensuring the library and its patrons have access to the publication for cataloging and consultation, and of long-term archiving and preservation of the publication. cf dark archives.
Less than
  The < character, meaning ‘less than’ in mathematics. In XML, it is used alongside > (the ‘greater than’ symbol) to delimit tag names (eg in ‘<RecordReference>’). For this reason, in XML data, a less than symbol must be replaced by (‘escaped as’) ‘&lt;’.
Leveling
  Measurement or assessment of the complexity of text and its context, or the reading ability required for comprehension. See also age ranging. Also, the arrangement of multiple books (eg in a collection of educational readers) into a sequence of progressively increasing complexity.
Libel
  Publication of an untrue and defamatory 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 binding
  A particularly robust form of hardback binding used for books destined for heavy use in a library, either as the original binding or when a prebound copy is re-bound. Occasionally termed a ‘turtleback’. Historically, library binding could also refer to rebinding books in a consistent form for inclusion in a private collection.
Library Management System, LMS
  Integrated software application to support the functioning of a library, including acquisition, cataloging, inventory, access and lending. Also ILS, Integrated Library System.
Library supplier
  Wholesaler which specializes in supplying library and sometimes school customers. Library suppliers (in North America, jobbers) usually provide selection or bundling of suitable products, and cataloging services in addition to wholesale fulfillment, and some also 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.
Lightweight packaging format, LPF
  Lightweight Packaging Format, the Zip-based digital publication packaging format used by the W3C’s specification for packaged audiobooks, typically containing a publication manifest in JSON-LD format plus the publication content itself.
Limited edition
  Book printed or product produced in strictly limited numbers, usually only in one impression. Copies in a limited edition may be individually numbered, or signed, and may have other attributes such as higher-quality binding or a decorated foredge.
Limp-bound
  See case-bound.
Linearized PDF
  PDF where the internal structure of the data in the file is arranged so that all the information required to display page 1 is at the beginning, followed by all the information for page 2, etc. This increases the file size a little over conventional PDFs, but reduces the time required to display the initial view of the document when downloading a PDF from a server.
Line art
  See halftone.
Line haul
  In logistics, term for long-distance transport of mixed goods – usually by road – from distributor to retailer, or on fixed city-to-city routes. cf short-haul and last-mile transportation.
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 https://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’ or graph database (a type of non-relational database). Linked open data (or LOD) is linked data published under an ‘open’ license, and the Semantic web is a collection of richly interlinked, machine-readable Linked open data resources on the internet that allows data to be shared freely and widely reused – for example for data mining.
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.
Literary agent
  Person or organization representing creators such as authors, negotiating and licensing their rights to publishers and others in return for a share of the licensing revenue.
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 – via an intermediate ‘offset’ roller – to the paper. cf POD.
LLM
  See large language model.
LMS
  See Learning Management System.
  See Library Management System.
LoC
  Library of Congress, the national library of the USA.
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.
Local publication date
  See Market publication date.
LOCKSS
  See CLOCKSS.
LOD
  Linked Open Data, see linked data, semantic web
Logistics
  Movement of goods from manufacturer (usually the printer) to customer (the retailer), including physical shipping and intermediate warehousing. See distributors, wholesalers, shippers, see also reverse logistics.
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.
Long grain
  Pages printed and bound where the spine of the book lies parallel to the grain, the preferred orientation of fibers, in the paper. This means a stronger binding because folds aligned with the grain break fewer fibers in the paper. cf cross grain, short grain or against the grain, where the spine is aligned at right angles to the grain of the paper.
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.
Lot control
  Inventory or stock control process within a warehouse that ensures separate lots of a product (different impressions) are managed, for example to ensure copies from older lots are sold first (‘first in-first out’). This avoids accumulation of very old copies which gradually become unsaleable.
Lot number
  In logistics, a number or identifier attached to a specific batch of manufactured products. For physical books, see impression. See also SKU.
Loudness
  Loosely, the perceived volume of a sound or of recorded audio. See normalization.
Lower case
  See case.
LPI
  See halftone.
LPF
  See Lightweight packaging format.
LRM
  See FRBR.
LUFS
  Loudness Units relative to Full Scale – a measurement of the average loudness of a recorded sound, based on human perception of loudness. See also dB.
MAC address
  Media access control address, a unique number assigned to the hardware of a computer, used for communication over a network. They are normally expressed as six groups of two hexadecimal digits, eg f4:0f:24:22:48:47.
Machine learning
  Computer algorithms that build and use mathematical or statistical models based on pre-existing training data to classify or make decisions about new data, often seen as one facet of AI. Deep learning is a type of machine learning inspired more by neuroscience than by statistical approaches. See also LLM, TDM.
Managed file transfer, MFT
  Third party, high-reliability service that delivers sender’s files to nominated recipients, with security, efficiency and guaranteed delivery either via the internet or dedicated data links. MFT imposes a management layer above basic file transfer protocols such as AS2, FTPS, SFTP or HTTPS.
Manifest
  In metadata, a list of files or other resources, eg those required to assemble the completed product. For example, ONIX Block 8 comprises a file manifest and some detailed processing instructions or product specifications.
  In international trade, a list of goods shipped as cargo.
Manifestation
  A physical or digital embodiment of a particular work. The related hardback, paperback, audio and e‑book products of a particular title are four different manifestations of the same work. All contain essentially identical content, but are described in separate ONIX Product records. Note that a manifestation encompasses multiple individual copies (or instances) of a book, which are identical (or very nearly so) and (with exceptions) fungible. Manifestations may be identified with ISBNs. See <indecs> and FRBR.
Manufacturer
  Physical maker of products. For books, a printer and/or binder.
Manuscript
  Author’s original handwritten or typed material (sometimes termed ‘typescript’), as submitted to the publisher, or at least, material that has not been edited, typeset or published yet. Originally, manuscript referred only to handwritten material.
MARC
  Machine Readable Cataloging, a family of metadata formats used in library cataloging since the 1960s. 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 around 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 (such as BIBFRAME) 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.
Market publication date
  Loosely, the publication date in a specific market. Strictly, the product’s Publication date (sometimes termed the ‘global’ publication date) is the earliest of possibly several market publication dates, and other market publication dates represent delayed availability in those markets. See Publishing date composite in Group P.20.
Markup
  Labels, delimiters or tags within a document that define its typographic style, 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 or text element within the document, so top-level heading text in HTML is contained between <H1> and </H1> tags. Markup can be described as either semantic or presentational, but in practice is often a mixture of both.
Markup language
  A specific type of markup or text encoding that can be applied within a document to specify its formatting or structure. See for example HTML, LaTeX or SVG. XML itself could be considered a meta-markup language, in that it can be used to define other markup languages.
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.
Mastering, Audio mastering
  Processing of audio data after initial recording and editing, to optimize the equalization and loudness, limit the dynamic range, etc and create the ‘master’ from which all future copies are made.
MathML
  A markup language for mathematical equations, which can be integrated into HTML5 web pages in much the same way as can SVG graphics. There are two flavors of MathML, focusing on either the visual presentation or mathematical meaning of the equation.
Matrix barcode
  So-called 2D barcode consisting of a grid of black and white squares or dots, rather than a simple linear barcode comprising a row of black and white bars, and using some particular encoding scheme or symbology. QR codes are the most familiar type of matrix barcode, but there are others (eg the Aztec codes used by airlines on most electronic boarding passes), some of which also incorporate color or different shapes. Matrix barcodes can encode more complex information than ordinary linear barcodes.
MEA
  See BIC’s Metadata Excellence Award.
Measure
  In typesetting, the width of a column of type. In ONIX, a physical dimension of a product (eg height, width, spine width, weight).
Mechanical pulp
  Wood pulp made from wood that is separated into its constituent fibres mechanically, by physically grinding and ‘refining’ wood chips to a fibrous slurry (a refiner for pulp is a type of pump with internal blades that shred the fibres in the pulp even finer). Compared with chemical pulping, it generally produces lower quality, bulkier, less long-lasting paper stock with a lower cellulose and higher lignin content, which in North America is sometimes termed groundwood paper (literally, ground wood).
Media kit, Press kit
  Bundle of promotional material provided to trade or consumer news organizations and other media outlets. Media kits usually include a press release, excerpts from the book, reviews and endorsements. See also blad.
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’.
MENA
  Middle East and North Africa, a broader and more inclusive term than ‘the Middle East’ for a geographical region stretching across North Africa (roughly from Morocco to Somalia), plus Asia Minor and the Levant, and southern Asia from Turkey to Iran (and occasionally Pakistan). Precise boundaries for the region vary according to context. See also EMEA.
Message
  See ONIX message, or the related Acknowledgement 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 standardized and highly structured metadata from one party to another within the supply chain. Some organizations might also consider internal workflow information to be part of the product’s metadata, though such internal metadata would not be shared with supply chain partners. Occasionally, metadata is used to mean addditional data, tags, keywords added to a web page for search engine optimization purposes.
Metadata aggregator
  See aggregator.
Metadata Excellence Award
  See BIC Basic.
Metered access
  Business model for library e‑books where the number of patron loans is limited. This is intended to mimic the fact that print books ‘wear out’ through use, and need to be rebound or replaced after a number of loans.
MFT
  See managed file transfer.
MG
  See middle grade.
Middle grade, MG
  Middle grade audience or (loosely) a book genre – intended to appeal to readers between younger childhood and teenage (approximately 9–12 years old) – sometimes called ‘tweens’. cf YA. Like YA, a lack of precision and international applicability means that the term is avoided in ONIX.
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.
ML
  Markup language, see HTML, SGML, MathML.
  See machine learning.
Moiré
  Irregular wavy pattern (akin to that seen in overpass railings) seen as a defect in halftoned color images, caused by the overlapping patterns of halftoned dots in the four (CMYK) colors. The grids of dots in printed with each process color ink must be arranged at very precise angles to avoid unsightly moiré.
Mojibake
  (pronounced ‘mo-ji-ba-keh’) Japanese term for the garbled text that results from data using one character encoding being interpreted as if it was in a different encoding. For example, the name Adélaïde might appear as Ad�la�de (Windows-1252 encoded text interpreted as if it were encoded as Unicode UTF-8, with two invalid characters), or as AdÃ©laÃ¯de (UTF-8 encoded text interpreted as if it were Windows-1252).
Mono, monochrome
  Printed using a single ink (usually black). Note this can include halftone images, not just text and line illustrations.
Mono, monaural, monophonic
  Sound recorded with a single microphone, or with a single channel of audio data, and usually reproduced by delivering the same audio to both ears. cf stereo (also binaural, stereophonic) recordings, which use two microphones, or contain two channels of audio data, fed more or less independently to each ear to create a sensation of width and the position of each individual sound source. Multichannel or Surround sound is audio recorded using multiple microphones and containing more than two audio channels (eg 2.1 audio contains left and right channels, plus an extra ‘effects’ channel for low frequency sounds. 5.1 surround sound uses left, center, right, rear left and rear right channels, plus a sixth effects channel). Audiobooks are generally mono unless they are multi-voiced or dramatized.
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. cf a continuing resource. Continuing resources include serial publications (or periodicals) such as academic journals, newspapers or magazines which are published in successive issues without a predetermined end, and integrating resources which are continually updated eg loose-leaf publications or a website.
  Sometimes also implies a detailed scholarly work, generally by a single author, covering an extensive field of study. cf contributed volumes (also called edited volumes), where each chapter of an academic or scholarly book is written by different authors. Contributed volumes usually also have a named editor (often termed a Contributing editor, Volume editor, Consultant editor etc) or an Editorial board, with overall responsibility for the various contributions.
Moral rights
  See copyright.
MP3
  MPEG-1 or -2 Audio Layer-Ⅲ, standard for compressed audio files. The quality and fidelity to the original (uncompressed) audio depends on the degree of ‘lossy’ compression, characterized primarily by the bit rate (eg 128 kilobits/s which many people can distinguish from a CD-quality uncompressed audio file, or 320 kbits/s which is almost impossible to distinguish by ear). cf AAC. See also codec.
MPEG
  Moving Pictures Expert Group, standards body jointly convened by ISO and IEC (the International Electrotechnical Commission), responsible for standards such as AVC and HEVC, as well as older compressed video standards such as MPEG-1 and -2 (which include the MP3 audio standard). Analogous to JPEG.
MS
  See manuscript. Occasionally ‘TS’ for Typescript.
MSDS
  See SDS.
Multi-component product, multi-item product
  A single copy of a product may contain multiple parts – components – that are always 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 copies (items) of a single product, or copies of several ‘smaller’ products, and is usually intended to be split before retail sale (though they are sometimes made available at retail as a bundle or multipack). Multi-item products such as a counterpack containing a dozen copies of an individual book are sometimes available only to the trade as the counterpack itself is intended for POS use.
NACO, LC/NACO
  Library of Congress / Name Authority Cooperative Program, a name authority file maintained by the LoC and the Program for Cooperative Cataloging. See also ISNI, VIAF, ORCID.
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.1/reference is the name of the ONIX 3.1 reference namespace. Note that there is no web page at that address – it is merely an unambiguous way of naming the namespace.
Narrator
  Loosely, the reader of an audiobook, but in ONIX, the narrator role is used specifically for a member of the cast of an audio dramatization.
Nation, People
  Relating to indigeneity, a group of people united by tribal, kinship or cultural affiliation, and often associated with a particular geographical territory.
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.
NBS
  See non-breaking space.
Negative invoice
  See credit note.
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 retail price maintenance laws and similar agreements in many 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 deduction of 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.
NISO
  National Information Standards Organization, US standards organization affiliated to ANSI and responsible for technical standards for information management (eg for the libraries community). NISO provides management support for TC46/SC9, an ISO committee responsible for the ISBN, ISNI, DOI and other identifier standards.
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.
Non-breaking space, NBS
  Typographical character that acts as a space character, except that it cannot act as a line wrapping point during hyphenation and justification of text. In some languages, non-breaking spaces are widely used between words and punctuation characters – for example in French between a word and a colon, or between guillemets and the text they enclose. There is also a similar non-breaking alternative to a hyphen.
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 as highly prioritized as fast data retrieval.
  In Unicode, the normalization form (NFC, NFD, NFKC or NFKD) concerns whether composite characters like é or the ﬀ ligature are decomposed into two separate characters (or more strictly, two separate codepoints), the e and ´ (a combining acute accent) or f plus f, or kept as a single precomposed character.
  In ONIX and other XML, and in HTML, ‘whitespace normalization’ means that, by default, combinations of multiple space, tab, return and new line characters are treated as if they were a single space character.
  In audio mastering, boosting or fading recorded audio to standardize the apparent volume (loudness) or to match the volume or other aspects of two different recordings.
Notation
  In ONIX codelists, the language-independent code that represents a particular concept. See also SKOS.
Notice and takedown, Takedown notice
  Legally-mandated process that operates in many jurisdictions whereby copyright-infringing material (and libelous content) is removed from online systems following a notice served to the online host by rightsholders.
Numerical character reference
  Method of encoding non-ASCII characters in HTML and XML, for example ‘&#x2013;’ for an en-dash. The numbers are the Unicode codepoints for particular characters, and can be ordinary decimal numbers (&#8211;) or in hexadecimal (&#x2013;). Numerical character references are largely unnecessary with the widespread use of Unicode characters, but can be useful where it is difficult to type the required character on the keyboard. cf named character entities.
NYP
  Not yet published: publication is forthcoming. cf AB.
OA
  See open access.
OAI-PMH
  Open Archives Initiative Protocol for Metadata Harvesting, a standard protocol used for disseminating metadata from a data repository, most widely implemented in the library and research sector and primarily using Dublin Core metadata.
OAPEN
  Online library hosting and distributing peer-reviewed open access books, particularly though not exclusively focusing on humanities and social sciences subjects. OAPEN (Open Access Publishing in European Networks) is operated by the not-for-profit OAPEN Foundation. See also DOAB.
Oblique
  See italic.
OCLC
  Originally the Online Computer Library Center, US-based global library cooperative offering services such as shared cataloging, technology services and research.
OFC, OBC
  Outside front cover (cover 1), Outside back cover (cover 4). cf IFC, IBC.
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.
Omnibus
  Publication containing the content of several previously-published products, sometimes termed a bind-up or (in ONIX) a combined edition.
One copy, one user
  Business model for library e‑books whereby an e‑book may only be loaned to one library patron at a time. Once returned, it can then be loaned to another patron, but the loans may not be concurrent. The e‑book may remain in the library’s collection permanently, or access may be limited to a fixed total number of loans.
ONIX feed
  Arrangement and supply of an ongoing series of ONIX messages exchanged between data sender and recipient, generally on a daily or weekly schedule or ‘as needed'. Once a data feed has been established with an initial message containing the full set of Product records, subsequent messages in the feed normally contain only Product records for new products and updates (more accurately, replacement data) for existing products.
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 as a set of guidelines under the aegis of the Association of American Publishers in 1999 and first published in January 2000, the standard has since early 2000 been managed, developed and supported by EDItEUR.
ONIX Acknowledgement message
  Special ONIX file returned to an ONIX metadata sender by the recipient, to confirm receipt and processing of an ONIX message, as part of an agreed message choreography. See Appendix A.13.
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 and responding appropriately to the confirmation message.
ONIX message
  A complete ONIX data file, generally one in a series of messages (an ONIX feed) passed between a data provider and a data recipient. A single message may contain one or many Product records, or none.
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.
Opacity
  Degree of translucence or opaqueness of a sheet of paper. High opacity reduces ‘show through’ of print from the opposite side of the sheet.
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, OA

  Licensed on ‘open’ terms following the recommendations of the Budapest Open Access Initiative and later policies, 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 commercial exploitation, or impose other restrictions.

  More often associated with serial publications 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 via an archive maintained by the author, the research institution or an independent ‘open access repository’ (collectively, ‘Green’ OA). Gold OA material is the version of record, whereas Green OA usually refers to a preprint or author-accepted manuscript – and either may be free of charge but remain subject to some, many or even all the usual copyright restrictions, depending on the exact licensing terms.

  Publication of OA material usually requires the payment of APCs, BPCs or PPCs by the author or author’s funder, to cover the costs incurred by the publisher – although so-called ‘Diamond’ OA does not (ie neither author nor reader pays), and Diamond principles also include other criteria. Other business models are also used, for example pledging or subscription models where libraries or library consortia fund individual publications or a broad publication program, ‘flip’ models where a publication becomes open after a certain number of conventional sales have been made, or freemium models where conventional sales of associated materials fund the core product. See also Plan S, hybrid OA.

Open access publisher
  Publisher – usually an academic publisher – which specializes in making its products available on open access terms. In the simplest cases, the publisher charges the author a fee – often termed an APC (article processing charge), BPC (book processing charge) or PPC (page 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. A range of other business models are also used. 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 for conventional publications. cf vanity publisher.
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. Some open source licenses require that any modifications made are also open source.
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.
Open Web Platform
  Loose term for the combination of HTML (particularly HTML5), CSS and JavaScript used to create web pages, web-based applications, and EPUB e‑books.
Operational management
  Design, implementation, control and optimization of systems of business processes for production of goods and delivery of services, at both day-to-day and strategic level.
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).
Opt-out
  In many jurisdictions, a legal exception allows use of copyright text for data mining (TDM). Sometimes this is a broad exception. In some jurisdictions (for example the EU), it is possible for a rightsholder to partially opt out of such an exception, thus proscribing TDM for at least commercial uses.
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. Like ISNI, ORCID is a sixteen-digit identifier, but the two divide the numberspace so the identifiers are not duplicated.
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. The EU’s Orphan Works Directive sets strict limits on the unlicensed use of orphan works by cultural heritage institutions, which may be subject to retroactive license fees should the rightsholders become known.
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). cf 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 remaining for sale in the supply chain. See also OPS, in print, in commerce, 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.

  Out of print is generally viewed as a ‘final’ status and a particular OP product (a particular ISBN) cannot revert to an active status – though a work considered out of print can revert if a new manifestation (with a new ISBN) is made available. Publishers do occasionally revert products from OP to a ‘forthcoming’ or active status (without a new ISBN), and even set a new ‘publication date’, but this is seen as exceptional, and is not recommended practice.

Overs, Overruns
  Excess physical copies printed beyond the number of copies ordered from the printer by the publisher.
Overstocks
  Excess physical copies held by a distributor or wholesaler and never needed to fulfill orders. See returns, remainders.
OWP
  See Open Web Platform.
P&A
  Price and availability. Not to be confused with A&P, advertising and promotion.
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.
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.2 × 1.0m (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 500–750 typical hardback novels or up to twice that number of paperbacks (depending on their extent), or a tonne or more of paper sheets. Common Euro and US ‘standard’ pallets differ in size – 1.2 × 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 normal doorways 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), no distinct flattened spine, and usually bound with a simple wire stitch (staple). A common format (Product form) for comic books, manga and other low-extent publications, and for informal publications. cf leaflet, booklet.
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.
Paperback
  Book – usually adhesive-bound – with a limp card cover and a distinct spine. Also softback, softcover etc. Generally much lower cost but much less robust and durable than an equivalent hardback (hardcover, ‘cased’ book) which is constructed from a stiff card or board cover finished with leather, textile or faux textile, commonly with higher-quality paper for the book block, bound with glue and/or thread, and often supplied with a paper jacket (dustjacket). cf pamphlet, which is usually self-covered, wire-stitched and of lower extent.
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.
Paradata
  Obscure term for a subset of metadata concerned with the creation of that metadata. In principle, timestamps on metadata fields – such as ONIX’s datestamp attribute – or data fields like <RecordSourceName> could be considered to be paradata. Narrowly within the field of online educational or scholarly resources, paradata can also mean usage statistics such as those produced by Project COUNTER.
Paratext
  See peritext.
Parser
  In XML, a parser is software that can read an XML document (such as an ONIX message), check that it matches the required XML syntax and grammar (by comparing it with a DTD or schema file – a process called validation), and make each individual data element available to other software (via an API).
Partial update
  See block update.
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. More loosely, may also be applied to organizations in the supply chain.
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 (ISO 32000). A PDF file can encapsulate almost every aspect of the document – the text, fonts, all vector and raster graphics, video and other rich media, and even limited interactivity and metadata (including an embedded ONIX file describing the PDF itself as a product). In general, a PDF fixes the visual aspects of the document exactly and PDF (specifically PDF/X) is often used to transfer publisher files to the printer for manufacturing, but reflowing PDFs are possible.

  Unfortunately, PDF files do not retain full structural or semantic markup, which reduces their accessibility. So-called web PDFs are normal PDFs (generally not reflowable) but which have lower quality images (fewer pixels or more loosely, lower resolution, than PDFs intended for printing) in order to reduce the file size.

PDF/A
  Specialized subset of the PDF standard for archiving and long-term preservation, ISO 19005. It prohibits use of external (‘linked’) fonts, content such as audio, video or forms, and encryption.
PDF/UA
  PDF/Universal Accessibility, an subset of the PDF standard for optimized for accessibility, ISO 14289.
PDF/X
  Specialised subset of the PDF standard intended to provide full print fidelity for the prepress and print industry, ISO 15930. It restricts the PDF document content to static, non-interactive and device-independent elements.
PE
  See AA.
Peer review
  Procedure in which professional and scholarly works are evaluated prior to publication by experts in the same discipline, to ensure that they meet the standards necessary for publication. Peer review is intended to validate research methods and ensure quality publications. Peer reviews can be double-blind where neither reviewer nor reviewee are aware of the other’s identity, single-blind in which reviewers are aware of the identity of the reviewee but not vice versa, or open.
PEFC
  See FSC.
People
  (as a singular noun) See nation.
Perfect binding
  See adhesive binding.
Period
  Punctuation mark (‘ . ’) also called a full stop, used at the end of 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.
Peritext
  In literary criticism, text published with but not as part of a work, and not usually written by the creator of the work – the prelims and back matter, and possibly also including notes, footnotes and bibliography. Together with the related concept epitext (comprising reviews, marketing and publicity material, interviews with the author etc), it forms the paratext of the book.
Permissions
  Authorization from the copyright or other rightsholder to incorporate one work, or more often a small 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 pseudonymous or otherwise distinct from the private identity of a real-world person. See also ISNI, contributor.
Picking
  Tiny defects on a printed page caused by paper fibers sticking to the printing plate and being pulled away from the paper surface.
  Selecting items from warehouse stock to make up an order, later to be dispatched to the customer.
Picture book
  Children’s illustrated storybook in which the narrative is told mostly through large – often full-page – illustrations, and with just a few words per picture. cf chapter book.
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 the Hellenistic poet Callimachus of Cyrene to catalog the papyri holdings of the Library of Alexandria around 245 BCE.
Piracy
  Illegally printing, duplicating and/or making physical or digital copies available of a book without holding the requisite publishing rights, sales rights, or compensating the rightsholders. Publishers, intermediaries, libraries and retailers need a coherent anti-piracy strategy to prevent this – via better supply chain security, DRM, web monitoring, takedown notices and so on, and by ensuring legitimate copies are easily available and priced reasonably in the market.
Pixel
  See raster image.
Plate
  In printing, a metal sheet that has raised, lowered or chemically-treated oleophilic patterns that pick up and deposit ink on the paper. In modern rotary presses, the plate is bent around a rotating drum, which presses the plate against the paper – or more likely, against an intermediate rubber roller known as a ‘blanket’ which in turn deposits the ink on the paper. This latter is offset printing.
  Photographic or illustrated image in a book. See plate section.
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.
Platform
  eg a e‑book retail platform, a self-publishing platform. Software infrastructure that enables user interaction and transactions to support a particular business model or set of operations. The platform may provide a brandable (white label) service that may appear to provided by the platform user but which is in fact provided by the platform operator. Alternatively, a platform might provide a set of tools for processing content, or orchestrate an online marketplace for buyers and sellers. See also the open web platform, cf the Windows platform.
Plan S
  2018 initiative from a consortium of research funding agencies (cOAlition S) that mandates that publication of scientific research funded by the agencies must – from 2021 – be open access (from the outset, without any delay after initial closed publication).
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.
PMS
  See Product management system.
  See Pantone.
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 (print) publishing workflows is limited. See also TIFF, JPEG.
Pocket book
  Small book, usually a paperback (in French: livre de poche). 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. Pocket book is roughly synonymous with A-format paperback. In the US, the equivalent is a rack-sized paperback.)
POD
  See print-on-demand.
Podcast
  Typically episodic series of digital audio files made available for downloading. They can be free to download, supported by advertising, or accessible via paid subscription.
Point
  Traditional primarily American and British typographic unit of size for typeset text, 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, and a large print book might be 16pt or above. See also em. cf didot, a 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. See EPOS.
  Promotional material such as posters, dumpbins and counterpacks, bookmarks placed near 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.
PPB or PP&B
  Paper, printing and binding, which together can be seen as the ‘manufacturing cost’ of a (physical) book.
PPC
  Page processing charge, see APC.
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 subject classification or categorization 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 may be 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.
PREMIS
  Normally refers to a common data dictionary defining metadata fields related to long-term preservation of digital publications, though not all preservation systems use the PREMIS data model (CLOCKSS does not). More rarely, ‘PREservation Metadata: Implementation Strategies’, the project that developed the data dictionary.
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. See also Subscription order.
Prepress
  Activities in a pre-digital or digital workflow preparatory to printing, including scanning of physical artwork or photographic images, imposition, proofing, platemaking, etc. (Typesetting is often omitted from the range of prepress activities.) Prepress processes are now largely digital and in some ways much simpler than in pre-digital workflows.
Preprint
  In scholarly publishing, the initial version of book or journal article content as initially submitted by the author to the publisher, and therefore still subject to peer review, correction, editing and final formatting before publication. In some disciplines, specialized ‘preprint server’ repositories such as arxiv.org or biorxiv.org are important (NB the x is pronounced as a Greek letter chi, so ‘archive’). cf author-accepted manuscript, version of record. See also green OA.
Presentational markup
  See semantic markup.
Preservation
  Ensuring access to a publication (whether physical or digital) for the long-term future – many decades after a publication is out of print and out of commerce. Digital preservation may also encompass the component parts of a publication – the text, individual images or data sets – to guard against obsolescence of the digital publication format itself, and the associated metadata to ensure future discoverability. Preservation is as much a problem of policy and sustainability as it is of technology. See legal deposit, dark archive.
Press
  Alternative term for a publisher, a printing press, or ‘the press’ meaning newspapers, magazines and the journalists that create them.
Press kit
  See media kit.
Press release
  Document announcing some notable event, for example the forthcoming publication of a book, distributed to the press in the hope of gaining media attention.
Price extension
  See barcode.
Printer’s pack, binder’s pack
  Carton in which multiple copies of a book are delivered from manufacturer (printer or binder) to the distributor (and possibly to the wholesaler or retailer). The individual copies may be sold separately at retail.
Printer’s pair
  See imposition.
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.
Printing
  See impression.
Print-on-demand, POD
  Manufacture of a single copy – often using xerographic (dry, toner-based) or inkjet printing – usually in response to an individual retailer or retail customer order. POD copies may be drop-shipped to the retail customer, or fulfilled via a retailer. Although POD has a reputation for inferior print quality and binding, it is largely undeserved: current POD technology rivals the quality of conventional litho manufacturing. cf short-run printing which often uses the same print technology as POD. See also ASR.
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 hexachrome 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 group of identical physical items or copies of a digital item that is available for sale to the public (or to an organization on a business-to-business basis, or to another defined group of customers), and distinct from similar groups of items (ie other products) that differ in form or content. A product – and its constituent copies or items – are commonly identified using an ISBN. Product metadata describes the key attributes shared by that particular group of items (and which differentiate the product from other products).

  In intellectual property terms, a product is a particular manifestation of a work, and <Product> is the primary entity in the ONIX framework.

  Although ONIX is almost always characterized as describing tradeable products, it can be used to describe parts of a product that are not individually available (sometimes termed components), products that comprise multiple copies of another product or copies of multiple other products (multi-item products), or groups of individual products (ie collections) that are only available individually. However, such components, parts and groups are often not identified using an ISBN, unless they are also products in their own right.

Product management system
  IT system used to manage the creation and editing of metadata decribing a publisher’s products, occasionally termed a Title management system. Often also incorporates production management, content or asset management functions.
Product record
  the complete set of metadata relating to a single product, provided within an ONIX message. A Product record is contained between <Product> and </Product> XML tags.
Pro forma
  See invoice.
Proof
  A ‘trial copy’ made of a column of typeset text (a galley proof), of a laid-out page (a page proof), a complete set of pages (a book proof), or a single image. Proofs are intended for checking and potential correction before a product is finalised.
Proprietary identifier
  See identifier.
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.
  Relating to EUDR, the geographical source(s) of raw materials such as timber: ‘where the trees grew’.
Publication date
  The date on which the product is nominally ‘published’, though not necessarily the exact date on which it first becomes available at retail. See Publishing date composite in Group P.20.
Publication day
  Day of the week on which most trade books are published – for example Tuesday in the USA or Thursday in the UK, but this is merely a convention within each market and there are many exceptions.
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. The publisher purchases or licenses the legal right to make the product available (in the specific language, format, territory, etc) from the original copyright owner or other rightsholder. cf contributor, packager, distributor, wholesaler and retailer. The publisher (even a self-publisher) is a legal entity, since it must take legal responsibility for the publication. cf imprint, which 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, and ultimately derived from the creator’s copyright. 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.

  Note that these publishing rights are not made explicit in ONIX. cf sales rights.

Pull method
  See push method.
Pulp
  Slurry of cellulose fibres (and some lignin) in water, used to make paper. The fibres are extracted chemically or mechanically from wood or recycled material, bleached to control the color of the final paper, washed, then spread on a seive or mat to drain the water. The remaining fibres are pressed and dried to make paper. Various coatings can be applied to improve the surface texture, brightness and absorption properties of the paper.
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.
Push method
  In ONIX, refers to data file transfers initiated by the data sender. Typically, a data sender uploads an ONIX file to a server controlled by the data recipient. The pull method is the opposite – the data sender makes a file available on a server it controls, and the data recipient downloads the file later. In general, transfer of ONIX files uses the push method. In contrast, transfer of associated resources (for example, marketing collateral from Block 2, or production files listed in the Block 8 Production manifest) mostly use the pull method, using a URL supplied in the ONIX itself.
Putaway
  Process of moving returned copies to their designated storage location in a warehouse. Copies may be returned to a location from which they can be re-sold, or to a location from which they will be destroyed (eg pulped).
QR code
  Quick Response code, a particular type (symbology) of 2D barcode (also termed a matrix barcode) comprising a grid of black and white squares. When scanned (eg with a dedicated scanner or 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, and sometimes used within a book to ease access to associated online resources.
Qualifier
  Category or code used within subject schemes such as Thema or the obsolete BIC scheme 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, pocket book.
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’.
Ragged right, left
  See hyphenation and justification.
RAM
  Random Access Memory, the working memory of a computer, usually in the range of 1 gigabyte (roughly a billion bytes, eg in a 2012-vintage smartphone) to 64 gigabytes or more (in a desktop PC or 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, in the form of a spinning hard disk or solid state drive, which is measured in hundreds of gigabytes.
Ranged left, right
  See hyphenation and justification.
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. Note also that the ‘dots’ or pixels in a digital image are generally not the same as halftone dots.
RDA
  See Resource description and access.
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 in a subject-predicate-object structure. 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
  RDF in Attributes, a data format for embedding RDF-style structured triple data within the markup of HTML web pages. It is one of the data formats used by schema.org.
Reader
  Educational book providing reading practice for beginners, usually aimed at younger students and often part of a formal reading scheme comprising multiple, carefully leveled texts.
  Proofreader, who reads and marks corrections to be made in typeset or marked-up material on behalf of a publisher.
  Publisher’s reader, who reads and selects (usually unsolicited) manuscripts for possible publication.
  Voice actor who reads an audiobook aloud. cf narrator.
  Sensitivity reader, who reads and comments upon manuscripts during preparation for publication, looking for stereotypical, insensitive or potentially offensive content, bias or a lack of diversity or inclusion.
  The eventual ‘user’ of a book.
Reading age
  Measure of a child’s reading proficiency or the proficiency required to read and comprehend a text, expressed as the age of a child of average reading ability with the same proficiency.
Reading line
  See cover line.
Reading system
  Hardware or software that takes a particular type of document file and presents it on screen – eg Acrobat Reader or Apple’s Preview application are reading systems for PDF (as are many web browsers), a Kindle device or application is a reading system for Amazon’s Kindle e‑book file formats. Thorium is a reading system for EPUB e‑book files.
Readium
  Open source software toolkit developed by EDRLab for creating online, mobile or desktop e‑book reading systems using the EPUB format. Thorium is a full-featured reading application developed using Readium.
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 such as √2, which cannot be represented exactly by fractions.) cf integer.
Recommended retail price, RRP

  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 countries where RRPs are the norm, the Agency model may still allow publishers to exert direct control over consumer prices.

  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.

Recto

  The side of a single leaf in a book that is read first – bound as a right hand page in a book, and given an odd page number. (Conceptually at least, the equivalent 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.
Referent
  Of an identifier, the thing identified.
Reflow, Reflowable
  For paginated e‑books, the ability of a reading system to adapt the presentation of the e‑book on screen as text font or size is changed by the reader, or as a result of viewing on a different size screen. If text size on a page is increased, text is re-paginated and spills over to ‘create’ new pages (the extent of the document increases), rather than the pagination being fixed. Graphical elements may be re-arranged at the same time. EPUB is primarily a reflowable file format, although there is a fixed-layout variant. Reflow is very similar to the concept of ‘adaptive layout’, a term applied in web design.
Region code
  Alphanumeric code used to identify a region. In ONIX, a region (for example in <RegionCode> or <RegionsIncluded>) generally references an administrative or geographical subdivision of a country – for example a State of the USA, or a Province of China (see List 49). The exception is WORLD, which represents the entire world. (One other supra-national region, the Eurozone, is defined but is deprecated in ONIX 3.0, and is not used at all in 3.1.) See also country code.
Registrant
  The person or organization requesting, registering or assigning an identifier (and distinct from the registration agency or authority).
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, NielsenIQ Bookdata in the UK and Bowker in the US operate national ISBN registration agencies. (This terminology mostly applies to ISO identifier standards.)
Registration marks
  Cross- or target-shaped marks printed a little outside the page edges (and subsequently trimmed off – see TLS). In color printing, the registration marks are used to ensure each color is printed in perfect alignment with the other inks, which avoids oddly-colored fringes appearing around printed color images. In CMYK printing, each of the four colors needs to be printed on the paper exactly ‘in register’ and the registration mark will appear perfectly black. See also trapping. cf crop marks.
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 temporarily unavailable (though not after the original was declared out of print or was permanently withdrawn). 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. Note that in non-ONIX contexts, ‘reissue’ can be used to describe re-publication of a product previously out of print.
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 particular 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, entity-relationship model.

  For some more specialised uses, there are also non-relational databases that do not use a table and column metaphor or SQL, instead storing data as a list of key-value pairs, in a graph (a network of nodes and links – see linked data) or as a collection of structured documents (eg so-called XML databases).

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.
Rendering
  For images, turning a vector image into a raster image (thus fixing the size in pixels). More loosely, displaying data on screen (or in print).
  A ‘version’ of a resource – for example a PDF rendering and an EPUB rendering of an e‑book.
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 rightsholder for licensing under particular terms.
Reprint
  [Print] a new impression, usually manufactured to replenish stock. See also reissue. 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 work identifier).
Reseller
  Supply chain organization, for example a wholesaler, library supplier or retailer that buys or stocks a publisher’s products in order to supply them to their customers – on either a business-to-business or business-to-consumer basis.
Reseller model
  Business model based on the idea that the publisher sells to an intermediary (typically a distributor, wholesaler or retailer – a reseller) 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 (or dereferencing) 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).
Resource
  In library science, any material available to a library patron – a book, an academic journal, online database or a website.
  In ONIX, an item of marketing collateral, or – in the context of ONIX Block 8 – a file used during creation or manufacture of a product. A resource in ONIX is referenced via its URL or filename.
Retailer
  A reseller which deals primarily in sales to consumers / end-users rather than in business-to-business sales. Retailers may sell through physical (‘bricks and mortar’) bookshops, through an online store, or they may operate a direct sales operation (such as a book club). Increasingly, retailers sell both physical and digital products through online stores.
Resource description and access, RDA
  Modern set of library cataloging rules aligned with the Library Reference Model data structure or abstract model – increasingly widely used and gradually supplanting AACR2 in most English language library applications. RDA rules are also applicable to cataloging in other languages.
Return
  See returns.
  Carriage return, character typed to indicate a new paragraph or confirm entry of data. In an XML or HTML data file, New line characters can be any of Carriage return (x0d in hexadecimal) or Line feed (x0a) or a CRLF combination (x0d 0a). However – in XML or HTML – whitespace normalization means that new lines are not significant and are usually treated as if they were spaces.
Returns

  Books sold to wholesalers or retailers on ‘sale or return’ terms, and which fail to sell at retail (often termed overstocks), can be returned to the wholesaler or distributor for credit. Such returned copies can then be re-sold to another retailer, or may be pulped. Often, the retailer must obtain an Authorized Returns Note (ARN) or Return Merchandise Authorization (RMA) from the publisher or distributor, or seek permission through some other returns authorization process before returning copies. 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 minimize 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 unsaleable. Thus, a certain level of returns is anticipated, and may be beneficial since the credit on returns frees retailers to order new books that are more likely to sell.

  Returns are a long-established example of reverse logistics, and although it varies across different countries, the eventual return of 5–15% of trade books dispatched is not unusual.

Reverse logistics
  In general, the logistics of returning goods back up the supply chain to recapture value (eg through resale) or for recycling or disposal. In the book industry, see returns.
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 a radio antenna and a chip carrying identification and other information for the item, which can be read at a short distance to track the item and automate many logistical processes. For example RFID tags can be used to automate library lending processes. See also NFC.
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. Each pixel’s color is specified by three numbers, usually 8-bit numbers, giving 256 levels of ‘redness’, ‘greenness’ and so on. RGBA adds an ‘Alpha channel’, with the fourth number specifying how transparent or opaque each pixel is. See also 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, ‘sub-rights’ or secondary rights – initially 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. They sometimes include the right to publish specialized manifestations such as large print or audio products – and some publishers even specialize in sub-licensing and exploiting these secondary rights.

  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.
RMA
  See ARN.
RNG
  RELAX NG schema language. See schema.
Roman
  Style of script or typeface for the Latin alphabet, with upright, mostly rounded, antiqua-style lower case characters based on late-medieval calligraphic scripts, combined with upper case characters styled on Roman carved inscriptions. In typography, roman (often termed antiqua in historical contexts), italic and blackletter represent the three main historical traditions of typeface style, though in modern Latin alphabet typography, roman and italic are used together (italic for emphasis, citations, foreign language words etc).
Romanization
  Transliteration of a non-Latin script into Latin script, for example switching the Russian patronymic Михайлович to Mikhailovich. The term is avoided in ONIX, in favour of the more general transliteration (romanization applies only to Latin script).
Roman numerals
  System of numerals developed in ancient Rome (and originating with the Etruscans) using Latin letters as numbers (Ⅰ = 1, Ⅴ = 5, Ⅹ = 10, Ⅼ = 50 etc) and a characteristic subtractive notation (Ⅸ = 9 etc). cf Arabic numerals.
ROR
  Research Organization Registry, body that maintains a registry of ROR identifiers for research organizations, to help link researchers and research output to institutions.
Rough front
  See deckle edge.
Royal
  Common hardback book size in the UK, with a trimmed page size typically around 234 × 153mm. Originally derived from ‘Royal Octavo’, a traditional Royal paper size folded twice for form eight pages around 10 × 6¼in before (quite generous) trimming. The overall size of a Royal hardback is a few millimetres larger because of the overhang of the cover boards. 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 these sums are often paid in advance and offset against assumed future royalties. Royalties are also paid based on a percentage of the value of rights and licensing sales. Minor contributors may receive only a one-off fixed fee in lieu of royalties.
RRO
  Reproduction Rights Organization, a (usually) national agency that administers collective copyright licensing on behalf of publishers, for example the UK’s Publishers Licensing Services (PLS). See also CMO, IFRRO.
RRP
  See recommended retail price.
R-strategies
  Choices such as ‘reduce, re-use, repair and recycle’ made to increase circularity in the economy and boost sustainability.
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.
RUC, OSI
  Reprint under consideration, or Out of stock indefinitely, a status when the publisher or publisher’s primary distributor has no new stock to fulfill orders, but is not currently reprinting or planning a reprint. Products with this status often languish for months or years, without any active consideration of the potential for reprinting, when (arguably) they should be declared out of print.
Rules of origin
  Rules used by a particular country to determine the ‘economic nationality’ of imported goods, in order to apply the appropriate tariffs, duties, quotas, trade embargoes or other measures which may vary according to the country of origin. However, rules of origin are not standardized: they vary across countries, meaning goods treated as ‘originating’ in a country by one importing country may be viewed as originating in a different country by a different importer. The World Trade Organization is one forum in which rules of origin are negotiated between countries.
Run around
  When text is ‘fitted’ around an illustration, with the length of each line of text adjusted as necessary.
Running head
  Heading, usually printed small at the top of each page of a book, usually the chapter title or the book title. In a dictionary, directory or similar, the running head can be the first and last entries on a page.
SAAS
  Software as a service, see ASP.
Saddle stitched

  Binding by stapling (wire stitching) folded sheets together in the seam of the fold. The clinch of the staple lies in the center of the book. This method is generally only used for single-signature publications such as comic books. cf side stitched, where a wire stitch is driven through folded signatures or individual sheets from front to back (the clinch of the staple lies at the back of the book).

  Section sewn, Saddle sewn or Smyth sewn binding is similar, but with thread rather than a wire stitch. Signatures are sewn through the fold, then multiple sewn signatures can be sewn or glued together to form the book block. Oversewn or stab binding is the thread-equivalent of side stitching.

  However the book block is constructed then trimmed, it may be reinforced by glueing a strip of paper or fabric to the back (spine) face of the block, with or without endbands, before affixing the cover card or boards. cf adhesive binding.

Sale or return, SOR

  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 (or sometimes, refund) if not sold on to retail customers – see also returns. Sometimes called ‘see-safe’ terms.

  The purchaser’s right to return unsold copies may expire when – or more usually a fixed period after – a book is declared out of print by the publisher, or may be limited to a particular time window. The right to return may be further constrained by industry agreement (eg the UK’s Industry Returns Initiative).

  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 in the United States, typically carry a triangular indicator containing a letter S adjacent to the barcode), or by mutual agreement, 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 agent
  Organization responsible for marketing, promotion and sales of the product on behalf of the publisher, usually in a territory outside the home territory of the publisher. Sales agents typically work with a distributor or with wholesalers who provide warehousing and fulfillment, in the same way a publisher does. (In some countries, ‘distributors’ typically act as sales agents too.) In ONIX, sales agents are named in the <PublisherRepresentative> composite.
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 between the publishing rights and the sales rights: publishing rights concern where (and perhaps when) 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.

  Underlying these publishing rights and sales rights are more specific rights, ultimately derived from the creator’s copyright. In particular, the publishing rights indicate that the publisher holds the ‘right to reproduce’, the ‘right to distribute’ and the ‘right to make available’, and the sales rights indicate the publisher is willing to pass (some of) these rights on to its supply chain partners. Without holding and passing on these necessary rights, the publisher cannot legitimately express the sales 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 usually 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 final 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
  See Standard address number.
SBTi
  Science-based Targets initiative, an international collaborative body created by the United Nations Global Compact, CDP (Carbon Disclosure Project) and WWF (World Wide Fund for Nature) to help companies build greenhouse gas emission reduction targets that are aligned with climate science and the Paris Agreement (the international treaty on climate change mitigation adopted in 2015).
Scanner
  In a book store or warehouse, a optoelectronic device that can recognize barcodes or QR codes printed on products or packages, and output the digital data the barcode represents, eg an ISBN or GTIN.
  In design and reprographics, a device that scans a physical document, photograph etc and turns it into a digital image, eg as a JPEG or TIFF.
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. Validation is the process of checking a particular XML file meets the requirements defined by a particular schema.

  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 based on XSD 1.1 technology is also available, and this 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. See also relational database. See also entity-relationship model.
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.
Scholarly
  See academic and scholarly.
Scope 1, 2, 3
  In measurement or reporting of greenhouse gas emissions, the breadth or terms of reference of any measurement or audit, according to defined Greenhouse Gas Protocol standards. Scope 1 covers only direct emissions by an organization, Scope 2 additionally covers emissions due to an organization’s purchases of energy, and Scope 3 includes all emissions from an organization’s suppliers, its operations and delivery network, and from customers’ use and disposal of the organization’s products. The majority of emissions usually lie in Scope 3.
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 now written using Latin script).
Scroll
  Printed or manuscript content arranged as a continuous document, not divided into discrete pages. cf codex.
SDGs
  The United Nations’ Sustainable Development Goals, 17 key goals intended to encourage greater environmental responsibility coupled with social and economic development within a sustainable framework by 2030. Within publishing, organizations can commit to the UN’s SDG Publishers Compact to indicate they actively support these goals.
SDS
  Safety data sheet, often MSDS (Material safety data sheet) or occasionally PSDS (Product safety data sheet), documentation covering the production, handling and use of substances and products that may potentially be hazardous or contain harmful chemicals. See GHS, the internationally-standardized system for SDSs.
Search engine optimization, SEO
  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. Can also refer to the optimization of book metadata to improve organic search results within an online bookstore, for example by using likely search terms within key fields like the long description, keywords or subtitle (this last is a common misuse). cf GEO.
Secondary rights
  See subsidiary rights.
Section 508
  Requirement in US law that federal agencies ensure their IT systems are accessible to people with disabilities. See also ADA.
Section mark
  Typographic symbol ‘ § ’ usually indicating a section or clause in a document.
Secure FTP
  See FTPS.
See-safe
  See sale or return.
Self-cover
  Cover which uses the same paper stock as the body of a book, rather than thicker card or board. See also pamphlet.
Self-publisher
  Person combining the roles of contributor and publisher – typically an author acting as a publisher in order to make their own work available, either directly, or indirectly via a self-publishing platform.
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 equals 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 (only) 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.
SEN, SEND
  Special educational needs (and disabilities), broad terms used in education and child support to encompass the range of learning difficulties that hamper a child’s development, and disabilities that hinder access to mainstream education. See also AAC.
SEO
  See search engine optimization.
Serial, serial publication
  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.
Service Level Agreement, SLA
  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 supply chain partner.
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.
Sewn binding
  See saddle stitched.
SFTP
  See FTPS.
SGML
  Standard Generalized Markup Language. Highly complex technical standard for markup. Effectively the predecessor of XML, but rarely used because of its complexity.
SGTIN
  Serialized GTIN, a GTIN-14 combined with a unique serial number to identify one specific physical item. See EPC.
Sheet-fed press
  See web press.
Shelfmark
  Code marked on a book (usually on the spine) and recorded in the library catalog, indicating where the book is shelved in a library, thus forming the link between the library’s catalog and its physical collection. The shelfmark may be based solely on physical location, or may be based on the subject of a book, and consequently, two different books may have the same shelfmark. cf a library call number, a generally more complex scheme identifying a book within a library that may have extensive collections beyond the open shelves, and which may include a representation of the author’s name (perhaps as a Cutter number) or the year of publication within the call number. Two different books would not have the same call number, though two copies of the same book would. See also accession number.
Shingling
  Slight adjustments to the width of the inner (gutter) margin of printed pages made during imposition, to account for the thickness of the paper when folded into a signature. The gutter margin is decreased on pages folded into the middle of a signature, so the margin appears consistent when folded and bound.
Shipper, Consignor
  In logistics, an organization in the supply chain – often the publisher itself – that sends or organizes shipments of books or other goods from manufacturer (a printer or binder) to customers (including distributors and wholesalers). Shipping can be domestic or international – the latter is more complex because of the knowledge of tariffs, duties, customs and quotas required, and is often handled by specialist customs brokers. Shippers usually contract with freight forwarders or third party logistics organizations to arrange the physical movement of goods. See also INCO terms, drop shipment, carrier, consolidation.
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.
Short grain
  See long grain.
Show-through
  Insufficiently opaque or dense paper allows text from the back of a leaf to become visible, making the page more difficult to read.
Shrink-wrap
  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.
Sidecar file
  A file of additional metadata that may accompany a conventional ONIX message, containing data that cannot be included in the ONIX. Generally viewed as undesirable. Sidecar files are sometimes required when sender or recipient ONIX implementations are incomplete, or when some specialist or proprietary data must be exchanged, but they are not a good long-term solution.
Side stitched
  See saddle stitched.
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) to form hierarchies and cross-references.
SKU
  Stock Keeping Unit. In logistics, a unique (and often proprietary) identifier for each product available. In the book trade, the ISBN or GTIN is often used as an SKU. But sometimes – 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 or GTIN). A book distributor might supplement the ISBN with an impression, batch or lot number to ensure older stock is sold before newer. Not all book trade stockholders implement this more granular lot control.
SLA
  See Service Level Agreement.
Slash
  See solidus.
Slash fiction
  Genre featuring re-imagined (often sexual) relationships between pre-existing characters from other works or other media, eg a ‘Kirk/Spock’ story.
Slip-case
  Sleeve constructed of rigid board into which a single book slides, or which holds multiple volumes, leaving the spine(s) exposed.
Social DRM
  See watermarking, DRM.
Soft hyphen
  Unicode character &#xad;, sometimes termed a discretionary hyphen, inserted into a word to indicate where H&J may optionally insert a line break in order to balance line lengths. A soft hyphen is normally invisible in text, unless the line is broken at that point – in which case a hyphen is displayed. cf zero width space.
Solidus
  Typographic symbol ‘ / ’, an oblique stroke or slash, used to indicate division (as in fractions like ⅞) or in separating alternatives (as in ‘donkey / ass’). There is also a reverse solidus, ‘ \ ’, commonly called a backslash. In mathematical typesetting, a ÷ (division sign) or ⁄ (fraction slash) may be more appropriate.
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, which groups adverts with others that are similar).
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 sales
  Business-to-business sales 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 (special sales are often also high-discount sales). Most special sales are to non-traditional outlets or channels that do not specialize in book retail.
Spine
  Bound edge or ‘back’ of a bound book, squared off or slightly rounded.
Spinner
  Rotating stand or rack holding multiple books for display to customers in a physical retail environment.
Split leather
  Type of real leather made from an animal hide after the top grain leather has been separated – essentially the innermost layer of the hide. Split leather tends to be lower quality than top grain, thinner and less durable, and often has an artificial texture added. Top grain retains the natural texture of the outer hide of the animal.
Spot color
  Specific colored ink used for printing, in contrast to simulating that color using process color inks and halftoning.
Sprayed edges
  Foredge (and possibly also the top and bottom of the book block) colored or illustrated, using an ink spray or inkjet printer. Page edges can also be gilded with foil applied to the bok block.
Spread
  Pair of facing pages in a book.
  In prepress, see trapping.
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.
Stamping
  Process in which a metallic (or metallic-effect) foil is impressed onto a jacket or cover using a stamping die. Also known as foil blocking. A similar die can be used (without the foil) to emboss a relief pattern on a jacket or paperback cover. Foil and embossing are often used in combination, particularly on trade book covers.
Standard Address Number, SAN
  American national standard identifier for a trading location within the supply chain. The SAN registry is administered by Bowker. SANs are also used in the United Kingdom, where the registry is maintained by NielsenIQ Bookdata. 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.
STEM
  In an education context, Science, Technology, Engineering and Mathematics as curriculum topics and as a publishing sector. The acronym STEAM adds either Agricultural science or the Arts, but there is no consensus on either this or the inclusion of Social Sciences within STEM. The antithesis is HSS or HASS (Humanities, the Arts and Social Sciences), or specifically in the UK, SHAPE (Social sciences, Humanities and the Arts for people and the economy). See also STM.
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’.
Stereo
  See mono.
STM, STML
  Scientific, Technical, Medical (and Legal) publishing, a subset of the academic and scholarly publishing sectors. cf HSS.
Stock
  Number of copies of books in a warehouse, or held at a retailer, available for distribution or for sale (eg ‘free stock’), also known as inventory. Stock control or inventory management is the process of managing the number of copies in stock to ensure that all orders can be fulfilled and overstocks and excessive returns avoided. See also lot control.
  The grade or type of paper or card used for printing (eg ‘cover stock’).
Street date
  See Strict on-sale date.
Strict on-sale date
  Also known as a sales embargo date (which is the preferred term within ONIX), or as an ‘on-sale date’, street 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 via an affidavit) and one that is not (ie 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.
Subject categorization, subject classification, subject coding
  Systematic arrangement of books according to what they are about, according to some subject scheme. Many schemes – see for example Thema, BISAC, Dewey – list all potential subjects or topics hierarchically, and each subject is associated with a code (see controlled vocabulary). Most strictly, classification implies a book may be a member of only a single subject group (ie the groups are mutually exclusive), whereas categorization implies a book may be assigned to many categories. In practice, however, ‘categorization’ and ‘classification’ are often used interchangeably. Dewey is a subject classification scheme, since a book can have only a single Dewey number, whereas Thema and BISAC are category schemes since a book can be assigned more than one Thema or BISAC subject code.
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 e‑book rental, but subscription usually applies to a library of many e‑books (eg Scribd’s Everand service), whereas rental usually applies to a single book, and subscription is often open-ended (auto-renewing each month) whereas rental tends to be for a fixed period.
  See subscription order.
Subscription order
  Retailer order placed with a wholesaler or distributor several weeks prior to publication date of a book – see also dues.
Subsidiary rights
  See rights.
Subsidy publisher
  See vanity publisher.
Subtitle
  Words that appear on a book’s title page which are subsidiary to the main title of a book, and which amplify or explain the main title. cf cover lines, which are usually more informational (‘includes 101 recipes for chicken’) and appear on the cover but not the title page, and promotional headlines which are clearly more promotional (‘the world’s best chicken recipes’), and which appear on neither the cover nor the title page – they are intended as a headline that can be used above a description of the book.
Subtitles
  See closed captions.
Superior, Inferior
  Also termed superscript, subscript. Characters printed smaller, and raised or lowered relative to the 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 management concept that encourages focus on process optimization, logistics and customer satisfaction, cf value chain, a closely-related business management term.
Sustainability
  Broad and ill-defined term indicating the ability or goal to maintain or improve upon something desirable or beneficial over a long period of time (or perhaps indefinitely). This is usually considered from environmental, social and economic viewpoints, and can encompass avoidance of the depletion of natural resources or degradation of the natural environment (see circularity), development towards a more equitable society that provides for and protects vulnerable communities (see DEI), or building successful business models to secure the long-term future of organizations and business systems. See also sustainable development.
Sustainable development
  Concept arising from the 1987 Brundtland Report (produced by an arm of the United Nations), and defined as ‘development that meets the needs of the present generation without compromising the ability of future generations to meet their own needs’. In essence it combines economic and social development with environmental sustainability. See SDGs.
SVG
  Scalable Vector Graphics, a vector image format or markup language incorporated within HTML5. The diagrams in this document use SVG.
Symbology
  Particular arrangement of bars, text and margins (‘quiet zones’) in and around a barcode. Identifiers such as ISBN, UPC, GTIN specify which symbology should be used to represent the identifier in machine-readable form. See also matrix barcodes.
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….
Tag line
  See cover line.
Takedown notice
  See Notice and takedown.
TARIC
  Tarif Intégré Communautaire, the EU’s system of commodity codes, used for administrative purposes relating to importation of goods into the EU. See Harmonized System codes, on which TARIC is based.
Tariff
  A duty or tax levied on imports into a country or customs territory. Tariffs might also be combined with quotas on imports, or other restrictions on international trade.
Tariff code
  See commodity code.
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, of which TC46/SC9 is a technical sub-committee. SC9 is responsible for managing the development of standards including ISBN, ISNI, DOI, ISCC.
TCP, TCP/IP
  See IP.
TDM
  See text and data mining.
TDMrep
  TDM reservation protocol, a metadata protocol applicable to material available via the internet that can express the publisher’s opt-out from the copyright exception that enables TDM under European Union law (even if opted out, TDM for research purposes is allowed).
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.
Territory
  In ONIX, a geographical area composed of countries and regions (parts of countries). Territories can be defined additively (eg USA plus Canada plus Mexico), or subtractively (eg WORLD minus USA, Canada, Mexico) – these two examples are complementary territories in that they ‘add up to’ the entire world. Territories can also add and subtract regions (eg Canada minus Quebec).
Territorial rights
  Loose term referring to rights that vary by location or territory. See rights, publishing rights, distribution rights, sales rights.
Text and data mining, TDM
  The extraction of useful (and possibly new) information through computer analysis of pre-existing text or other data, a key part of ML and the training of large language models (LLMs). While published material might appear to be protected from unwanted text and data mining by virtue of copyright, that is rarely the case. Depending on jurisdiction, TDM is sometimes allowed through a specific copyright exception, at least for research or more broadly non-commercial purposes. In other jurisdictions, text and data mining is allowed as a fair use.
Thema

  A new(ish) subject categorization scheme developed in part from the legacy BIC scheme, but updated, internationalized and significantly extended to create a multilingual scheme with global applicability. Thema 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 and multilingual category browser is available at ns.editeur.org/thema.

  Like ONIX, Thema is managed by EDItEUR. Thema was introduced in late 2013. It was initially intended to be used in parallel with existing nationally-focused schemes, but it has the potential to supplant them as a single global scheme. Usage is growing rapidly: it has already been adopted widely across the book trade in a number of countries, including Germany, Spain, the UK, Norway and Sweden, Japan and others, and has become a key part of Amazon’s ‘browse by subject’ scheme in its online stores.

Third party logistics, 3PL
  Organization combining the functions of a carrier and a freight forwarder, offering a complete logistics service to clients.
Thorium
  See Readium.
Thumb index
  In dictionaries, directories and similar, a crescent-shaped cut out from the foredge of a group of pages, to aid in opening the book at a specific page. The foredge of the indexed page is sometimes reinforced with card.
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, book plates, gatefolds and other pages that are not the same size, or sometimes for pages intended to be removed such as reply cards.
Title

  The name of a book, as listed on the title page or cover, or one of the variants of that (former title, abbreviated title, alternative title etc). This might also include any collection title. Titles often incorporate a volume or part number when a work is split into separately-bound books, a year or year range for annually-issued publications, or a subtitle which may amplify or clarify the title. The title does not include any promotional cover lines, endorsements or marketing messages that might also appear on the book cover.

  More loosely, can imply a group of products that share the same name and contents – akin to a work.

Title management system
  IT system used to manage the creation and editing of metadata decribing a publisher’s products, more frequently termed a Product management system.
Title page
  Recto page at the beginning of a book that bears the title of the book, and usually also the names of contributors and the publisher (or imprint), and the 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 Copyright page or imprint page, often the fourth page of the book block) usually contains copyright details and any CIP information and colophon. A Half-title page is a recto page before the title page – and thus usually the first page of the book block – that often 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 folding, trimming and binding. 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 example within the HTTPS protocol.
TMS
  See Title management system.
TOC
  Table of Contents.
Top grain leather
  The outermost (and highest quality) layer of a tanned animal hide. See split leather.
Tote
  In logistics, a reusable plastic crate used to collect and convey items within a distribution center or warehouse.
TPB
  See trade paperback.
TPS
  Trimmed page size. See TLS.
Traces NT
  Trade Control and Expert System, the European Commission’s online portal that enables creation and submission of Due diligence statements (DDSs) linked to compliance with the EU Deforestation Regulation (EUDR).
Tracking
  See kerning.
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 originally 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). cf X.12.
Trade
  The book trade – the business and commerce of book publishing, manufacture, distribution and bookselling, in phrases like ‘trade-only’, ‘trade-pack’, ‘trade association’, trade discount etc. In this context, ‘non-trade’ is occasionally used to describe non-traditional sales channels such as through catalogs, ‘special’ sales’ 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. Non-trade books generally include specialist non-fiction, educational, and academic and scholarly titles.
Trade discount
  See discount.
Trade paperback
  In the UK, a paperback book produced in a size more typical of hardbacks (see demy, royal, C format); in the US, a softcover book that’s larger than rack-size mass-market paperbacks (but not necessarily as large as a typical hardcover book).
  In comic books and manga, a book containing a complete collected story originally published in serialized form (eg in a magazine, or as a series of floppy comics) – conceptually similar to an omnibus. In Japanese, a​「tankōbon」. A few comic trade paperbacks are in fact bound as hardbacks.
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, Children’s, Education, Business and professional, Academic and scholarly publishing. Note that trade books are only a small part of the book trade.
Training data
  In AI and machine learning, an initial set of data used as examples to construct a statistical model of how the application should react to future data inputs. For example a set of books, including their full text content and Thema subject codes, could be used to ‘train’ a model to assign Thema codes to future book texts. Training data is typically augmented by separate validation and text data, used to tune and verify correct operation of the trained application. LLMs are trained on vast sets of text (eg scraped from the internet) so they can react seemingly knowledgeably to general queries.
Transcoding
  Conversion of one digital audio or video file format to another (eg from MP3 to AAC). With lossy formats, transcoding always involves a further loss of audio or video quality.
Translation
  Conversion of text from a source language into another, target language (possibly also inclusing conversion of the writing system to the script usually associated with the target language). There are two main approaches to this, ‘formal equivalence’ which focuses on word-for-word translation and maintenance of the gramatical structure of the original, and ‘dynamic equivalence’ (sometimes termed ‘pragmatic equivalence’) which prioritizes the overall meaning and natural expression in the target language, while adjusting sentence structure, vocabulary etc, to suit the target audience of the translation.
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 written phonetically in the Latin alphabet (so Владивосток becomes Vladivostok). cf translation, where Russian is converted into the English language. Transliteration converts the sound of a language rather than its meaning, often to aid pronunciation – for example in the romanization (conversion into Latin script) of Arabic, Korean Hangul or Japanese Kanji.
Trapping
  In prepress, particularly for litho printing with spot or process inks, expanding (or ‘spreading’) a light color against a darker background so they overlap by perhaps a tenth of a point, to guard against any mis-registration causing a white line between the two colors. The amount of intentional overlap is dependent on the expected tolerance of the registration during printing. The related adjustment, ‘choking’, shrinks areas of darker color slightly so that a deliberate white line between them does not disappear through misregistration.
Triangulation
  In (usually international) logistics, pattern of trade between three parties, where goods are shipped directly from the first party to the third, but invoicing is indirect: the first invoices the second and the second invoices the third. This avoids the need to physically ship products via the intermediary. Somewhat similar to drop shipment.
Trim marks
  See crop marks.
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).
Trope
  In literary analysis, a rhetorical or stylistic device used by a writer. In marketing, a recurrent (and often clichéd) theme, motif, archetype or plot device of niche genre fiction – ‘love triangles’, ‘grump and sunshine’, ‘enemies to lovers’ in romance fiction – which set or realize reader expectations.
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.
Twin loop binding, ‘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.
Typeface
  A set of characters of a particular consistent design, for example Helvetica regular or Garamond italic. cf font. Typefaces are often designed in closely-related ‘families’ – for example Helvetica regular, bold, oblique and so on.
Typesetting
  Arrangement of text in a particular typeface and point size, column width and leading, usually by a specialist compositor (typesetter). Originally, compositors used metal type, and later used computer-controlled phototypesetting machines which output the final text as physical (photographic) artwork. These days, type is almost universally set using a computer software application like Adobe InDesign, and output as a PDF/X file ready for prepress.
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 identifier and barcode system.
UCS
  Universal coded character set – see Unicode.
Universal Decimal Classification, UDC
  Common and highly detailed systematic subject classification system used within many libraries and information services. UDC has a complex ‘grammar’ of punctuation symbols used to combine multiple subjects and facets (cf Thema qualifiers) to provide rich subject information. See also DDC, on which UDC was originally based, LCC, CLC.
UDC
  See Universal Decimal Classification.
Ultraviolet
  Digital rights management system which implemented an internet-accessible key locker, so DRM-protected content could be unlocked by any of the Ultraviolet account owner’s devices. One of a range of key locker-based DRM schemes.
Umlaut
  See dieresis.
Uncoated paper
  See coated paper.
Unicameral
  See case.
Unicode

  Comprehensive set of characters standardized as ISO 10646, and 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. The Unicode character set, or Universal Coded Character Set (UCS), 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 – even emoji. There are around 150,000 characters defined in all, with more being added in successive Unicode updates. However, displaying or printing 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!

  Each character in Unicode has a 32‑bit number or codepoint (cf ASCII, which uses 7 bits (binary digits) for each codepoint, or Latin‑1, 8 bits per codepoint, and are therefore limited to a much smaller range of characters), so in principle Unicode files are four times the size of Ascii or Latin-1 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.

  This document is composed using the Unicode character set then encoded using UTF-8, 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.

  See also normalization.

Uniform Resource Identifier, URI
  An identifier for a resource (usually, but not necessarily, a resource on the internet). URIs are limited to the Ascii characters. See also URL, URN, IRI.
Uniform Resource Locator, URL
  Type of URI that identifies a resource based on where it can be found or ‘actioned’. See also web address. For example, the familiar https://www.editeur.org URL is the identifier for a resource – the EDItEUR website.
Uniform Resource Name, URN
  Type 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. (It is true that a text search for the ISBN will find a copy of the book at an internet retailer, but it’s equally likely to find a reference to the book on a normal web page – this is not the same as the certainty offered by a URN resolver.)
Universally Unique identifier, UUID

  A label or identifier that can be minted in accordance with RFC 4122. UUIDs are essentially random numbers, sufficiently large to ensure uniqueness in all practical circumstances, 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, but for general use, Type 4 (random) UUIDs are preferred. To pick a new UUID, see www.UUIDgenerator.net/version4.

  GUIDs (Globally Unique Identifiers) are UUIDs, but the GUID name is more common in some particular contexts (eg within Microsoft software).

UN Regional Groups
  Five distinct geopolitical groupings of United Nations member states: African group, Asia and the Pacific group, Eastern European group, Latin American and Caribbean group, and the Western European and Others group (‘Others’ here includes the USA, Canada, Australia).
UPC
  See GTIN. Also refers to a specific barcode symbology used to represent UPC identifiers in machine-readable form.
Upper case
  See case.
URI
  See Uniform Resource Identifier.
URL
  See Uniform Resource Locator.
URN
  See Uniform Resource Name.
Usage constraint
  A limit on what an end-purchaser may do with an e‑publication – for example cut and paste or print a portion of the e‑book, or loan the e‑book to others – according to the license the end-purchaser obtains. The constraints may be enforced using DRM. Significantly different constraints imply a different product (with a different product identifier and a different ONIX Product record).
US customary units
  System of weights and measures used in the US based on inches, ounces etc. For measurements of length (in inches) or weight (in ounces), there is no significant difference between US customary units and the former UK Imperial units, though for fluid measurements (of volume) the systems are different.
USP
  Unique selling point (or proposition), also unique value proposition (UVP). The singlular primary benefit of a product that differentiates it from – and makes it superior to – its competitor products. More loosely, marketers occasionaly identify multiple USPs, better termed key selling points or KSPs.
UTC
  Coordinated Universal Time, or ‘Zulu’ time, which is for all practical purposes the same as Greenwich Mean Time (GMT), the normal time kept in London, England (in winter). Unlike other timezones, UTC does not change with daylight saving. Local timezones use a specific offset from UTC, so EST (Eastern Standard Time, used in Eastern USA in winter) is five hours behind UTC and is often labelled ‘UTC−5’, and EDT (Eastern Daylight Time, used in Eastern USA in summer) is four hours behind, UTC−4. London uses British Summer Time (BST, UTC+1) in summer. Some areas have unusual offsets: India Standard Time is UTC+5:30, five and a half hours ahead of UTC / Greenwich Mean Time.
UTF‑8
  Practical encoding of the Unicode character set (UCS). UTF stands for Unicode Transformation Format. Each Unicode character (or more strictly, each codepoint) 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 – and particularly in other scripts – 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 the full UCS where codepoints are represented by either two or four bytes (never three), but it also comes in two flavors, UTF‑16LE and UTF‑16BE (little-endian and big-endian). An initial Byte order mark can indicate the difference if it’s not otherwise clear.
UUID
  See Universallly Unique Identifier.
UVP
  See USP.
Validation
  The process of checking an XML document (such as an ONIX file) first meets the requirements of the XML syntax (a single root element, all tags explicitly closed etc), and second meets the requirements of a particular DTD or schema – for example the ONIX for Books DTD and XSD. The former means the file or document is well-formed (ie it qualifies as correctly-structured XML), and the latter means it’s valid according to the structure or grammar requirements of a particular DTD or schema. Special XML parser software is required to validate an XML document. Note also that validation is not necessarily enough – there may also be various restrictions and business rules on validity that may not be possible to check via a schema.
Value Added Tax, VAT

  Also known in some countries as GST (Goods and Services Tax). Value Added Tax is levied as a percentage of sales of most goods and many services (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 and (from 2020) e‑books is levied at 0%, while physical or digital audiobooks carry standard rate (20%) VAT. In Ireland, books – and from 2024, e‑books and audiobooks – all attract 0% VAT while the standard rate is 23%. In France, the low rate of TVA (Taxe sur la valeur ajoutée) applied to books (physical, digital and audio) is 5.5% while the standard VAT rate on other goods and services 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. In most countries with VAT, prices advertised to consumers must include the tax, while business-to-business prices are usually advertised excluding tax.

  Note that in the small number of countries – including Ireland and the UK – where books are taxed at a special zero rate, this is legally different from being tax-exempt.

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, with profits accruing according to how well each organization extracts 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 term.
Vanity publisher
  Publisher which charges (rather than pays) the author to publish the author’s book, and imposes only minimal quality standards upon the author’s content. 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 or to protect (‘seal’) the printed image. Applied as a liquid, and often dried or cured using ultraviolet light. cf lamination.
VAT
  See value added tax.
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
  Generic supply chain term for an organization offering goods or service for sale – a seller or supplier. A vendor may be a creator or manufacturer, a service operator or service provider, or a reseller such as a distributor, wholesaler or retailer.
Vendor of record
  See distributor.
Version of record
  In scholarly publishing, final, peer-reviewed, fully edited and formatted version of the book or journal article content – the content as published. cf author-accepted manuscript, preprint. See also Gold OA.
Verso
  See recto.
VIAF
  See Virtual International Authority File.
Virtual International Authority File, VIAF
  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, NACO ORCID.
Virtual learning environment, VLE
  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.
VLE
  See virtual learning environment.
Volatile organic compounds, VOCs
  Chemicals such as toluene, isopropyl alcohol or acetone widely used as solvents in printing inks and as cleaning agents. Many are hazardous to health and highly flammable, though of course they evaporate before the printed material leaves the printing plant.
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.
Voluntary product accessibility template
  Standardised form for reporting a self-assessed accessibility statement. See ACR.
Voucher copies
  Free copies of a book given to secondary contributors. cf author’s copies.
VPAT
  See Voluntary product accessibility template.
W3C
  See World Wide Web Consortium.
W3C audiobook package
  A digital audiobook format defined by the W3C and intended to be a standard format for delivery of audiobook products to the reader. It includes audio files, any supplemental resources and a manifest that defines some metadata (including for example the listening order of the audio files and other data required for navigation purposes on the listener’s device, and links to alternative resources for accessibility purposes). These are packaged into a single LPF file for delivery. To some degree, the W3C audiobook format is the audio equivalent of EPUB.
Warengruppen-Systematik, WGS
  Product category scheme 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.
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 DRM (digital rights management), 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. WAVs are typically large files, around 10MB per minute of stereo audio. cf AAC, MP3 compressed audio, FLAC and AIFF uncompressed audio files.
WCAG
  See web content accessibility guidelines.
WCO
  See World Customs Organisation.
Web
  Continuous strip of paper taken from a reel and used on a web press.
  See also world wide web, one of the services that together constitute the internet.
Web address
  Loosely, a URL, the address of a website such as www.editeur.org. A DNS is used to ‘resolve’ a textual web address into the appropriate IP address.
Web content accessibility guidelines, WCAG
  W3C guidelines, occasionally termed a ‘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 access issues. The guidelines are also relevant when creating accessible e‑books, and form a part of the EPUB Accessibility Specification.
Web PDF
  See PDF.
Web press
  Printing press fed using paper on a bulk reel. The paper is only cut into sheets after printing. cf sheet-fed presses that use pre-cut sheets. With either web-fed or sheet-fed presses, these cut sheets are typically much larger than a single page, and are folded and trimmed to form a single signature. Web-fed presses can handle stock with a lower paper weight and sustain much higher printing speed than sheet-fed presses. Modern high-capacity sheet- or web-fed presses are ‘rotary’ presses, where the paper is moved through the press using a series of rollers, and printed using a cylindrical printing plate. In contrast, ‘flatbed’ presses use a flat printing plate and are limited to low-volume work.
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.
Well-formed
  See validation.
WGS
  See Warengruppen-Systematik.
WGS84
  Standard mathematical model (‘geodetic model’) of the 3D geometric shape of the Earth, used as a frame of reference for GPS location coordinates.
WHATWG
  Web Hypertext Application Technology Working Group, loose industry community that coordinates development of the HTML living standard.
White space
  The space, tab and return or new line characters. See normalization. Occasionally also includes other ‘blanks’ such as the non-breaking space or narrow space characters.
Wholesale model
  See reseller model.
Wholesale price
  Price charged by a (distributor or) wholesaler when a product is sold to another reseller (typically a retailer) – a business-to-business transaction not subject to trade discount. See also net price.
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. See also reseller.
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 (or repertoire) 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. cf Unicode.
WIP
  Work in progress.
WIPO
  See World Intellectual Property Organization.
Wire stitch
  Staple. A wire stitch through the middle of a set of folded sheets forms a simple booklet or pamphlet. See saddle stitched.
Wiro, Wire-O binding
  See twin loop binding.
World Customs Organization, WCO
  Intergovernmental body representing customs administrations globally, responsible for the Harmonized System of commodity codes.
World Intellectual Property Organization, WIPO
  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.
Work

  Distinct intellectual or artistic creation, from which several products (or manifestations in <indecs> terms) may be created; roughly synonymous with title, where hardback, paperback and e‑book manifestations of that title are all versions of the same work. Textual works may have a work identifier of some type, and may previously have been 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, and thus multiple works can be arranged in chains or networks of derivation. As such, ONIX uses the <indecs> view of a work; cf FRBR or LRM, within which a ‘work’ has a broader definition roughly equivalent to the entire chain or network of derived works. A FRBR or LRM expression is the near-equivalent of an <indecs> work. See also BIBFRAME, in which a work is roughly equivalent to an <indecs> work, and a hub is the equivalent of a FRBR or LRM work.

  Care is needed when discussing works or expressions, because of the confusion that can arise from differing and overlapping terminology across the different abstract models.

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 (or its encrypted HTTPS equivalent) to exchange data and documents created using HTML, CSS and JavaScript. Together, HTML, CSS and JavaScript are often termed the open web platform.
World Wide Web Consortium, W3C

  Body that develops and maintains 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, and WHATWG which develops the HTML living standard. It is now also responsible for the EPUB e‑book standard that was originally created by the IDPF.

  Note that W3C standards are routinely called ‘Recommendations’.

Wove
  See laid.
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 US book supply chain).
x-height
  In typography, height from the baseline to the top of a lower-case x character in a particular typeface, usually expressed relative to the point size of the type. See also ascender, descender.
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. The term (X)HTML is often used to refer to HTML and XHTML together. Loosely, XHTML (and specifically the ‘XML serialization of HTML5’) is also used in the EPUB standard.
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 Definition, language for defining XML schemas. Pertinent to ONIX, XSD comes as versions 1.0 and 1.1 – and in general, free-of-charge XML validation solutions only support v1.0. XSD 1.1 is required for the ONIX ‘strict’ schema.
XSL
  See XSLT.
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 type of XML to another – from one DTD or schema to another, or into an XHTML format. Transformation procedures are stored in XSL files.
YA
  See young adult.
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 disk to store any kind of digital data: for example ‘MP3 CDs’ (CD-Rom discs containing .mp3 files).
Young adult, YA
  Young adult book audience or (loosely) a genre of books – 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 or even 30 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. It is particularly problematic in international contexts, and ONIX avoids using the term. Similar terminology (eg ‘new adult’) often suffers a similar lack of clarity.
Zero width space
  Unicode character &#x200b;, which can be inserted into a word like a soft hyphen, the difference being that if a line of text is broken at a zero width space, no actual hyphen is displayed. A non-breaking zero width space (character &feff;) does not indicate a location for a discretionary line break, but is used as a byte order mark in Unicode UTF-16 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 (ie zipping is lossless). The compression algorithm is the same (it’s called ‘Deflate’), but Gzip is used for individual files, whereas Zip may also 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, MP3s or (usually) PDFs, but the algorithm works well with ONIX data files.

#### 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.1">` |
  `<Header>` |
  `<Sender>` |
  `<SenderName>Publishing Service Inc</SenderName>` |
  `</Sender>` |
  `<SentDateTime>20141209</SentDateTime>` |
  `</Header>` |
  `<NoProduct/>` |
  `</ONIXMessage>` |

  using Short tags, with addition of optional encoding attribute |
  --- | ---
  `<?xml version="1.0" encoding="UTF-8"?>` |
  `<ONIXmessage release="3.1">` |
  `<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.

The minimum set of ONIX data elements that you should support – as sender or recipient – is highly dependent on your business requirements and those of your supply chain partners.

- Senders should ensure they properly populate all elements the recipient requires;
- Recipients should not demand that senders use only a particular set of data elements: any extra data elements should just be ignored.

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.

  sample data element checklist ☑
  # | Reference name | Short tag | Notes
  --- | --- | --- | ---
  Message
  | `<?xml version="1.0" encoding="UTF‑8"?>` | `<?xml version="1.0" encoding="UTF‑8"?>` | ☑ version is mandatory, encoding is strongly recommended
  | `<ONIXMessage release="3.1" xmlns="http://ns.editeur.org/​onix/3.1/reference">` | `<ONIXmessage release="3.1" xmlns="http://ns.editeur.org/​onix/3.1/short">` | ☑ release is mandatory, xmlns is strongly recommended
  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>` | ☐ if in a series or set
  | `. . . . <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>` | ☐ if multiple contributors
  | `. . . . <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>` | ☐
  | `. . . . <UnnamedPersons>` | `<b249>` | ☐ for anon., et al
  | `. . . <ContributorStatement>` | `<b049>` | ☐
  | `. . . <NoContributor/>` | `<n339/>` | ☐ if no contributors
  Group P.8
  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>` | ☑
  | `. . . . <SequenceNumber` | `<b034>` | ☐ if multiple reviews
  | `. . . . <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 on use of text, 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) ☐ audio samples
  | `. . . . <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 on use of resources, 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>` | ☑ repeat if multiple markets
  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 represents 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 explanatory definition note or scope note;
- these terms are taken from SKOS (Simple Knowledge Organization System), a handy framework for structuring controlled vocabularies. The same structure is used for Thema;
- some codelists have an implied hierarchical structure, 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, but the underlying semantic relationships could be made explicit in the future. While List 150 makes the implicit underlying hierarchy more or less visible in the codes, other lists do not. List 74 for example does not make each language’s membership of a macrolanguage or language family group visible – the Mandarin language (code cmn) is a particular instance of the Chinese macrolanguage (chi), which itself is a member of the Sinitic language group (zhx) and ultimately of an even larger Sino-Tibetan group of languages.

The concept and its notation are language-independent. Conventionally, the preferred label and notes columns are in English, 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 in Dutch, Sonderausgabe in German, 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 « Relié » in French, to​「精装书」​(Jīngzhuāng shū) in Chinese or to ‚Gebundene ausgabe‘ in German – so long as the concept is unchanged, the labelling and notes can be translated into any language.

Within any one language, there might also be alternative labels and hidden labels to hide or highlight synonyms – ‘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 British, German or Chinese retailer will contain the code ‘BB’, which specifies the concept expressed as ‘Hardcover’ by the publisher and the identical concept expressed as ‘Hardback’, ‚Gebundene ausgabe‘ or​「精装书」​by the retailer.

The codelists are published in English, but could be translated into any language, provided the concept expressed by each row is unchanged.

  Sample codelist translation
  code | libellé | remarques
  --- | --- | ---
  BA | Livre |
  BB | Livre relié | Livre relié ou livre cartonné
  BC | Livre broché | Livre broché ou autre livre de poche
  BD | Feuillets mobiles | Livre à feuillets mobiles, feuilles de papier individuelles, en option avec classeur actualisable

Some ONIX National Groups may produce translations of the controlled vocabularies for languages other than English, and some translations are available from an online browser at https://ns.editeur.org/onix or as XML files from the EDItEUR website. But the use of the notation – the language-independent code – in ONIX messages avoids the need to maintain a central public registry of all translations.

The user interface of 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 in the codelists, as they never appear in a message, nor does it apply to textual data in an ONIX message.

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. The same framework is used for the structure of Thema, and Thema is available in SKOS XML/RDF format (see https://ns.editeur.org/thema.rdf).

#### A.4 Development and support lifecycle

Successive versions of the Specification and schema are numbered as {major release}.{minor release}.{revision}. The status of a particular version of ONIX for Books – say of Release 3.0.2 – follows an orderly development and support lifecycle.

1. Active development – the schema is under active development, and will be extended or enhanced to deliver new functionality as new business requirements are identified, providing they can be met without introducing incompatibilities with existing implementations of the release;
   - new codes and new codelists will be introduced as necessary. Revisions of the codelists are generally published quarterly, and this is the primary means of adding new functionality to the release;
   - changes to schema and codelists will be discussed with ONIX National Groups, must be approved by the ONIX International Steering Committee – the primary governance body for the standard – and will be fully documented;
   - changes to the schema imply a new minor release or revision, depending on the scope of the additional functionality. Release 3.1 would be a minor release increment after 3.0, whereas 3.0.1 (also known as 3.0 revision 1) is a revision increment from 3.0 (more specifically, from 3.0.0). A new minor release would aim to retain a very high degree of forwards and backwards compatibility, but might introduce very limited incompatible changes – new mandatory elements or removal of deprecated elements, for example – into the schema where necessary to support new functionality. A new revision 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 revision, 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 revision);
     - full compatibility also implies that new revisions 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 revisions are unclear in their specification, and revisions may on occasion clarify the interpretation of existing data;
     - new minor releases are not fully back- and forward-compatible, but any breaking changes should be extremely limited in scope – for example, removal of rarely-used data elements;
     - another difference between a minor release and a revision is that revisions completely replace the equivalent earlier version in all respects, whereas minor releases retain separate identities (ie a minor revision is a separate development branch and thus has a separate development and support status). That is, for practical purposes, revision 3.0.1 no longer exists after release of 3.0.2, whereas 3.1 (or its latest revision) would still be maintained after release of 3.2;
   - 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 release increment after 3.x);
   - a new release (major or minor) usually implies the older release becomes ‘feature complete’;
2. Feature complete – the schema will not be extended, whether new requirements could be accommodated or not, except possibly to meet new legal requirements;
   - 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;
   - feature complete releases may be declared ‘legacy’ at any time, but normally only after a significant warning period;
3. Legacy (extended use) – the schema is frozen, and extensions, corrections, bugfixes and minor workarounds will not be developed;
   - new codes and codelists will not be added – except possibly as result of developing later releases 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);
     - such addition of new codes and codelists to legacy releases is termed ‘twilight support’;
     - some special consideration will be made for new codes required to meet legal obligations;
   - 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;
   - legacy releases may be declared ‘obsolete’ at any time, but normally only after several years of extended use;
   - continued long-term reliance on a legacy release must be viewed as a business risk, as data senders or recipients may cease support at any time;
4. Obsolete – no documentation or support available.

Note that none of these stages are defined by reference to a ‘current’ version of ONIX. At the time of writing, 3.1 is the latest release and is under active development, but both Release 2.1 and Release 3.0 remain ‘current’ in the sense that they are still in widespread use. However, 3.0 is ‘feature complete’ and 2.1 has reached the ‘obsolete’ phase of the lifecycle. Only ONIX 3.1 is recommended for new developments. No version of ONIX ‘stops working’ at any stage in this process – excepting that some recipients may simply refuse to accept data in an outdated version – but the model guides the orderly reduction in EDItEUR support effort for superseded versions and allows implementers to plan roadmaps and budget for future development.

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

- ONIX 3.1: active development, latest revision 3.1.2;
- ONIX 3.0: feature complete from end 2022, final revision 3.0.8;
- ONIX 2.1: obsolete from early 2023 (was legacy from end of 2014);
- 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 (the ‘sunset date’). 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 at the end of 2014, 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 for 2.1 ceased entirely after Issue 36 in January 2017 (‘midnight’).

ONIX release 3.0, first published in 2009 and revised in 2010 and in eight further revisions culminating in 3.0.8 in mid-2021, became feature complete at the beginning of 2023, when the decision to drop various deprecated elements and number the next version 3.1 was made.

At the time of writing, most ONIX senders and recipients, and most commercial software applications, support both ONIX 2.1 and ONIX 3.0. Some also support 3.1. There are still a few data recipients which accept only ONIX 2.1, despite there being important product attributes that cannot be adequately communicated in 2.1. However, an increasing number of ONIX recipients now accept only ONIX 3.0 or 3.1, 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 a supported version – 3.0 or, ideally, 3.1.

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 setting up 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 a standardized syntax and grammar (the underlying XML structure and ONIX tagging) and semantic consistency (standardizing the nature and meaning of the data to be included in each ‘column’ – or in each ONIX data element). Data suppliers should in principle be able to create a single data output process to feed all their supply chain partners. The content of a 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 or 3.1 and adding a new delivery address to a list of FTP sites. Partners need to:

1. agree the overall character set and encoding – ideally this would be Unicode and UTF-8;
2. 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);
3. agree the selection criteria for records to be included in the feed;
   - how far ahead should the scope extend for forthcoming products?
     - a minimum of around four months is likely to be typical (but a minimum of around six months in some national supply chains). It is best practice to ensure that all key data is available at least four months prior to publication;
     - there is usually some flexibility for later delivery (eg two months prior to publication) for a small number of drop-in products, or in digital and audio supply chains;
   - should the feed include solely physical print products, should it be e‑books or digital audio 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 (and used copy trading). Conversely, are products that are exclusive to the recipient included in the main ONIX file, or will their metadata be delivered separately?
   - should already-obsolete (ie out of print) products be included, for example to facilitate used book trading or to improve customer service?
     - it is common for the last ONIX update for a specific product to be supplied when that product is declared out of print;
4. 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?
   - if block-level updates, does this include granular, per-market Block 6 updates using <MarketReference>, which are unique to release 3.1?
5. 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;
   - it’s rare to require intra-day updates;
   - it is highly inefficient to send frequent updates consisting of only a single product record;
6. 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;
7. agree the file collection/delivery method, for example;
   - ‘push’ or ‘pull’ model for the ONIX message (ie use of a server controlled by the recipient, or by the sender);
     - pull requires regular polling of the pickup location by the data recipient, so push is usually more efficient and is the most common option;
   - requirements for secure authentication and data transfer;
   - file transfer protocol (eg relatively insecure FTP or HTTP, or more secure SFTP, FTPS, HTTPS…);
   - server address details and account credentials;
   - whether the files will be compressed (‘zipped’) or not;
   - the file naming convention used for the ONIX file;
     - consider including a date/time or sequence number within the filename so referencing a particular file will be unambiguous in the case of any future errors or issues (but recipients should always use the internal <SentDateTime> for ingestion processing);
8. 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 simple filename or a relative URI delivered in the ONIX message), ie a ‘pull’ or ‘push’ model for the collateral. For supporting resources, a pull model is the most common;
   - avoid a simple ISBN.jpg filenaming convention for such resources. At minimum, include something like ISBN-FC.jpg and ISBN-AP.jpg (for front covers and author photos respectively);
   - a convention like <RecordReference>-#.jpg – where # is a simple number for each unique resource for that particular product – can be useful, since the ONIX contains the necessary information about what the resource file contains;
   - the pull method can make it convenient for a recipient to rename the file to match any internal requirements as part of the download process;
   - in the rarer case of using a relative URI, agree the base URI to which it is relative in advance;
9. check the method used to embed any markup within certain data elements (XHTML markup, or HTML with either CDATA or escaping). XHTML is the most preferred, escaped HTML the least preferred method;
10. agree whether ongoing post-publication updates of price and availability will be provided as part of the ONIX data feed, or whether separate price and availability updates will be delivered using another method (eg via an X.12 or EDIFACT PRICAT message);
    - if using ONIX, confirm whether by full records (delta updates) or by partial (‘block’) updates, and if by block updates, can Market references (which are unique to 3.1) be used to make markets updateable individually;
11. discuss whether other data suppliers might also provide updates on the sender’s products (eg both a publisher and a distributor, or both domestic and overseas distributors, updating metadata for a particular product);
    - ensure the record- and product-matching criteria are well understood (eg shared Record references or – much better – unique Record references per sender and secondary matching based on the ISBN);
12. 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);
    - it is quite normal for recipients to ignore particular data elements that are not required by their business model - for example, if contributor biographies are unnecessary, a recipient will likely ignore <BiographicalNote> and <TextContent> with Text type code 12. However, some data elements should not be ignored as their value may modify the meaning of an element that is used. One example is <SalesRestriction> which can entirely change the meaning of its enclosing <SalesRights> composite;
    - in general, recipients who redistribute the data to other recipients should be particularly wary of ignoring any data elements;
13. 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;
14. 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;
15. 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 to eliminate them should be established and made public;
16. 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;
17. 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;
    - some organizations including BISG and BIC have produced guidelines for service levels within their specific markets which set out expectations for both senders and recipients;
18. agree on points of contact for routine liaison;
19. agree procedures for occasional emergency notification of required changes or product ‘takedowns’ (eg in response to legal or product safety issues);
20. deliver and process initial full feed and begin supplying updates as agreed.

On top of these considerations, senders and recipients should carefully consider the ongoing costs of developing a ‘bespoke’ ONIX feed for just one recipient. Ideally, a recipient should be able to accept the sender’s ‘normal’ ONIX feed, as sent by that sender to multiple recipients, and without any recipient-specific tailoring. Avoid bespoke or modified feeds wherever possible, except perhaps in terms of the selection of products included. Ensuring ONIX messages in a feed are all valid (using the classic or ‘strict’ XSD), and following documented best practices, decreases the need for bespoke variations.

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

A character encoding is a method of mapping individual characters to numbers that can be stored (in binary form) in a data file or exchanged between computers in a message. A character set is the repertoire of characters that a particular encoding allows you to use.

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). For encodings other than UTF-8 or -16, such declaration is required.

An XML file is essentially just text. Wherever possible, use native text characters in the encoding used by the message, and reserve the use of numerical character references for those characters that cannot – or at least cannot easily – be represented in that encoding. While any character can be incorporated into ONIX as a numerical character reference (eg &#65; in the data is a simple character A), independent of the message-level encoding used, this is not recommended for any character that’s easy to represent natively.

If your message uses an 8-bit encoding such as Windows-1252 or ISO Latin-1, there are likely to be many characters you wish to include in the message that cannot be represented natively. In this case, use a numerical character reference – ISO Latin-1 contains neither € nor ‘ and ’, so € is &#x20ac; and ‘ and ’ can be represented by &#x2018; and &#x2019. ISO Latin-9 (technically it’s ISO 8859-15) is similar: Latin-9 includes the € symbol natively, you lose the native fractions ¼, ½ and ¾, and you still need &#x2018; and &#x2019 for ‘ and ’.

Whichever encoding is used, a few hard-to-type characters may be incorporated more easily as numerical character references, one of the most common being &#160; or &#xa0; for a non-breaking space – though a native non-breaking space is perhaps better. On a Windows machine, a native non-breaking space can usually be typed as Alt+0160 (that is, hold down Alt and type 0160 on the numeric keypad), and on MacOS it is Option+Space or Shift+Option+Space.

Common issues with character sets and encodings:

- failing to declare the character encoding used in the XML declaration;
  - omitting the encoding means your message will be interpreted as if it is UTF‑8;
- declaring or implying (through omission of the declaration) that the message uses UTF‑8 or -16 when in fact it uses another encoding;
  - this will likely cause parsing errors when the recipient processes the file – the file may not even be openable;
- declaring the encoding as Windows-1252 when in fact the message uses Latin-1 (or similar);
  - this will likely cause unusual character combinations to appear in the file, particularly where non-ASCII characters are used;
- unnecessary use of numeric character references such as &#39; or &#x27; where a plain ' character would be fine;
- use of named character entities such as &hellip; or &ndash; – these are not valid in ONIX 3.0 or later (though they were valid in earlier releases of ONIX).

The ONIX Specification lists the basic range of characters that can be incorporated into an ONIX message without any special care. This list comprises the printable ASCII characters – with the exception of the ‘&’ and ‘<’ characters, which must be encoded as ‘&amp;’ and ‘&lt;’ when included in data. (Of course, they are used un-encoded, as ‘&’ and ‘<’, as part of the XML markup.) Space, tab, line feed and carriage return are also allowed.

Any characters beyond this basic set can be incorporated in ONIX data one of two ways, using either a suitable message-wide character encoding or a Unicode numerical character references. 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.)

What is a ‘character encoding’? It’s really a mapping between the binary numbers that are actually stored in a file and the text characters those numbers represent. In principle, a stored binary number could map to any character, but ‘Latin-1’ or ‘Windows‑1252’ are particular well-known mappings. They are very similar, but differ just a little – for example, while the binary number 01100001 maps to the character ‘a’ (lower case A) in both mappings, the number 10010011 maps to the ‘“’ character (open double quotes) using the Windows-1252 mapping and doesn’t map to anything at all in the Latin-1 mapping. So the same binary data file is interpreted differently depending on the mapping – the encoding – used.

The mapping also constrains the number of characters available. The Latin-1 and Windows-1252 mappings are mappings between 8-bit binary numbers and characters, so they can’t encode more than about 250 characters (that’s the highest you can count using only 8 binary digits). In practice, they encode about 190 or 220 characters respectively – the repertoire of characters in each is quite limited. Windows-1252 can’t be used to encode Russian or Chinese text, because the necessary characters just aren’t available. On the other hand, Latin-5 and Windows-1251 are different mappings that do include Cyrillic characters – but they lack a bunch of characters that are included in Latin-1 and Windows-1252.

Of course this means that the same binary number in a file can represent two entirely different characters, depending on which encoding is used. This is why it’s important to declare the encoding at the start of the ONIX XML file.

Unicode, in UTF-8, UTF-16 or UTF-32 encoded form, is (in principle) a mapping between 32-bit binary numbers and characters, and it encodes around 150,000 different characters, including Chinese, Japanese, Korean characters, symbols, emoji as well as more conventional ‘alphabetic’ characters in many different scripts. The repertoire of characters available is increasing as new revisions of the Unicode standard are released.

Each Unicode character has a 32-bit binary number, and the most basic encoding is to use that number in stored files or messages – that’s UTF-32. But this means that plain text files become very large, each character using four bytes (32 bits) 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).

It may be useful to think of a numerical character reference (such as &#xe9; = é) 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).

  encodings of the characters ‘é’, ‘ž’, ‘д’ and a non-breaking space
  desired character in metadata | é | ž | д | nbsp ¹
  --- | --- | --- | --- | ---
  numerical character reference | text in file
  decimal | `&#233;` | `&#382;` | `&#1076;` | `&#160;`
  hexadecimal | `&#xe9;` | `&#x17e;` | `&#x434;` | `&#xa0;`
  native character | binary data in file (in hexadecimal)
  UTF-8 | `c3 a9` | `c5 be` | `d0 b4` | `c2 a0`
  UTF-16LE | `e9 00` | `7e 01` | `34 04` | `a0 00`
  UTF-16BE | `00 e9` | `01 7e` | `04 34` | `00 a0`
  Latin-1 (ISO 8859-1) | `e9` | — ² | — | `a0`
  Latin-9 (ISO 8859-15) | `e9` | `b8` | — | `a0`
  Windows-1251 | — | — | `e4` | `a0`
  Windows-1252 | `e9` | `9e` | — | `a0`
  MacRoman | `8e` | — | — | `ca`
  named character entity | text in file
  (not valid in ONIX 3.0, used in 2.1) | `&eacute;` | `&zcaron;` | `&dcy;` | `&nbsp;`

  ¹ non-breaking space – a space that prevents an automatic line break at that position when text is wrapped into lines
  ² 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 of characters) and UTF‑8 (a way of encoding the characters in that set as sequences of numbers that can be stored in a data file or transmitted to another computer), 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 they 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 use one of four ‘normalization’ forms. ONIX messages are almost always in ‘NFC’ normalization form – this is the strongly recommended normalization form for data senders – and normalization can usually be ignored. Very occasionally, something other than NFC can cause unpredictable – and often quite hard to diagnose – issues.

  Normalization concerns whether, for example, the character é is encoded as a single character é (that’s c3 a9, two bytes of UTF‑8 hexadecimal data), or as two characters, a conventional e followed by the acute accent ´ (that’s 65 cc 81 in UTF‑8, three bytes of hexadecimal data, with 65 representing a conventional e and cc 81 being the combining acute accent character). Diacritics and other so-called ‘combining characters’ can be ‘precomposed’ (combined with the character they modify, like é), or decomposed (supplied as separate characters, like e followed by ´). It also concerns whether characters like ﬁ (the fi ligature ¹) can be used, or whether it is decomposed into its separate but compatible f and i characters. These two choices give the four possible normalization forms:

    Desired character | é | ﬁ ¹
    --- | --- | ---
    | binary data in file (in hexadecimal)
    UTF‑8 NFC | `c3 a9` | `ef ac 81`
    UTF‑8 NFD | `65 cc 81` | `ef ac 81`
    UTF‑8 NFKC | `c3 a9` | `— ²`
    UTF‑8 NFKD | `65 cc 81` | `—`

    ¹ the difference between ﬁ (the ligature) and fi may not be apparent, but the first is a single character – on-screen, try selecting just the f…. This is a special case of Unicode character compatibility. More generally, the question can be whether ‘𝓉𝒽𝒾𝓈’ should be normalized to ‘this’ – these are compatible, even if they aren’t homographs in the way that é and e followed by a combining acute are.

    ² dash indicates the character cannot be represented in this normalization form.

    For more information on Unicode normalization see https://unicode.org/reports/tr15/.

  Data recipients should not entirely rely on Unicode text being supplied in any particular normalization form. Typically it will be supplied in NFC (where both é and ﬁ are single characters), but if it proves necessary, any particular normalization form can be converted to any other. Note however that the conversions are not always perfectly reversible.

  ONIX senders may wish to retain – and recipients might even 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 and exchanging ONIX data in NFC form.

  A very rare issue encountered with ONIX data is where parts of an ONIX message are NFC and parts are another normalization form. The normalization form should be NFC throughout the message file.

If the declared encoding fails to match the actual encoding used for a message, the data (particularly text) may appear garbled when processed or displayed by the ONIX recipient.

  sent – `<PersonName>Marie-Adélaïde Barthélemy-Hadot</PersonName>`
  received – `<PersonName>Marie-AdÃ©laÃ¯de BarthÃ©lemy-Hadot</PersonName>`

Certain combinations of declared and actual encodings may render the ONIX file unusable.

#### A.7 How many characters is ‘&#x064a;’?

One, or eight?

Many ONIX data fields have suggested limits on their length. For example, the suggested maximum length of data in the <PersonName> field is ‘100 characters’. This appendix concerns the relationship between characters in the message and the number of bytes of data in that message or the number of bytes of storage space required to store the ONIX data.

100 characters in the ONIX message is not the same as 100 bytes of data in the message or 100 bytes of storage in a database.

1. The number of bytes of message data or storage required to hold 100 characters of text depends on the way the text is encoded as it is sent or stored. If the text was sent or stored while encoded as Unicode UTF-8, then the byte size is dependent on the repertoire of characters used – 100 characters of plain English text (ie of basic characters from the Latin alphabet) might be sent or stored in 100 bytes, each Latin character requiring one byte of message data or storage space. But 100 characters of French text might require 120 or 130 bytes, because Latin characters with accents (à, é, î etc) mostly require two bytes of storage when encoded as UTF-8. Similarly, 100 characters of Arabic text generally requires at least 200 bytes of message data or storage space in UTF-8 because every letter from the Arabic alphabet requires two (or occasionally three) bytes in UTF-8. The exact amount of message data or storage space required is somewhat unpredictable.

   In contrast, if the same 100 characters of English, French or Arabic text were stored as Unicode using UTF-32 encoding, all versions would require exactly 400 bytes of storage. UTF-32 requires 4 bytes per character. In effect, UTF-8 uses clever data compression to reduce the storage space required compared with UTF-32.

   And if the same text was sent or stored while encoded as Latin-1, Latin-9 or Windows-1252 (see the previous Appendix), then basic English and French text would require exactly 100 bytes each, since all characters are represented by one byte, including à, é and î which would otherwise require two bytes in UTF-8. However, Arabic text cannot be sent or stored in this way at all – the repertoire of characters available in these encodings does not include any Arabic characters at all. Latin-1, Latin-9, Windows-1252 are more efficient in their use of storage space, but at the expense of a limited repertoire of around 200 different characters.

   So if you choose to send or store some text in the Latin-9 encoding, how can you include a single Arabic letter? Well, in one sense you can't, because the Arabic character is not present in the Latin-9 encoding. But in another, you can, using a numerical character reference – the letter ‘ي’ (yeh, the last letter of the Arabic alphabet in hija’i order – when it’s used for sorting lists of names or book titles) can be encoded as ‘&#x064a;’ – but this requires 8 (Latin) characters to represent one (Arabic) character, and therefore at least 8 bytes of message data or storage space in a Latin-1, Latin-9 or Windows-1252-based system. The ampersand character (or in some circumstances the five characters representing an ampersand – see 2. below), the hash, the x, the zero and so on are all stored as individual characters, even though taken together they represent only one Arabic character. This means that 100 Arabic characters might require nearly a kilobyte of storage space if stored this way (though doing so would be a very poor technical choice). NB Chinese, Japanese, Korean characters can require even more space when encoded and stored in this way. Beyond Latin-based texts, Unicode UTF-8 or even UTF-32 encoding tends to be much more efficient than using numerical character references in terms of message data or storage bytes.

   Therefore, even though many ONIX textual fields have recommended character length limits, recipients need to calculate the size of database fields according to the way their database encodes text. And data received needs to be switched from the encoding used in the ONIX message to the encoding used within the database. ‘&#x064a;’ counts as one character in an ONIX message, but the storage required can vary from two to at least 8 bytes and possibly more, depending on exactly how it’s stored;

2. When calculating exact storage sizes, you might also need to take into account how you store &amp; and &lt; – as the native characters & and < in whatever encoding you’re using, or as named character entities requiring four or five characters-worth of space. This might depend on whether you are storing an & used as an ampersand or less than symbol used within textual data, or an ampersand as part of a named character entity or numerical character reference, or a < as part of a markup tag;

3. And if you are using Unicode, the normalization form will make a difference – an é character in the data is represented differently in NFC (the recommended normalization form in ONIX) and NFD – specifically, UTF-8 NFC requires two bytes, UTF-8 NFD requires three.

   See https://unicode.org/reports/tr15/ for in-depth information on Unicode normalization;

4. Some ONIX fields that have a recommended maximum length can also include (X)HTML markup (see the following Appendix).

   So how many characters is ‘<strong>bestseller</strong>’? Ten (‘bestseller’) or 27 (including the characters used for markup)?

   In general, ONIX counts the (X)HTML markup within an ONIX data field as part of the data, as it lies between two ONIX XML tags. Thus the answer should be 27. On the other hand, characters are typically perceivable characters (é is one perceivable character, even if sent or stored in a Unicode normalization form that decomposes it into ´ and e). So maybe the answer should be ten, because in some circumstances the markup is not perceivable. Unfortunately, this was not well-defined in earlier versions of ONIX, was rarely considered carefully by either data senders or recipients, and frequently caused issues with Short descriptions (one of the many options in <TextContent>). Short descriptions have a hard limit (not just a recommended maximum) of 350 characters defined in the Specification, but it’s common for Short descriptions to exceed this 350 character limit when they contain markup.

   So – from ONIX 3.1 – for the purposes of suggested and hard character limits, limits are defined as not counting the characters of the markup (ie for ONIX 3.1 and later, the answer to the question, how many characters is ‘<strong>bestseller</strong>’, is definitely ten). Data recipients should ensure they can accept and store Short descriptions where the character length of the data significantly exceeds 350 characters (when counting the markup), but senders must ensure the number of non-markup characters does not exceed 350.

   For earlier versions of ONIX, and to avoid the possibility of truncating or rejecting fields where (X)HTML markup is included, data recipients are encouraged to be very generous with the text length they accept, particularly for Short descriptions but also for other data that might contain (X)HTML markup. Conversely, data senders are strongly encouraged to avoid exceeding recommended length limits including the length of the markup.

5. As an aside, emoji also form a part of the Unicode system. The grinning face 😀 and palm tree emoji 🌴 are single characters &#x1f600; and &#x1f334; respectively. Some other emoji are encoded as two or more consecutive characters, a base emoji character and one or more modifiers – for example 👩🏽 is composed from a simple woman emoji 👩 (&#x1f469;) followed by a modifier character &#x1f3fd;, and the Union Flag 🇬🇧 is composed of &#x1f1ec; plus the &#x1f1e7; modifier. Note that these emoji modifiers remain separate Unicode codepoints even with NFC normalization – unlike the superficially similar combining diacritics. Use of emoji in ONIX is not recommended, as they are not supported by all databases (even those that otherwise support Unicode text), they cause issues for recipients who do not use Unicode, recently-added emoji cannot be displayed by all recipients, and they can sometimes represent an accessibility issue: follow the guidelines provided by readabilityguidelines.co.uk.

#### A.8 Reference list of allowed HTML / XHTML tags

The ONIX 3.1 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.1 XSD and RNG schemas. However, while the Specification allows a long list of XHTML tags, it is strongly recommended that XHTML markup is limited to a simple subset of tags.

The same textual data elements can also contain HTML tags (use textformat="02"). These require special treatment to prevent them making the overall ONIX file invalid – either the use of CDATA or replacement of the < character in HTML markup with &lt;. CDATA is preferred. Note that the structure of the HTML tags will not be validated – since HTML is not XML, it cannot be validated, and the whole point of CDATA or of escaping the < character is to ‘hide’ the non-XML markup from the validation process. However, it is strongly recommended that any HTML markup be limited to the same simple subset of tags.

Recommended tags

  It is strongly recommended that HTML and XHTML tags are limited to this small set
  paragraphs and line breaks | `<p>` | `<br>` (in HTML) or `<br />` (in XHTML)
  emphasis | `<strong>` | `<em>` | `<b>` | `<i>`
  book titles | `<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"><em>This is <strong>incorrect​</strong>, as the outermost tags are not block level.</em></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 that <cite> has been included in this recommended subset of HTML because of its importance in highlighting book titles within descriptions, biographies etc.

  In HTML, using <br> without a trailing / character is the current recommendation, but modern browsers will still cope with <br />. In XHTML, you must always include the trailing slash.

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, and some are invalid in HTML5.

  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.9 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>` | `<NumberOfCopies>`
  `<EditionNumber>` | `<NumberOfItemsOfThisForm>`
  `<EventNumber>` | `<NumberOfPages>`
  `<FreeQuantity>` | `<OrderQuantityMinimum>`
  `<LatestReprintNumber>` | `<OrderQuantityMultiple>`
  `<MapScale>` | `<PackQuantity>`
  `<MessageNumber>` | `<PalletQuantity>`
  `<MessageRepeat>` | `<PositionOnList>`
  `<MinimumOrderQuantity>` | `<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>` |

  Note that real numbers in XML must use the period character ‘.’ as the decimal separator, not a comma or mid-dot.

#### A.10 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:

- `<MainAudience/>`
- `<MainSubject/>`
- `<NoCollection/>`
- `<NoContributor/>`
- `<NoEdition/>`
- `<NoPrefix/>`
- `<NoProduct/>`
- `<NoResource/>`
- `<NoSupplement/>`
- `<PrimaryPart/>`
- `<TaxExempt/>`

In addition, the following five blocks may be empty, but in block updates only, where the intent is to ‘delete’ all metadata previously sent in that block:

- `<CollateralDetail/>` (Block 2)
- `<PromotionDetail/>` (Block 7)
- `<ContentDetail/>` (Block 3)
- `<RelatedMaterial/>` (Block 5)
- `<ProductionDetail/>` (Block 8)

As a special case, and again in block updates only, <ProductSupply> (Block 6) may be effectively empty when it contains only a <MarketReference>.

In full records, any ‘empty’ block must be omitted entirely.

  Although they are synonymous in XML, the shorthand <MainSubject/> form is generally preferred over <MainSubject></MainSubject> for empty tags and blocks.

#### A.11 Reference list of deprecations

The following ONIX XML tags are deprecated in Release 3.1.

- `<DefaultCurrencyCode>`
- `<DefaultLanguageOfText>`
- `<DefaultPriceType>`
- `<TitleText>` ¹

Deprecated elements and composites are subject to removal from the next release of ONIX for Books.

Whenever possible, the deprecated elements and composites should not be used in new implementations of ONIX 3.1 (wherever possible including migrations from any version of ONIX 3.0), and users of existing implementations should avoid their continued long-term use and replace them with preferred (non-deprecated) alternatives as quickly as is practicable. For each of the above, the currency, language of text and price types should instead be specified explicitly within each Product record.

¹ deprecated except in cases where the language of the title does not use explicit definite or indefinite articles (eg Swedish), or where national practice is to include these articles for alphabetic sorting purposes.

#### A.12 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. Each XPath selects a block, a large or small composite, or an individual data element.

It is a feature of ONIX that some elements and composite structures can occur at many different 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, its ‘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. The XPath for <ProductIdentifier> in Group P.2 is different from the XPath for <ProductIdentifier> in Group P.4.

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. A generic [ ] is used in the table to indicate repeating composites and data elements that are likely to need predication. For example, the XPath for the <Date> element within the <PublishingDate> composite is `/ONIXMessage/​Product[]/​PublishingDetail/​PublishingDate/Date`, but multiple repeats of the <PublishingDate> 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 of a product, the predicated path `/ONIXMessage/​Product[]/​PublishingDetail/​PublishingDate[PublishingDateRole eq '01']/​Date` is required (note the predicate for Product[ ] is omitted here, but must be inserted to select a specific product within an ONIX file). Further processing based on the date format in any dateformat attribute 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 of a specific product (assuming it is present, and using the Contributor sequence number rather than the order of data elements in the XML file) would have a predicate to select a product, a second to select a single contributor to that product, 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 here do not target a particular Product record: if there are multiple products in an ONIX message, a further predicate would be required to target a specific Product record in the message, for example `/ONIXMessage/​Product[3]` to select the third Product record in a message.

A handful of the 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. The XPaths are listed with Reference name tags (long tags) only.

  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.5a | `. . . <TelephoneNumber>` | `/ONIXMessage/​Header/​Sender/​TelephoneNumber`
  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.11a | `. . . <TelephoneNumber>` | `/ONIXMessage/​Header/​Addressee[]/​TelephoneNumber`
  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`
  ○ | `. . <RecordSource​Identifier>` | `/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[]`
  ○ | `. . . <ProductForm​Feature>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductFormFeature[]`
  P.3.4 | `. . . . <ProductForm​FeatureType>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductFormFeature[]/​ProductFormFeatureType`
  P.3.5 | `. . . . <ProductForm​FeatureValue>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductFormFeature[]/​ProductFormFeatureValue`
  P.3.6 | `. . . . <ProductForm​Feature​Description>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductFormFeature[]/​ProductFormFeatureDescription[]`
  P.3.7 | `. . . <ProductPackaging>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductPackaging`
  P.3.8 | `. . . <ProductForm​Description>` | `/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 | `. . . <CountryOf​Manufacture>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​CountryOfManufacture`
  P.3.16 | `. . . <EpubTechnical​Protection>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​EpubTechnicalProtection[]`
  ○ | `. . . <EpubUsage​Constraint>` | `/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[]`
  ○ | `. . . . <EpubLicense​Expression>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​EpubLicense[]/​EpubLicenseExpression[]`
  P.3.20b | `. . . . . <EpubLicense​ExpressionType>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionType`
  P.3.20c | `. . . . . <EpubLicense​Expression​TypeName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionTypeName`
  P.3.20d | `. . . . . <EpubLicense​ExpressionLink>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionLink`
  ○ | `. . . . <EpubLicense​Date>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​EpubLicense[]/​EpubLicenseDate[]`
  P.3.20e | `. . . . . <EpubLicense​DateRole>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​EpubLicense[]/​EpubLicenseDate[]/​EpubLicenseDateRole`
  P.3.20f | `. . . . . <Date>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​EpubLicense[]/​EpubLicenseDate[]/​Date`
  P.3.21 | `. . . <MapScale>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​MapScale[]`
  ○ | `. . . <ProductClassification>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductClassification[]`
  P.3.22 | `. . . . <ProductClassification​Type>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductClassification[]/​ProductClassificationType`
  P.3.22a | `. . . .<ProductClassification​TypeName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductClassification[]/​ProductClassificationTypeName`
  P.3.23 | `. . . . <ProductClassification​Code>` | `/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[]/​ProductIDType`
  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[]`
  ○ | `. . . . <ProductForm​Feature>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductPart[]/​ProductFormFeature[]`
  P.4.7 | `. . . . . <ProductForm​FeatureType>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductPart[]/​ProductFormFeature[]/​ProductFormFeatureType`
  P.4.8 | `. . . . . <ProductFormF​eatureValue>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductPart[]/​ProductFormFeature[]/​ProductFormFeatureValue`
  P.4.9 | `. . . . . <ProductForm​FeatureDescription>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductPart[]/​ProductFormFeature[]/​ProductFormFeatureDescription`
  P.4.9a | `. . . . <ProductPackaging>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductPart[]/​ProductPackaging`
  P.4.10 | `. . . . <ProductForm​Description>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductPart[]/​ProductFormDescription[]`
  P.4.11 | `. . . . <ProductContentType>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductPart[]/​ProductContentType[]`
  ○ | `. . . . <Measure>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductPart[]/​Measure[]`
  P.4.11a | `. . . . . <MeasureType>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductPart[]/​Measure[]/​MeasureType`
  P.4.11b | `. . . . . <Measurement>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductPart[]/​Measure[]/​Measurement`
  P.4.11c | `. . . . . <MeasureUnitCode>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ProductPart[]/​Measure[]/​MeasureUnitCode`
  P.4.12 | `. . . . <NumberOfItems​OfThisForm>` | `/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.1a | `. . . . <CollectionFrequency>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​CollectionFrequency`
  P.5.2 | `. . . . <SourceName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​SourceName`
  ○ | `. . . . <CollectionIdentifier>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​CollectionIdentifier[]`
  P.5.2a | `. . . . . <CollectionElementLevel>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​CollectionIdentifier[]/​CollectionElementLevel`
  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 | `. . . . . <CollectionSequence​Type>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​CollectionSequence[]/​CollectionSequenceType`
  P.5.5b | `. . . . . <CollectionSequence​TypeName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​CollectionSequence[]/​CollectionSequenceTypeName`
  P.5.5c | `. . . . . <CollectionSequence​Number>` | `/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 | `. . . . . <PersonName​Inverted>` | `/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.32 | `. . . . . <CorporateName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​CorporateName[]`
  P.5.33 | `. . . . . <CorporateName​Inverted>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​CorporateNameInverted[]`
  P.5.33a | `. . . . . <UnnamedPersons>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​UnnamedPersons`
  ○ | `. . . . . <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 | `. . . . . . <PersonName​Inverted>` | `/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.48 | `. . . . . . <CorporateName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​AlternativeName[]/​CorporateName[]`
  P.5.49 | `. . . . . . <CorporateName​Inverted>` | `/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.52 | `. . . . . . <Date>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​ContributorDate[]/​Date`
  ○ | `. . . . . <Professional​Affiliation>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​ProfessionalAffiliation[]`
  P.5.53 | `. . . . . . <Professional​Position>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​ProfessionalAffiliation[]/​ProfessionalPosition[]`
  ○ | `. . . . . . <Affiliation​Identifier>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]`
  P.5.53a | `. . . . . . . <Affiliation​IDType>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​AffiliationIDType`
  P.5.53b | `. . . . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​IDTypeName`
  P.5.53c | `. . . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​IDValue`
  P.5.54 | `. . . . . . <Affiliation>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​ProfessionalAffiliation[]/​Affiliation`
  ○ | `. . . . . <Prize>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​Prize[]`
  P.5.54a | `. . . . . . <SequenceNumber>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​Prize[]/​SequenceNumber`
  ○ | `. . . . . . <PrizeIdentifier>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​Prize[]/​PrizeIdentifier[]`
  P.5.54b | `. . . . . . . <PrizeIDType>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​Prize[]/​PrizeIdentifier[]/​PrizeIDType`
  P.5.54c | `. . . . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​Prize[]/​PrizeIdentifier[]/​IDTypeName`
  P.5.54d | `. . . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​Prize[]/​PrizeIdentifier[]/​IDValue`
  P.5.54e | `. . . . . . <PrizeName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​Prize[]/​PrizeName[]`
  P.5.54f | `. . . . . . <PrizeYear>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​Prize[]/​PrizeYear`
  P.5.54g | `. . . . . . <AwardingBody>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​Prize[]/​AwardingBody[]`
  P.5.54h | `. . . . . . <PrizeCountry>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​Prize[]/​PrizeCountry`
  P.5.54i | `. . . . . . <PrizeRegion>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​Prize[]/​PrizeRegion`
  P.5.54j | `. . . . . . <PrizeCode>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​Prize[]/​PrizeCode`
  P.5.54k | `. . . . . . <PrizeStatement>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​Prize[]/​PrizeStatement[]`
  P.5.54l | `. . . . . . <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 | `. . . . . <Contributor​Description>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​ContributorDescription[]`
  ○ | `. . . . . <ContributorPlace>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​Contributor[]/​ContributorPlace[]`
  P.5.61 | `. . . . . . <ContributorPlace​Relator>` | `/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 | `. . . . <Contributor​Statement>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Collection[]/​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 | `. . . . <PersonName​Inverted>` | `/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.19 | `. . . . <CorporateName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​CorporateName[]`
  P.7.20 | `. . . . <CorporateName​Inverted>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​CorporateNameInverted[]`
  P.7.20a | `. . . . <UnnamedPersons>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​UnnamedPersons`
  ○ | `. . . . <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 | `. . . . . <PersonName​Inverted>` | `/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.35 | `. . . . . <CorporateName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​AlternativeName[]/​CorporateName[]`
  P.7.36 | `. . . . . <CorporateName​Inverted>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​AlternativeName[]/​CorporateNameInverted[]`
  ○ | `. . . . <ContributorDate>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​ContributorDate[]`
  P.7.37 | `. . . . . <Contributor​DateRole>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​ContributorDate[]/​ContributorDateRole`
  P.7.39 | `. . . . . <Date>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​ContributorDate[]/​Date`
  ○ | `. . . . <Professional​Affiliation>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​ProfessionalAffiliation[]`
  P.7.40 | `. . . . . <Professional​Position>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​ProfessionalAffiliation[]/​ProfessionalPosition[]`
  ○ | `. . . . . . <Affiliation​Identifier>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]`
  P.7.40a | `. . . . . . . <AffiliationIDType>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​AffiliationIDType`
  P.7.40b | `. . . . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​IDTypeName`
  P.7.40c | `. . . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​IDValue`
  P.7.41 | `. . . . . <Affiliation>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​ProfessionalAffiliation[]/​Affiliation`
  ○ | `. . . . <Prize>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​Prize[]`
  P.7.41a | `. . . . . <SequenceNumber>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​Prize[]/​SequenceNumber`
  ○ | `. . . . . <PrizeIdentifier>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​Prize[]/​PrizeIdentifier[]`
  P.7.54b | `. . . . . . <PrizeIDType>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​Prize[]/​PrizeIdentifier[]/​PrizeIDType`
  P.7.54c | `. . . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​Prize[]/​PrizeIdentifier[]/​IDTypeName`
  P.7.54d | `. . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​Prize[]/​PrizeIdentifier[]/​IDValue`
  P.7.41b | `. . . . . <PrizeName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​Prize[]/​PrizeName[]`
  P.7.41c | `. . . . . <PrizeYear>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​Prize[]/​PrizeYear`
  P.7.41d | `. . . . . <AwardingBody>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​Prize[]/​AwardingBody[]`
  P.7.41e | `. . . . . <PrizeCountry>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​Prize[]/​PrizeCountry`
  P.7.41f | `. . . . . <PrizeRegion>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​Prize[]/​PrizeRegion`
  P.7.41g | `. . . . . <PrizeCode>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​Prize[]/​PrizeCode`
  P.7.41h | `. . . . . <PrizeStatement>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​Prize[]/​PrizeStatement[]`
  P.7.41i | `. . . . . <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 | `. . . . <Contributor​Description>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​ContributorDescription[]`
  ○ | `. . . . <ContributorPlace>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Contributor[]/​ContributorPlace[]`
  P.7.48 | `. . . . . <ContributorPlace​Relator>` | `/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/​ContributorStatement[]`
  P.7.52 | `. . . <NoContributor/>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NoContributor`
  ○ | `. . . <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[]`
  ○ | `. . . . . <EventSponsor​Identifier>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Event[]/​EventSponsor[]/​EventSponsorIdentifier[]`
  P.8.23 | `. . . . . . <EventSponsor​IDType>` | `/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 | `. . . <EditionVersion​Number>` | `/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 | `. . . . . <BibleText​Organization>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ReligiousText/​Bible/​BibleTextOrganization`
  P.9.11 | `. . . . . <BibleReference​Location>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ReligiousText/​Bible/​BibleReferenceLocation`
  P.9.12 | `. . . . . <BibleTextFeature>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ReligiousText/​Bible/​BibleTextFeature[]`
  P.9.13 | `. . . . <ReligiousText​Identifier>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ReligiousText/​ReligiousTextIdentifier`
  ○ | `. . . . <ReligiousText​Feature>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ReligiousText/​ReligiousTextFeature[]`
  P.9.14 | `. . . . . <ReligiousText​FeatureType>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ReligiousText/​ReligiousTextFeature[]/​ReligiousTextFeatureType`
  P.9.15 | `. . . . . <ReligiousText​FeatureCode>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​ReligiousText/​ReligiousTextFeature[]/​ReligiousTextFeatureCode`
  P.9.16 | `. . . . . <ReligiousText​Feature​Description>` | `/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 | `. . . . <AncillaryContent​Type>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​AncillaryContent[]/​AncillaryContentType`
  P.11.9 | `. . . . <AncillaryContent​Description>` | `/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 | `. . . . <PersonName​Inverted>` | `/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.21 | `. . . . <CorporateName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​CorporateName[]`
  P.12.22 | `. . . . <CorporateName​Inverted>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​CorporateNameInverted[]`
  ○ | `. . . . <AlternativeName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]`
  P.12.23 | `. . . . . <NameType>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​NameType`
  ○ | `. . . . . <NameIdentifier>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​NameIdentifier[]`
  P.12.24 | `. . . . . . <NameIDType>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​NameIdentifier[]/​NameIDType`
  P.12.25 | `. . . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​NameIdentifier[]/​IDTypeName`
  P.12.26 | `. . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​NameIdentifier[]/​IDValue`
  P.12.27 | `. . . . . <PersonName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​PersonName`
  P.12.28 | `. . . . . <PersonName​Inverted>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​PersonNameInverted`
  P.12.29 | `. . . . . <TitlesBeforeNames>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​TitlesBeforeNames`
  P.12.30 | `. . . . . <NamesBeforeKey>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​NamesBeforeKey`
  P.12.31 | `. . . . . <PrefixToKey>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​PrefixToKey`
  P.12.32 | `. . . . . <KeyNames>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​KeyNames`
  P.12.33 | `. . . . . <NamesAfterKey>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​NamesAfterKey`
  P.12.34 | `. . . . . <SuffixToKey>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​SuffixToKey`
  P.12.35 | `. . . . . <LettersAfterNames>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​LettersAfterNames`
  P.12.36 | `. . . . . <TitlesAfterNames>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​TitlesAfterNames`
  P.12.37 | `. . . . . <CorporateName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​CorporateName[]`
  P.12.38 | `. . . . . <CorporateName​Inverted>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​AlternativeName[]/​CorporateNameInverted[]`
  ○ | `. . . . <SubjectDate>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​SubjectDate[]`
  P.12.39 | `. . . . . <SubjectDateRole>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​SubjectDate[]/​SubjectateRole`
  P.12.41 | `. . . . . <Date>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​SubjectDate[]/​Date`
  ○ | `. . . . <Professiona​lAffiliation>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​ProfessionalAffiliation[]`
  P.12.42 | `. . . . . <Professional​Position>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​ProfessionalAffiliation[]/​ProfessionalPosition[]`
  ○ | `. . . . . <Affiliation​Identifier>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]`
  P.12.42a | `. . . . . . <AffiliationIDType>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​AffiliationIDType`
  P.12.42b | `. . . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​IDTypeName`
  P.12.42c | `. . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​IDValue`
  P.12.43 | `. . . . . <Affiliation>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​NameAsSubject[]/​ProfessionalAffiliation[]/​Affiliation`
  ○ | `. . . <Audience>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Audience[]`
  P.13.1a | `. . . . <MainAudience/>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Audience[]/​MainAudience`
  P.13.2 | `. . . . <AudienceCodeType>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Audience[]/​AudienceCodeType`
  P.13.3 | `. . . . <AudienceCodeTypeName>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Audience[]/​AudienceCodeTypeName`
  P.13.4 | `. . . . <AudienceCodeValue>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Audience[]/​AudienceCodeValue`
  P.13.4a | `. . . . <AudienceHeadingText>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Audience[]/​AudienceHeadingText[]`
  ○ | `. . . <AudienceRange>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​AudienceRange[]`
  P.13.5 | `. . . . <AudienceRange​Qualifier>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​AudienceRange[]/​AudienceRangeQualifier`
  P.13.6 | `. . . . <AudienceRange​Precision>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​AudienceRange[]/​AudienceRangePrecision[not(exists(preceding-sibling::AudienceRangePrecision))]`
  P.13.7 | `. . . . <AudienceRange​Value>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​AudienceRange[]/​AudienceRangeValue[not(exists(preceding-sibling::AudienceRangeValue))]`
  P.13.8 | `. . . . <AudienceRange​Precision>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​AudienceRange[]/​AudienceRangePrecision[exists(preceding-sibling::AudienceRangePrecision)]`
  P.13.9 | `. . . . <AudienceRange​Value>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​AudienceRange[]/​AudienceRangeValue[exists(preceding-sibling::AudienceRangeValue)]`
  P.13.10 | `. . . <AudienceDescription>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​AudienceDescription[]`
  ○ | `. . . <Complexity>` | `/ONIXMessage/​Product[]/​DescriptiveDetail/​Complexity[]`
  P.13.11 | `. . . . <ComplexityScheme​Identifier>` | `/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 | `. . . . <SequenceNumber>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​SequenceNumber`
  P.14.1a | `. . . . <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 | `. . . . <TextSource​Corporate>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​TextSourceCorporate`
  P.14.5a | `. . . . <TextSource​Description>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​TextSourceDescription[]`
  P.14.6 | `. . . . <SourceTitle>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​SourceTitle[]`
  P.14.6a | `. . . . <TextSourceLink>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​TextSourceLink[]`
  ○ | `. . . . <EpubUsage​Constraint>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​EpubUsageConstraint[]`
  P.14.6b | `. . . . . <EpubUsage​Type>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​EpubUsageConstraint[]/​EpubUsageType`
  P.14.6c | `. . . . . <EpubUsage​Status>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​EpubUsageConstraint[]/​EpubUsageStatus`
  ○ | `. . . . . <EpubUsage​Limit>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​EpubUsageConstraint[]/​EpubUsageLimit[]`
  P.14.6d | `. . . . . . <Quantity>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​EpubUsageConstraint[]/​EpubUsageLimit[]/​Quantity`
  P.14.6e | `. . . . . . <EpubUsage​Unit>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​EpubUsageConstraint[]/​EpubUsageLimit[]/​EpubUsageUnit`
  ○ | `. . . . <EpubLicense>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​EpubLicense[]`
  P.14.6f | `. . . . . <EpubLicenseName>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​EpubLicense[]/​EpubLicenseName[]`
  ○ | `. . . . . <EpubLicense​Expression>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​EpubLicense[]/​EpubLicenseExpression[]`
  P.14.6g | `. . . . . . <EpubLicense​Expression​Type>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionType`
  P.14.6h | `. . . . . . <EpubLicense​Expression​TypeName>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionTypeName`
  P.14.6i | `. . . . . . <EpubLicense​Expression​Link>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionLink`
  ○ | `. . . . . <EpubLicense​Date>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​EpubLicense[]/​EpubLicenseDate[]`
  P.14.6j | `. . . . . . <EpubLicense​DateRole>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​EpubLicense[]/​EpubLicenseDate[]/​EpubLicenseDateRole`
  P.14.6k | `. . . . . . <Date>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​EpubLicense[]/​EpubLicenseDate[]/​Date`
  ○ | `. . . . <ContentDate>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​ContentDate[]`
  P.14.7 | `. . . . . <ContentDateRole>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​ContentDate[]/​ContentDateRole`
  P.14.9 | `. . . . . <Date>` | `/ONIXMessage/​Product[]/​CollateralDetail/​TextContent[]/​ContentDate[]/​Date`
  ○ | `. . . <CitedContent>` | `/ONIXMessage/​Product[]/​CollateralDetail/​CitedContent[]`
  P.15.1 | `. . . . <SequenceNumber>` | `/ONIXMessage/​Product[]/​CollateralDetail/​CitedContent[]/​SequenceNumber`
  P.15.1a | `. . . . <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.11 | `. . . . . <Date>` | `/ONIXMessage/​Product[]/​CollateralDetail/​CitedContent[]/​ContentDate[]/​Date`
  ○ | `. . . <SupportingResource>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]`
  P.16.1 | `. . . . <SequenceNumber>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​SequenceNumber`
  P.16.1a | `. . . . <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 | `. . . . . <ResourceFeature​Type>` | `/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`
  ○ | `. . . . . <ResourceVersion​Feature>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ResourceVersion[]/​ResourceVersionFeature[]`
  P.16.8 | `. . . . . . <ResourceVersion​FeatureType>` | `/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[]`
  ○ | `. . . . . <EpubUsage​Constraint>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]`
  P.16.11a | `. . . . . . <EpubUsageType>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]/​EpubUsageType`
  P.16.11b | `. . . . . . <EpubUsageStatus>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]/​EpubUsageStatus`
  ○ | `. . . . . . <EpubUsage​Limit>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]/​EpubUsageLimit[]`
  P.16.11c | `. . . . . . . <Quantity>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]/​EpubUsageLimit[]/​Quantity`
  P.16.11d | `. . . . . . . <EpubUsageUnit>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]/​EpubUsageLimit[]/​EpubUsageUnit`
  ○ | `. . . . . <Epub​License>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]`
  P.16.11e | `. . . . . . <EpubLicense​Name>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseName[]`
  ○ | `. . . . . . <EpubLicense​Expression>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseExpression[]`
  P.16.11f | `. . . . . . . <EpubLicense​ExpressionType>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionType`
  P.16.11g | `. . . . . . . <EpubLicense​Expression​TypeName>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionTypeName`
  P.16.11h | `. . . . . . . <EpubLicense​ExpressionLink>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionLink`
  ○ | `. . . . . . <EpubLicense​Date>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseDate[]`
  P.16.11i | `. . . . . . . <EpubLicense​DateRole>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseDate[]/​EpubLicenseDateRole`
  P.16.11j | `. . . . . . . <Date>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseDate[]/​Date`
  ○ | `. . . . . <ContentDate>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ContentDate[]`
  P.16.12 | `. . . . . . <ContentDateRole>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ContentDate[]/​ContentDateRole`
  P.16.14 | `. . . . . . <Date>` | `/ONIXMessage/​Product[]/​CollateralDetail/​SupportingResource[]/​ContentDate[]/​Date`
  ○ | `. . . <Prize>` | `/ONIXMessage/​Product[]/​CollateralDetail/​Prize`
  P.17.1 | `. . . . <SequenceNumber>` | `/ONIXMessage/​Product[]/​CollateralDetail/​Prize[]/​SequenceNumber`
  ○ | `. . . . <PrizeIdentifier>` | `/ONIXMessage/​Product[]/​CollateralDetail/​Prize[]/​PrizeIdentifier[]`
  P.17.1a | `. . . . . <PrizeIDType>` | `/ONIXMessage/​Product[]/​CollateralDetail/​Prize[]/​PrizeIdentifier[]/​PrizeIDType`
  P.17.1b | `. . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​CollateralDetail/​Prize[]/​PrizeIdentifier[]/​IDTypeName`
  P.17.1c | `. . . . . <IDValue>` | `/ONIXMessage/​Product[]/​CollateralDetail/​Prize[]/​PrizeIdentifier[]/​IDValue`
  P.17.1d | `. . . . <PrizeName>` | `/ONIXMessage/​Product[]/​CollateralDetail/​Prize[]/​PrizeName[]`
  P.17.2 | `. . . . <PrizeYear>` | `/ONIXMessage/​Product[]/​CollateralDetail/​Prize[]/​PrizeYear`
  P.17.2a | `. . . . <AwardingBody>` | `/ONIXMessage/​Product[]/​CollateralDetail/​Prize[]/​AwardingBody[]`
  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 | `. . . . . <PersonName​Inverted>` | `/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.31 | `. . . . . <CorporateName>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​CorporateName[]`
  P.27.32 | `. . . . . <CorporateName​Inverted>` | `/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 | `. . . . . . <PersonName​Inverted>` | `/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.47 | `. . . . . . <CorporateName>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​AlternativeName[]/​CorporateName[]`
  P.27.48 | `. . . . . . <CorporateName​Inverted>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​AlternativeName[]/​CorporateNameInverted[]`
  ○ | `. . . . . <ContributorDate>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​ContributorDate[]`
  P.27.49 | `. . . . . . <Contributor​DateRole>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​ContributorDate[]/​ContributorDateRole`
  P.27.51 | `. . . . . . <Date>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​ContributorDate[]/​Date`
  ○ | `. . . . . <Professional​Affiliation>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​ProfessionalAffiliation[]`
  P.27.52 | `. . . . . . <Professional​Position>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​ProfessionalAffiliation[]/​ProfessionalPosition`
  ○ | `. . . . . . <Affiliation​Identifier>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]`
  P.27.52a | `. . . . . . . <AffiliationIDType>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​AffiliationIDType`
  P.27.52b | `. . . . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​IDTypeName`
  P.27.52c | `. . . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​IDValue`
  P.27.53 | `. . . . . . <Affiliation>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​ProfessionalAffiliation[]/​Affiliation`
  ○ | `. . . . . <Prize>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​Prize[]`
  P.27.53a | `. . . . . . <SequenceNumber>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​Prize[]/​SequenceNumber`
  ○ | `. . . . . . <PrizeIdentifier>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​Prize[]/​PrizeIdentifier[]`
  P.27.53b | `. . . . . . . <PrizeIDType>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​Prize[]/​PrizeIdentifier[]/​PrizeIDType`
  P.27.53c | `. . . . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​Prize[]/​PrizeIdentifier[]/​IDTypeName`
  P.27.53d | `. . . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​Prize[]/​PrizeIdentifier[]/​IDValue`
  P.27.53e | `. . . . . . <PrizeName>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​Prize[]/​PrizeName[]`
  P.27.53f | `. . . . . . <PrizeYear>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​Prize[]/​PrizeYear`
  P.27.53g | `. . . . . . <AwardingBody>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​Prize[]/​AwardingBody[]`
  P.27.53h | `. . . . . . <PrizeCountry>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​Prize[]/​PrizeCountry`
  P.27.53i | `. . . . . . <PrizeRegion>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​Prize[]/​PrizeRegion`
  P.27.53j | `. . . . . . <PrizeCode>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​Prize[]/​PrizeCode`
  P.27.53k | `. . . . . . <PrizeStatement>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​Prize[]/​PrizeStatement[]`
  P.27.53l | `. . . . . . <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[]`
  ○ | `. . . . . <ContributorPlace>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​Contributor[]/​ContributorPlace[]`
  P.27.60 | `. . . . . . <ContributorPlace​Relator>` | `/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 | `. . . . . . <OccurrenceDate​Role>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​OccurrenceDate[]/​OccurrenceDateRole`
  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.77a | `. . . . . <PostalCode>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​PostalCode`
  P.27.78 | `. . . . . <VenueNote>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​VenueNote[]`
  P.27.79 | `. . . . . <EventDescription>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​EventDescription[]`
  ○ | `. . . . . <SupportingResource>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]`
  P.27.79a | `. . . . . . <SequenceNumber>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​SequenceNumber`
  P.27.79b | `. . . . . . <ResourceContentType>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceContentType`
  P.27.79c | `. . . . . . <ContentAudience>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ContentAudience[]`
  ○ | `. . . . . . <Territory>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​Territory`
  P.27.79d | `. . . . . . . <CountriesIncluded>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​Territory/​CountriesIncluded`
  P.27.79e | `. . . . . . . <RegionsIncluded>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​Territory/​RegionsIncluded`
  P.27.79f | `. . . . . . . <CountriesExcluded>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​Territory/​CountriesExcluded`
  P.27.79g | `. . . . . . . <RegionsExcluded>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​Territory/​RegionsExcluded`
  P.27.79h | `. . . . . . <ResourceMode>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceMode`
  ○ | `. . . . . . <ResourceFeature>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceFeature[]`
  P.27.79i | `. . . . . . . <ResourceFeature​Type>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceFeature[]/​ResourceFeatureType`
  P.27.79j | `. . . . . . . <FeatureValue>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceFeature[]/​FeatureValue`
  P.27.79k | `. . . . . . . <FeatureNote>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceFeature[]/​FeatureNote[]`
  ○ | `. . . . . . <ResourceVersion>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion`
  P.27.79l | `. . . . . . . <ResourceForm>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​ResourceForm`
  ○ | `. . . . . . . <ResourceVersion​Feature>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​ResourceVersionFeature[]`
  P.27.79m | `. . . . . . . . <ResourceVersion​Feature​Type>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​ResourceVersionFeature[]/​ResourceVersionFeatureType`
  P.27.79n | `. . . . . . . . <FeatureValue>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​ResourceVersionFeature[]/​FeatureValue`
  P.27.79o | `. . . . . . . . <FeatureNote>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​ResourceVersionFeature[]/​FeatureNote[]`
  P.27.79p | `. . . . . . . <ResourceLink>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​ResourceLink[]`
  ○ | `. . . . . . . <EpubUsage​Constraint>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]`
  P.27.79q | `. . . . . . . . <EpubUsage​Type>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]/​EpubUsageType`
  P.27.79r | `. . . . . . . . <EpubUsage​Status>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]/​EpubUsageStatus`
  ○ | `. . . . . . . . <EpubUsage​Limit>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]/​EpubUsageLimit[]`
  P.27.79s | `. . . . . . . . . <Quantity>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]/​EpubUsageLimit[]/​Quantity`
  P.27.79t | `. . . . . . . . . <EpubUsage​Unit>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]/​EpubUsageLimit[]/​EpubUsageUnit`
  ○ | `. . . . . . . <EpubLicense>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]`
  P.27.79u | `. . . . . . . . <EpubLicense​Name>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseName`
  ○ | `. . . . . . . . <EpubLicense​Expression>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseExpression[]`
  P.27.79v | `. . . . . . . . <EpubLicense​Expression​Type>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionType`
  P.27.79w | `. . . . . . . . <EpubLicense​Expression​Type​Name>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionTypeName`
  P.27.79x | `. . . . . . . . <EpubLicense​Expression​Link>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionLink`
  ○ | `. . . . . . . . <EpubLicense​Date>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseDate[]`
  P.27.79y | `. . . . . . . . <EpubLicense​DateRole>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseDate[]/​EpubLicenseDateRole`
  P.27.79z | `. . . . . . . . <Date>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseDate[]/​Date`
  ○ | `. . . . . . . <ContentDate>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ContentDate[]`
  P.27.79α | `. . . . . . . . <ContentDate​Role>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ContentDate[]/​ContentDateRole`
  P.27.79β | `. . . . . . . . <Date>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​SupportingResource[]/​ContentDate[]/​Date`
  ○ | `. . . . . <EventSponsor>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​EventSponsor[]`
  ○ | `. . . . . . <EventSponsor​Identifier>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventOccurrence[]/​EventSponsor[]/​EventSponsorIdentifier`
  P.27.80 | `. . . . . . . <EventSponsor​IDType>` | `/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[]`
  ○ | `. . . . <SupportingResource>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]`
  P.27.87a | `. . . . . <SequenceNumber>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​SequenceNumber`
  P.27.87b | `. . . . . <ResourceContentType>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceContentType`
  P.27.87c | `. . . . . <ContentAudience>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ContentAudience[]`
  ○ | `. . . . . <Territory>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​Territory`
  P.27.87d | `. . . . . . <CountriesIncluded>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​Territory/​CountriesIncluded`
  P.27.87e | `. . . . . . <RegionsIncluded>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​Territory/​RegionsIncluded`
  P.27.87f | `. . . . . . <CountriesExcluded>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​Territory/​CountriesExcluded`
  P.27.87g | `. . . . . . <RegionsExcluded>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​Territory/​RegionsExcluded`
  P.27.87h | `. . . . . <ResourceMode>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceMode`
  ○ | `. . . . . <ResourceFeature>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceFeature[]`
  P.27.87i | `. . . . . . <ResourceFeature​Type>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceFeature[]/​ResourceFeatureType`
  P.27.87j | `. . . . . . <FeatureValue>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceFeature[]/​FeatureValue`
  P.27.87k | `. . . . . . <FeatureNote>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceFeature[]/​FeatureNote[]`
  ○ | `. . . . . <ResourceVersion>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]`
  P.27.87l | `. . . . . . <ResourceForm>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​ResourceForm`
  ○ | `. . . . . . <ResourceVersion​Feature>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​ResourceVersionFeature[]`
  P.27.87m | `. . . . . . . <ResourceVersion​Feature​Type>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​ResourceVersionFeature[]/​ResourceVersionFeatureType`
  P.27.87n | `. . . . . . . <FeatureValue>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​ResourceVersionFeature[]/​FeatureValue`
  P.27.87o | `. . . . . . . <FeatureNote>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​ResourceVersionFeature[]/​FeatureNote[]`
  P.27.87p | `. . . . . . <ResourceLink>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​ResourceLink[]`
  ○ | `. . . . . . . <EpubUsage​Constraint>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]`
  P.27.87q | `. . . . . . . . <EpubUsage​Type>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]/​EpubUsageType`
  P.27.87r | `. . . . . . . . <EpubUsage​Status>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]/​EpubUsageStatus`
  ○ | `. . . . . . . . <EpubUsage​Limit>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]/​EpubUsageLimit[]`
  P.27.87s | `. . . . . . . . . <Quantity>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]/​EpubUsageLimit[]/​Quantity`
  P.27.87t | `. . . . . . . . . <EpubUsage​Unit>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​EpubUsageConstraint[]/​EpubUsageLimit[]/​EpubUsageUnit`
  ○ | `. . . . . . . <EpubLicense>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]`
  P.27.87u | `. . . . . . . . <EpubLicense​Name>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseName`
  ○ | `. . . . . . . . <EpubLicense​Expression>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseExpression[]`
  P.27.87v | `. . . . . . . . <EpubLicense​Expression​Type>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionType`
  P.27.87w | `. . . . . . . . <EpubLicense​Expression​Type​Name>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionTypeName`
  P.27.87x | `. . . . . . . . <EpubLicense​Expression​Link>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionLink`
  ○ | `. . . . . . . . <EpubLicense​Date>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseDate[]`
  P.27.87y | `. . . . . . . . <EpubLicense​DateRole>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseDate[]/​EpubLicenseDateRole`
  P.27.87z | `. . . . . . . . <Date>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ResourceVersion[]/​EpubLicense[]/​EpubLicenseDate[]/​Date`
  ○ | `. . . . . . <ContentDate>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ContentDate[]`
  P.27.87α | `. . . . . . . <ContentDate​Role>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ContentDate[]/​ContentDateRole`
  P.27.87β | `. . . . . . . <Date>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​SupportingResource[]/​ContentDate[]/​Date`
  ○ | `. . . . <EventSponsor>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventSponsor`
  ○ | `. . . . . <EventSponsor​Identifier>` | `/ONIXMessage/​Product[]/​PromotionDetail/​PromotionalEvent[]/​EventSponsor[]/​EventSponsorIdentifier[]`
  P.27.88 | `. . . . . . <EventSponsor​IDType>` | `/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 | `. . . . <LevelSequence​Number>` | `/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`
  ○ | `. . . . <EpubUsage​Constraint>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​EpubUsageConstraint[]`
  P.18.8h | `. . . . . <EpubUsageType>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​EpubUsageConstraint[]/​EpubUsageType`
  P.18.8i | `. . . . . <EpubUsageStatus>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​EpubUsageConstraint[]/​EpubUsageStatus`
  ○ | `. . . . . <EpubUsage​Limit>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​EpubUsageConstraint[]/​EpubUsageLimit[]`
  P.18.8j | `. . . . . . <Quantity>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​EpubUsageConstraint[]/​EpubUsageLimit[]/​Quantity`
  P.18.8k | `. . . . . . <EpubUsageUnit>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​EpubUsageConstraint[]/​EpubUsageLimit[]/​EpubUsageUnit`
  ○ | `. . . . <EpubLicense>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​EpubLicense[]`
  P.18.8l | `. . . . . <EpubLicenseName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​EpubLicense[]/​EpubLicenseName[]`
  ○ | `. . . . . <EpubLicense​Expression>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​EpubLicense[]/​EpubLicenseExpression[]`
  P.18.8m | `. . . . . . <EpubLicense​Expression​Type>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionType`
  P.18.8n | `. . . . . . <EpubLicense​Expression​TypeName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionTypeName`
  P.18.8o | `. . . . . . <EpubLicense​Expression​Link>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionLink`
  ○ | `. . . . . <EpubLicense​Date>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​EpubLicense[]/​EpubLicenseDate[]`
  P.18.8p | `. . . . . . <EpubLicense​DateRole>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​EpubLicense[]/​EpubLicenseDate[]/​EpubLicenseDateRole`
  P.18.8q | `. . . . . . <Date>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​EpubLicense[]/​EpubLicenseDate[]/​Date`
  P.18.9 | `. . . . <ComponentTypeName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​ComponentTypeName`
  P.18.10 | `. . . . <ComponentNumber>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​ComponentNumber`
  ○ | `. . . . <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 | `. . . . . <PersonName​Inverted>` | `/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.37 | `. . . . . <CorporateName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​CorporateName`
  P.18.38 | `. . . . . <CorporateName​Inverted>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​CorporateNameInverted`
  P.18.38a | `. . . . . <UnnamedPersons>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​UnnamedPersons`
  ○ | `. . . . . <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 | `. . . . . . <PersonName​Inverted>` | `/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.53 | `. . . . . . <CorporateName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​AlternativeName[]/​CorporateName`
  P.18.54 | `. . . . . . <CorporateName​Inverted>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​AlternativeName[]/​CorporateNameInverted`
  ○ | `. . . . . <ContributorDate>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​ContributorDate[]`
  P.18.55 | `. . . . . . <ContributorDate​Role>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​ContributorDate[]/​ContributorDateRole`
  P.18.57 | `. . . . . . <Date>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​ContributorDate[]/​Date`
  ○ | `. . . . . <Professional​Affiliation>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​ProfessionalAffiliation[]`
  P.18.58 | `. . . . . . <Professional​Position>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​ProfessionalAffiliation[]/​ProfessionalPosition`
  ○ | `. . . . . . <AffiliationIdentifier>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]`
  P.18.58 | `. . . . . . <AffiliationIDType>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​AffiliationIDType`
  P.18.58 | `. . . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​IDTypeName`
  P.18.58 | `. . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​IDValue`
  P.18.59 | `. . . . . . <Affiliation>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​ProfessionalAffiliation[]/​Affiliation`
  ○ | `. . . . . <Prize>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​Prize[]`
  P.18.59a | `. . . . . . <SequenceNumber>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​Prize[]/​SequenceNumber`
  ○ | `. . . . . . <PrizeIdentifier>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​Prize[]/​PrizeIdentifier[]`
  P.18.53b | `. . . . . . . <PrizeIDType>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​Prize[]/​PrizeIdentifier[]/​PrizeIDType`
  P.18.53c | `. . . . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​Prize[]/​PrizeIdentifier[]/​IDTypeName`
  P.18.53d | `. . . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​Prize[]/​PrizeIdentifier[]/​IDValue`
  P.18.59b | `. . . . . . <PrizeName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​Prize[]/​PrizeName[]`
  P.18.59c | `. . . . . . <PrizeYear>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​Prize[]/​PrizeYear`
  P.18.59d | `. . . . . . <AwardingBody>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​Prize[]/​AwardingBody[]`
  P.18.59e | `. . . . . . <PrizeCountry>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​Prize[]/​PrizeCountry`
  P.18.59f | `. . . . . . <PrizeRegion>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​Prize[]/​PrizeRegion`
  P.18.59g | `. . . . . . <PrizeCode>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​Prize[]/​PrizeCode`
  P.18.59h | `. . . . . . <PrizeStatement>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​Prize[]/​PrizeStatement[]`
  P.18.59i | `. . . . . . <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[]`
  ○ | `. . . . . <ContributorPlace>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Contributor[]/​ContributorPlace[]`
  P.18.66 | `. . . . . . <ContributorPlace​Relator>` | `/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[]/​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 | `. . . . . <SubjectScheme​Identifier>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Subject[]/​SubjectSchemeIdentifier`
  P.18.71 | `. . . . . <SubjectScheme​Name>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Subject[]/​SubjectSchemeName`
  P.18.72 | `. . . . . <SubjectScheme​Version>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Subject[]/​SubjectSchemeVersion`
  P.18.73 | `. . . . . <SubjectCode>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Subject[]/​SubjectCode`
  P.18.74 | `. . . . . <SubjectHeading​Text>` | `/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 | `. . . . . <PersonName​Inverted>` | `/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.89 | `. . . . . <CorporateName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​NameAsSubject[]/​CorporateName`
  P.18.90 | `. . . . . <CorporateName​Inverted>` | `/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 | `. . . . . . <PersonName​Inverted>` | `/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.90p | `. . . . . . <CorporateName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​NameAsSubject[]/​AlternativeName[]/​CorporateName`
  P.18.90q | `. . . . . . <CorporateName​Inverted>` | `/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.90t | `. . . . . . <Date>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​NameAsSubject[]/​SubjectDate[]/​Date`
  ○ | `. . . . . <Professional​Affiliation>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​NameAsSubject[]/​ProfessionalAffiliation[]`
  P.18.90u | `. . . . . . <Professional​Position>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​NameAsSubject[]/​ProfessionalAffiliation[]/​ProfessionalPosition[]`
  ○ | `. . . . . . <Affiliation​Identifier>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​NameAsSubject[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]`
  P.18.90v | `. . . . . . <AffiliationIDType>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​NameAsSubject[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​AffiliationIDType`
  P.18.90w | `. . . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​NameAsSubject[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​IDTypeName`
  P.18.90x | `. . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​NameAsSubject[]/​ProfessionalAffiliation[]/​AffiliationIdentifier[]/​IDValue`
  P.18.90y | `. . . . . . <Affiliation>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​NameAsSubject[]/​ProfessionalAffiliation[]/​Affiliation`
  | `. . . . <TextContent>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]`
  P.18.91 | `. . . . . <SequenceNumber>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​SequenceNumber`
  P.18.91a | `. . . . . <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[]`
  P.18.96a | `. . . . . <TextSourceLink>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​TextSourceLink[]`
  ○ | `. . . . . <EpubUsageConstraint>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubUsageConstraint[]`
  P.18.96b | `. . . . . . <EpubUsageType>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubUsageConstraint[]/​EpubUsageType`
  P.18.96c | `. . . . . . <EpubUsageStatus>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubUsageConstraint[]/​EpubUsageStatus`
  ○ | `. . . . . . <EpubUsageLimit>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubUsageConstraint[]/​EpubUsageLimit[]`
  P.18.96d | `. . . . . . . <Quantity>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubUsageConstraint[]/​EpubUsageLimit[]/​Quantity`
  P.18.96e | `. . . . . . . <EpubUsageUnit>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubUsageConstraint[]/​EpubUsageLimit[]/​EpubUsageUnit`
  ○ | `. . . . . <EpubLicense>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]`
  P.18.96f | `. . . . . . <EpubLicenseName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]/​EpubLicenseName[]`
  ○ | `. . . . . . <EpubLicense​Expression>` | `/ONIXMessage/​Product[]/​CollateralDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]/​EpubLicenseExpression[]`
  P.18.96g | `. . . . . . . <EpubLicense​Expression​Type>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionType`
  P.18.96h | `. . . . . . . <EpubLicense​Expression​TypeName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionTypeName`
  P.18.96i | `. . . . . . . <EpubLicense​Expression​Link>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionLink`
  ○ | `. . . . . . <EpubLicense​Date>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]/​EpubLicenseDate[]`
  P.18.96j | `. . . . . . . <EpubLicense​DateRole>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]/​EpubLicenseDate[]/​EpubLicenseDateRole`
  P.18.96k | `. . . . . . . <Date>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]/​EpubLicenseDate[]/​Date`
  ○ | `. . . . . <ContentDate>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​ContentDate[]`
  P.18.97 | `. . . . . . <ContentDateRole>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​ContentDate[]/​ContentDateRole`
  P.18.99 | `. . . . . . <Date>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​ContentDate[]/​Date`
  ○ | `. . . . <CitedContent>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​CitedContent[]`
  P.18.100 | `. . . . . <SequenceNumber>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​CitedContent[]/​SequenceNumber`
  P.18.100a | `. . . . . <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.110 | `. . . . . . <Date>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​CitedContent[]/​ContentDate[]/​Date`
  ○ | `. . . . <SupportingResource>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]`
  P.18.111 | `. . . . . <SequenceNumber>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​SequenceNumber`
  P.18.111a | `. . . . . <ResourceContent​Type>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​ResourceContentType`
  P.18.112 | `. . . . . <ContentAudience>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​ContentAudience[]`
  ○ | `. . . . . <Territory>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​Territory`
  P.18.112a | `. . . . . . <CountriesIncluded>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​Territory/​CountriesIncluded`
  P.18.112b | `. . . . . . <RegionsIncluded>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​Territory/​RegionsIncluded`
  P.18.112c | `. . . . . . <CountriesExcluded>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​Territory/​CountriesExcluded`
  P.18.112d | `. . . . . . <RegionsExcluded>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​Territory/​RegionsExcluded`
  P.18.113 | `. . . . . <ResourceMode>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​ResourceMode`
  ○ | `. . . . . <ResourceFeature>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​ResourceFeature[]`
  P.18.114 | `. . . . . . <Resource​FeatureType>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​ResourceFeature[]/​ResourceFeatureType`
  P.18.115 | `. . . . . . <FeatureValue>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​ResourceFeature[]/​FeatureValue`
  P.18.116 | `. . . . . . <FeatureNote>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​ResourceFeature[]/​FeatureNote[]`
  ○ | `. . . . . <ResourceVersion>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​ResourceVersion[]`
  P.18.117 | `. . . . . . <ResourceForm>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​ResourceVersion[]/​ResourceForm`
  ○ | `. . . . . . <ResourceVersion​Feature>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​ResourceVersion[]/​ResourceVersionFeature[]`
  P.18.118 | `. . . . . . . <ResourceVersion​FeatureType>` | `/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[]`
  ○ | `. . . . . <EpubUsageConstraint>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubUsageConstraint[]`
  P.18.121a | `. . . . . . <EpubUsageType>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubUsageConstraint[]/​EpubUsageType`
  P.18.121b | `. . . . . . <EpubUsageStatus>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubUsageConstraint[]/​EpubUsageStatus`
  ○ | `. . . . . . <EpubUsageLimit>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubUsageConstraint[]/​EpubUsageLimit[]`
  P.18.121c | `. . . . . . . <Quantity>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubUsageConstraint[]/​EpubUsageLimit[]/​Quantity`
  P.18.121d | `. . . . . . . <EpubUsageUnit>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubUsageConstraint[]/​EpubUsageLimit[]/​EpubUsageUnit`
  ○ | `. . . . . <EpubLicense>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]`
  P.18.121e | `. . . . . . <EpubLicenseName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]/​EpubLicenseName[]`
  ○ | `. . . . . . <EpubLicense​Expression>` | `/ONIXMessage/​Product[]/​CollateralDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]/​EpubLicenseExpression[]`
  P.18.121f | `. . . . . . . <EpubLicense​Expression​Type>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionType`
  P.18.121g | `. . . . . . . <EpubLicense​Expression​TypeName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionTypeName`
  P.18.121h | `. . . . . . . <EpubLicense​Expression​Link>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]/​EpubLicenseExpression[]/​EpubLicenseExpressionLink`
  ○ | `. . . . . . <EpubLicense​Date>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]/​EpubLicenseDate[]`
  P.18.121i | `. . . . . . . <EpubLicense​DateRole>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]/​EpubLicenseDate[]/​EpubLicenseDateRole`
  P.18.121j | `. . . . . . . <Date>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​TextContent[]/​EpubLicense[]/​EpubLicenseDate[]/​Date`
  ○ | `. . . . . . <ContentDate>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​ContentDate[]`
  P.18.122 | `. . . . . . . <ContentDate​Role>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​ContentDate[]/​ContentDateRole`
  P.18.124 | `. . . . . . . <Date>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​SupportingResource[]/​ContentDate[]/​Date`
  ○ | `. . . . <Publisher>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Publisher[]`
  P.18.124a | `. . . . . <PublishingRole>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Publisher[]/​PublishingRole`
  ○ | `. . . . . <PublisherIdentifier>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Publisher[]/​PublisherIdentifier[]`
  P.18.124b | `. . . . . . <PublisherIDType>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Publisher[]/​PublisherIdentifier[]/​PublisherIDType`
  P.18.124c | `. . . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Publisher[]/​PublisherIdentifier[]/​IDTypeName`
  P.18.124d | `. . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Publisher[]/​PublisherIdentifier[]/​IDValue`
  ○ | `. . . . . . <PublisherName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Publisher[]/​PublisherName[]`
  ○ | `. . . . . . <Funding>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Publisher[]/​Funding[]/`
  ○ | `. . . . . . . <FundingIdentifier>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Publisher[]/​Funding[]/​FundingIdentifier[]`
  P.18.124e | `. . . . . . . . <FundingIDType>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Publisher[]/​Funding[]/​FundingIdentifier[]/​FundingIDType`
  P.18.124f | `. . . . . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Publisher[]/​Funding[]/​FundingIdentifier[]/​IDTypeName`
  P.18.124g | `. . . . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Publisher[]/​Funding[]/​FundingIdentifier[]/​IDValue`
  ○ | `. . . . . . <Website>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Publisher[]/​Website[]`
  P.18.124h | `. . . . . . . <WebsiteType>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Publisher[]/​Website[]/​WebsiteType`
  P.18.124i | `. . . . . . . <WebsiteDescription>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Publisher[]/​Website[]/​WebsiteDescription[]`
  P.18.124k | `. . . . . . . <WebsiteLink>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​Publisher[]/​Website[]/​WebsiteLink[]`
  ○ | `. . . . <CopyrightStatement>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​CopyrightStatement[]`
  P.18.124l | `. . . . . .<CopyrightType>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​CopyrightStatement[]/​CopyrightType`
  P.18.124m | `. . . . . <CopyrightYear>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​CopyrightStatement[]/​CopyrightYear[]`
  ○ | `. . . . . <CopyrightOwner>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​CopyrightStatement[]/​CopyrightOwner[]`
  ○ | `. . . . . . <CopyrightOwner​Identifier>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​CopyrightStatement[]/​CopyrightOwner[]/​CopyrightOwnerIdentifier[]`
  P.18.124n | `. . . . . . . <CopyrightOwner​IDType>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​CopyrightStatement[]/​CopyrightOwner[]/​CopyrightOwnerIdentifier[]/​CopyrightOwnerIDType`
  P.18.124o | `. . . . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​CopyrightStatement[]/​CopyrightOwner[]/​CopyrightOwnerIdentifier[]/​IDTypeName`
  P.18.124p | `. . . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​CopyrightStatement[]/​CopyrightOwner[]/​CopyrightOwnerIdentifier[]/​IDValue`
  P.18.124q | `. . . . . . <PersonName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​CopyrightStatement[]/​CopyrightOwner[]/​PersonName`
  P.18.124r | `. . . . . . <CorporateName>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​CopyrightStatement[]/​CopyrightOwner[]/​CorporateName`
  P.18.124s | `. . . . <CopyrightStatement​Text>` | `/ONIXMessage/​Product[]/​ContentDetail/​ContentItem[]/​CopyrightStatementText[]`
  ○ | `. . . . <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[]/​IDValue`
  ○ | `. . . . <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[]/​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`
  ○ | `. . . . <ProductContact​Identifier>` | `/ONIXMessage/​Product[]/​PublishingDetail/​ProductContact[]/​ProductContactIdentifier[]`
  P.19.16 | `. . . . . <ProductContact​IDType>` | `/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.20a | `. . . . <TelephoneNumber>` | `/ONIXMessage/​Product[]/​PublishingDetail/​ProductContact[]/​TelephoneNumber[]`
  P.19.20b | `. . . . <FaxNumber>` | `/ONIXMessage/​Product[]/​PublishingDetail/​ProductContact[]/​FaxNumber[]`
  P.19.21 | `. . . . <EmailAddress>` | `/ONIXMessage/​Product[]/​PublishingDetail/​ProductContact[]/​EmailAddress[]`
  P.19.22 | `. . . . <StreetAddress>` | `/ONIXMessage/​Product[]/​PublishingDetail/​ProductContact[]/​StreetAddress`
  P.19.23 | `. . . . <LocationName>` | `/ONIXMessage/​Product[]/​PublishingDetail/​ProductContact[]/​LocationName`
  P.19.24 | `. . . . <PostalCode>` | `/ONIXMessage/​Product[]/​PublishingDetail/​ProductContact[]/​PostalCode`
  P.19.25 | `. . . . <RegionCode>` | `/ONIXMessage/​Product[]/​PublishingDetail/​ProductContact[]/​RegionCode`
  P.19.26 | `. . . . <CountryCode>` | `/ONIXMessage/​Product[]/​PublishingDetail/​ProductContact[]/​CountryCode`
  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.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[]`
  ○ | `. . . . . <CopyrightOwner​Identifier>` | `/ONIXMessage/​Product[]/​PublishingDetail/​CopyrightStatement[]/​CopyrightOwner[]/​CopyrightOwnerIdentifier[]`
  P.20.8 | `. . . . . . <CopyrightOwner​IDType>` | `/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`
  P.20.12a | `. . . . <CopyrightStatement​Text>` | `/ONIXMessage/​Product[]/​PublishingDetail/​CopyrightStatementText[]`
  ○ | `. . . <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[]`
  ○ | `. . . . . . <SalesOutlet​Identifier>` | `/ONIXMessage/​Product[]/​PublishingDetail/​SalesRights[]/​SalesRestriction[]/​SalesOutlet[]/​SalesOutletIdentifier[]`
  P.21.5b | `. . . . . . . <SalesOutlet​IDType>` | `/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`
  ○ | `. . <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[]`
  ○ | `. . <ProductionDetail>` | `/ONIXMessage/​Product[]/​ProductionDetail`
  ○ | `. . . <ProductionManifest>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]`
  ○ | `. . . . <ProductIdentifier>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​ProductIdentifier[]`
  P.28.1 | `. . . . . <ProductIDType>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​ProductIdentifier[]/​ProductIDType`
  P.28.2 | `. . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​ProductIdentifier[]/​IDTypeName`
  P.28.3 | `. . . . . <IDValue>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​ProductIdentifier[]/​IDValue`
  ○ | `. . . . <CoverManifest>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest`
  ○ | `. . . . . <Specification​Bundle​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​SpecificationBundleName[]`
  P.28.4 | `. . . . . . <Specification​Bundle​Name​Type​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​SpecificationBundleName[]/​SpecificationBundleNameTypeName`
  P.28.5 | `. . . . . . <Specification​Bundle​Name​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​SpecificationBundleName[]/​SpecificationBundleNameValue`
  P.28.6 | `. . . . . <SpecificationDetail>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​SpecificationDetail[]`
  ○ | `. . . . . <SpecificationFeature>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​SpecificationFeature[]`
  P.28.7 | `. . . . . . <Specification​Feature​Type>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​SpecificationFeature[]/​SpecificationFeatureType`
  P.28.8 | `. . . . . . <Specification​Feature​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​SpecificationFeature[]/​SpecificationFeatureValue`
  P.28.9 | `. . . . . . <Specification​Feature​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​SpecificationFeature[]/​SpecificationFeatureDescription[]`
  P.28.10 | `. . . . . <Specification​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​SpecificationDescription[]`
  ○ | `. . . . . <Cover​Resource>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]`
  P.28.11 | `. . . . . . <Sequence​Number>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​SequenceNumber`
  ○ | `. . . . . . <Sales​Outlet>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​SalesOutlet[]`
  ○ | `. . . . . . . <Sales​Outlet​Identifier>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​SalesOutlet[]/​SalesOutletIdentifier[]`
  P.28.12 | `. . . . . . . . <Sales​Outlet​IDType>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​SalesOutlet[]/​SalesOutletIdentifier[]/​SalesOutletIDType`
  P.28.13 | `. . . . . . . . <IDType​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​SalesOutlet[]/​SalesOutletIdentifier[]/​IDTypeName`
  P.28.14 | `. . . . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​SalesOutlet[]/​SalesOutletIdentifier[]/​IDValue`
  P.28.15 | `. . . . . . . <Sales​Outlet​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​SalesOutlet[]/​SalesOutletName`
  ○ | `. . . . . . <Resource​Identifier>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​ResourceIdentifier[]`
  P.28.16 | `. . . . . . . <Resource​IDType>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​ResourceIdentifier[]/​ResourceIDType`
  P.28.17 | `. . . . . . . <IDType​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​ResourceIdentifier[]/​IDTypeName`
  P.28.18 | `. . . . . . . <ID​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​ResourceIdentifier[]/​IDValue`
  P.28.19 | `. . . . . . <Resource​Role>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​ResourceRole`
  P.28.20 | `. . . . . . <Resource​File​Detail>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileDetail[]`
  ○ | `. . . . . . <Resource​File​Feature>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileFeature[]`
  P.28.21 | `. . . . . . . <Resource​File​Feature​Type>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileFeature[]/​ResourceFileFeatureType`
  P.28.22 | `. . . . . . . <Resource​File​Feature​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileFeature[]/​ResourceFileFeatureValue`
  P.28.23 | `. . . . . . . <Resource​File​Feature​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileFeature[]/​ResourceFileFeatureDescription[]`
  P.28.24 | `. . . . . . <Resource​File​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileDescription[]`
  P.28.25 | `. . . . . . <Resource​File​Content​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileContentDescription[]`
  P.28.26 | `. . . . . . <Resource​File​Link>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileLink[]`
  ○ | `. . . . . . <Resource​File​Date>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileDate[]`
  P.28.27 | `. . . . . . . <Resource​File​Date​Role>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileDate[]/​ResourceFileDateRole`
  P.28.29 | `. . . . . . . <Date>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileDate[]/​Date`
  P.28.30 | `. . . . . . <No​Resource>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​CoverResource[]/​NoResource`
  ○ | `. . . . <BodyManifest>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest`
  ○ | `. . . . . <Specification​Bundle​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​SpecificationBundleName[]`
  P.28.31 | `. . . . . . <Specification​Bundle​Name​Type​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​SpecificationBundleName[]/​SpecificationBundleNameTypeName`
  P.28.32 | `. . . . . . <Specification​Bundle​Name​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​SpecificationBundleName[]/​SpecificationBundleNameValue`
  P.28.33 | `. . . . . <SpecificationDetail>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​SpecificationDetail[]`
  ○ | `. . . . . <SpecificationFeature>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​SpecificationFeature[]`
  P.28.34 | `. . . . . . <Specification​Feature​Type>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​SpecificationFeature[]/​SpecificationFeatureType`
  P.28.35 | `. . . . . . <Specification​Feature​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​SpecificationFeature[]/​SpecificationFeatureValue`
  P.28.36 | `. . . . . . <Specification​Feature​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​SpecificationFeature[]/​SpecificationFeatureDescription[]`
  P.28.37 | `. . . . . <Specification​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​SpecificationDescription[]`
  ○ | `. . . . . <Body​Resource>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]`
  P.28.38 | `. . . . . . <Sequence​Number>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​SequenceNumber`
  ○ | `. . . . . . <Resource​Identifier>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​ResourceIdentifier[]`
  P.28.39 | `. . . . . . . <Resource​IDType>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​ResourceIdentifier[]/​ResourceIDType`
  P.28.40 | `. . . . . . . <IDType​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​ResourceIdentifier[]/​IDTypeName`
  P.28.41 | `. . . . . . . <ID​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​ResourceIdentifier[]/​IDValue`
  P.28.42 | `. . . . . . <Resource​Role>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​ResourceRole`
  P.28.43 | `. . . . . . <Resource​File​Detail>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileDetail[]`
  ○ | `. . . . . . <Resource​File​Feature>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileFeature[]`
  P.28.44 | `. . . . . . . <Resource​File​Feature​Type>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileFeature[]/​ResourceFileFeatureType`
  P.28.45 | `. . . . . . . <Resource​File​Feature​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileFeature[]/​ResourceFileFeatureValue`
  P.28.46 | `. . . . . . . <Resource​File​Feature​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileFeature[]/​ResourceFileFeatureDescription[]`
  P.28.47 | `. . . . . . <Resource​File​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileDescription[]`
  P.28.48 | `. . . . . . <Resource​File​Content​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileContentDescription[]`
  P.28.49 | `. . . . . . <Resource​File​Link>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileLink[]`
  ○ | `. . . . . . <Resource​File​Date>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileDate[]`
  P.28.50 | `. . . . . . . <Resource​File​Date​Role>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileDate/[]​ResourceFileDateRole`
  P.28.52 | `. . . . . . . <Date>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileDate/​Date`
  ○ | `. . . . <InsertManifest>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]`
  ○ | `. . . . . <Specification​Bundle​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​SpecificationBundleName[]`
  P.28.53 | `. . . . . . <Specification​Bundle​Name​Type​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​SpecificationBundleName[]/​SpecificationBundleNameTypeName`
  P.28.54 | `. . . . . . <Specification​Bundle​Name​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​SpecificationBundleName[]/​SpecificationBundleNameValue`
  P.28.55 | `. . . . . <SpecificationDetail>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​SpecificationDetail[]`
  ○ | `. . . . . <SpecificationFeature>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​SpecificationFeature[]`
  P.28.56 | `. . . . . . <Specification​Feature​Type>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​SpecificationFeature[]/​SpecificationFeatureType`
  P.28.57 | `. . . . . . <Specification​Feature​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​SpecificationFeature[]/​SpecificationFeatureValue`
  P.28.58 | `. . . . . . <Specification​Feature​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​SpecificationFeature[]/​SpecificationFeatureDescription[]`
  P.28.59 | `. . . . . <Specification​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​SpecificationDescription[]`
  ○ | `. . . . . <Insert​Point>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertPoint`
  P.28.60 | `. . . . . . <Insert​Point​Type>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertPoint/​InsertPointType`
  P.28.61 | `. . . . . . <Insert​Point​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertPoint/​InsertPointValue`
  ○ | `. . . . . <Insert​Resource>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]`
  P.28.62 | `. . . . . . <Sequence​Number>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​SequenceNumber`
  ○ | `. . . . . . <Sales​Outlet>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​SalesOutlet[]`
  ○ | `. . . . . . . <Sales​Outlet​Identifier>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​SalesOutlet[]/​SalesOutletIdentifier[]`
  P.28.63 | `. . . . . . . . <Sales​Outlet​IDType>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​SalesOutlet[]/​SalesOutletIdentifier[]/​SalesOutletIDType`
  P.28.64 | `. . . . . . . . <IDType​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​SalesOutlet[]/​SalesOutletIdentifier[]/​IDTypeName`
  P.28.65 | `. . . . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​SalesOutlet[]/​SalesOutletIdentifier[]/​IDValue`
  P.28.66 | `. . . . . . . <Sales​Outlet​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​SalesOutlet[]/​SalesOutletName`
  ○ | `. . . . . . <Resource​Identifier>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceIdentifier[]`
  P.28.67 | `. . . . . . . <Resource​IDType>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceIdentifier[]/​ResourceIDType`
  P.28.68 | `. . . . . . . <IDType​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceIdentifier[]/​IDTypeName`
  P.28.69 | `. . . . . . . <ID​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceIdentifier[]/​IDValue`
  P.28.70 | `. . . . . . <Resource​Role>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceRole`
  P.28.71 | `. . . . . . <Resource​File​Detail>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileDetail[]`
  ○ | `. . . . . . <Resource​File​Feature>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileFeature[]`
  P.28.72 | `. . . . . . . <Resource​File​Feature​Type>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileFeature[]/​ResourceFileFeatureType`
  P.28.73 | `. . . . . . . <Resource​File​Feature​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileFeature[]/​ResourceFileFeatureValue`
  P.28.74 | `. . . . . . . <Resource​File​Feature​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileFeature[]/​ResourceFileFeatureDescription[]`
  P.28.75 | `. . . . . . <Resource​File​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileDescription[]`
  P.28.76 | `. . . . . . <Resource​File​Content​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileContentDescription[]`
  P.28.77 | `. . . . . . <Resource​File​Link>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileLink[]`
  ○ | `. . . . . . <Resource​File​Date>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileDate[]`
  P.28.78 | `. . . . . . . <Resource​File​Date​Role>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileDate[]/​ResourceFileDateRole`
  P.28.80 | `. . . . . . . <Date>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileDate[]/​Date`
  P.28.81 | `. . . . . . <No​Resource>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​InsertManifest[]/​InsertResource[]/​NoResource`
  | `. . . . <Supplement​Manifest>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]`
  P.28.82 | `. . . . . <Sequence​Number>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​SequenceNumber`
  ○ | `. . . . . <Sales​Outlet>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​SalesOutlet[]`
  ○ | `. . . . . . <Sales​Outlet​Identifier>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​SalesOutlet[]/​SalesOutletIdentifier[]`
  P.28.83 | `. . . . . . . <Sales​Outlet​IDType>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​SalesOutlet[]/​SalesOutletIdentifier[]/​SalesOutlet​IDType`
  P.28.84 | `. . . . . . . <IDType​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​SalesOutlet[]/​SalesOutletIdentifier[]/​IDTypeName`
  P.28.85 | `. . . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​SalesOutlet[]/​SalesOutletIdentifier[]/​IDValue`
  P.28.86 | `. . . . . . <SalesOutletName>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​SalesOutlet/​SalesOutlet​Name`
  ○ | `. . . . . <ProductIdentifier>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​ProductIdentifier[]`
  P.28.87 | `. . . . . . <ProductIDType>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​ProductIdentifier[]/​ProductIDType`
  P.28.88 | `. . . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​ProductIdentifier[]/​IDTypeName`
  P.28.89 | `. . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​ProductIdentifier[]/​IDValue`
  P.28.90 | `. . . . . <ProductForm>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​ProductForm`
  P.28.91 | `. . . . . <ProductForm​Detail>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​ProductFormDetail[]`
  P.28.92 | `. . . . . <ProductForm​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​ProductFormDescription[]`
  ○ | `. . . . . <Measure>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​Measure[]`
  P.28.93 | `. . . . . . <MeasureType>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​Measure[]/​MeasureType`
  P.28.94 | `. . . . . . <Measurement>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​Measure[]/​Measurement`
  P.28.95 | `. . . . . . <MeasureUnitCode>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​Measure[]/​MeasureUnitCode`
  ○ | `. . . . . <CoverManifest>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest`
  ○ | `. . . . . . <Specification​Bundle​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​SpecificationBundleName[]`
  P.28.96 | `. . . . . . . <Specification​Bundle​Name​Type​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]//​SupplementManifest​CoverManifest/​SpecificationBundleName[]/​SpecificationBundleNameTypeName`
  P.28.97 | `. . . . . . . <Specification​Bundle​Name​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​SpecificationBundleName[]/​SpecificationBundleNameValue`
  P.28.98 | `. . . . . . <SpecificationDetail>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​SpecificationDetail[]`
  ○ | `. . . . . . <SpecificationFeature>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​SpecificationFeature[]`
  P.28.99 | `. . . . . . . <Specification​Feature​Type>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​SpecificationFeature[]/​SpecificationFeatureType`
  P.28.100 | `. . . . . . . <Specification​Feature​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​SpecificationFeature[]/​SpecificationFeatureValue`
  P.28.101 | `. . . . . . . <Specification​Feature​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​SpecificationFeature[]/​SpecificationFeatureDescription[]`
  P.28.102 | `. . . . . . <Specification​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​SpecificationDescription[]`
  ○ | `. . . . . . <Cover​Resource>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]`
  P.28.103 | `. . . . . . . <Sequence​Number>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​SequenceNumber`
  ○ | `. . . . . . . <Sales​Outlet>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​SalesOutlet[]`
  ○ | `. . . . . . . . <Sales​Outlet​Identifier>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​SalesOutlet[]/​SalesOutletIdentifier[]`
  P.28.104 | `. . . . . . . . . <Sales​Outlet​IDType>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​SalesOutlet[]/​SalesOutletIdentifier[]/​SalesOutletIDType`
  P.28.105 | `. . . . . . . . . <IDType​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​SalesOutlet[]/​SalesOutletIdentifier/[]​IDTypeName`
  P.28.106 | `. . . . . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​SalesOutlet[]/​SalesOutletIdentifier[]/​IDValue`
  P.28.107 | `. . . . . . . . <Sales​Outlet​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​SalesOutlet[]/​SalesOutletName`
  ○ | `. . . . . . . <Resource​Identifier>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​ResourceIdentifier[]`
  P.28.108 | `. . . . . . . . <Resource​IDType>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​ResourceIdentifier[]/​ResourceIDType`
  P.28.109 | `. . . . . . . . <IDType​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​ResourceIdentifier[]/​IDTypeName`
  P.28.110 | `. . . . . . . . <ID​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​ResourceIdentifier[]/​IDValue`
  P.28.111 | `. . . . . . . <Resource​Role>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​ResourceRole`
  P.28.112 | `. . . . . . . <Resource​File​Detail>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileDetail[]`
  ○ | `. . . . . . . <Resource​File​Feature>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileFeature[]`
  P.28.113 | `. . . . . . . . <Resource​File​Feature​Type>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileFeature[]/​ResourceFileFeatureType`
  P.28.114 | `. . . . . . . . <Resource​File​Feature​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileFeature/[]​ResourceFileFeatureValue`
  P.28.115 | `. . . . . . . . <Resource​File​Feature​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileFeature[]/​ResourceFileFeatureDescription`
  P.28.116 | `. . . . . . . <Resource​File​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileDescription[]`
  P.28.117 | `. . . . . . . <Resource​File​Content​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileContentDescription[]`
  P.28.118 | `. . . . . . . <Resource​File​Link>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​CoverManifest/​SupplementManifest[]/​CoverResource/​ResourceFileLink[]`
  ○ | `. . . . . . . <Resource​File​Date>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileDate[]`
  P.28.119 | `. . . . . . . . <Resource​File​Date​Role>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileDate[]/​ResourceFileDateRole`
  P.28.121 | `. . . . . . . . <Date>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​ResourceFileDate[]/​Date`
  P.28.122 | `. . . . . . . <No​Resource/>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​CoverManifest/​CoverResource[]/​NoResource`
  ○ | `. . . . . <BodyManifest>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​BodyManifest`
  ○ | `. . . . . . <Specification​Bundle​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​SpecificationBundleName[]`
  P.28.123 | `. . . . . . . <Specification​Bundle​Name​Type​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​SpecificationBundleName[]/​SpecificationBundleNameTypeName`
  P.28.124 | `. . . . . . . <Specification​Bundle​Name​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​SpecificationBundleName[]/​SpecificationBundleNameValue`
  P.28.125 | `. . . . . . <SpecificationDetail>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​SpecificationDetail[]`
  ○ | `. . . . . . <SpecificationFeature>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​SpecificationFeature[]`
  P.28.126 | `. . . . . . . <Specification​Feature​Type>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​SpecificationFeature[]/​SpecificationFeatureType`
  P.28.127 | `. . . . . . . <Specification​Feature​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​SpecificationFeature[]/​SpecificationFeatureValue`
  P.28.128 | `. . . . . . . <Specification​Feature​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​SpecificationFeature[]/​SpecificationFeatureDescription[]`
  P.28.129 | `. . . . . . <Specification​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​SpecificationDescription[]`
  ○ | `. . . . . . <Body​Resource>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]`
  P.28.130 | `. . . . . . . <Sequence​Number>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​SequenceNumber`
  ○ | `. . . . . . . <Resource​Identifier>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​ResourceIdentifier[]`
  P.28.131 | `. . . . . . . . <Resource​IDType>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​ResourceIdentifier[]/​ResourceIDType`
  P.28.132 | `. . . . . . . . <IDType​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​ResourceIdentifier[]/​IDTypeName`
  P.28.133 | `. . . . . . . . <ID​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​ResourceIdentifier[]/​IDValue`
  P.28.134 | `. . . . . . . <Resource​Role>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​ResourceRole`
  P.28.135 | `. . . . . . . <Resource​File​Detail>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileDetail[]`
  ○ | `. . . . . . . <Resource​File​Feature>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileFeature[]`
  P.28.136 | `. . . . . . . . <Resource​File​Feature​Type>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileFeature[]/​ResourceFileFeatureType`
  P.28.137 | `. . . . . . . . <Resource​File​Feature​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileFeature[]/​ResourceFileFeatureValue`
  P.28.138 | `. . . . . . . . <Resource​File​Feature​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileFeature[]/​ResourceFileFeatureDescription[]`
  P.28.139 | `. . . . . . . <Resource​File​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileDescription[]`
  P.28.140 | `. . . . . . . <Resource​File​Content​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileContentDescription[]`
  P.28.141 | `. . . . . . . <Resource​File​Link>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileLink[]`
  ○ | `. . . . . . . <Resource​File​Date>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileDate[]`
  P.28.142 | `. . . . . . . . <Resource​File​Date​Role>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileDate[]/​ResourceFileDateRole`
  P.28.144 | `. . . . . . . . <Date>` | `/ONIXMessage/​Product[]/​ProductionDetail//​ProductionManifest[]/​SupplementManifest[]/​BodyManifest/​BodyResource[]/​ResourceFileDate[]/​Date`
  ○ | `. . . . . <InsertManifest>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]`
  ○ | `. . . . . . <Specification​Bundle​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​SpecificationBundleName[]`
  P.28.145 | `. . . . . . . <Specification​Bundle​Name​Type​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​SpecificationBundleName[]/​SpecificationBundleNameTypeName`
  P.28.146 | `. . . . . . . <Specification​Bundle​Name​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​SpecificationBundleName[]/​SpecificationBundleNameValue`
  P.28.147 | `. . . . . . <SpecificationDetail>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​SpecificationDetail[]`
  ○ | `. . . . . . <SpecificationFeature>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​SpecificationFeature[]`
  P.28.148 | `. . . . . . . <Specification​Feature​Type>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​SpecificationFeature[]/​SpecificationFeatureType`
  P.28.149 | `. . . . . . . <Specification​Feature​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​SpecificationFeature[]/​SpecificationFeatureValue`
  P.28.150 | `. . . . . . . <Specification​Feature​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​SpecificationFeature[]/​SpecificationFeatureDescription[]`
  P.28.151 | `. . . . . . <Specification​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​SpecificationDescription[]`
  ○ | `. . . . . . <Insert​Point>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertPoint`
  P.28.152 | `. . . . . . . <Insert​Point​Type>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertPoint/​InsertPointType`
  P.28.153 | `. . . . . . . <Insert​Point​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertPoint/​InsertPointValue`
  ○ | `. . . . . . <Insert​Resource>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]`
  P.28.154 | `. . . . . . . <Sequence​Number>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​SequenceNumber`
  ○ | `. . . . . . . <Sales​Outlet>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​SalesOutlet[]`
  ○ | `. . . . . . . . <Sales​Outlet​Identifier>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​SalesOutlet[]/​SalesOutletIdentifier[]`
  P.28.155 | `. . . . . . . . . <Sales​Outlet​IDType>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​SalesOutlet[]/​SalesOutletIdentifier[]/​SalesOutletIDType`
  P.28.156 | `. . . . . . . . . <IDType​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​SalesOutlet[]/​SalesOutletIdentifier[]/​IDTypeName`
  P.28.157 | `. . . . . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​SalesOutlet[]/​SalesOutletIdentifier[]/​IDValue`
  P.28.158 | `. . . . . . . . <Sales​Outlet​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​SalesOutlet[]/​SalesOutletName`
  ○ | `. . . . . . . <Resource​Identifier>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceIdentifier[]`
  P.28.159 | `. . . . . . . . <Resource​IDType>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceIdentifier[]/​ResourceIDType`
  P.28.160 | `. . . . . . . . <IDType​Name>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceIdentifier[]/​IDTypeName`
  P.28.161 | `. . . . . . . . <ID​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceIdentifier[]/​IDValue`
  P.28.162 | `. . . . . . . <Resource​Role>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceRole`
  P.28.163 | `. . . . . . . <Resource​File​Detail>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileDetail[]`
  ○ | `. . . . . . . <Resource​File​Feature>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileFeature[]`
  P.28.164 | `. . . . . . . . <Resource​File​Feature​Type>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileFeature[]/​ResourceFileFeatureType`
  P.28.165 | `. . . . . . . . <Resource​File​Feature​Value>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileFeature[]/​ResourceFileFeatureValue`
  P.28.166 | `. . . . . . . . <Resource​File​Feature​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileFeature[]/​ResourceFileFeatureDescription[]`
  P.28.167 | `. . . . . . . <Resource​File​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileDescription[]`
  P.28.168 | `. . . . . . . <Resource​File​Content​Description>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileContentDescription[]`
  P.28.169 | `. . . . . . . <Resource​File​Link>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileLink[]`
  ○ | `. . . . . . . <Resource​File​Date>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileDate[]`
  P.28.170 | `. . . . . . . . <Resource​File​Date​Role>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileDate[]/​ResourceFileDateRole`
  P.28.172 | `. . . . . . . . <Date>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​ResourceFileDate[]/​Date`
  P.28.173 | `. . . . . . . <No​Resource>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​NoResource`
  P.28.174 | `. . . . . <NoSupplement>` | `/ONIXMessage/​Product[]/​ProductionDetail/​ProductionManifest[]/​SupplementManifest[]/​InsertManifest[]/​InsertResource[]/​NoSupplement`
  ○ | `. . <ProductSupply>` | `/ONIXMessage/​Product[]/​ProductSupply[]`
  P.24.1 | `. . . <MarketReference>` | `ONIXMessage/​Product[]/​ProductSupply[]/​MarketReference`
  ○ | `. . . <Market>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​Market[]`
  ○ | `. . . . <Territory>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​Market[]/​Territory`
  P.24.1a | `. . . . . <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 | `. . . . . <TelephoneNumber>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​MarketPublishingDetail/​PublisherRepresentative[]/​ProductContact[]/​TelephoneNumber[]`
  P.25.11h | `. . . . . <FaxNumber>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​MarketPublishingDetail/​PublisherRepresentative[]/​ProductContact[]/​FaxNumber[]`
  P.25.11i | `. . . . . <EmailAddress>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​MarketPublishingDetail/​PublisherRepresentative[]/​ProductContact[]/​EmailAddress[]`
  P.25.11j | `. . . . . <StreetAddress>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​MarketPublishingDetail/​PublisherRepresentative[]/​ProductContact[]/​StreetAddress`
  P.25.11k | `. . . . . <LocationName>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​MarketPublishingDetail/​PublisherRepresentative[]/​ProductContact[]/​LocationName`
  P.25.11l | `. . . . . <PostalCode>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​MarketPublishingDetail/​PublisherRepresentative[]/​ProductContact[]/​PostalCode`
  P.25.11m | `. . . . . <RegionCode>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​MarketPublishingDetail/​PublisherRepresentative[]/​ProductContact[]/​RegionCode`
  P.25.11n | `. . . . . <CountryCode>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​MarketPublishingDetail/​PublisherRepresentative[]/​ProductContact[]/​CountryCode`
  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.16 | `. . . . . <Date>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​MarketPublishingDetail/​PublisherRepresentative[]/​MarketDate[]/​Date`
  P.25.17 | `. . . . <PromotionCampaign>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​MarketPublishingDetail/​PublisherRepresentative[]/​PromotionCampaign[]`
  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[]/​TelephoneNumber[]`
  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[]/​SupplyContactIDType`
  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 | `. . . . . <TelephoneNumber>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​SupplyContact[]/​TelephoneNumber[]`
  P.26.11h | `. . . . . <FaxNumber>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​SupplyContact[]/​FaxNumber[]`
  P.26.11i | `. . . . . <EmailAddress>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​SupplyContact[]/​EmailAddress[]`
  P.26.11j | `. . . . . <StreetAddress>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​SupplyContact[]/​StreetAddress`
  P.26.11k | `. . . . . <LocationName>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​SupplyContact[]/​LocationName`
  P.26.11l | `. . . . . <PostalCode>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​SupplyContact[]/​PostalCode`
  P.26.11m | `. . . . . <RegionCode>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​SupplyContact[]/​RegionCode`
  P.26.11n | `. . . . . <CountryCode>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​SupplyContact[]/​CountryCode`
  | `. . . . <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[]/​SupplyDateRole`
  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/​SupplierIdentifier[]`
  P.26.22 | `. . . . . . <SupplierIDType>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​NewSupplier/​SupplierIdentifier[]/​SupplierIDType`
  P.26.23 | `. . . . . . <IDTypeName>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​NewSupplier/​SupplierIdentifier[]/​IDTypeName`
  P.26.24 | `. . . . . . <IDValue>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​NewSupplier/​SupplierIdentifier[]/​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[]`
  ○ | `. . . . . <Website>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​NewSupplier/​Website[]`
  P.26.28a | `. . . . . . <WebsiteRole>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​NewSupplier/​Website[]/​WebsiteRole`
  P.26.28b | `. . . . . . <WebsiteDescription>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​NewSupplier/​Website[]/WebsiteDescription[]​`
  P.26.29c | `. . . . . . <WebsiteLink>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​NewSupplier/​Website[]/WebsiteLink[]​`
  ○ | `. . . . <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 | `. . . . . . <StockQuantityCode​Type>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Stock[]/​StockQuantityCoded[]/​StockQuantityCodeType`
  P.26.34 | `. . . . . . <StockQuantityCode​TypeName>` | `/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[not(exists(preceding-sibling::OrderQuantityMinimum))]`
  P.26.41c | `. . . . <OrderQuantityMinimum>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​OrderQuantityMinimum[exists(preceding-sibling::OrderQuantityMinimum)]`
  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 | `. . . . . <EpubTechnical​Protection>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​EpubTechnicalProtection[]`
  ○ | `. . . . . <PriceConstraint>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​PriceConstraint[]`
  P.26.44b | `. . . . . . <PriceConstraint​Type>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​PriceConstraint[]/​PriceConstraintType`
  P.26.44c | `. . . . . . <PriceConstraint​Status>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​PriceConstraint[]/​PriceConstraintStatus`
  ○ | `. . . . . . <PriceConstraint​Limit>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​PriceConstraint[]/​PriceConstraintLimit[]`
  P.26.44d | `. . . . . . . <Quantity>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​PriceConstraint[]/​PriceConstraintLimit[]/​Quantity`
  P.26.44e | `. . . . . . . <PriceConstraint​Unit>` | `/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[]`
  ○ | `. . . . . . <EpubLicense​Expression>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​EpubLicense/​EpubLicenseExpression[]`
  P.26.44g | `. . . . . . . <EpubLicense​Expression​Type>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​EpubLicense/​EpubLicenseExpression[]/​EpubLicenseExpressionType`
  P.26.44h | `. . . . . . . <EpubLicense​Expression​Type​Name>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​EpubLicense/​EpubLicenseExpression[]/​EpubLicenseExpressionTypeName`
  P.26.44i | `. . . . . . . <EpubLicense​Expression​Link>` | `/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 | `. . . . . . <PriceCondition​Type>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​PriceCondition[]/​PriceConditionType`
  ○ | `. . . . . . <PriceCondition​Quantity>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​PriceCondition[]/​PriceConditionQuantity[]`
  P.26.48 | `. . . . . . . <PriceCondition​Quantity​Type>` | `/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 | `. . . . . . <DiscountCode​Type>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​DiscountCoded[]/​DiscountCodeType`
  P.26.55 | `. . . . . . <DiscountCode​TypeName>` | `/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 | `. . . . . . <PriceCode​Type>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​PriceCoded/​PriceCodeType`
  P.26.64 | `. . . . . . <PriceCode​TypeName>` | `/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 | `. . . . . . <PricePart​Description>` | `/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`
  ○ | `. . . . . <ComparisonProduct​Price>` | `/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/[]​PriceType`
  P.26.81 | `. . . . . . <PriceAmount>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​ComparisonProductPrice[]/​PriceAmount`
  P.26.82 | `. . . . . . <CurrencyCode>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​ComparisonProductPrice[]/​CurrencyCode`
  ○ | `. . . . . <PriceDate>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​PriceDate[]`
  P.26.83 | `. . . . . . <PriceDateRole>` | `/ONIXMessage/​Product[]/​ProductSupply[]/​SupplyDetail[]/​Price[]/​PriceDate[]/​PriceDateRole`
  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`
  P.26.149 | `. <NoProduct/>` | `/ONIXMessage/​NoProduct`

#### A.13 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.14 ONIX ‘classic’ and ‘strict’ XSD schemas

The ONIX 3.1 XSD schemas can be used to validate ONIX messages, checking both the tagging structure (tag order, nesting, cardinality etc), and the use of codes from codelists. The classic XSD also implements a few uniqueness constraints – for example ensuring the Record reference is unique within an ONIX message, and that if there are multiple identifiers for the product, each repeat of the <ProductIdentifier> composite is distinctive in some way.

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>. These are termed ‘second-order codelists’). It cannot check identifier check digits, or ‘microformats’ like the structure of Product classification codes, FSC certifications or Lexile measures.

  Note that the RNG schema is the most basic schema available for 3.1, and it checks only the tagging structure and codes from (first-order) codelists, as it is unable to support uniqueness constraints. Validation with a DTD is even more limited, and is not generally recommended. There is no public DTD available for ONIX 3.1.

  Note also that distinct schemas are available for each release of ONIX (ie 3.0 and 3.1 are separate) and for long and short tag variants of each. However, revisions of each release share a single schema (ie 3.1.0, 3.1.1 and 3.1.2 share a single long tags schema, or rather, the schemas and documentation for 3.1.2 completely replace the older schemas and documentation for 3.1.0 and 3.1.1).

The ONIX 3.1 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:

- 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 ex-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;
- and it ensures there are 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 fully replace the ONIX classic 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. Schematron can also report whether the message uses any of the new data elements introduced in particular revisions of a specific release 3.0.4, 3.0.5 and so on, and when characters from a non-Latin script are present. However, these optional Schematron rules are purely informative – they never invalidate an ONIX message. These embedded rules can be used with Saxon or Xerces parsers in oXygen, but XML Spy does not support Schematron.

  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.1_reference_strict.xsd"?>`
  `<ONIXMessage release="3.1" xmlns="http://ns.editeur.org/​onix/​3.1/​reference" xmlns:xsi="http://www.w3.org/​2001/​XMLSchema-instance" xsi:schemaLocation="http://ns.editeur.org/​onix/​3.1/​reference ONIX_BookProduct_3.1_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.1_short_strict.xsd"?>`
  `<ONIXmessage release="3.1" xmlns="http://ns.editeur.org/​onix/​3.1/​short" xmlns:xsi="http://www.w3.org/​2001/​XMLSchema-instance" xsi:schemaLocation="http://ns.editeur.org/​onix/​3.1/​short ONIX_BookProduct_3.1_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.15 Long tags, short tags and tag conversion

ONIX 3.1 messages can be expressed using either long or short tags. Each tag has both a Reference name and a short name, for example <RecordReference> and <Contributor> contrast with <a001> and <contributor>. Long and short names are entirely equivalent – there is no difference in meaning – but they cannot be mixed within a single ONIX message file.

Two indicators at the beginning of an ONIX file show the form of tagging used throughout the remainder of the file. An initial <ONIXMessage> tag indicates long tags are used, and <ONIXmessage> indicates short tags – note the lower-case m in the latter. And if it’s present, the xmlns attribute also indicates the tag ‘flavor’, as the namespace is either http://ns.editeur.org/onix/3.1/reference or http://ns.editeur.org/onix/3.1/short. (Note these are XML namespaces, not the locations of real files. Trying to access those addresses will result in a 404 ‘file not found’ HTTP error.) Ideally, all ONIX implementations should support both flavors, possibly by incorporating an automated tag conversion step.

For ONIX users who choose to implement only one flavor for any reason, neither is specifically preferred and neither has particular technical benefits, but long tags appear to be more common globally and they are certainly more easily understood if the ONIX data is read ‘by eye’. If you receive – or need to send – a message of the unsupported flavor, then a ‘tag converter’ can be used to switch the tag flavor within a message. EDItEUR makes a suitable XSL Transform available. In effect, this switches <RecordReference> and <Contributor> with the equivalent <a001> and <contributor> tags, as well as dealing with any namespace attribute.

The XSLT approach works with the ONIX message file, and derives the long and short tag names from either an XSD or DTD schema. This makes it convenient to integrate tag conversion with a workflow that includes validation. But it has the limitation that it works ‘in memory’ – very large files may require more memory than is available to the XML parser software.

#### A.16 Why does ONIX use XML rather than JSON?

ONIX is built upon XML. 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 legibility and 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 brevity.

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 aims similar to those of XML. It is simple to use, and is 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. It’s often more concise than XML, and has more direct integration with data object models in some common programming languages.

So why does ONIX use XML and not JSON?

In part, this is a question of history. XML was specified just 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 standardization of JSON took several years – it was only published as a standalone specification, independent of JavaScript, in 2013, a few years after the release of ONIX 3.0.

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

- compared with JSON’s simple key–value pair structure, 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. There’s little doubt that its terse syntax would have been a significant benefit of 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 files with short tags, and equivalent JSON data all compress to approximately the same file size;
- the more direct support for JSON data in a range of common programming languages is a potential benefit;
- XML attributes are used in ONIX to convey ‘meta-metadata’ (data about metadata, such as the textformat or datestamp attributes on individual ONIX data fields). However, JSON lacks any equivalent of XML’s attributes. In effect, an XML attribute like textformat in ONIX would require the <Text> data element to be a more complex object in JSON rather than a simple text value. In XML terms, every ONIX data element would have to be a multi-element composite in JSON (ie a JSON object). This extra level of complexity negates most or all of the brevity and ‘programming simplicity’ of JSON;
- namespaces are unique to XML, but rarely used in the context of ONIX – and the development of JSON-LD offers similar benefits;
- JSON only supports Unicode data, whereas XML supports multiple character encodings. This could be viewed as useful simplification or as a significant limitation of JSON (it would certainly be a limitation with legacy IT systems);
- ONIX XML tags must be in the specified order, but JSON keys can be in any order within an object. Mostly this does not matter, but there are a couple of ONIX tags where their order or position relative to other tags is critical (eg <Proximity> within <Stock>);
- the human readability of deeply nested or repeated data structures is poor in JSON, which relies on square brackets, curly braces and commas rather than readable end tags. The end of a particular data structure is visually more obvious in XML. In addition, JSON does not support comments within a data file, whereas XML does. Neither of these issues is important in routine data exchange, but readability and commenting are valuable during development, testing and troubleshooting, or during onboarding of new data partners;
- DTD, XSD and RNG schemas allow the structure and (with XSD and RNG) 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 for this reason a DTD was an integral part of the ONIX framework from the outset. An XSD validation option was introduced in 2006 and RNG in 2009, and a ‘strict’ XSD (using XSD 1.1 and Schematron) was added in 2017. As of the end of 2022, JSON still does not yet have viable standard schema tools for validation of complex message structures – development of JSON Schema is ongoing and may make JSON an option when fully stable and supported by a range of software tools;
- 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-standardized and complex data structures between disparate organizations where the validity of an implementation or its conformance to a standard may need to be checked, because of the ability to verify the data’s structure with XSD and RNG schemas. JSON may be better where the data is simpler in structure and under the full control of a single organization, and where development speed is paramount. A simple API might choose JSON for its brevity, whereas XML is more appropriate for exchanging larger or more complex messages.

  If re-expressing ONIX XML data in JSON format for strictly internal use, remember the requirement for Unicode. Ensure all repeatable composites are converted to JSON arrays, even when they are not actually repeated (and thus include only a single JSON object). And do not ignore ONIX XML attributes – they need to be treated as JSON attributes too, and this requires that simple data fields in XML are converted to JSON objects with multiple attributes, not just simple JSON attributes.

  Also note there are a couple of additional ‘gotchas’, in particular with the <AudienceCodePrecision>, <OrderQuantityMinimum> and <Proximity> tags, where the position of a tag relative to its predecessors and successors affects its meaning. This cannot be replicated directly in JSON.

  Some EDItEUR standard messages – in particular some reports in the EDItX family – do include JSON syntax options.

#### A.17 Why does ONIX not use Canonical XML?

Canonical XML is a restrictive variant of XML that’s intended to ensure two XML files with equivalent content can be compared and easily shown to be functionally identical. As a simple example, where ordinary XML might use either Unicode or the ISO-Latin-1 character set, and both Return and Line feed characters between lines, or just Line feed, or nothing (no new lines at all), Canonical XML must always use Unicode, and the Line feed character. There are a range of detailed limitations, including:

- the document must use Unicode and UTF-8 (which also means that named or numbered characters like &ouml; or &#xf6; are converted to native Unicode characters);
- line breaks use the Line feed character &#x0a; (only);
- CDATA sections are replaced by their character content;
- empty elements like <MainSubject/> are converted to <MainSubject></MainSubject>;
- the XML declaration (normally the first line of an XML file) is removed.

ONIX does not use this Canonical XML form, not least because removal of any CDATA sections would often make an ONIX file invalid. Not all product metadata management applications can make use of Unicode, and the Specification requires the inclusion of the XML declaration.

However, the aims of Canonical XML are sound, and some ONIX best practice is intended to simplify comparison of ONIX Product records – and even where it conflicts with Canonical XML, the aim is consistency. In ONIX:

- use Unicode (in NFC form) and UTF-8 if possible;
- minimize or eliminate numerical character references like &#xf6; (use the native ö character instead). And the only character entities you need when using Unicode are &lt; and &amp; when they occur in the data (and outside a CDATA section);
- use CDATA only where it’s strictly necessary – that is, only when the data contains HTML markup;
- eliminate unnecessary white space (that is, spaces, tabs, returns and new lines). Use just one space between tagnames and attributes, one new line between ONIX tags, and avoid leading or trailing white space within the data. Any indentation of the tags should use tab characters only, and should correctly reflect the nesting of elements and composites (for technical reasons, indentation with fixed-width spaces is used in this document to emphasize the structure of the ONIX, but indentation can be omitted or should use only tabs in real-world ONIX in a production environment);
- don’t use extra spaces and Returns within data fields in an attempt to mimic any text formatting – use a minimal set of simple XHTML or HTML markup for formatting rich text data;
- minimize the use of comments;
- use <MainSubject/>, not <MainSubject></MainSubject>, even though they’re synonymous;
- always include the XML declaration, and ideally the optional namespace (the xmlns attribute) on the <ONIXMessage> tag. However, do not include a DOCTYPE declaration nor any other XML processing instructions.

The aim of best practice like this is to ensure that a change in the ONIX XML is always a meaningful change in the data, not simply the same data presented in a trivially different way.

#### A.18 Why are some ONIX codelists ‘based on’ ISO lists?

A number of ONIX codelists are based on ISO code lists – in particular the ONIX lists of Country (List 91) and Region codes (List 49), and lists for Currency, Language and Text script.

- Why are these lists based on ISO lists? In part because these pre-existing and well-managed lists meet the requirements of ONIX metadata, and because using existing lists promotes interoperability with the many other standards that use them. Most codes in – for example – List 74 are taken from the ISO 639‑2 language code list;
- A minor benefit of using an ISO list as a basis for an ONIX list is that it provides standardized orthography for the list entries, though this is not without drawbacks too. Indigenous groups may object to certain language exonyms, for example. Some more acceptable alternative names or spellings can also be supplied in the headings or notes for each ONIX code;
- But why ‘based on’? Well, there are further differences, as ONIX needs to be able to add new languages as necessary – and occasionally, these new languages are not present in ISO 639‑2. New codes can be taken from other more comprehensive ISO language lists (eg ISO 639‑3), or might be unique to ONIX. And ONIX also needs to maintain policies on deprecation and retirement of old codes that are independent of ISO’s rules;
- In the case of the language lists, why doesn’t ONIX use the most comprehensive ISO list? Because ISO’s long list – ISO 639‑3 – is impractically long at nearly 8000 codes. That’s twice the length of all other ONIX codelists added together. Some of those languages are extinct. Most are spoken by quite small groups (<100,000 people), and will likely never feature in the commercial book trade. In contrast, ONIX’s country and currency lists include the full selection of relevant ISO codes, and they include some additional older codes that have been removed from the ISO lists – these are merely deprecated in ONIX, since removal would invalidate some old data files;
- What are the criteria for additions to these ONIX lists? Again taking List 74 as an example, the list is not extended merely because a language ‘exists’ – otherwise List 74 would comprise well over 7000 codes. EDItEUR also looks for evidence of contemporary, commercially-traded books in a particular language, and a likelihood that any new code added will be actively used. An active language preservation program may also promote addition to List 74. Note that List 74 also includes macrolanguages and language families (collective names) so that there are codes that are reasonably appropriate for most individual languages that are not in the list;
- How does ONIX differentiate between a language and a dialect? While linguists and language historians might focus on the degree of lexical or syntactic distinctiveness, for ONIX the question is primarily about the commercial need to distinguish;
- And why does the ISO list say that the code for German is ‘deu’, whereas ONIX List 74 says ‘ger’? In fact, ISO 639‑2 comes in two flavors – terminological and bibliographic – and some languages have two differently-flavored codes. ONIX List 74 uses the bibliographic flavor;
- In List 74, what are the ‘macrolanguages’? In the context of the ISO language lists, it is a language entry in a less-detailed list such as ISO 639‑2, which maps to and from multiple entries in a more detailed list ISO 639‑3. It does not necessarily imply any linguistic relationship among the member languages. ONIX List 74 includes several of these macrolanguage codes, taken from ISO 639‑2. Macrolanguages are not themselves distinct languages. An example is the Chinese macrolanguage (ONIX code chi) maps to the individual languages Mandarin (ONIX code cmn), Cantonese (yue), plus more than a dozen other Chinese languages that are in general not mutually intelligible, and which are present in neither ISO 639‑2 nor ONIX List 74. The ONIX <Language> composite should carry the most detailed appropriate code that’s available, so only books in Chinese languages other than Mandarin or Cantonese should use macrolanguge code chi. Books in Mandarin or Cantonese should use the more specific cmn and yue. NB the other ‘based on’ lists don’t have any equivalent of this structure;
- List 49 only includes regional sub-divisions for a few countries. Why does it not include sub-divisions of all countries? Apart from the excessive size of such a comprehensive list, the criteria for inclusion include whether or not the sub-divisions are commonly used in book trading or logistics, and whether or not an ONIX national user group has requested the inclusion of a country’s sub-divisions;
- List 91 incudes a number of codes that are not in themselves sovereign countries – Gibraltar (country code GI), Guadeloupe (code GP), Puerto Rico (PR), Hong Kong (HK) and similar territories which nonetheless have ‘country codes’ of their own. For the purposes of ONIX, inclusion of these minor territories is not implied by inclusion of their ‘parent’ country, and they should be explicitly included in any <Territory>. So for example, if the intention is to specify ‘all of China’, HK (and other codes should be listed in addition to CN (CN alone represents what’s commonly known as ‘mainland China’). ‘All of France’ should include both FR and GP;
- ONIX List 96 does not include all currency codes defined by ISO – it omits a small number of codes formerly used in pre-Euro bond trading, other non-currency ‘units of account’, special fund codes, and codes used in precious metals trading, but it still includes a number of deprecated codes that ISO has removed from its list of current currencies.

The other ONIX lists follow similar principles, allowing ONIX to mirror the ISO lists while adding extra codes as necessary and retaining deprecated codes that ISO has removed. Changes in ONIX lists may be prompted by changes in the underlying ISO lists, but are treated in the same way as any other ONIX codelist changes.

#### A.19 Can a recipient just ignore unwanted parts of a Product record?

Yes and no – it depends on the particular tags or composites, and what commercial effect the specific data in those tags has.

For example, if a retailer data recipient chooses to ignore the short description, or ignore the snippets of text from reviews of the product (ie the recipient ignores or fails to make use of those <TextContent> composites with Text type code 02 or code 06 respectively), then that really only affects the data recipient. It has no significant commercial effect, except perhaps that the recipient forgoes some number of potential sales. If a retailer ignores a Last date for returns (in <SupplyDate> with Supply date role code 18), it harms only that retailer as late attempted returns may not be authorized.

Similarly, in a library or legal deposit scenario, data recipients may not be interested in any of the content of Block 2 (Collateral detail). In that case, recipients can easily ignore the entire block.

In contrast, there are some key data fields that cannot safely be ignored by a recipient, because they fundamentally alter the interpretation of data that the recipient does use.

This of course requires a little analysis of the workings of the standard by recipients:

- for each composite or individual data element, does lack of implementation of a tag mean that important data is lost?
- or other data is mis-interpreted?
- when implementing a subset of codes in a codelist, for each code entry not directly supported, how should each valid code be mapped into its nearest internal equivalent?

The most obvious simple example is <PublishingDate>, which can contain both a Publication date and a Sales embargo date. All products have a publication date, whereas only some have a sales embargo. In the absence of a sales embargo, a product that becomes available to the retailer a few days prior to the nominal Publication date can be sold immediately to a retail customer (or dispatched immediately to customers who ordered in advance). But if the retailer does not ingest and use Sales embargo dates (Publishing date role code 02) when they are present, then retail sales are much more likely to begin before any embargo expires. However inadvertent, these early sales could jeopardize serialization payments to the publisher, disrupt marketing plans and threaten publisher–retailer relationships.

But for library data recipients, the Sales embargo date is irrelevant, and can be ignored. For most librarians, only the Publication date matters.

In a more sophisticated scenario, a wholesaler or retailer can ‘ignore’ any <ProductSupply> composite that decribes commercial arrangements in a market in which they do not operate. However, the recipient would clearly have to implement <Market> within <ProductSupply> – at least to some minimal extent – in order to judge whether a particular market can be ignored, and would have to implement <ProductSupply> fully to deal with the commercial details for the market that does apply. The danger of an incomplete implementation is that the data recipient only makes use of the first (or perhaps the last) <ProductSupply> rather than selecting the correct repeat among several.

So the question is, which data fields are commonly ignored or are not implemented by recipients, yet cause commercial issues as a result?

The most common and most serious are Sales restrictions (including those that apply only within a specific market), and Market dates (which can override the Publishing dates provided in Block 4).

  ignoring <SalesRestriction> creates erroneous interpretation of <SalesRights>
  using Reference names |
  --- | ---
  `<SalesRights>` |
  `<SalesRightsType>01</SalesRightsType>` |
  `<Territory>` |
  `<RegionsIncluded>WORLD</RegionsIncluded>` |
  `</Territory>` |
  `<SalesRestriction>` |
  `<SalesRestrictionType>06</SalesRestrictionType>` |
  `<EndDate>20250930</EndDate>` |
  `</SalesRestriction>` |
  `</SalesRights>` |

  using short tags |
  --- | ---
  `<salesrights>` |
  `<b089>01</b089>` | For sale
  `<territory>` | globally
  `<x450>WORLD</x450>` |
  `</territory>` |
  `<salesrestriction>` | But…
  `<b381>06</b381>` | only to libraries
  `<b325>20250930</b325>` | End date of restriction
  `</salesrestriction>` |
  `</salesrights>` |

  The example Sales restriction temporarily limits sales to libraries (public and national libraries, libraries in educational institutions etc). This limitation may reflect a limitation on the publishing rights held by the publisher, or simply the publisher’s commercial preference. In this case, it’s likely to be the latter, since the restriction ends on the specified date (the restriction expires on the last day of September, and unrestricted sales to non-library end-customers can begin on the first day of October).

  However, if the recipient does not implement the <SalesRestriction> tag in its system (or otherwise ignores the restriction, or fails to pass it on when re-distributing the metadata to others), the sales rights will appear to be global – thus the recipient may well sell to non-library customers in the period before the restriction is lifted. This will almost certainly constitute an infringement of some rightsholder’s rights or a breach of the publisher’s terms and conditions of sale.

  Retailer exclusives are a common type of Sales restriction (with Restriction type code 04), and there is an example in the section on <SalesRestriction>. However, the need for commercial confidentiality often restricts Product records for retailer exclusives from being sent to other retailers (at least prior to publication), so retailer exclusivity is usually less of an issue than channel exclusivity.

  ignoring market dates creates false expectation of publication and availability
  using Reference names |
  --- | ---
  `<!-- Block 4 -->` |
  `<PublishingDate>` |
  `<PublishingDateRole>01</PublishingDateRole>` |
  `<Date>20251001</Date>` |
  `</PublishingDate>` |
  `<SalesRights>` |
  `<SalesRightsType>01</SalesRightsType>` |
  `<Territory>` |
  `<RegionsIncluded>WORLD</RegionsIncluded>` |
  `</Territory>` |
  `</SalesRights>` |
  `. . .` |
  `<!-- Block 6 -->` |
  `<Market>` |
  `<Territory>` |
  `<CountriesIncluded>CA US MX</CountriesIncluded>` |
  `</Territory>` |
  `</Market>` |
  `<MarketPublishingDetail>` |
  `<MarketDate>` |
  `<MarketDateRole>01</MarketDateRole>` |
  `<Date>20251101</Date>` |
  `</MarketDate>` |
  `</MarketPublishingDetail>` |

  using short tags |
  --- | ---
  `<!-- Block 4, within <PublishingDetail> -->` |
  `<publishingdate>` |
  `<x448>01</x448>` | ‘Global’ Publication date is…
  `<b306>20251001</b306>` | 1st October
  `</publishingdate>` |
  `<salesrights>` |
  `<b089>01</b089>` | For sale
  `<territory>` |
  `<x450>WORLD</x450>` | …everywhere
  `</territory>` |
  `</salesrights>` |
  `. . .` |
  `<!-- Block 6, within <ProductSupply> -->` | There must be at least one other repeat of <ProductSupply>, to cover sales outside of North America
  `<market>` |
  `<territory>` | This market is composed of…
  `<x449>CA US MX</x449>` | Canada, USA, Mexico only
  `</territory>` |
  `</market>` |
  `<marketpublishingdetail>` |
  `<marketdate>` | In this particular market…
  `<j408>01</j408>` | the local ‘publication date’ is
  `<b306>20251101</b306>` | 1st Nov (ie delayed by a month)
  `</marketdate>` |
  `</marketpublishingdetail>` |

  The assumption that the relevant Publication date is always in Block 4 is not correct. For certain markets, the date can be delayed. Ignoring (or failing to implement) the multiple-market model, and <MarketPublishingDetail> in particular, can lead to false expectations. A retailer in North America that does not implement <MarketPublishingDetail> is likely to assume this product will ‘published’ a month earlier than is truly the case. The product will be published somewhere in October – in another market – but the ‘local publication date’ in the North American market is in November;

  Other metadata from Block 4 can also be ‘overridden’ for a specific market includes the publisher (at least for some functions, as supplied by a <PublisherRepresentative>), and Publishing status.

  Note only the ‘global’ publication date in Block 4 is the true Publication date of the product. A market ‘publication date’ is really a planned availability date specific to that market.

Some other examples are listed below, relating to data fields that are less well-known or less frequently implemented. Some are called out as duties of the implied license to use ONIX metadata.

- Trade and Public annoucement dates: these dates are effectively embargos on the re-distribution or public display of the product’s metadata – Publishing date role codes 02 or 09. A recipient’s failure to abide by these embargos forces data senders to hold back product information from that recipient – while possibly supplying the data earlier to the recipient’s competitors;
- similarly, start and end dates attached to marketing material in <ContentDate>: failure to implement <ContentDate> means data senders have to rely on judiciously-timed updates of collateral, rather than supplying new collateral in advance, with the confidence that data recipients will switch from old to new collateral at the appointed time;
- there are also issues with ignoring <ContentAudience> within Block 2, under the assumption that supplied marketing collateral is always suitable for display to the consumer audience. Content audience should modify the way that collateral in <TextContent> and <SupportingResource> is used. Sometimes, limiting the use of particular collateral to the book trade (<ContentAudience> code 02) can be vital. Less commonly, <Territory> can also be important;
- Required credit: when making use of a particular Supporting resource (eg a photograph of an author), there is a duty to use any supplied photographer’s credit or similar – Resource feature type code 01;
- Market reference: when supporting Block updates, failure to implement Market reference can easily lead to serious loss of metadata describing multiple markets;
- Price qualifier: <PriceQualifier> can limit applicability of a particular price to a certain set of end-customer types (eg educational institutions, Price type qualifier code 11);
- Price date: <PriceDate> limits when a particular price applies. If Price dates are ignored, there might typically be two or even three prices that appear to apply. The dates are intended to remove any ambiguity;
  - if dates are ignored by a recipient, future price changes cannot be notified in advance, and require a data sender to send updates at the time of the price change;
- any assumption within <Price> that ‘Currency implies Country’ is troubling: a Price specified in US Dollars is not automatically applicable to the USA, nor is it necessarily applicable only to the USA. Where supplied, <Territory> inside <Price> limits where a particular price is valid, and if <Territory> is omitted, then the price applies throughout the market (as defined by <Territory> inside <Market>), or failing that, throughout the combined territories where the Sales rights indicate the product is for sale;

Ideally, each data recipient should be transparent about its support or lack of support for each composite or data element, and each code for at least the most important codelists, in a set of widely-available data supply guidelines.

#### A.20 Key changes between ONIX 2.1 and ONIX 3.0

ONIX 2.1 and ONIX 3.0 are different releases of the ONIX Product information message format. Both are based on XML, and they incorporate a similar (though not identical) range of tags and data structures, and a consistent ‘style’. Both use a set of codelists with many individual codes and lists in common. However there are significant differences of structure and detail throughout the two standards. Development of the newer version was prompted by the need to improve the handling of digital products and international trading, and the recognition that the price of maintaining backwards-compatibility was hugely complicating adoption by data recipients. ONIX 3.0 also aimed to:

- simplify the message structure somewhat and reduce redundancies and inconsistencies within the range of tags;
- extend the range of metadata that can be expressed in a Product record;
- improve the way some metadata is expressed, for example to match the workings of real-world publishing, to clarify the intended interpretation of the data, and to encourage greater consistency and better interoperability between implementations;
- make future extension of the standard simpler;
- introduce an option for more efficient data updates;
- maintain good alignment with a broader range of standards.

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’ in the period since 2.1 was originally published (ie since 2003). 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 six-part block structure within the Product record, intended to support more granular, block by block updating, is new to ONIX 3.0. The ONIX Price and Availability Update message is no longer a separate message format – it is 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). From 3.0 revision 7, an additional and optional Block 7 has been added to support description of promotional events. From 3.0 revision 8, an optional Block 8 has been added to support print-on-demand, e‑book and digital audio workflows.
  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 to support Open Access publications. 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 |  | E‑publication 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 or in P.6.
  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, sequence numbering is handled differently, 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> in P.7.
  | 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 held 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 if necessary carry 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.
  | P.28 | Production details: new in ONIX 3.0 (from revision 8), with no 2.1 equivalent, and carrying details required in the product supply chain such as a manifest of PDFs for print-on-demand manufacture or of WAV files for compression and assembly into a digital audiobook package for delivery to the purchaser.
  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, repeatable, <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. From revision 4, a separate license associated with each price can be specified.
  Attributes | The meaning of the datestamp attribute has been slightly modified.
  Multilingual text | Most textual data elements are repeatable if the text is supplied in multiple parallel languages (from 3.0 revision 1). Note that named entities for non-ASCII characters – for example &ndash; or &uuml; – are not supported in 3.0. Use native characters in your chosen encoding, or numerical character references (eg &#x2013; or &#252;) instead. The five built-in XML entities are exceptions, though only two – &amp; and &lt; are mandatory – the remaining three are not recommended for use in ONIX 3.0 and later.
  Use of XHTML 1.1 | Allows the use of the <ruby> tag in XHTML marked up textual data (from 3.0 revision 1). For textual data elements that do not support XHTML markup, Unicode interlinear annotation delimiters (characters &#xfff9;, &#xfffa; and &#xfffb;) may be used to delimit text glosses.
  XML schemas | XML developers can choose between DTD, XSD or RNG expressions of the ONIX data structure and of the codelists, for validation – although DTD validation is not recommended. An extended validation tool based on XSD 1.1 with embedded Schematron rules is also available, and is recommended for system development and testing, and for onboarding new data partners.
  Application notes | A selection of notes and pre-recorded video ‘webinars’ 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.0. Other application note topics include use of (X)HTML markup in ONIX, metadata for Open Access monographs, collections, audiobooks, block updates, commodity codes etc.
  Acknowledgement message | A new ‘reply 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 in their detail, and some ONIX national groups provide modified guidelines for use within a particular country.

#### A.21 Key changes between ONIX 3.0 and ONIX 3.1

ONIX 3.0 and ONIX 3.1 are different releases of the ONIX Product information message format. ONIX 3.1 aims to:

- continue the development direction established with revisions 3.0.1 to 3.0.8, by adding to the range of metadata elements that can be expressed within the message;
- eliminate the small number of previously-deprecated data elements, in order to simplify the message and remove redundancies wherever possible;
  - the <Gender> tag has also been removed;
  - the removal of these data elements mandates the increase in the release number;
  - but the loss of backwards compatibility is minimized. Any ONIX 3.0 message that does not use these deprecated elements (or <Gender>) requires only an update to the release and xmlns attributes withing the <ONIXMessage> tag to become valid ONIX 3.1;
- extend the ‘block update’ option to allow per market updates within Block 6;

The table below summarizes the major changes between the two releases.

  Key changes between ONIX 3.0 and ONIX 3.1
  3.0 | 3.1 | Notes
  --- | --- | ---
  <ONIXMessage> | Root element: the mandatory release and optional xmlns attributes are updated to refer to release 3.1.
  <Header> | Header: three <Default… elements have been deprecated.
  <Product> | Product: the eight-part block structure remains unchanged, but in 3.1, Block 6 can be interpreted differently, as a truly repeatable Block where each repeat consists of a single independent <SupplyDetail> composite, whereas in ONIX 3.0, it was advisable to treat Block 6 as a non-repeatable block containing one or more <SupplyDetail> composites). This is particularly relevant to Block updates.
  P.1 | P.1 | Record reference number, type and source: no changes.
  P.2 | P.2 | Product identifiers, barcodes: no changes.
  P.3 P.4 | P.3 P.4 | Product form, Product parts: an <EpubLicenseDate> composite has been added to support notification of future changes of licensing.
  P.5 | P.5 | Collection: the publication frequency of items in a collection can now be specified, and a collection identifier can be linked to a specific collection level for a product arranged in a collection, subcollection and sub-subcollection hierarchy.
  P.6 | P.6 | Product title: no changes, but the <TitleText> element has been deprecated.
  P.7 | P.7 | Authorship: a new <AffiliationIdentifier> allows educational and research institutions and other professional affiliations to be identified, the outmoded <Gender> tag and a redundant option for the use of <UnnamedPersons> have been removed. The treatment of corporate names in multiple languages has been changed, and the changes to <Prize> have been inherited from revision of Group P.17.
  P.8 | P.8 | Event: no significant changes. The deprecated and redundant <Conference> composite has been removed.
  P.9 | P.9 | Edition: no changes.
  P.10 | P.10 | Language: no changes.
  P.11 | P.11 | Extents and other content: no changes.
  P.12 | P.12 | Subject: no changes other than those inherited into <NameAsSubject> from revision of other Group P.7.
  P.13 | P.13 | Audience: where multiple audiences are specified, a <MainAudience> flag can be used.
  P.14 P.15 P.16 | P.14 P.15 P.16 | Descriptions and other supporting text / supporting resources / links to cited resources: a <SequenceNumber> element has been added to prioritize collateral of the same type, for example multiple reviews or multiple product images.
  P.17 | P.17 | Prizes: a <SequenceNumber> element has been added to prioritize prizes, and the Awarding body may now be named.
  P.27 | P.27 | Promotional events: no changes other than those inherited from revision of other Group P.7 and Block 2.
  P.18 | P.18 | Content items: details of digital content licensing and usage constraints, funding and copyright can be specified on a per-chapter basis to support hybrid open access publishing models. A range of other changes are inherited from revision of other Blocks.
  P.19 | P.19 | Publisher: no significant changes.
  P.20 | P.20 | Global publishing status and dates / copyright: no changes.
  P.21 | P.21 | Territorial rights and other sales restrictions: removal of a deprecated and redundant option for the use of <SalesRestriction>.
  P.22 P.23 | P.22 P.23 | Related works and products: no changes.
  P.28 | P.28 | Production manifest: no changes.
  P.24 P.25 P.26 | P.24 P.25 P.26 | Market / Market representation and market publishing details / Supplier, availability and prices: addition of a <MarketReference> data element may modify the processing of Block updates significantly. Removed deprecated <CurrencyZone> element and the entire <Reissue> composite, some regularization of contact detail composites.
  XML schemas | No DTD is available for ONIX 3.1.