When eLife was launched in 2012, almost all article metadata was collected from what the corresponding author entered into the submission form during the peer review phase. These data were converted to JATS XML at acceptance and, with the text of the author Word file, were fed to the content processor (typesetter/compositor) to generate full text XML during production, resulting in final output for publication of the version of record (XML, HTML and PDF). This paper will describe the benefits and limitations of this approach, and how and why eLife has reverted to a more traditional method of using the complete author's Word file to generate elements of the XML metadata within the production process.

eLife also publishes the accepted manuscript PDF for approximately 60% of accepted articles. This is done within days of acceptance and is followed up later by the full text final version. This process still relies on the metadata entered via the submission system to generate the HTML heading and metadata information online (from JATS XML).

Aspects of the peer-review process and submission system that affect the acquisition and conversion of article metadata for both accepted article PDFs and the final version of record will be discussed. I will also outline the challenges eLife encountered in the efforts to streamline the production process and improve the end-to-end author experience.

Introduction

eLife aimed to achieve an XML first workflow for all metadata but found this more difficult to achieve than anticipated. When setting up the publishing platform, the submission system and the production vendor, we selected the most secure and flexible vendors to partner with us. Since that time we have replaced some of those partnerships and built internal workflows to get us closer to our goals of an efficient, fast, and author-friendly workflow.

There are benefits and limitations to all workflow approaches, and this paper will describe our experiences to date, focusing mainly on the process from submission to publication. I will describe three variations below, with the benefits and pitfalls, as well as eLife-specific issues.

1. Metadata output as an XML source for production

When the submission system was set up we planned to collect all metadata from the corresponding author via the submission screens, thereby eliminating the content processor (typesetter/compositor) requirement for finding the information from different parts of the manuscript and key information that may be hidden within the text (for example funding details). This would also mean that the metadata would arrive into production in a structured XML format - JATS XML.

The corresponding author was asked to input the following information in the submission screens:

• title;
• abstract;
• author details – names, affiliations (subdivided into department, institution, city and country), any present addresses, whether corresponding author, which authors contributed equally, contribution statements and competing interests;
• group author details, if applicable;
• funding details (funder, grant reference and authors associated with the funding);
• major datasets generated and/or used (authors, year, title, source, url/accession number, accessibility statement);
• ethics statements (human, animal, clinical trial registration);
• major subject area, research organism and author-defined keywords.

The authors were informed the title page they provided within their article file would be removed before the accepted article would be sent through to production, so the information on the submission screens had to be accurate.

2. All key metadata output as XML source for production but supplemented by author Word file

Late in 2015 we changed typesetting vendor. The new vendor would convert the author Word file to HTML/XML at the point of output and encouraged us to use what was in the author's Word file as well as the XML output to convert the content. As a result we stopped removing the author’s title page and started delivering all information to the vendor on acceptance.

3. Reduce key metadata output as XML source for production, rely more on author Word file

We are now in the process of reviewing the submission screen requirements and reducing them, to reduce the amount of input required from authors. However, as our author accepted manuscript publication workflow still relies on these data, we cannot remove all submission requirements and revert to the author Word file completely.

General observations

There are some things many authors see as unnecessary or don’t understand from an XML point of view, so if a publisher wants clean and good XML output, some QC will always be required. For example, authors can list a number of different departments in the same field on the submission screen (or string of text in their Word file), but in the XML each department should be listed as its own entity (e.g. <institution content-type="dept">). Authors don’t always supply all necessary information required to find a source, for example a database accession number or url.

Production workflow changes and future plans

We now convert to HTML and have XML available from the point of content entering into the production workflow, and the typeset PDF is available at any point thereafter (it can be automatically re-generated at each point of the production process, incorporating any changes). We can view the content at any time in the process, and all actions are made in the single online HTML viewer system, whether it is a production, content processor, copy editor or author action. This means eLife is much more in control of content during production, and we have access to it at any point. We can drop additional assets into the article when they are ready (for example, eLife publishes the author’s decision letter and response, which are delivered to production a few days after the main files and data, and the eLife Digest, which is delivered 5-10 days after acceptance). We automatically send a link of the “Proof” to author when we know the paper is complete and ready for them. We receive the author’s reviewed content automatically, and we can automatically sign off for final delivery and view the content on the hosting platform within 10 minutes.

In theory, based on the new workflow we now have in place, we could publish final content within a week of acceptance, if not sooner, and with no intervention from the content processor, except their initial pre-editing and/or copy editing.

Using this new platform, we can speed up our production times, and we can add new features to our workflow. For example, we plan to allow authors to add ORCIDs to their paper during production, using ORCID’s system-to-system authentication so they are validated, via the author proofing tool. We also plan to add more metadata to the funding details; this is available from the FundRef database.

Now we are more in control we can make more process improvements and reduce turnaround times.

Conclusion

Until authors submit and convert to HTML from the point of submission and edit in a common system that is built for this type of content and can convert to XML at any time point, we will not escape most of the issues discussed above. Once we get to that point, production and editorial workflow processes merge into one, and we will have the potential to publish the author’s final version of record article in full text HTML/XML at the point of acceptance, or even submission (bearing in mind support for preprint repositories).