The invention is a Conscious Editing Environment (C2E) for collaborators to create deliberate, intrinsic, context-anchored diffs (change/edit/instructions) in a structured XML document presented as HTML. The diff entry interaction is set up in a way that it prevents inadvertent errors. At its core, C2E is a diff-authoring environment and not a document-authoring environment.

The invention is currently implemented in a web based proofing application that acts as a single platform for authors to verify the copyedited proof of the articles and communicate the changes to resources in journal production that consolidate the edits and the instructions made by the author. In this application, direct keying-in into the document is prohibited but deletes, inserts and instructions can be created. The micro-level diffs are stored in the system for further analysis and evolution of the system. Interactive dashboards for queries, replies and discussions based on a particular part of text also build further on the features of the current generation of blog-editors.

A Conscious Editing Environment IC2E)

The invention in appreciation of publisher needs, provides a platform that does not allow too many or drastic changes to the peer-reviewed manuscript. The extent of control/freedom however is fundamentally scalable. TNQ speaks of this as a Conscious Editing Environment (C2E).

A Change Publishing Platform (C2P)

The invention is also a Change Publishing Platform (C2P) that keeps track of and interim-publishes all changes to a manuscript, aggregating and (interim) publishing these changes to stakeholders, until the manuscript is signed and shipped out to the host platform or print house. As a Change Publishing Platform, the invention fits into various use cases - as a more flexible online platform for revising a previous edition of a book, as a companion website to make available additional material for a book that has been printed.

An End-to-End Publishing Platform Central to the publishing process, quite literally, the invention is engineered in such a way that it can extend forwards and backwards - as a Submission System that accepts and screens manuscripts, reporting to author, editor and publisher, as a Peer Review Workflow and Content Management System, as an Online Content Rendering, Interaction and Communication Management System, the invention
discloses a clear roadmap to engineer and deploy the various functionalities visualized for the working of the invention. Both demand and development are apace.

Traditional Methods of Editing
Conventional editing allows direct keying in of characters in a WYSIWIG environment (MS Word) or in code view (Wikipedia/LaTeX). The diffs are system-created and the user is not in full control. If numerous changes, for instance, are introduced in a paragraph, the system more often than not shows that the whole paragraph has been replaced. The excessive reliance on the system to create the diffs and its consequent failures are mitigated in the Conscious Editing Environment where the ability to control the diffs are handed to the user who is capable of taking more intelligent decisions.

Traditional Method of Proofing

The page proofs PDF of the articles is hosted on the web and the web URL is e-mailed to the author. The author annotates the PDF or prints and marks corrections on the hard copy. Author emails the annotated PDF or scanned copy of the corrected PDF to the Publisher. Apart from this, other reviewers also get emails with the proof PDF.

The major drawbacks of this method:

■ Non-visibility of copyeditor's corrections to the authors. This forces the authors to read the entire proof again

■ Author not answering all queries raised during copy editing. In this case, the unanswered queries are again raised and the article is kept on-hold till the author response is received

■ Author corrections not legible for master copying. Few authors are not comfortable with annotation. So they print the proof, make the corrections manually in it and mail the scanned copy of it.

This manual corrected proof may not be clear for master copying

• Multiple sources of corrections. In some instances, apart from annotated PDF, author sends the corrections via other medium like e-mail, scanned copy, etc.

Lack of accuracy in executing the author correction during master copying. Since annotation is freehand tool, there are possibilities of misleading the correction

■ Handling PDF files required installation of third party

Due to these reasons the turnaround time in this stage is comparatively very high. This affects the timely publication and thereby increases the cost and time for publishing.

A Novel Solution to Alleviate Author Proofing
Scripts are employed to convert the Page Proof XML to HTML which is presented as an online proof. This acts as a single platform for authors to verify the page proof of the articles and for typesetters to carry out the author corrections accurately and quickly. This application also tracks the changes and provides an overview of instructions and changes made by each collaborator on an article. The application can provide reports on the changes made. It reduces the need for subsequent manual intervention and thereby increases the overall quality of the correction process.

The application restricts the author to submit the proof without answering all queries. Since the complete process happens within the application, the problem of multiple sources of correction is eliminated.

Architecture

Component Architecture

The application is designed with the following components illustrated in fig.l:

■ Validator
■ Prep Tool
■ Editor
■ OUT XML Creator
■ Workflow

Functionality of the components are listed in the below table

Component I Functionality
Validator I Validates the input file (article XML)
Intimates the errors, if any, to workflow during validation
Prep Tool Creates HTML from the article XML
Processes images for proper loading in the browser Converts Math equations into images

Editor Loads the articles in the browser

Enables edits and save, and provides various basic formatting features OUT XML creator Generates OUT XML (corrections from HTML IS transferred XML Workflow Integrates the other components
Communicates to suppliers, authors and publishers

Technology Stack

Technology Description
Java with XSLT To transform XML to HTML for online rendering, and then finally transform back the HTML to XML PHP Server-side language for managing online content and users JavaScript Browser based scripting language to provide rich user- friendly edit operations MySQL Database persistence
Linux Operating system

Server Architecture
The production environment may be hosted in any web services such as Amazon Web Services using EC2 Instance, Elastic Load Balancer, S3 for Storage and RDS for database. Amazon Web Services available in multiple regions with multiple availability zones can be used for this application.

To have better user experience, the web component may be maintained in Web Server and input/output, and workflow components are maintained in App server.

Two instances of Web and App servers may be maintained in two different availability zones data centers in Amazon to reduce any risks associated with service outages to a particular availability zone.

The web servers are mapped under a single load balancer which will help to manage the load and traffic to the application as well as to ensure service availability in the event of an outage affecting a web server in an availability zone.

Database servers are created in two different availability zones in the selected web services, and both the failover and failback will be automatic.

The whole set-up can be constantly monitored from a remote monitoring centre using CloudWatch.
Fig.2 depicts the server architecture of the application.

Workflow

If a publisher wants to host an article, they have to create a zip package containing the article XML, images and other supporting files. When dropped into the FTP site, the Proof XML is converted to HTML to provide an online proof to the author. The author can edit this proof, answer to the copyeditor's queries, introduce new corrections and attach files. Once the author submits the corrections, the page proof XML is updated accordingly. The updated XML can be viewed as an online proof with author corrections. The supplier can validate the corrections from the author and introduce new corrections.

Supplier submits the corrections after validation. On submission, the application generates two XML files - OUT XML and Diff XML, in which the validated corrections are captured. These two files are mailed to Suppliers as OUT package 2. Suppliers can use these XML files to paginate the revised PDF.

IN Workflow
The supplier drops the input zip package followed by the ready.xml file in the production input drop zone.

The supplier should ensure that the XML IN contains Copyediting Track changes and queries in the correct format. The application picks up the input zip package and validates it before processing. During validation, if any error is found in the package, the error report is mailed to the Supplier. The supplier fixes the error and drops the package again in the input drop zone. The package without error is processed and the article link is generated. The generated article link is mailed to the Supplier; in turn Supplier should mail the link to the author. The work flow is illustrated in Fig.3.

Input

A zip package containing the article XML, images and other supporting files:

The article IN XML may contain Copyediting track changes and queries in any one of the below formats.

Format -1

Insertion I <'~xxx
Deletion ] ^DEI^^OE^T
Query !
Replacement xxx

The query identifiers have the form: 'q' followed by the query number, e.g. ql, q5.

OUT Workflow

Process -1: PC Online Mode

In this mode the author made corrections in the PC HTML pages. The supplier validates the corrections from the author and raises queries to the Journal Manager, if required, using the link provided in the application. After validating the corrections, the supplier submits the article. The application updates the final XML and generates OUT PACKAGE 2. The supplier processes the OUT XML and generates the revised PDF.

Process - 2: PC Offline Mode

In this mode the author annotated the PDF file and uploaded it to PC. The supplier downloads the annotated PDF from the Supplier PC link and follows the traditional method of processing.

This work flow is illustrated in Fig.4

Outputs Output XML
OUT XML is a replica of the article XML with validated author corrections captured using OPT (Online Proofing Tool) tags. Three basic OPT tags are used (, , and ) to capture the corrections and uses an error tag () to track the corrections that could not be executed in OUT XML. After processing the OPT tags, Suppliers can use this XML file for pagination.

The naming convention of the file in OUT package 2 is: Journal abbreviation_article number_out.xml (Example: WR_2340_out.xml).

The following table describes the processing of OPT tags:

OPT Tag J Process

... i Delete opening and closing tags.
... Delete opening and closing tags along with the text
enclosed within the tags.

... ! and closinB taSs alonS with the text enclosed within
the tags.

The instruction is captured between the tags and the | text to which the instruction applies is captured as \ SelectedText parameter.

! Refer t0 the correction in the Diff XML or in Edit
Summary. Execute the correction in the OUT XML \ manually and delete this tag. For more details refer to the section "How to Handle the opt Error Tag"

Notes

For instructions on figures and equations, the "selectedText" parameter will be empty in the tag. (...)

Notes
Due to high tag density in Author groups. Affiliations and References, the insertion of text in these parts are captured using tag as shown below: iinsert: school of

The text to be inserted is captured between the tags along with the prefix "insert:".

In the above case, "School of" is the text to be inserted in the affiliation. So insert the text "School of" in the appropriate position and remove the tag.

Notes The nested and tags, i.e. ' element containing an
element' and ' element containing an element' will
result i0000000000000n deletion of the content enclosed within ... tags.

Features of Edited Equations
Equations that were not edited appear in the OUT XML file in exactly the same form as in the input file, including pagination instructions. For equations that were edited in the math editor, the OUT XML file contains the MathML formula that was exported by the math editor. This formula represents faithfully the equation as it was edited in the math editor by the author and/or the MC. The new formula does not contain pagination instructions.

The MathML export formula of the math editor has the following feature:

■ Stretched parentheses are represented by an mfenced element rather than by mo elements. The mfenced expression content is equivalent to xcontenty.

Pagination Instructions
Edited equations are new equations and do not contain pagination instructions. The original pagination instructions are retained in the original equations in the corresponding ... tags.

They can be fetched from there and copied into the edited equation whenever appropriate.

Example:
In the example (Fig.5), MathML tags within ... (highlighted in yellow) don't contain any 3B2 comments, but the corresponding MathML tags within ... contains 3B2 comments (highlighted in green). The user can retrieve these 3B2 comments for opt_DEL>... before processing the ... tags.

Opt Error Tag
When a correction could not be executed in OUT XML, the script marks this correction using tag where "optxyz" is the correction id of the correction. User should carry out this correction in OUT XML manually, either by referring to Diff XML or "Edit Summary".

Using Edit Summary:
Once the OUT package 2 is generated, the corrections, which could not be executed in OUT XML, are marked as error in the Edit Summary.

Step 1: Open the Supplier PC link of the article.

Step 2: ciicdMlillill The Edit Summary pop-up appears as shown in fig.6

The "Edit Summary" is updated with Error marks only after the generation of OUT XML i.e. after mastercopier submits the article without any further Query

The edits marked as ->(Krror) are the corrections, which could not be executed in OUT XML

Step 3: Click on the edit to view the correction in the article

Step 4: Execute the correction in the OUT XML manually.

Using Diff XML:
The opt error tag captures the correction id of the correction that could not be executed in OUT XML.

Step 1: Using the correction id mentioned in the tag, search the same in Diff XML

Step 2: Get the details of the correction in the Diff XML.

Step 3: Execute the correction in the OUT XML manually.

Example:
In the below example (Fig.7), the correction could not be executed in the OUT XML. The sytem captures
only the correction id in this case. Refer to the correction in the Diff XML using the correction id and
execute the correction in OUT XML.

The Diff XML refers to "insert" correction for the correction id:

opt 1144 216 5 7 2
OPT_ID_22 3
223
264
996
change in

Insert the text "change in" inside 223rd tag of the article at character offset 264 from the parent tag manually in the OUT XML.

DiffXML
Diff XML captures all validated corrections with their positional references. This file serves as a reference, when corrections could not be executed in the XML file. The supplier can use this file to check the corrections executed in the OUT XML file.

In this file, a correction begins with and ends with and the elements within these two tags are positional references of the correction.

The file is named as changes2.xml in OUT package 2.

Tag Description
DiffXML uses various tags to capture the corrections. The tags used in the DiffXML are explained below:

Tag Description

j File be§ins witn this ta8
A correction begins with this tag. It captures the type of
correction (Change Type) made by the author or mastercopier. i The various change types used in Diff XML are:

optinsert - insert a text; optdelete - delete a text; optcomment -I instruction on text, figure or equation; optreject - copyediting correction rejected by author; replace - format (bold, italics, subscript or superscript) a text and edit an equation

... ! Correction id - A unique id for every correction except equation editing.

... ! OpT id - A unique id generated by the application for all the tags in the article XML. It numbers all tags in the article XML

sequentially. The numbering includes inline tags like ce:italic.

Copy edit comments INS and DEL are converted internally to ins and del tags. These ins and del tags are also included in the tag I numbering. Other comments and processing instructions are i excluded while numbering. This element is used only for cross-I checking purpose.

Nomenclature of the ID: OPT_ID_tag count.

Example:

we demonstrated that the administration of
i.4nbsp;acidophiliis Dru 3tvi
L.4nbsp;paracase1Vce:italio A13 significantly increased the
IgA 4plus; cell number in the sraall intestine and this effect depended on the
a&im'stration period for S04nbsp;Wa HPH treated cells. vinderola etSnbspjal. (2004) denonstrated that