What is Visimark?

Visimark demoVisimark demo

In short, Visimark is a way of creating and editing XML texts without tags, so that even inexperienced users can create highly structured texts, without requiring any technical training.

Visimark is based on the general purpose text conversion system I created to recover and remodel legacy digital or non-digital content into modern formats. In fact, it’s a real-time, two-way rich text conversion process.

Nowadays, a lot of scholarly texts are XML-based, either for general-purpose formats like TEI, or for more specialized texts like e.g. dictionaries. Despite their popularity, one of the most relevant barriers for their usage is represented by the editing experience: whether you use some sort of grid-like systems, which visually represent the XML tree structure with nested text boxes, or just directly type tags with a wealth of aids (syntax coloring, tag autocompletion, real-time validation and preview transforms, etc.), these solutions are often far from being ideal.

As for grid-like solutions, they can be perfect when you are editing lists of XML records, but they fall short when dealing with large and highly structured texts. In this case, entering data in indented boxes may quickly become a nightmare: it’s very easy to get lost in a visual structure which is much larger than your screen, and you completely lack a global vision of the document you are editing. Also, most editing operations, like e.g. cutting and pasting portions of text around, become cumbersome and unnatural.

Editing an XML text like a grid

As for XML direct editing, it can be the best solution for an expert user, but this is not the case for the majority of non-technical users who might require to enter these texts. In most cases, these are scholarly texts related to humanities, and their nature often involves people skilled in different fields, who ask for the simplest technical solution, and just have a word-processor editing background.

The Visimark Approach

Visimark started right off the editing habits of its candidate users, which are connected to two main experiences: visual-based, and content-based.

The visual-based experience is the traditional word-processor/web-CMS like environment, where you just apply formatting properties to the text (bold, italic, color, etc.), and immediately see the results. Most users are happy with such systems, but of course for XML we require a way to handle structural markup, which is content- rather than presentation- oriented. For instance, in a TEI text you usually mark things like divisions, paragraphs, strophes, verses, page boundaries, foreign words, etc. rather than things like bold, italic, red, etc.; and the structures being marked are often complex and highly nested.

The content-based experience is provided by lightweight markup languages, like the popular Markdown, which use some content-based conventions to represent meta-textual data; later, it can automatically be converted into a full HTML code. For instance, in Markdown a line starting with a single # character represents a first level heading, and another starting with ## represents a second level heading; a series of lines starting with a dash represent a bulleted list; text between _ characters represent emphasis, and between __ strong emphasis; and so forth. In this case, you are using some content-based conventions to represent meta-textual data with text characters.

Visimark combines both approaches to let users type XML documents without any XML tag. All the meta-textual data are represented by visual-based (e.g. bold or color) or content-based (e.g. a line starting with # for a header) aspects. All these aspects are not predefined, but are differently used according to the XML format you are handling, and the preferences of your users.

For instance, if editing a text representing a dictionary, you might want to represent a lemma with red color, and a sense section with a line including just a number, representing the sense number itself (1, 2, 3…), like this:



a simple device for calculating, consisting of a frame with rows of wires or grooves along which beads are slid.


the flat slab on top of a capital, supporting the architrave.

In some lexicographic XML dialect, this might be translated as a lemma element followed by a group of sns (senses) elements:

<item><lemma>abacus</lemma><gc><sns>a simple device for calculating, consisting of a frame with rows of wires or grooves along which beads are slid.</sns><sns>the flat slab on top of a capital, supporting the architrave.</sns></gc></item>

This way, users would just select “lemma” from a drop-down list of available semantic markers (e.g. lemma, grammatical information, pronunciation, etc.), and type the lemma, which would happen to come up in red; or type a number in a new line, and then start entering the text for a new sense after this line. He would end up with a rich text using some conventions, which can later be converted into an XML dialect (or whatever else).

We thus deal with a rich-text where formattings and/or conventions are used to represent meta-textual data. Whenever required, Visimark can take this text and produce a fully well-formed and valid XML code in the dialect of choice. In this case, what happens is just a conversion from a rich text to an XML text.

What really makes Visimark an editing tool, is that it is capable also of the inverse conversion: it can take the XML text, and produce a rich text following all the rules defined to represent meta-textual data in it, with formattings and/or conventions.

In both cases, whatever the direction of the conversion, it happens in real-time. Thus you can effectively switch from one editing mode to another, and have a full-fledged, real-time conversion system, which takes rich texts and produces XML, or takes XML and produces rich texts.

This way, inexperienced users just type text like in a traditional word processor, applying either logical (e.g. “lemma” represented by red) or presentational (e.g. “bold”) formattings; also, they follow some content-conventions when required, to represent other structural aspects of their document (e.g. a line starting with # to represent a header opening a section). This greatly simplifies editing, and often also speeds it up, insofar as picking a color from a drop-down or typing a character is quicker than typing several characters for the opening and closing tags.

For instance, think of a TEI text representing a simple group of lines, like:

<l>Nel mezzo del cammin di nostra vita</l>
<l>mi ritrovai per una selva oscura</l>
<l>che la diritta via era smarrita.</l>

Here, lg represents the line group (and the type attribute its metre), and l each line (and the n attribute its numbering). Say that in our Visimark rich text we want to represent the start of a line group with a line starting with %, eventually followed by the metre name; and that after this, each line just represents a verse. Eventual numberings are typed just like in a printed text, as our convention will be that whenever we find a verse starting with a digit, all the characters from that digit up to the first whitespace represent the number. Thus, we might type:

1 Nel mezzo del cammin di nostra vita
mi ritrovai per una selva oscura
che la diritta via era smarrita.

This automatically gets converted into the above XML, and vice-versa.

Another example shows even more clearly how quicker we can get: let’s take the case of CBML, an XML dialect used to represent the text of comics. Here, a typical structure is represented by the panel, which has a list of the characters in it (characters element), their balloons (balloon element), sound effects (sound element), and captions (caption element). For instance:

<panel characters="#superman #policeman1">
<balloon who="#superman">Hello, sir!</balloon>
<balloon who="#policeman1">Hello.</balloon>
<caption type="newspaper">Audacious robbery at the bank...</caption>

Say we want a rich text where panels are wrapped into lines with [[ and ]], each balloon is a line of text beginning with a speaker name wrapped in [], and each caption a line eventually starting with its type wrapped in :. Here is the result:

[#superman] Hello, sir!
[#policeman1] Hello.
:newspaper:Audacious robbery at the bank...

Here too, we automatically get the CBML code above from this rich text, and vice-versa. Further, you may have noticed that the list of characters does not appear in this rich text: this is because it is automatically built by the conversion itself, thus saving a lot of tedious (and error-prone) work to editors.

Using the Demo

The Visimark demo is a simple, no-frills demo setup to show how Visimark works with a selection of XML dialects.

The details about each dialect and the corresponding Visimark rich text are beyond the scope of the demo, but you can just use as a starting point the sample XML code provided for each dialect in the demo itself. First of all, you must pick a profile, which represents both the XML dialect and its corresponding rich text. You will find a number of XML dialects used for different projects: some are subsets of TEI or TEI-derived dialects like CBML, more or less specialized for different types of documents; others are related to some XML lexicographic dialects I designed for a business project.