We've been getting quite a few questions from publishers about ONIX 3. So, we went straight to the horse’s mouth and asked Graham Bell of Editeur what exactly ONIX 3 will bring to the eBook party. Here is part 1 of a 2-part interview.

 Vearsa: A lot of our eBook distribution customers have been asking about ONIX 3. We're not quite ready yet, and nor are many of our customers, but what are the primary functional and content differences between ONIX 2.1 and 3.0?

Graham Bell (GB): Well, it's important first of all to understand that 2.1 and 3.0 are not completely different. I speak to a lot of people who believe that the update is a huge undertaking, equivalent perhaps to the effort of implementing ONIX from scratch. In truth, it's nothing like that – for two reasons. First, the biggest challenge when implementing ONIX is not the technical issue of creating the XML, it's an organisational challenge – and someone migrating from 2.1 to 3.0 has already tackled that. And probably two-thirds of a typical ONIX 2.1 message doesn't need to be changed significantly to make it valid 3.0.

Vearsa: So if that much of 2.1 and 3.0 are the same, what are the differences?

GB: Ignoring the wholly new stuff which we'll get to in a moment, there are perhaps five types of change that anyone migrating from 2.1 to 3.0 needs to cover.

First, in ONIX 2.1, you have a lot of data elements that are 'dedicated' – elements like or . They were inherited from ONIX 2.0 or even earlier versions, and they are deprecated. Although for most people they have been replaced by more flexible composite elements like or , they are still a part of the standard. And that makes 2.1 rather complex, particularly for data recipients – there are actually more tags in 2.1 than in the latest revision of 3.0, and there's often two or three ways of conveying the same information. 'Spring cleaning' 3.0 swept the deprecated elements away, leaving only the composites. If your ONIX 2.1 is 'up to date' – if it doesn't use any of the deprecated elements – then a good part of your migration to 3.0 has already been done.

That's not to say that 3.0 doesn't have any deprecated elements of its own – it's already accumulated a handful, in further moves to reduce the number of different ways of doing the same thing.

Second, there is some rather trivial renaming and reordering of tags. A good example is within , where from 2.1 is now , and if you use it goes before the actual name of the contributor rather than after. Obviously the tag has been renamed to reflect its meaning better (contributors can be people or organisations), and the reordering introduces some consistency (in general, the 'ONIX style' is to include identifiers before the names or the text).

Third, there are some significant changes that introduce a better and more consistent structure to ONIX 3.0. A good example would be the geographical structures for sales rights, markets and price validity. In 2.1, is inflexible – you can list countries, or parts of countries, but always additively. On the other hand, there's and , which obviously subtract countries. And if you look at prices and currencies, you've got tags like holding one country where a price applies, and which holds a list of countries. All these structures are describing a geographical area, but they do it in three inconsistent ways (this reflects the history of ONIX 2.1, as the variations were added at revision 02 and revision 03).

Now in ONIX 3.0, these three different areas of the Product record all use the same structure – it's consistent, more flexible, and in most cases much easier to understand than the 2.1 version.

Fourth, there are a small number of big structural changes. Sets and series disappear, to be replaced by 'collections'.  The way book titles are handled is different, and 3.0 begins to look at titles in a more hierarchical way  (a collection title, then possibly a sub-collection title, then the product title, all in the same repeatable data structure but at different 'levels'). There's a new way of doing that's much more flexible and better for linking to marketing collateral and other resources on the web. But to my mind, the biggest of these structural changes is the recasting of PR.24 25 and 26 from ONIX 2.1 into the new composite. This composite describes a 'market' (usually a geographical area, and for many simple cases this is 'everywhere I have sales rights'). Within that it lists the suppliers that operate in that market (just one, or multiple suppliers in multiple repeats of ), and each supplier list the prices and other details. It's modular and logical, and the structure is able to describe more complex distribution arrangements.

And there are some small and very detailed technical changes too – like 'named character entities' not being valid (these are things like … to represent an ellipsis). In ONIX 3.0, you can use the numerical equivalent, … instead, but there's strong encouragement to use Unicode 'native' characters that avoids this stuff entirely (you just include the … character).