Balisage Paper: TAGML: A markup language of many dimensions

Philosophy, definitions

From cave wall to clay tablet, and from codex to bits, the way we write and the ways in which we model, store, and process textual objects are influenced by the medium and technologies at our disposal. Hence, over time, we have had various understandings of text, ranging from a sequence of characters designed to support oral recital to a hierarchical tree of objects. Our changing understanding and implementation of our perspectives on what text really is has had consequences for how we interact with textual objects, since the affordances and limitations of a prevailing technology may blind us to aspects not supported by that technology (Dillen 2015, 69). Encoding a historical text in TEI-XML, for instance, might subtly encourage us to ignore textual phenomena that are not part of the TEI-XML encoding model (Sahle 2013, 381–82). We maintain that it is most natural, idiomatic, and inclusive to consider text as a network of often implicit information. Adhering to this conceptual idea of text opens the way to an innovative approach to creating, modeling, and processing textual objects.

This article describes recent progress in the design and implementation of TAGML, a markup language for the Text As Graph (TAG) model of text, from a conceptual and a technical perspective. We characterize the relationship between the markup language and the data model, and we outline how creating layers of markup and annotation on the text allows the user to formally describe complex textual features in a straightforward manner. The article builds on two previous articles on the same topic (Haentjens Dekker and Birnbaum 2017; Bleeker et al. 2018a), which respectively introduced the TAG model and described how to model textual variation in TAG.

Over the past decades, a variety of definitions of the term text has been suggested. In order to construct a well-grounded and useful model, we need a highly refined definition of the textual object, a definition that holds on a conceptual level and one that translates informatically. We therefore propose to distinguish between a conceptual description and a technical description of text. On the one hand, we define written text as a sequence of characters (e.g., letters, digits, spaces, and punctuation in most alphabetic writing systems) inscribed in a document. A document, here, is a physical object that contains some sort of inscribed information. Both text and document are broadly defined, and may also include, for example, the bits on a disk or the symbols carved in a tree. The items that make up written text are culturally determined, and although not all writing is alphabetic, nonalphabetic writing systems also use written symbols to express linguistic textual content.

On the other hand, the TAG model understands text to be a multi-layered, non-linear construct containing information that is at times ordered, partially ordered, and unordered. A layer is, in principle, defined as a hierarchical set of Markup nodes (including associated annotations). By multi-layered we mean that a text in TAG can have multiple layers of markup. A layer is hierarchically structured; layers may overlap. Layers have a key function in TAGML, as is described in Layers.

By non-linear we mean that the text nodes (textual content) of a TAG document do not necessarily form a single ordered list. The TAG model distinguishes three types of information: textual content, textual variation, and markup. These three types of information can be expressed without workarounds in TAGML, as illustrated in Order of textual content.

Textual content in TAG, from an informational perspective, is a sequence of characters (including symbols, but excluding any type of formatting). In the following excerpt from a letter by Willa Cather, the phrase now Mariel I am "packing" and I know you will excuse this brief scrawl makes up the textual content:

Figure 1

Excerpt from a letter from Willa Cather to Mariel Gere, source: letter ID 0005, in the Willa Cather archive, edited by Andrew Jewell (20104-2018)

Markup can be used to make implicit information explicit. Adding markup to a document can be understood as adding one or more layers of additional information (structural, interpretive, etc.) to the information expressed by the sequence of textual characters.

In TAGML, markup consists of start-tags and end-tags. A start-tag and an end-tag together constitute a Markup node. Markup nodes can have attributes, which are called annotations. Annotations are comparable to the attributes on XML elements in that they represent properties of an object. Annotations in TAGML, unlike XML, are typed (Data typing).

Alexandria is a text repository system that serves as the reference implementation of the TAG model, under ongoing development at the Research and Development team of the Humanities Cluster of the Dutch Royal Academy of Science (Alexandria). Within the framework of Alexandria, a view is a version of a TAG document with one or more layers of markup. The concept of view can best be understood from a user’s perspective: similarly to the git (Git) workflow, working with text in Alexandria entails checking out from the Alexandria repository a version of the TAG document with a specified set of layers (the view), editing this view, and checking in the edited view back into the repository. The motivation for supporting customizable views of a TAG document is that the TAG document in its full, hypergraph glory may contain more information (layers of Markup nodes and annotations) than can be visualized in any informative way. In situations where users are able to interact meaningfully with a text without seeing all Markup layers simultaneously, a view enables them to work on specific aspects of a document without distraction by other features. A more detailed description of these concepts is given in TAGML, and the theoretical dimensions of views are laid out in Workflow.

Overview

It is a truth universally acknowledged—at least within the markup community—that a markup technology stack is a complex business. Such a stack typically includes at least four ingredients: a model, a syntax, a query language, and a schema. Haentjens Dekker and Birnbaum 2017, presented at Balisage 2017, introduced the model—a hypergraph model for text—that understood text as a network of information. Our 2017 paper identified a number of textual phenomena that the hypergraph model needs to express, and it showed how the model represents each of them. That paper also introduced the Alexandria prototype implementation of TAG (Alexandria), which can import documents marked up in either LMNL (Piez 2008) or TexMECS (Huitfeldt and Sperberg-McQueen 2003). At that time TAG did not have its own markup language, and it borrowed from the syntax from LMNL and TexMECS to represent features of TAG. Finally, an Appendix to our 2017 paper identified five issues that were not yet part of the TAG model, although they had been identified as important, and therefore as goals for future development:

Our paper begins with an introduction to the syntax of the TAG markup language (TAGML, section “Syntax”), including a formal grammar of TAGML (TAGML grammar). The next section describes a workflow that facilitates editing a multilayered document (Workflow) and sketches at least three implementations of the layer functionality. As an illustration of the workflow we focus on editing a historical manuscript, but TAG also facilitates modeling and processing other types of text, e.g., born-digital texts, or non-literary texts, such as those represented in judicial or pedagogical documents. The consequences and implications for the way we model, work with, and understand text are discussed in the Discussion and Conclusion.

Two essential ingredients of the markup technology stack are not addressed at all in the present article: schema language validation and the query language. We introduce the concept of the schema language in this paper, but it remains at an early stage of development. The query language was introduced in an exploratory way in our Balisage 2017 article, and will be extended in the future. The aspects of the project that we regard as ready for presentation at the Balisage 2018 conference are the TAGML markup language, our modifications to the TAG hypergraph model, and the proposed workflow for managing multiple Markup layers.

Despite work on the (implementations of the) TAG model being under active development, we consider our experiences with developing TAGML as beneficial to a productive discussion on designing a markup language. The affordances of TAG’s hypergraph model allowed us to reconsider ingrained notions of textual features and how to model them most effectively. Our article, then, can be read not only as a technical report of recent project developments, but also as a conceptual and methodological reflection on the potential of markup to express our understandings of text.

Preamble

TAG is designed to be able to model (and TAGML is designed to be able to encode) text and markup, including overlapping markup and ordered, partially ordered, and unordered information. This design principle means that TAG processing can support any type of query, from Boolean to ranked pattern matches at the level of the model, and that the complex mixture of information can be parsed and processed in an idiomatic manner and without work-arounds. Encoding of unordered data is supported in a JSON-like manner (Data typing); as is linking from a TAGML transcription of ordered text to unordered information (Linking elements). Annotations in TAG, unlike attributes in XML, can contain both text and markup. This feature is defined as Rich text (Rich text annotations). Annotations may also have annotations.^[1]

TAGML allows the straightforward expression of the multi-layered, non-linear features of text described in Philosophy-and-Definitions. The following subsections first describe the general features of TAGML: layers, non-linear structures, and order. They then go on to discuss TAGML’s syntax in detail. TAGML’s general specifications are then illustrated with examples that include the (main) constraints of the syntax. Finally, the specifications are summarized in tabular format.

Layers

Layers are used to classify a specific set of Markup nodes. The reasons for grouping Markup nodes together into a set may vary. For example, a set of Markup nodes may express a research perspective on text, as with a layer that consists of Markup that describes the physical aspects or the poetic structure of a text. Alternatively, in the case of an editorial workflow with two or more users, a layer could identify a set of Markup nodes that is added by a particular user.

In TAGML we model containment as well as dominance.^[2] To understand this feature, it is helpful to examine the distinction between total containment, partial containment, and dominance. Partial containment, or partial overlap, occurs when content is shared by two or more Markup nodes. Total containment occurs when all content in one Markup node is shared with another Markup node. In hierarchical terms, A fully contains B means A is an ancestor of B, etc.^[3] Dominance presupposes total containment, but also requires meaningful semantics:

Two basic ways are available to record dominance within an encoding: in the syntax of the document instance or in a schema. In the model of Extended Annotation Graphs (eAG), dominance is represented in the syntax, which means that the dominance needs to be recorded per individual item or element (e.g., A extends B or a > b [Barrellon et al. 2017]).

In TAGML dominance is also represented in the syntax, but in a different way. Rather than specifying the parent node of each node, nodes are grouped in a layer. This means that markup within a layer represents a dominance relationship, while layers that overlap represent containment. This is somewhat similar to the notation that XConcur uses to indicate that an element belongs to multiple hierarchies (Hilbert et al. 2005), but with an important distinction: in XConcur, complete subtrees are shared, while in TAGML indidivual markup nodes are shared between layers. This is more akin to how nodes are shared in Multi-Colored-Trees (MCT, Jagadish et al. 2004). Layers do not have to be defined at the beginning of the document, a new layer can be started at any point in the document, and Markup nodes may be part of multiple layers.

Order of textual content

In general, the text of a TAGML document is to be read in the order in which it is transcribed. Continuous textual content is normally fully ordered. The value of the data is represented by the character sequence, and the order of the characters is therefore an inalienable part of the meaning. Because of its fully ordered nature, the information is parsed and processed by traversing the characters in a manner determined by the writing system (from left to right, proceeding from top to bottom, in the Cather letter).

Textual variation constitutes partially ordered information. Consider the following example, also by Willa Cather:

Figure 2

Excerpt from a letter from Willa Cather to Mariel Gere, source: letter ID 0005, in the Willa Cather archive, edited by Andrew Jewell (20104-2018)

The word white is crossed out, so that the phrase can read either It will be quite a white until school begins or It will be quite a while until school begins.^[4] There are, metaphorically speaking, two paths through the sequence of text characters, which diverge after the word a and reconverge before the word until. Cather wrote the word white before she wrote the word while, and that order is meaningful with respect to the genesis of the text, but synchronically the variation is simultaneous: there is an erroneous path through white and a correct path through while. The two words that alternate are mutually exclusive in terms of whether we choose the original or the corrected reading, and they are at the same distance from the beginning of the sentence, a phenomenon we describe, using terms from graph theory, by saying that they have the same rank. Items at the same rank are logically unordered, which means that although the textual content in general is fully ordered, at the points in the text where variation occurs the textual units (which we call Text nodes) at the same rank on different paths are unordered. Within each path, however, the textual information is again fully ordered.

Order of metadata

Although the combined set of information (i.e., text and markup) is at times ordered, unordered, or partially ordered (see also Order of textual content), depending on the kind of information that is expressed, existing text models and markup languages in wide use are typically well-suited to handle only specific types of information. For example, unordered data can be represented naturally in JSON objects, the contents of which are necessarily unordered. Meanwhile, the XML data model (and associated markup syntax) require that all elements be ordered (and that XML attributes be unordered, about which see below).

Unordered information is commonly found in metadata contexts. For example, a corpus of Willa Cather’s letters might include, perhaps in an ancillary document, biographical information about her correspondents, such as their first names, surnames, birth and death dates, addresses, etc. This type of information is often encoded in name:value pairs, as in a JSON object, and the order of the properties of a JSON object is, by definition, not informational. (An object is an unordered set of name/value pairs. Introducing JSON) In so-called data-centric XML,^[5] a schema may specify that sibling elements that encode name/value pairs may appear in any order, and in this sense data-centric XML may seem similar to name:value pairs in JSON objects in not ascribing meaning to the order of properties. There is, however, an important difference. Two JSON objects that happen to store their name:value pairs in different orders (on disk or in memory) are informationally identical because the order of properties in a JSON object is undefined. But two XML documents that have the same properties in a different order are never informationally identical, that is, deep-equal(). A schema may license alternative orders, and a query may ignore order, but order is an inherent and inalienable part of XML element structure. For example, the use of TEI-XML elements to represent regularization (orig/reg), correction (sic/corr), or abbreviation (abbr/expan) is ordered in the sense that two XML documents that differ in the order of an orig/reg choice are different XML documents, and that difference can be ignored only at the application level. (Bleeker et al. 2018a) XML attributes are unordered, but the type of values they can represent is limited because attributes cannot contain markup, which means that they can represent only flat, atomic content. This means that at the level of the model and syntax, XML has no way of representing unordered content that is more complex than atomic values.

Intermediate conclusion

Many of the features of TAGML discussed above are adopted or adapted from other markup languages, including LMNL, TexMECS, XML, and FtanML. Wherever possible, our goal has been to synthesize effective solutions originally developed elsewhere, and we regard their relative familiarity to the markup community as a virtue. Combined with the affordances of TAG’s hypergraph model, TAGML seeks to realize the full potential of markup for text modeling.

The support for ordered, partially ordered, and unordered information results in an inclusive textual model that not only broadens our understanding of what text really is, but also expands our means of expressing it and improves our means of processing it. These features of TAGML offer users the means to express their interpretation of a text’s structure, its whitespace, and the various data types used in the model. As a result, a TAG file contains a refined and explicit model of text.

Syntax

[ -> \[
< -> \<
| -> \|
! -> \!
" -> \"
' -> \'
\ -> \\

< -> \<
[ -> \[
\ -> \\

< -> \<
[ -> \[
\ -> \\
| -> \|

! -> \!
\ -> \\								

' -> \'
" -> \"
\ -> \\

[line>The rain in Spain falls mainly on the plain.<line]

[line>The rain

on the plain.<line] 

[line>The Spanish rain.<paragraph]

[>The Spanish rain.<]

[line|+A>Cookie Monster likes cookies.<line|A]

[line month_1='November' month_2=11>In the eleventh month...<line]

[animal type="cat" type="feline">Puss in Boots<animal]

[img src='http://example.com/img.png']

[l>When in the course of human events,<l]
[! The spelling and punctuation reflects the original.!]
[l>it becomes necessary...<l]

[!ns p http://tag.com/poetry]
...
[p:poem>Roses are red, .....<p:poem]

[poem type="limerick"
      author='John'
      year=1818
      rhymes=true
      keywords=["unfinished","censored"]>There once was a vicar from Slough...<poem]

[origin 
	location={ 
		position={x=1 y=2} 
		countrycode='nl' 
	}>Amsterdam<origin]

[letter date=["March", 12, "Twothousandeightteen"]>Dear Maurice, ...<letter]

[letter date={month="March", year=2018, day=12}>Dear Maurice, ...<letter]

[q>To be, or [del>to be not<del][add>not to be<add].<q]

[q>To be, or <|[del>to be not<del]|[add>not to be<add]|>!<q]

[q>To be, or [?del>perchance<?del] not to be?<q]

[q>To be, or <|to be not|not to be|>.<q]

[text>Hello, my name is [gloss addition=[>that’s [qualifier>Mrs.<qualifier] to you<]>Doubtfire. How do you do?<gloss]<text]

[line>[a|+A>Cookie Monster [b|+B>likes<a|A] cookies.<b|B]<line]

[line>[a|+A1>Cookie Monster [a|+A2>likes<a|A1] cookies.<a|A2]<line]

[phrase>[phrase>Oscar the Grouch is<phrase] a trash can-dwelling creature.<phrase]

[phrase|+P1>[phrase|+P2>Rosita is<phrase|P1] a bilingual monster.<phrase|P2] 

[text>[phrase|+P1>[phrase|+P2>Music is<phrase|P1] part of<phrase|P2] being human.<text]

[q>and what is the use of a book,<-q] thought Alice[+q>without pictures or conversation?<q]

[markup>Cookie <-markup][+markup> Monster<markup]

[q|+A> Cookie <-q|A] Monster [w|A>likes<w|A] chocolate [+q|A>cookies<q|A]

[q|+A> Cookie <-q|A] Monster [w|+B>likes<w|B] chocolate [+q|A>cookies<q|A]

[q|+A, +B> Cookie <-q|A, B] Monster [+q|A> likes [+q|B> cookies <q|A,B]

<xml>
  <meta>
    <persons>
      <person xml:id="huyg0001">
        <name>Constantijn Huygens</name>
        .....
      </person>
    </persons>
  </meta>
  <text>
    <title>De Zee-Straet</title> door <author pers="#huyg0001">Constantijn Huygens</author>
  </text>
</xml>

[text meta={ persons=[ {:id=huyg0001 name='Constantijn Huygens'} ] }>[title>De Zee-Straet<title] door [author pers->huyg0001>Constantijn Huygens<author] ....... <text]

[q>and what is the use of a <|[del>book,<-q]<del]| [add>thought
Alice<add]|> [+q>without pictures or conversation?<q]

[text>It is a truth universally acknowledged that every <|[add>young [b>woman<add]|[del>rich<del]|> man <b] is in need of a maid.<text] 

[text>It is a truth universally acknowledged that every <|[add>young [b>woman<add]<b]|[b>[del>rich<del]|> man <b] is in need of a maid.<text]

[text>It is a truth universally acknowledged that every <|[add>young [b>woman<add]<b]|[b>[del>rich<del]<b]|> [b>man<b] is in need of a maid.<text]

[text> [q>Hello my name is [gloss addition=[>that’s<-q] [qualifier>mrs.<qualifier] to you<]>
Doubtfire, [+q>how do you do?<q]<gloss]<text] 

Interacting with Alexandria

Working with multiple views in a Git-like manner requires a number of tools, including:

In practice, the workflow for interacting with a TAG document using the Alexandria TAG repository may look as follows:^[9]

This workflow is similar to the one described for concurrent XML in Iacob and Dekhtyar 2003 and Dekhtyar and Iacob 2005; see also their Iacob and Dekhtyar 2005. Concurrent XML, however, refers to multiple markup layers over a common text layer, while the TAG workflow permits editing the textual content of a view, and not only the markup.

In principle, the user never interacts directly with the master file TAG. In the process of checking out a version of the master file, the user specifies which layers of markup to expose and which to conceal. The TAG document with the markup layers that they check out is referred to as a view. A view thus represents one or more layers of markup. It is a part of the entire TAG hypergraph in the repository, rendered in a human-readable format.

Views and layers

Because the concepts of view and layer are central to this workflow, it is helpful to revisit the difference between a layer and a view.

As described in Layers, a layer is a grouped set of markup and annotations. A view is a selection from among all available layers. Turning off (that is, not checking out) certain markup does not mean that the text to which the markup points is ignored, but it is then possible to choose only certain paths (e.g., in case of text with and without deletions and additions or with diverging paths for original and regularized versions of the same textual moments).

The reasons for grouping a set of markup and annotations may vary. In the paragraphs below we identify three scenarios: first, a layer as representation of a research perspective on text; second, a layer identifying user edits; third, a layer as a resolution to local overlap. The textual fragment from Prometheus Unbound is used as illustration.

For reasons of clarity our example sentences are short and simple, but in practice the master TAG document can be as large as needed, and may thus become highly complex. Here, we focus on the speech of the second voice from the Springs, which runs over two folium pages, as Figure 4 and Figure 5 show.

Figure 4

Selection of MS-e1-21v (source: Shelley-Godwin Archive, http://shelleygodwinarchive.org/sc/oxford/prometheus_unbound/act/i/#/p7).

Figure 5

Selection of MS-e1-22v (source: Shelley-Godwin Archive, http://shelleygodwinarchive.org/sc/oxford/prometheus_unbound/act/i/#/p8).

[poem>
[sp>
[speaker>2d. Voice from the Mountains<speaker]
[stanza rhyme="abac">
[lg type="quatrain">
[l>Thunderbolts had parched our [w rhyme="a">water<w]<l]
[l>We had been stained with bitter [w rhyme="b">blood<w]<l]
[l>And had ran mute ’mid shrieks of [w rhyme="a">slaugter<w]<l]
[l>Thro’ a city & a [w rhyme="c">solitude<w]<l]
<lg]
<sp]
<stanza]
<poem]

1. albert$ alexandria init
2. albert$ alexandria register-document --file MS-e1-21v-22v.tagml --name MS-e1-21v-22v

3. bertina$ alexandria define-view --name material-view  --file material-view.json
4. bertina$ alexandria checkout --view material-view --document MS-e1-21v-22v

[l>2d. Voice from the Springs<l]
[l>Thunderbolts had parched our water<l]
[l>We had been stained with bitter blood<l]
[l>And had ran mute 'mid shrieks of slaugter<l]
[l>Thro’ a city & a solitude<l]

[page n="21v">
[p>
[line rend="indent2">2d. Voice from the Springs<line]
[line>Thunderbolts had parched our water<line]
[line rend="indent2">We had been stained with bitter blood<line]
<page]
[page n="22v">
[line>And had ran mute <|[del>thro<del]|[add>'mid<add]|> shrieks of <|[sic>slaugter<sic]|[corr>slaughter<corr]|> laughter<line]
[line rend="indent2">Thro' a city & a solitude!<line]
<p]
<page]

[line rend="indent2"|material>[speaker|poetic>2d. Voice from the Springs<speaker|poetic]<line|material]

[s>We had been stained with bitter blood And had ran mute 'mid shrieks of slaughter<s]

[s>We had been stained with bitter blood<s] [s>And had ran mute 'mid shrieks of slaughter<s]

[s|claire>
  [s|dirk>We had been stained with bitter blood<s|dirk] 
  [s|dirk>And had ran mute 'mid shrieks of slaughter<s|dirk]
<s|claire]

[s>We had been stained with bitter blood And had ran mute 'mid shrieks of slaughter<s]

[page>
	[line>We had been stained with bitter blood<line]
<page]
[page>
	[line>And had ran mute 'mid shrieks of <|[sic>slaugter<sic]|[corr>slaughter<corr]|><line]
<page]

[page|material>
	[s|linguistic>[line|material>We had been stained with bitter blood<line|material]
<page|material]
[page|material>
	[line|material>And had ran mute 'mid shrieks of <|[sic|material>slaugter<sic|material]|[corr|material>slaughter<corr|material]|><line|material]<s|linguistic]
<page|material]

TAGML files

TAGML documents are inherently multi-layered and non-linear, and can best be represented by combining ordered and unordered information. This conceptual understanding of text is reflected in the syntax of TAGML: textual features such as non-linearity and discontinuity can easily be expressed; annotations can be nested within other annotations; annotation values can contain both text and markup (cf. Rich text annotations). Together with the data typing feature of TAGML, the recursivity of Rich text allows for explicit modeling of many textual features. Layers remove boundaries by allowing for overlap and the modeling of dominance and containment without the need for a schema, all of which facilitates the mapping of semantic information to the Text nodes in the hypergraph model.

Complete semantic mapping and querying would also require TAG to map semantic information to the properties of nested annotations. JSON-LD, for instance, provides a notation for linking the properties of JSON objects to ontologies. A similar feature will be part of the future development of TAG and TAGML.

Syntax and schema

Designing a new markup language means deciding which functionality to put into the syntax which responsibilities to put into the schema. Initially we tried to include only non-linear aspects of the text, such as containment, into the syntax, while making information about dominance explicit in the schema. When the syntax allows for arbitrary overlap, however, it is no longer possible for a parser to consistently extract a hierarchical structure from the data, which means that many use cases would require a schema. In the end we decided on the use of the layer mechanism in the syntax to allow the user to explicitly model containment and dominance relations without the need for a schema, while allowing for overlap. The syntax contains basic data types, such as String, Lists and nested annotations. The schema is used to make explicit any information about complex data types, such as persons, dates, and significant whitespace.

TAGML agrees in certain respects with other markup languages, much as the TAG model corresponds to some extent to other text models. Many textual aspects discussed in this paper can be modeled in, for instance, an XML-transcription with an associated schema and application-level rules. TAGML, however, moves much of that responsibility to the syntax by having explict encoding mechanisms for containment, dominance, discontinuity, non-linearity, and overlap, with the goal of removing ambiguity from the application level. Accordingly, TAGML brings together and expands on qualities of existing formats, and creates an inclusive and definite framework for modeling textual and structural information.

Users, views, and Alexandria

The TAG and TAGML division of labor requires the active engagement of the user, who needs to think in great detail about the informational structures and elements in the text, and about how these are best represented so that the modeling of a textual object conforms to the developer’s conceptual understanding of it. In principle, we regard this increased textual consciousness as a positive feature. In a similar way, the TAG repository Alexandria compels its users to make explicit their views on text.

Alexandria is designed to accommodate complex and information-rich TAG documents, while at the same time exposing an intuitive and straightforward method of interacting with that information. While understanding text as a graph may not be straightforward, especially for those who are accustomed to modeling text as a mono-hierarchical ordered tree (that is, in XML), the idea of adding layers of information to a text appears to be intuitive. Alexandria, then, accommodates a theoretically unlimited number of informational layers on a text, using views to allow users to query this information and to add and edit new layers.

The editorial workflow of Alexandria has a number of implications, in particular with regard to the diff and the merge functionalities and the command line tool. The first of these involves Alexandria’s diff and merge functionalities. In the Workflow we clarify our decision to keep both layers of markup, instead of considering the edit operations in the markup layer (e.g., from l to line) as replacements (a deletion of the l layer and an addition of the line layer). We reason that it is undesirable to have Bertina’s changes overwrite Albert’s markup, and propose to store both layers of markup in different layers that identify the two users.^[11]

An open question, however, is whether changes in the textual content should be treated in the same way. For example, if Bertina were to alter some text characters, should the master file adopt her changes as replacements for Albert’s, or as alternatives? The first option implies that the text from Albert’s view will be lost, while the second option implies that the Albert’s text and Bertina’s text will be stored in the TAG master file as textual variation. Since both options are supported by Alexandria, the question is philosophical, rather than technical.

As for our decision to have users work on the command line instead of providing a Graphical User Interface to interact with Alexandria: we recognize the wide variety of editor software that exists within text editing communities, as well as the fact that many users work with a preferred editor whose interface they are familiar with and appreciate. For that reason, our goal for interacting editorially with TAG documents has been not to develop a custom TAG editor, but to ensure that TAG works with any editor. This allows users to engage with the results of individual decisions about layers and views in the generic programming editor of their choice.