Did you go into publishing so that you could spend your days copying and pasting ever-changing metadata from spreadsheets, emails and databases into InDesign? You did? Great. No need to read on.

If you didn’t, perhaps this article will interest you. In it I’m going to show you how to create a catalogue in a single click.

This isn’t a sales pitch. You don’t need to scan ahead for the paragraph where it says “and all you need to do is buy our MagicSoftware™ for twenty grand a year”. All the tools you’ll need are very likely to be there on your work computer. I’m assuming, you being a publisher, that you have a copy of InDesign, and that you can get an ONIX file of your data. (If you don’t have an ONIX file then, actually, this is a sales pitch. Producing an ONIX file of your book data is a basic publishing necessity: call me.)

Here’s what we’re going to cover in this article. First, we’ll prepare an InDesign template. Then we’ll get our data arranged into a suitable format for the InDesign template to understand. Finally, we’ll import the data into the template and revel in the catalogue we’ve created in a single click.

The most exciting bit about this is that you only have to do things once. You set up the InDesign template once, with one sample book entry. You write the XML transformation code once. Then, when you import the data, the single-book template replicates itself to create as many catalogue entries as there are book records in your data — potentially thousands and thousands of catalogue entries with a single click. And of course you can reuse your template and code for the next season’s catalogue, and the next.

Before we start it’s probably a good idea to read this previous article about XML, and this one about ONIX.

ONIX is a wonderful way of sending rich book data to the companies who need it – Nielsen, Bowker and the like. But ONIX’s comprehensive nature means that it can be quite verbose. In a catalogue, we don’t need every last bit of information about a book. So we’re going to convert our ONIX XML message into another XML file that’s a bit less wordy, using a language called XSLT. Then we’ll be able to import it into InDesign. (In fact, InDesign can handle the conversion process itself, when we import the XML.)

Download the files here. You’ll see I’ve prepared an InDesign template for you — so that’s the first bit done. Here’s the structure pane of our InDesign template, showing how each entry will be structured: we’re going to need to whittle our ONIX down until we’ve got an XML file that matches this structure.


So let’s prepare our data for it, using an XSL transformation. Open transform.xsl: this is how the transform.xsl file looks.

Keep calm! Whilst this is code, and it might look a bit overwhelming at first glance, it’s not all zeroes and ones. We can read it, because it uses English words. And you’re good at English words, remember!

So, one line at a time, let’s read this code. (This, by the way, is the very first code I ever wrote, in 2006. Nowadays I’m a professional Ruby on Rails programmer. We all have to start somewhere.)

Line 1 tells the computer that this is an XML file.

Line 2 defines the first tag, called


and gives a bit more information about this part of the file – which is that this code is XSL.

Line 3 is where it starts to get interesting.

<xsl:for-each select="ONIXMessage/Product">

means “find each mention of ONIXMessage/Product in the ONIX file.”

The next bit declares a new XML tag, called


If you peek ahead to line 24, you’ll see its sister, the closing tag


(We know it’s a closing tag because of the backslash.)

Lines 5 to 7 set up some variables. A variable is like having a shortcut. For example, I can define a variable called “address”:

address = “Chiltern House, Thame Road, Haddenham, Aylesbury, Buckinghamshire HP17 8BY, UK”

Now, next time I want to give my office location, I don’t have to spell out the whole thing. The variable “address” is a shorthand way of saying the whole thing.

Back to our code. We’re going to define three variables on the next lines: one called form, one called date and the other called isbn, so we can use them later. We’re getting the values of the variables from the ONIX file. We select the data tagged up with ProductFormDetail and assign it to the variable called form.

Similarly, we find the value in the ONIX tagged up as PublicationDate, and save that as the variable date.

Lastly we find the bit in the ONIX tagged up as ProductIdentifier[ProductIDType = '03']/IDValue and set that as the variable called isbn. That last one is a bit complicated but if I show you the ONIX, it’ll make more sense.


There’s two ProductIdentifier tags here. Oh no – which IDValue should we select? Ah, it’s the one with ProductIDType 03. (A lot of learning programming is about getting familiar with the syntax – the particular way that the programming language is laid out. Here, we’re using square brackets to nest ProductIDType after ProductIdentifier. Don’t fret about learning syntax– that’s the easy bit. Understanding the actual logic is the thing to really master. It’s why kids’ learn-to-code tools such as Scratch are so great – they teach the principles and the logic, not one language’s particular way of writing them.)

Line 8 defines another XML tag, called . Because it’s an image tag, it takes an href attribute. And can you see how we say where the computer should look for the right file? That’s right – we use our freshly-minted “isbn” variable. So this URL:

<image href="file:///{$isbn}.jpg" />

will become:

<image href="file:///9780954575984.jpg" />

The next line is quite fruity, but I’ve included it so we can see just how malleable data can be in the hands of a computer. The line defines a new XML tag, . We’re using a new XLS command:


Line 9 says “Get the value of the ‘date’ variable”. It also fiddles around with the date quite a lot. If the line read

<xsl:value-of select="$date"/>

then the new <year> XML tag would read <year>20120228</year>. But who wants to use ISO-format dates in a catalogue? Instead we want it to read 28/02/2012. So whilst concat(substring($dt,7,2), ‘/’,substring($dt,5,2), ‘/’,substring($dt,1,4)) looks fairly unholy at a glance, what it’s doing is saying “Concatenate the following. Get the value of the date variable which is 20120228. Count to the 7th digit, which is 2. Then get the 2 following digits, which would be 28. Then put a backslash in. Next, use that same date variable and get the fifth number, which is 2, and then the next two digits, which gives you 02. Pop another backslash in. Finally, get that same date variable, and get the first number, which is 2, and then the next four digits, which gives you 2012. All of that gives you 28/02/2012.” See, it looks awful to start with, but you just have to sit and read the code until it makes sense.

The next line, 10, is also an <xsl:value-of>, and we use our handy isbn variable again. This line produces another XML tag called <productid>.

All these tags will be used in the InDesign document we’ll see in a bit. Home straight now! You’re doing very well.

We’re going to look at the last XSL command for today, which is


This is quite self-explanatory. On line 11, we spark up another XML tag, called <format>. But what to put in this tag? The syntax says “Choose from the following: when the ONIX form variable is B104, put in A Format Paperback. When the ONIX form variable is B105, put “B Format Paperback” in our new tag.” And so on.

The next bit is best shown on video. Watch how we’re going to use our XSLT code to transform ONIX into a more concise XML file and automatically flow it into our InDesign template. (You’d best watch it on HD so you can see the detail.)

Use the files you’ve downloaded to practice, and then use your own company’s ONIX file and have a go. Then, tweak the InDesign template so that the colours and fonts are to your taste, and produce your own catalogue.

This demo is a deliberately pared-down example. You’ll likely want to include more information such as the title, the blurb and the price. I can recommend A Designer’s Guide to InDesign and XML which contains even more templates and excellent descriptions of how to start using InDesign properly and productively.

You know, we could have automated this catalogue’s production in a number of ways. If you use Bibliocloud, you can export pared-down XML without having to convert ONIX, or you can export data directly to PDF. If you still store your metadata in Excel, you can get it to export an XML file. The point is that if you explore the tools you have available to you right now on your machine, you’ll find that your computer could be working a lot harder for you. Automation is the key to a happy modern working life – and when your happiness is at stake, that’s worth a bit of an investment of time in learning about automation processes like this, wouldn’t you say.

Originally published on Bookmachine, February 2015


    Most popular

  1. Ruby code and why you should care
  2. A quick look at data visualisation and analysis
  3. Menial publishing jobs are destroying our future
  4. It's us in the industry who need to be able to code
  5. A manifesto for skills
  6. Learning how to code, the long way around
  7. Company news

  8. New website
  9. 2018 Customer survey report
  10. 2017 in review
  11. Sara O'Connor to join the team!
  12. And now we are five
  13. Prizes galore
  14. Product news

  15. 'Continuing to solve real problems': Futurebook 40, London Book Fair 2018 and the Works page
  16. How many authors is too many?
  17. Better ONIX fragments
  18. Advanced advance information!
  19. Schedules page
  20. Publishers hack their own bibliographic data
  21. Case studies

  22. Burleigh Dodds Science Publishing
  23. Zed Books
  24. IOP Publishing
  25. Code

  26. A publisher’s guide to APIs
  27. What publishers need to know about Ruby on Rails
  28. How APIs can make publishing more efficient
  29. A day in the life of a programmer
  30. eCommerce

  31. To go direct, publishers must mean business
  32. Don’t outsource your publishing business away
  33. Who has the balance of power over data?
  34. Inbound marketing
  35. The business case for going direct
  36. Why publishers must use direct sales
  37. ONIX

  38. A hidden benefit
  39. Thema Subject Codes Update November 2017
  40. ONIX. Not very standard
  41. Three ways to do more with ONIX
  42. A non-technical, beginners’ guide to ONIX for Books
  43. ONIX Changes
  44. BIC, Thema and artificial intelligence...
  45. How to create a catalogue automatically using ONIX and InDesign
  46. Skills

  47. Embrace the code
  48. Mechanical sympathy
  49. Publishers can learn a few things from programmers
  50. A taste of code
  51. Strategy

  52. Rejuvenation
  53. Why ‘easy’ publishing solutions hardly ever are
  54. The right tool for the job
  55. No computer system can fix a broken publisher
  56. Five things I've learned since moving into enterprise product management
  57. Managing expectations
  58. Start with Why – How to refine your publishing mission
  59. The real price of a strategy shift
  60. Technical debt
  61. Decisions, decisions
  62. Creative industries and the division of labour
  63. A company of one's own.
  64. Responsibility, Authority, Capability
  65. Sometimes, size matters
  66. The search for publishing's holy grails