The benefits of XML-First workflow in Digital Publishing

Picture this: A publishing house receives manuscripts as word files from authors, editors, subject matter experts, and other contributors. They are then typeset on InDesign to make interactive PDFs as end-deliverables.

 

What does such a process flow typically indicate?

A print-first production that is prolonged and less dynamic in nature. In this context, what can a markup language do? Provide a streamlined approach that considers several aspects of the publishing process in the digital environment.

 

XML markup is not new. The first version (1.0) existed in 1998 and was developed by the SGML Editorial Review Board. At that point in time, the primary deal was to enable Internet usability, along with compatibility, stability, and formation. XML describes content in structural terms and uses semantic tags to communicate structural definitions. With time, the relevance of maintaining file stability and adaptability to various output formats became crucial. And that’s also when digital took the world by storm.

 

A quick peek into the digital publishing setup today and one of the oft-heard terms that holds significant ground is the XML-first approach. It’s commonplace. It’s that one comprehensive approach that digital publishers fall back on to produce any form of content in digital formats. So much so that XML-first is the new normal for publishing and is characterized by a size and layout-agnostic principle. Documents are turned into pure information, ready to be displayed virtually anywhere, thereby, making it consumable and reinterpretable across several media.

What is an XML-first Workflow?

In a traditional workflow, content creation and editing come first. Sometimes the entire document is converted to PDF on its way through different channels. Only at the end are XML tags added. Contrary to that, with an XML-first workflow, XML tags are inserted from the start, and documents are formulated with XML in retrospective effect from the beginning. XML severs the ties between content and layout (so, it separates content from format). Hence, content is secure, editable, and rendered convertible to multiple output formats.

 

Here’s a take on the pros that an XML-first adoption in digital publishing lends itself to.

Welcomes platform independence and interoperability!

When publishers take care of XML upfront, it simplifies the publishing process by enabling the delivery of multiple digital formats such as HTML, ePub, PDF, ePapers, eMagazines quickly. Besides, it helps repurpose content and layouts across various platforms such as InDesign and QuarkXPress.

Brings intuitiveness at its core

By implementing an XML-first workflow, we get intuitive documents that adapt themselves to any publishing medium. This in turn enables useful repurposing of content to eliminate redundancies as well. It also minimizes the need to convert one format to another every single time, thereby increasing publishing efficiency.

Makes way for collaboration

By incorporating XML tags right at the authoring stage, independent chapters can be handled by different editors/SMEs simultaneously, setting the stage for collaboration. This also paves the way for making global style changes effortlessly and designing content that is well-suited specifically for the web.

Fits the web quite naturally

Using an XML-first approach tailor makes content to make it work for the web. It helps publishers amplify their market leadership by eliminating the need to re-create content across different channels and platforms and steering publishing efficiency.

So, what does the future hold?

In the realm of digital publishing, infusing manuscripts with granular XML encoding prior to typesetting ensures an enriched, consistent product that works for the digital world. Particularly, if typesetting is managed in-house, applying an XML-first workflow helps typesetters with their work.

 

When an XML file is ingested into a typesetting application, the content styles are already established. The underlying code has organized the text into its various components, even down to the individual parts of a reference. XML-first is flexible and can be added as a new step in your workflow without overhauling the entire system. In fact, changing this one step will make the rest of the process easier even if everything else stays the same.

To Script or to plug-in

Publishers, worldwide, have accepted InDesign over the years as a worthy tool in their arsenal. One of the main reasons for InDesign’s acceptance is its design capabilities and scope for automation in a world that demands extremely short TATs and cost efficiencies.

 

Automation in InDesign can either be done from a high-level approach with supported scripts or diving deep into the InDesign SDK and develop a native plug-in. Both approaches have their advantages and limitations.

 

Let’s look at the easier option of scripting first. InDesign offers great support for scripting. Creating and running a script in InDesign is relatively inexpensive, easier for the programmers, and has a short turnaround time to develop. One can say that almost all of InDesign’s functionalities can be evoked through the ExtendScript Toolkit. For these reasons, a faction of developers go the script road rather than develop a plug-in. Scripts can be used for simple tasks like how a macro functions and also for complex tasks that improve performance.

 

InDesign evolved and with the introduction of the Script UI. Scripts could be run in the background and could be run in interfaces involving dynamic input. With Script UI, scripting embraced greater functionality and could dream of scaling up to plug-ins’ capabilities. However, scripting can be used only to automate existing functionalities and plug-ins allow developers to create new functionalities and create value in situations where high performance is vital.

 

For this reason, a segment of developers swear by plug-ins and take the time and pain in deep level coding that allows them access to InDesign’s core architecture. While InDesign’s SDK is extensive and requires a deep understanding of C++, standard libraries, and software patterns the benefits outweigh the effort involved. Plug-ins can create newer functionalities and offer seamless integration in high-critical areas.

 

The question then arises, “What should a publisher and their supplier choose to leverage their automation processes?” There is no universal solution. The journey continues and each software engineering team has to create their own solution to meet their custom needs. To script or develop a plug-in for extending functionalities — that’s for the customer’s needs to decide.