Blending semantic markup, visual layout, and collaborative editing

[nawkboy]

When initially authoring content I am a big fan of writing in simple plain text, or some form of basic semantic markup. The two semantic markups that come to mind are Markdown and LaTex. This approach keeps down the cognitive clutter and is also very conducive to keeping the text under proper source control using tools such as Git, Subversion, or the like. It also lets people use most any plain text editor of their choice. Even the Scrivener type fans are effectively plain text people.

Layout and graphic design on the other hand is best expressed visually. Performing page layout in something like Affinity Publisher, InDesign, etc. is a great improvement over writing TeX, LaTex, or groff macros or plugins. Unfortunately, I'm not aware of any visual page layout tool that can easily consume a simple semantic markup file for the text content (IDML doesn't count). There would need to be some simple user friendly way to extend to the semantic markup notation to map it to new paragraph or text styles above some pre-defined basic set.

Lastly, some sort of collaborative editing support for the body text such as that seen in Google Docs would be exceptionally useful. The collaborative editing and commenting capability would only need to focus on the semantically marked up text. Presumably the visual layout design would have to remain a locking style model given the complexity of providing automated merge functionality on visual layout. Think of a marriage between something like Google Docs and a Git backed wiki with semantic markup text files.

All of this would need to be designed from the perspective of the overall ecosystem, while ensuring as much flexibility in tooling choices as possible. The key bit of missing functionality is the ability of Affinity Publisher to consume simple semantic markup; yet any testing, tutorials, and documentation need to keep the bigger context in mind. This includes making sure there is support for a build system to easily kick off a command line run which will render a PDF or any other supported output format.

To achieve meaningful market impact will likely require key functionality is open source. One shouldn't have to fight license problems when trying to get the solution to run on a continuous integration infrastructure. At the same time, interactive usage will probably need to require a license. The revenue challenge is to figure out how Affinity can be properly paid for its efforts while not destroying the usability and mass market affordability of the product offering.

 

 

[sfriedberg]

I do not want collaborative editing a la Google Docs.  Not at all!  I want the editor (singular) to control the document.  However, I do want contributors to be able to edit/update text flows, including marked-up text flows, and have the editor notified (as currently) when the external linked source files are updated.

One thing I'll add to @nawkboy's comments, is that ingesting marked-up copy, and round-tripping marked-up copy through external editors, potentially have a very close relationship to a native plugin interface.  Tagged content is collected (generally from many scattered spans of the document) for the appropriate plugin, the plugin does arbitrary processing, often involving external databases (like content management systems, bibliographic reference lists, etc), and supplies replacement content back into the layout program.  The original tagged content remains in the document, but it's the replacement content which is used for text flow and related layout.  Replacement content can include images and styled text, not just raw keystrokes.

Oh, and "simple .. way to extend ... semantic markup to .. paragraph or text styles".  CSS is an excellent example of how styling can be applied to a semantically structured document.  Many of those principles could be applied to ingest of semantically marked-up copy.

[PaoloT]

This would be great for magazines.

I'm a technical writer, and I can foresee the beautiful workflow of single-sourcing in markdown, and then releasing the documents as a web help (via conversion to HTML) and as a page layout (via conversion to Affinity Publisher styled documents).

Being able to re-edit the source markdown file, or update the text flow with an edited file, would be essential.

Paolo