Expect that most people here have been hearing about the promise of XML for the last few years.There are a fair few things we’ve been promised. It should be cheaper to produce books this way – automation, repeatability.Starting with XML we can generate the app files and/or output files from the same source with a high level of automationPenguin – backlist conversion project – 3000 books to XML & ePub for Sony Reader UK launchBA – new imprint with a novel business model looking to have a digital workflow from day one for flexibility and cost controlIncremental sales – easier to respond to new opportunities when you have AGILE content. Because XML can be queried
XML can be entirely formatting neutral, it can be entirely formatting based. It’s partially a corporate decision and partly a project specific decision as to where on a continuum you need to be. I would almost always try to have a semantic structure down as far as inline content and I’d mark up anything *important* in the inline content. Of course, only you can know what’s important in your books. But... the more semantic the content the more opportunities you have to create new uses for that content (the extent to which this is true depends greatly on what sort of content we’re talking about)
You need to know where your content is, what form it’s in, is it worth converting (not always). Conversion is a one off cost but still a cost.penguin converted 3000 backlist titles. How many are selling? Before you convert it, decide what you want to convert to.
Ken ???? from Cengage – small number of styles
Mention penguin issues with backlist materialsDiscuss poetry and drama. Line orientated text. Spread based layouts (hard to create XML anyway)Specifications are a requirement – ask the people who’ve done this a while (sweet & maxwell, OUP)