Xml more trouble than it's worth
- 1. XML – more trouble than it’s worth? Andy Williams University Press Conference 17th March 2016
- 2. Of course you should do XML… If cost no object! For elegance, future preservation and re-use Book sales are tough, revenue per title down, digital revenue/sales not replacing print directly Migrating to digital but print still important and needed for books Need to deliver in many formats, but no increase in revenue, just potential increase in costs Need to spend wisely and ensure that the items funded have a positive benefit (either immediate financial, or long term profile) Need to balance investment now against long term opportunities and future proofing People keep telling you that you should be doing it differently…
- 3. Scope Business case Building it as a process Upsides Downsides University Press extra wrinkles Journals versus books Implementation impacts to consider for the business case Workflow Organisational impacts Project management Systems
- 4. Business case process What benefits looked for? Possible solution What will it cost Am I happy of balance benefits vs costs NO Reconsider, must haves, nice to have, revisit solution Work out detail YES Review: have we maximized the potential? Ongoing review
- 5. Drivers – why do it Better products … Sell more, increased revenue, attract more authors, attract more users (discoverability) Better processes (now) … Cheaper, faster, better (quality), cost avoidance (COPQ) Better future … Easier re-use, future proofing, preservation
- 6. XML providing the potential Better products – richer content Crossref and DOIs (external hyperlinking) Final products (epub, epdf eBooks); internal hyperlinking Indexes, internal hyperlinking Semantic tagging Maximises delivery platform functionality Better process – cost avoidance Benefits in the workflow, regardless of final outputs Standardised tools, workflow QA automation (COPQ) Speed to market Onix bibliographic data Better future Standards – easier for integration, easier to cope with change Ease of transfer and migration For future preservation and re-use
- 7. Drivers – why do it Better products Crossref and DOIs (external hyperlinking) Final products (epub, epdf eBooks); internal hyperlinking Indexes, internal hyperlinking Semantic tagging Maximises delivery platform functionality Better process Benefits in the workflow, regardless of final outputs; speed Standardised tools, workflow QA automation Speed to market Onix bibliographic data Better future Standards – easier for integration Ease of transfer and migration For future preservation and re-use
- 8. Constraints – why not? Costs: Direct (typesetters etc) Infrastructure and maintenance Disruption Author impacts; content variability Inflexibility; supplier choice Lack of skills required in house Supplier impacts: copy editors, existing typesetters Accounting – title level costings/GM may not change, pay back from elsewhere? Usage – PDF downloads vs HTML … still favours PDF “researchers said that they like the PDF and use it to ‘ consume’ an article – to engage with it, scrawl all over it etc”
- 9. Constraints – why not? Typesetter direct costs Book workflows/outputs Workflow delivering print PDF only 88% Workflow delivering standard product files = print PDF, EPDF and epub 2.1 (minimal linking) 100% Workflow delivering print PDF, EPDF, epub plus XML (rich linking) 120% Journal workflows/outputs Workflow delivering print PDF only 92% Workflow delivering standard files = print PDF and HTML 100% Workflow delivering print PDF, HTML plus XML 108%
- 10. Affordability (how to cheat) 0 20 40 60 80 100 120 In house XML/offshore No XML/offshore Depends on your starting point…
- 11. University Press specific bumps Size of output and hence volumes for buying power and amortisation of costs Onshore setting Onshore freelance copy editors DAMS patchy… QA potential? HSS content Speed
- 12. Journals versus books How many workflows? Are journals different from books… “In the realm of technical production, there are differences between monographs and journals, but these are predominantly now the result of legacy systems. There is no reason why books should not feature the same XML- first workflow that is widely used in journal production. After all, the technology behaves in the same way when dealing with 8,000 words or 80,000 words” Martin Paul Eve, 2014 … a book is not a journal, a chapter is not an article Journals … ‘just do it’
- 13. Journals facilitators Standardised inputs; standardised outputs Consistent and repeating structure to articles, written to style Industry standard delivery platform requirements Key areas to code, authors, title, abstract and references – could limit to these/metadata JATS DTD emerging as a default… humanities? “Most” suppliers probably have standard workflow for other customers; not a new build Digital revenue potentially greater now than print revenue
- 14. Journals scenario Define minimum coding requirements for platforms used (authors, title, abstract and references) Offshore coding and typesetting Potentially offshore copy editing Tagging at/just after copy editing Validate DTD (JATS?) Piggy back on supplier existing workflows
- 15. Journals drivers – why do it DOIs article submission and references resolution (external hyperlinking) Full suite of final products (PDF for print; ePDF; HTML); (internal hyperlinking); speed of final files/upload Potential for semantic tagging (hence greater discoverability) Delivery platforms requirements met, maximised functionality Ease of transfer and migration; digital preservation QA automation
- 16. Books – more to think about Chapters of a book have relationships to other chapters (bibliographic references; indexes; cross references) Greater variation of input Less control of authors and styles (e.g. references!) HSS less standardised authoring vs STM Epdf and epub as formats generally work as deliverables; platform requirements less defined Print still essential (at least for HSS)
- 17. Mapping out the journey Q1 2016 Q2 2016 Q3 2016 Q4 2016 TechnicalspecificationOrganisation Systems & business integration Job descriptions Identify systems implications Current capability, DAMS? QA? Receipt? Tracking? Requirements assessment DocumentationProject & change management Workflow specification Content and delivery requirements Confirm QA processesAlign DTD with designs; check content Workflow System selection as required System implementation or modification Run systems tests Run tests on deliverables Supplier contracts Coding rules, supplier instructions DTD Business case Retire legacy systems? QA rules Design spex
- 18. Implementation considerations Where in the workflow (xml first, middle or end?) Technical choices (which DTD etc) Organisational impacts Project management Systems Development approach, who owns and controls the process? publisher predicates and controls subcontract out to supplier, specify deliverables subcontract out to supplier, supplier defined deliverables collective boilerplate
- 19. Where in the workflow? Author creates Before copy editing During copy editing Post copy editing During page make up At final file delivery Post processing (Never)
- 20. Where in the workflow? Before copy editing • Pre-edit for copy editors • Standardised files for copy editors • Standardised tools and processing • Potentially supplier independent • Early identification of issues, rules based checking • Metadata workflow and systems integration • Annoyed authors, delays, confusing • Potential complexity for copy editors • Changes and rewrites • Perfect/finished input • Imperfect initial hyperlinking
- 21. Where in the workflow? Author creates Before copy editing During copy editing Post copy editing During page make up At final file delivery Post processing • Logical • Automation of checks • Possibly being done by suppliers already • Skills sets? Tagging vs grammar • Costs • Resistance ‘traditional’ copy editors • Tools required, configuration management • Author changes and approval
- 22. Where in the workflow? Author creates Before copy editing During copy editing Post copy editing During page make up At final file delivery Post processing • “Not my problem” • Appropriate skill sets • Implicit in the process • Hyperlinking – when to check? • Complexity implementing publisher DTD • Change management • Cost Can you actually tell?
- 23. Where in the workflow? Author creates Before copy editing During copy editing Post copy editing During page make up At final file delivery Post processing • Gives you XML • May be relatively cheap (less infrastructure overhead) • Quality of XML vs DTD • Difficulty for supplier to convert • Time delays • No advantages of QA during the process • What additional QA required beyond usual final file checks • How to fix errors identified and issues
- 24. Where in the workflow? Author creates Before copy editing During copy editing Post copy editing During page make up At final file delivery Post processing • Only code what you need as XML, on finished version • Insert single point of control – consistency of XML • Include with other processing requirements • Only subset of content as rich XML • Time delay • No advantages of QA during the process • What additional QA required beyond usual final file checks • How to fix errors identified and issues, some product already published!
- 25. Where in the workflow? Author creates Before copy editing During copy editing Post copy editing During page make up At final file delivery Post processing (Never) LeastCostMost LeastFunctionalityMost
- 26. Implementation considerations Where in the workflow (xml first, middle or end?) Technical choices (which DTD etc) Organisational impacts Project management Systems Development approach, who owns and controls the process? publisher predicates and controls subcontract out to supplier, specify deliverables subcontract out to supplier, supplier defined deliverables collective boilerplate
- 27. Organisational impacts Q1 2016 Q2 2016 Q3 2016 Q4 2016 TechnicalspecificationOrganisation Systems & business integration Job descriptions Identify systems implications Current capability, DAMS? QA? Receipt? Tracking? Requirements assessment Documentation Project & change management Workflow specification Content and delivery requirements Confirm QA processesAlign DTD with designs; check content Workflow System selection as required System implementation or modification Run systems tests Run tests on deliverables Supplier contracts Coding rules, supplier instructions DTD Business case Retire legacy systems? QA rules Design spex
- 28. Project management Q1 2016 Q2 2016 Q3 2016 Q4 2016 TechnicalspecificationOrganisation Systems & business integration Job descriptions Identify systems implications Current capability, DAMS? QA? Receipt? Tracking? Requirements assessment Documentation Project & change management Workflow specification Content and delivery requirements Confirm QA processesAlign DTD with designs; check content Workflow System selection as required System implementation or modification Run systems tests Run tests on deliverables Supplier contracts Coding rules, supplier instructions DTD Business case Retire legacy systems? QA rules Design spex
- 29. Project management Development approach, who owns and controls the process? publisher predicates and controls subcontract out to supplier, specify deliverables subcontract out to supplier, supplier defined deliverables collective boilerplate solution (establish common standard requirements and operating procedures) Roll out… big bang, gentle migration how to handle business as usual plus extra new work
- 30. Systems Q1 2016 Q2 2016 Q3 2016 Q4 2016 TechnicalspecificationOrganisation Systems & business integration Job descriptions Identify systems implications Current capability, DAMS? QA? Receipt? Tracking? Requirements assessment Documentation Project & change management Workflow specification Content and delivery requirements Confirm QA processesAlign DTD with designs; check content Workflow System selection as required System implementation or modification Run systems tests Run tests on deliverables Supplier contracts Coding rules, supplier instructions DTD Business case Retire legacy systems? QA rules Design spex
- 31. Sales – revenue opportunities HR – communication; roles Production – workflow; process; suppliers Editorial – content drivers Technology -- systems Marketing – discoverability; profile Decision?
- 32. XML – not more trouble than it’s worth Timing/resources Is this the best way to spend your money and effort, now? Are there other short term improvements to focus the team on first? Metadata accuracy and distribution Minimizing stock risk for legacy print; warehousing costs Eyes open; clear expectations; engage everyone Understand the consequences (suppliers, systems etc) Define your minimum success criteria; how will you know when you’ve reached your initial goal; how long? Not a solution looking for a problem, define the problem