A lot of software vendors and some firms go to great lengths to prepare ONIX files tailored to markets, creating separate files by certification standards for BISG, BookNet, and BIC. And some ONIX senders tailor their output based on what a retailer requests, so, for example, Indigo may not receive the imprint code that Amazon asks for.
At BookNet Canada, we think that so long as the ONIX file is a properly prepared XML document it shouldn’t matter. The end user must program to pull pieces of information from it but the existence of other pieces of information in the file shouldn’t affect them because the XML file can still be loaded by them all. Beyond that, our contention is that to deny end users data points creates a distinct disadvantage. The data should mean something. So if BIC subjects can help a North American retailer focus their subject headings why shouldn’t they have the opportunity to use them? And what if they are selling internationally and need them?
Sure, this isn’t widely practiced, but it would work. As far as I know there are two reasons it might cause problem:
First, a publisher might be supplying different information to different markets or companies. The file could contradict itself. It’s hard to think of a plausible example but say discount codes could contradict (deprecated in NAm) discount percentages. Conceivably information intended for one market might not apply in another. ONIX 3.0 with it’s enhanced market reporting should solve that, but ONIX 2.1 users might argue this.
The other reason might be sloppy programming by end users. For example, there’s a problem if the end user assumes that there’s only one price is in the file and he decides to load a <PriceAmount> without any reference to the surrounding SupplyDetail, when in fact there’s more than one is in the record. This was an issue 10 years ago for some users, but no multiple price file should cause a problem today. A similar problem could occur on the title level: A file that uses multiple Title entries (Distinct & Translated title, for example) risks that end users may not expect this and only program for a single entry, ignoring TitleType. In any case, by including all possible information, you may need to rely more heavily on the end user to identify the pieces they need.
I think the first problem can be dismissed because I doubt users of ONIX are that subtle. There really shouldn’t be ONIX records in an international supply chain that internally contradict themselves. BookNet’s thinking is that having done the data entry work senders would want everyone to have access to the data.
But the second problem is potentially real, but I don’t see what you can do about it—other than communicate. It is certainly not the intent of certification systems to police at that level and say only Distinct Title should be supplied. The Canadian Bibliographic Standard is an expression of the most important data points—the minimum needed, not a statement of what to expect in a file. End users should expect ONIX as writ by Editeur, and like my price example, no one should program for ONIX based on an assumption that other possible values won’t be sent.
ONIX records should be as complete as the sender can make them. End users should be able to see all the data and make their own choices about what’s useful. The only real reason I think tailoring might be necessary would be due to very large companies: End users, for reasons of processing, might want to get a smaller file and ask the sender to eliminate unneeded parts.
Tell us if you think we’re wrong: If you know better, help us understand why!
