Non-Geeks Keep Out
Seriously, there's not much point in you reading this unless you have mastery over most things electronic. I want to ask the SnowBlog readership for help (assuming there really is a SnowBlog readership) but just reading the question will give you a nose bleed if you're at all prone to technophobia.
But if you believe your kung fu is strong enough, please read on...
So I'm working on a project involving Onix messages. I want to store a big bunch of them in a database and then let users fetch them out, edit them, create new ones, and save them back to the database using a web interface. I'm using JavaServer Faces, writing my code in the Sun Creator environment, and all that side of things is going swimmingly - though I'm only doing it to a proof-of-concept level at the moment. I'll probably use Sun's Application Server to host the thing too, because it makes my life so easy. I'm just starting to think about what the database design should look like and I'm very aware that someone else must have done this first. The couple of Onix-y apps I'm aware of both use FileMaker. But I want to go with something SQL-compliant. I'm using MySQL at the moment, which I'll stick with unless there's a good reason not to. Has someone already got a schema that maps db tables to the Onix message structure? Or heard rumours of such a thing? I'd even be lured into using an XML database (preferably an open-source one) if someone has already got something working with Onix. I mean, ideally I'd also like someone to send me some nice abstraction/interface code that loads a message into a DOM and lets me use XPath and XSL to work on it, but a proven database design would be a good start.
So any thoughts? Anyone? Bueller? Anyone?
Comments: 5
Pity the poor publisher who employs arts graduates. I can pretty much guarantee that we are the only small publisher in the UK at the moment having this sort of conversation. We rule (by which, natch, I mean you).
Posted by: Em on March 21, 2007 04:55 PM
Oh, except maybe Chris at Salt.
Posted by: Em on March 21, 2007 04:57 PM
I agree with the first James - in fact, his approach is what I used for writing our ONIX support.
I found the 30 or so fields that were relevant to us, created a basic DB schema to suit, then used regular SQL queries and Ruby's XML building code to output valid ONIX files.
Posted by: JamesH on March 21, 2007 11:10 PM
I'm not sure the first James has done me any favours here. Since the system isn't going to be an in-house Snowbooks project - it's for lots of publishers to use - I can't very well just stick to the fields that Snowbooks uses. It might turn out that most of the Onix standard is deadwood and no one needs all those other fields, but I can't really assume that without some proof. Thanks for taking the time to comment, though, JamesH. Why not get in touch? It would be interesting to hear more about what you built and what you use it for.
Posted by: Rob on March 22, 2007 09:47 AM
I maintain the website (amongst other things) for Rainbow Book Agencies - a franken-company that imports, distributes, and wholesales in Australia.
My challenge is taking the data from around 100 suppliers in varying formats (word/excel/pdf/bisac/onix/smoke signals) and supplying it to our customers in a standard way. ONIX is proving useful now that the software many of our customers use supports it (thanks to the ISBN13 transition).
Posted by: JamesH on March 22, 2007 02:41 PM