From b60e8dc3b8cf07186212042310fe9552fed483cd Mon Sep 17 00:00:00 2001 From: Adam Hyde <adam@coko.foundation> Date: Fri, 7 Jan 2022 20:34:48 +0000 Subject: [PATCH] Update aTypescriptForTheWeb.md --- src/articles/aTypescriptForTheWeb.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/articles/aTypescriptForTheWeb.md b/src/articles/aTypescriptForTheWeb.md index 3b48eb5..07285f5 100644 --- a/src/articles/aTypescriptForTheWeb.md +++ b/src/articles/aTypescriptForTheWeb.md @@ -1,10 +1,10 @@ --- title: "A Typescript for the Web" -subtitle: "" -author: Adam Hyde +subtitle: "Why HTML is a better starting point than .docx" +author: Wendell Piez and Adam Hyde date: "2016-12-05" --- - +<p>Originally written in 2016, small updates in 2022.</a> <p>In the days of the typewriter, a typescript was a typed copy of a work. The typescript copy was used for improving the document through the editorial process – for reviewing, commenting, fact and rights checking, revision etc.</p> <p>For many years, since the advent of desktop publishing, the hand-typed typescript has been replaced by Microsoft Word documents. This advanced the publishing world quite a bit. Emailing typescript in the form of Word documents was far easier than mailing paper copies, and making revised copies moved from being an arduous typing exercise to the one click ‘save as’<span style="color: #ff0000;">.</span> There are obvious efficiencies.<p></p> <p>But now we are in the age of networked documents. We have the opportunity to make another paradigmatic workflow change – in a sense: bringing typescript to the browser. With this evolution, we can bring an end to many of the frustrations of emailing Word documents around for comment and revision – while exploring wider options for collaboration, innovating more interesting content types, more easily understanding and managing a document’s history, using automated typesetting and data exchange. All of these represent cost and time savings for the publishing process and have the potential to move the communication of research beyond the <a href="https://coko.foundation/publishing-for-reproducibility-collaborative-input-and-networked-output/">limited paradigm of the manuscript.</a></p> @@ -23,7 +23,7 @@ date: "2016-12-05" </ol> <p>Interestingly, since HTML does not require you to enforce a strict document structure if you do not have it, an unstructured document flows into HTML as easily as a structured, or partially structured, document flows into it. If your aim is a well-controlled document format, such a failure to enforce strict structures is regarded as a flaw or weakness. Yet, since we do not have much or any document structure in the originating Word document, and our goal is to improve it – HTML’s flexibility becomes a critical feature.</p> <p>This process produces an intermediary carrier format — an information- rich, sanitized HTML format that is suitable for improvement. In an HTML editor, we can then bring to bear further tools for adding structure, reviewing, commenting, revising. Hence, there is a kind of similarity to its historical predecessor – which is why we are using the working title ‘HTML typescript’.</p> -<p>If the decision is to improve the structure programmatically, the Coko INK platform comes in nicely. INK enables developers to chain conversion steps together. Hence, a developer can use an XSweet “docx extraction†to get to HTML typescript, and then write (or reuse) another step, in the language of their choice, to do structural interpolation. By separating concerns here, XSweet under INK allows developers to provide structural interpolations that suit the kinds of content their organisations are working with, in the way that makes most sense for them.</p> -<p>When manual improvement is required, we can use sophisticated editors like those built with the <a href="http://substance.io">Substance</a> libraries. These editors manage strict control of the source and ensure that the manually applied structure is semantically robust. This also means that we can apply explicit structure to the text and co-relate that to the other output formats we require, such as JATS XML.</p> +<p>If the decision is to improve the structure programmatically, the Coko XSweet platform comes in nicely. A developer can use an XSweet “docx extraction†to get to HTML typescript, and then write (or reuse) another step, in the language of their choice, to do structural interpolation. By separating concerns here, XSweet allows developers to provide structural interpolations that suit the kinds of content their organisations are working with, in the way that makes most sense for them.</p> +<p>When manual improvement is required, we can use sophisticated editors like those built with the <a href="http://prosemirror.net">ProseMirror</a> libraries (such as <a href="https://waxjs.net">Wax</a>). These editor manages strict control of the source and ensure that the manually applied structure is semantically robust. This also means that we can apply explicit structure to the text and co-relate that to the other output formats we require, such as JATS XML as Coko has done with the Wax-JATS editor.</p> <p>It is not a revolutionary new approach, rather a shift in emphasis. By avoiding over-complicating the conversion as described above, we have been able to make faster headway – and to turn our focus to the tools required to support the editorial processes via a web-based typescript.</p> <p><em>Post by Wendell Piez and Adam Hyde.</em></p> -- GitLab