overlapping markup

Working With Fragmented Overlapping Markup

Jeni — Sun, 28 Dec 2008 20:15:56 +0000

In my last post I talked about different techniques for representing overlap within XML. One technique is fragmentation. In the work that I’ve been doing, I’ve been using milestone-based formats similar to ECLIX, but my eyes were opened at the GODDAG workshop: fragmentation would make overlap so much easier to process in XSLT, especially when dealing with localised overlap such as revision or comment markup.

But how could fragmentation be used with full-on overlap? I had a little play and came up with some XSLT to demonstrate.

Fragmentation Example

First, an example of how to represent overlap using fragments. Using fragments for overlap comes straight out of the support for aggregation within TEI where they’re used to not only represent overlapping structures but to construct completely new “virtual” elements that are not necessarily contiguous (and may even contain fragments in different orders from how they appear in the text). In TEI, they usually use the next and prev attributes to point from one fragment to another in order to reconstruct the element.

In the example here, I’ve done something slightly different, namely to use an ID in the http://www.jenitennison.com/xslt/fragmentation namespace to link the elements: all elements with the same ID are actually the same element. Here’s what it looks like.

<book xmlns:f="http://www.jenitennison.com/xslt/fragmentation">
    <page f:id="page199" n="199">
        ...
    </page>
    <poem>
        <page f:id="page199" n="199">
            <title>
                <pl>Recueillement</pl>
            </title>
            <stanza>
                <sl><s><pl>Sois sage, ô ma douleur, et tiens-toi plus </pl>
                                                          <pl>tranquille.</pl></s></sl>
                <s>
                    <sl><pl>Tu réclamais le Soir; il descend; le voici:</pl></sl>
                    <sl><pl>Une atmosphère obscure enveloppe la ville,</pl></sl>
                    <sl><pl>Aux uns portant la paix, aux autres le souci.</pl></sl>
                </s>
            </stanza>
            <stanza>
              <s f:id="s3">
                  <sl><pl>Pendant que des mortels la multitude vile,</pl></sl>
                  <sl><pl>Sous le fouet du Plaisir, ce bourreau sans merci,</pl></sl>
                  <sl><pl>Va cueillir des remords dans la fête servile,</pl></sl>
                  <sl><pl>Ma douleur, donne moi la main; viens par ici,</pl></sl>
        </s>
            </stanza>
            <stanza>
                <sl><pl><s f:id="s3">Loin d'eux. </s><s f:id="s4">Vois se pencher les défuntes </s></pl>
                                                                        <pl><s f:id="s4">Années, </s></pl></sl>
                <s f:id="s4">
                  <sl><pl>Sur les balcons du ciel, en robes surannées; </pl></sl>
                  <sl><pl>Surgir du fond des eaux le Regret souriant; </pl></sl>
        </s>
            </stanza>
        </page>
        <page f:id="page200">
            <stanza>
              <s f:id="s4">
                  <sl><pl>Le Soleil moribund s'endormir sous une arche, </pl></sl>
                <sl><pl>Et, comme un long linceul traînant à l'Orient, </pl></sl>
                <sl><pl>Entends, ma chère, entends la douce Nuit qui </pl>
                                                               <pl>marche.</pl></sl>
                </s>
            </stanza>
        </page>
    </poem>
</book>

You can see that I’ve played pretty fast and loose here with the markup language. The <s> elements can be children of <stanza> or <sl> or even <pl>, purely depending on what happens to most neatly contain them. This makes the XML inconsistent, but less verbose than it would otherwise be. Elements that are actually fragments have f:id attributes, and multiple elements may have the same f:id; this is precisely what’s used to work out that they’re the same element.

Desired Rendering

So what would we like to do when processing this? Say we wanted to create an HTML rendition of the poem, looking something like:

page 199

Recueillement

Sois sage, ô ma douleur, et tiens-toi plus

tranquille.

Tu réclamais le Soir; il descend; le voici:

Une atmosphère obscure enveloppe la ville,

Aux uns portant la paix, aux autres le souci.

Pendant que des mortels la multitude vile,

Sous le fouet du Plaisir, ce bourreau sans merci,

Va cueillir des remords dans la fête servile,

Ma douleur, donne moi la main; viens par ici,

Loin d’eux. Vois se pencher les défuntes

Années,

Sur les balcons du ciel, en robes surannées;

Surgir du fond des eaux le Regret souriant;

page 200

Le Soleil moribund s’endormir sous une arche,

Et, comme un long linceul traînant à l’Orient,

Entends, ma chère, entends la douce Nuit qui

marche.

The logic behind this rendition is:

process the pages; for each one, create a horizontal rule followed by a paragraph giving the page number
process the parts of the poem within each page; give the title if it has one in this fragment, followed by the stanzas
create an ordered list for each stanza, starting at the number for the stanza line within the (whole) poem, and process the stanza lines
create a list item for each stanza line; if the line contains parts of two sentences and the first of these sentences doesn’t begin in this line, highlight it as this indicates an interesting overlap between prosodic and syntactic structures
process the page lines within each stanza line; if there’s more than one, align the second to the right

It wouldn’t be easy to express that logic against the fragmented XML above, for two reasons.

First, the fragmented markup above is inconsistent: you can’t tell what kinds of children a particular element will have and which elements will be fragmented. You could fix this in the markup by deciding, for example, that the prosodic hierarchy of book/poem/stanza/sl would be primary and all other elements fragmented as necessary; you could further decide which of the hierarchies would be secondary within this: whether an <sl> element would hold <s> or <page> elements as children.

Second, though, the different logical steps require the markup to be structured in different ways: 1 requires a physical hierarchy where the markup is primarily divided into pages; 2 and 3 require a prosodic hierarchy within the page, dividing the poem into stanzas and stanza lines; 4 requires a syntactic hierarchy, where the stanza lines are split into sentences; 5 requires switching back to the physical hierarchy to see the page lines within the stanza line.

What you can do (and what I’ve done) is to write a function to help with this kind of processing by switching between the different hierarchies as and when necessary.

Labelling Elements

To prepare for switching, you must annotate the elements in the document with an indication of the trees that they belong to. The trees can be called anything you like; for the example above, I could use the labels “physical” (book, page, page line), “syntactic” (book, poem, sentence) and “prosodic” (book, poem, stanza, stanza line). The idea of labelling elements based on a tree that they belong to comes from the multi-coloured trees technique, but I think it’s more useful to use meaningful labels if you can.

You could imagine a built-in extension element that allowed you to describe the trees that different elements belonged to, and the annotation happening at the level of the XPath Data Model as its created. But to make things easier I’m using a f:trees attribute on each element. Adding the attribute can be done in XSLT with code like:

<xsl:template match="*" mode="annotate">
  <xsl:copy>
    <xsl:attribute name="f:trees">
      <xsl:apply-templates select="." mode="trees" />
    </xsl:attribute>
    <xsl:copy-of select="@*" />
    <xsl:apply-templates mode="annotate" />
  </xsl:copy>
</xsl:template>

<xsl:template match="book" mode="trees">prosodic syntactic physical</xsl:template>
<xsl:template match="poem" mode="trees">prosodic syntactic</xsl:template>
<xsl:template match="title | stanza | sl" mode="trees">prosodic</xsl:template>
<xsl:template match="s" mode="trees">syntactic</xsl:template>
<xsl:template match="page | pl" mode="trees">physical</xsl:template>

Once elements are labelled with the trees they belong to, it’s possible to work out dominance hierarchies. An element A is a descendant of an element B if the elements share a tree and A starts and ends within B. If A is within B but they don’t appear in the same tree, then the containment is happenstance and does not imply dominance.

Note: Trees should be defined so that all the elements within a given tree fit within each other without fragmenting. I haven’t considered how self-overlap should be handled here; the elements need to be part of the same tree, but they can still overlap and therefore be fragmented even when that particular tree is primary. In my experience, self-overlap usually occurs in situations like comments or revision markup, in which the self-overlapping markup is never primary anyway, so I’m not sure how serious this issue is.

Swapping Hierarchies

Once the elements are annotated, it’s possible to swap between hierarchies. The function I’ve written — f:swap() — takes two or three arguments. The first is an element, and the f:swap() function returns this same element (actually a copy) but with its children, and possibly its parents, rearranged based on the trees listed in the second argument. The third argument defaults to the element specified as the first argument and provides a starting point from which the rearrangement takes place; the two most useful values for this argument are the element itself (which means that its children are restructured) and the root of the tree (which means that the entire document is rearranged).

Some examples will help make this clearer. Starting with the poem above, to get the rendering I want, I need to swap to a “physical” view and process the pages:

<xsl:apply-templates select="$annotated/book/f:swap(., 'physical')/page" />

The f:swap() call here returns the <book> element but with its descendants rearranged so that the physical hierarchy is primary. The new version of the <book> element will have <page> children, which will themselves have <pl> children. The <pl> elements will contain fragments of <poem>, <s>, <stanza> and <sl> elements, nested purely based on their happenstance containment within a particular <pl>.

Here’s the code for processing the <page> elements:

<xsl:template match="page">
  <hr />
  <p style="text-align: right; ">page <xsl:value-of select="@n" /></p>
  <xsl:apply-templates select="f:swap(., ('prosodic', 'syntactic'))/poem" />
</xsl:template>

So each <page> generates a horizontal rule, a paragraph containing the page number and then processes… here the switch is from the physical hierarchy to a prosodic/syntactic hierarchy. The list of two items as the second argument of f:swap() means that the primary hierarchy is prosodic (poems, containing stanzas, containing stanza lines), but once you reach the bottom of the prosodic hierarchy (the stanza lines) you switch to a syntactic hierarchy (sentences) rather than a physical hierarchy (page lines).

The fact that the f:swap() call above only has two arguments means that the rearrangement starts from the <page> element that’s being processed. The ancestry of the <page> element itself stays the same, and only its content is rearranged according to the views specified in the second argument. So in this case the <poem> elements that a given <page> contains will be fragments.

Processing the poems can continue in the normal way:

<xsl:template match="poem">
  <xsl:apply-templates select="title" />
  <xsl:apply-templates select="stanza" />
</xsl:template>

<xsl:template match="title">
  <h3><xsl:value-of select="." /></h3>
</xsl:template>

The next difficulty appears when I want to start the numbering for a particular stanza based on the number of the first line within the stanza. I’m doing this by setting the start attribute like this:

<xsl:template match="stanza">
  <ol>
    <xsl:attribute name="start">
      <xsl:number select="f:swap(., 'prosodic', /)/sl[1]" 
        count="sl" from="poem" level="any" />
    </xsl:attribute>
    <xsl:apply-templates select="sl" />
  </ol>
</xsl:template>

This illustrates the three-argument version of the f:swap() function. To number the stanza line, I need to know the number of that stanza line within the poem that contains it. That would be easy to do with <xsl:number> (or in other ways), but for the fact that the <poem> element the <stanza> element appears in is currently fragmented between two <page> elements. To work out the number of the line, I really want an XML document in which the physical hierarchy is completely ignored, and the elements are arranged book/poem/stanza/sl.

The three-argument version of f:swap() allows me to swap to a prosodic hierarchy, starting from the very root of the document. It returns the element given as the first argument as it appears within the new hierarchy. Unlike the two-argument version, which only affects the descendants of the first argument, the three-argument version may also affect its ancestors, and even merge the element if it’s originally fragmented or split it if it doesn’t appear in the primary hierarchy. In this example, the returned <stanza> element’s parent <poem> is a child of the <book> element rather than being a fragmented child of the <page> element.

The rearrangement for the purposes of computing the start number for the list doesn’t affect the tree that’s being processed; the template for the <stanza> elements goes on to process the <sl> elements it contains, which use this template:

<xsl:template match="sl">
  <li>
    <xsl:if test="count(s) > 1 and not(f:first(s[1]))">
      <xsl:attribute name="style">background-color: yellow; </xsl:attribute>
    </xsl:if>
    <xsl:apply-templates select="f:swap(., 'physical')/pl" />
  </li>
</xsl:template>

Recall that the hierarchy currently being processed is a prosodic/syntactic hierarchy. The <sl> elements contain <s> elements, and it’s therefore possible to check whether the <sl> element being processed contains more than one <s>. The f:first() function checks whether a given fragment is the first fragment of that element, so the test in the <xsl:if> in this template checks whether the <sl> contains more than one <s> and the first <s> is not the first fragment of the sentence it represents.

To get the rendering I want, I need to generate an HTML paragraph for each page line within the stanza line. Currently the <sl> elements contain <s> elements, so to get the page lines I need to switch once more to the physical hierarchy and process the <pl> elements that are children of this <sl>. That processing is done by the template:

<xsl:template match="pl">
  <p>
    <xsl:if test="preceding-sibling::pl">
      <xsl:attribute name="style">text-align: right; </xsl:attribute>
    </xsl:if>
    <xsl:value-of select="." />
  </p>
</xsl:template>

and we’re done.

Final Thoughts

The one thing that concerns me about the approach I’m taking is the fact that because XSLT can’t actually amend an existing tree, the f:swap() function essentially makes a copy of the entire tree every time you use it, and I don’t know how well that will scale (both in terms of memory and in terms of work copying elements) when you get to documents that are larger than this toy example. Maybe processors are clever enough to discard trees they no longer need so it won’t be an issue; I just don’t know.

Other than that, I think this approach is promising because it enables users to mostly use familiar tree-processing approaches rather than having to learn new paradigms for transforming overlapping markup or introducing a raft of new axes.

Representing Overlap in XML

Jeni — Thu, 18 Dec 2008 21:44:57 +0000

I’m still on an overlap jag. I’ve shown some examples in the last couple of posts of TexMECS, XCONCUR and LMNL syntax, which depart from the usual well-formedness strictures in XML. But these syntaxes have one big problem: they’re not XML. XML is well-known, well-understood, and has great tools available for it, for querying, transforming, and pipelining. So it would be a real win if overlap could be represented within XML in a usable manner.

XML syntaxes for overlap, such as in TEI or in LMNL, adopt five different techniques:

milestones: one hierarchy is represented through normal XML markup; the others through empty elements (or, in some cases, processing instructions) that mark the start and end of structures that do not fit into that hierarchy
fragmentation: one hierarchy is represented through normal XML markup: the others are represented through fragment elements that are linked together through their attributes (eg all XML elements that represent the same structure are given the same identifier)
flattened: all start and end tags are represented by milestones within a single meaningless root element
multiple document: the document is split into multiple documents, each with a different set of elements within them. A particular element may be present in more than one of these documents, and of course the textual content (known as the frontier) remains the same in each
standoff: the frontier is kept in a single place, perhaps including a common (sacred) hierarchy and all other overlapping structures are represented by elements that point to their start and end within that content (either using offsets or XPointers)

There’s been some really good research at the University of Bologna on how to translate between formats that use these techniques (as well as LMNL and TexMECS syntax). What I want to look at here is when and why it might be appropriate to use each of them.

All these representations are useful in their own ways and in different situations. I’m going to talk a bit about the payoffs here. Here’s a summary of pros and cons:

technique	advantages	disadvantages
milestones	easy to see main structure	favours one main structure; hard to identify content of overlapping structures
fragmentation	easy to see main structure; easy to work out content of overlapping structures	favours one main structure; leads to spurious containment; can lead to discontinuous elements
flattened	all structures treated equally	hard to see any structure; hard to process naturally using XML tools
stand-off	all structures treated equally	hard to see any structure; hard to process naturally using XML tools hard to edit without tools
multiple document	easy to see individual structures	content gets repeated; complex to align structures; hard to do cross-hierarchy analysis; hard to edit without tools

So first, there’s the ability of the format to represent different kinds of overlap or support specialised tasks. Multiple separate well-formed documents, for example, can’t represent self-overlapping markup unless you have some variable, and possibly increasing, number of documents based on how much self-overlap there is. Fragmentation naturally supports discontinuous elements in a way that the other methods don’t. Stand-off markup lets you mark up other people’s documents without having write permissions on them. You might be constrained to use, or avoid, a particular technique simply because of what kind of overlap you’re dealing with.

Second, there’s editability. Milestones, fragments and (arguably) flattened structures are almost as easy to edit by hand as normal XML (that is, straight-forward for geeks, impossible for normal people). Stand-off markup (depending a little on how the marked up parts of the document are referenced) and multiple documents really require specific editing tools both for adding markup and changing the content of the document. I’m generally of the opinion that tools should never been a necessity, but if you’re creating an editor then you’re probably going to use stand-off markup or multiple documents behind the scenes.

Third, there’s how much, and how easily, you can use standard XML tools to process the documents. If you were using XSLT (as I usually am), and were presented with multiple documents, stand-off markup or flattened structures, you’d want someone to translate them into a milestoned or fragmented structure before you did anything. I have done quite a few transforms in which the documents were represented using a milestone technique, for example the changes within the revised statutes on the OPSI website, which all have to be highlighted in blue, surrounded by square brackets and have a link at the start, and they’re fiddly (especially in XSLT 1.0), though tractable. Fragmented markup, on the other hand, would be much easier to process.

Finally, there’s the issue of whether one particular hierarchy has prominence within the XML. In some examples of overlap, particularly the ones I’m concerned with such as comments and revisions, there’s an obvious primary hierarchy (the main document markup) with the others being secondary. This makes techniques such as milestones and fragmentation particularly appropriate. On the other hand, when there are multiple equal hierarchies, particularly when the two hierarchies use elements with the same names (such as marking up the pages in two editions of the same book), it might seem strange to choose one over another. You either need a neutral format (such as flattened markup, stand-off markup or multiple documents) or, in processing, the ability to easily switch between different primary hierarchies.

So I don’t think it’s ever going to be possible to say “this is the way in which you should mark up your overlap using XML”. However, I do think it would be really useful to have standard vocabularies for marking up overlap in XML, mostly in the form of namespaced attributes. If we had a set of model-neutral (ie not LMNL, nor GODDAG, nor XCONCUR, nor …) and markup-language-neutral (ie not TEI, nor …) vocabularies for representing overlap, we could start constructing querying, transformation and validation tools that would be useful across a range of projects. (I was thinking an RFC, but I have no idea how to go about it.)

Essential Hierarchy

Jeni — Tue, 09 Dec 2008 17:59:32 +0000

In my last post I discussed the kinds of situations where overlapping markup can appear in documents, and the distinction between containment, when one element happens to contain another, and dominance, where the relationship between the two elements is more meaningful. Here I’ll expand a bit more on the issue of whether dominance relationships are or should be part of the essential information in the document.

I wrote:

So an important challenge is how to get from a flat, containment-only model to a DAG. There are four approaches that can be taken:

For any document, for each pair of range names A and B, if every range named A contains a range named B, then assume that A dominates B; from that set of relationships, create a DAG.

Introduce additional syntax into tags, such that dominance relationships between ranges can be expressed explicitly within the serialisation.

Associate each document with a schema, and use the model expressed in the schema to identify dominance relationships; a Creole schema like the one above could be taking as asserting that poems dominate stanzas, for example, since stanzas are mentioned in the content model of the poem range.

Defer the construction of a DAG to the point of processing; a document would then not be a DAG in and of itself, but only in relation to a particular process.

I find the last of these the most satisfactory. 1 is too arbitrary. 2 requires too much syntax. 3 requires a single schema per document (which, from experience with XML, I think is a broken model).

James Clark commented:

I’m surprised by your rejection of approach 2 on the grounds that it “requires too much syntax”. I would be inclined to start by designing the information model first and then figure out a syntax to represent that information model. Maybe I’m just brainwashed by too much XML/SGML, but the hierarchical relationships seem like a fundamental aspect of the information about the document which the markup should be capturing explicitly.

So I shall expand upon my rather throw-away rejection of the option of using additional syntax within tags to express dominance relationships. There are two parts to it: philosophical and pragmatic.

Philosophy

My philosophical objection applies to both the idea of indicating hierarchy within tags and using a schema (option 3 above). My attitude going into the development of LMNL (an attitude that might not be shared by the other members of the ad hoc LMNL committee) has been to carry over as few assumptions as possible from the SGML/XML world, and to see how far we can get without those assumptions. So as well as overlap, LMNL has weird things like structured and ordered annotations, atoms, and anonymous ranges.

In that spirit, I want to see if we can get away with not having hierarchy as a fundamental part of the information model. Does this allow us to do things that we couldn’t otherwise do, or is it a burden? I don’t know yet.

I view this as somewhat similar to the questions around datatyping XML. Some people (seem to) think that elements and attributes have a particular datatype as part of their essential nature, others (myself amongst them) that two processes could reasonably view a document using different datatypes or no datatypes at all if it wasn’t important for that particular processing. Just as with datatyping, the restrictive, “there can be only one”, attitude is fine for people whose documents fit that model, but causes problems for those whose don’t. Conversely, if your documents need only ever be seen in one way, it won’t (or shouldn’t) hurt you that other people want to take a more permissive approach. So allowing processing to determine hierarchy seems more likely to satisfy more people.

As a small illustration that hierarchy is in the eye of the beholder, take the poem from my previous post. During my talk at the workshop in Amsterdam I asserted that the stanza line (sl) elements could hold (dominate) one or more page line (pl) elements. Fabio Vitali objected strongly to this, saying that the relationship was simply one of containment. Shouldn’t it be possible for us both to process the poem based on our differing views?

Pragmatism

There are several models floating around as possibilities for representing overlapping structures. I talked about two of them in my last post: the LMNL data model in which a document is basically a sequence of atoms (most of which will be characters) with annotated ranges over them, and the GODDAG model in which a document is a directed acyclic graph (DAG) of nodes. The GODDAG model is closest to SGML/XML in that it views the hierarchy of elements as an fundamental part of the document.

The TexMECS syntax, which is supposed to be amenable to representing GODDAG structures, only represents hierarchy through containment. If you want to read about it, Yves Marcoux did some analysis of what is and isn’t serialisable within TexMECS at Balisage last year.

In LMNL, we have the concept of limina which hold ranges (rather than atoms/characters), over which you can define other ranges. This gives us a structure roughly equivalent to a GODDAG. But despite a lot of back and fro, we were never able to come up with a satisfactory serialisation. You might imagine an extension to the LMNL syntax that goes something like:

[page=p199 [n}199{]}
...
[poem=poem}
  [title^poem}[pl^p199}Recueillement{pl]{title]
  [stanza=s1^poem}
    [s^poem}[sl^s1}[pl^p199}Sois sage, ô ma douleur, et tiens-toi plus {pl]
                                        [pl^p199}tranquille.{pl]{sl]{s]
    [s^poem}[sl^s1}[pl^p199}Tu réclamais le Soir; il descend; le voici:{pl]{sl]
    [sl^s1}[pl^p199}Une atmosphère obscure enveloppe la ville,{pl]{sl]
    [sl^s1}[pl^p199}Aux uns portant la paix, aux autres le souci.{pl]{sl]{s}
  {stanza]
  [stanza=s2^poem}
    [s^poem}[sl^s2}[pl^p199}Pendant que des mortels la multitude vile,{pl]{sl]
    [sl^s2}[pl^p199}Sous le fouet du Plaisir, ce bourreau sans merci,{pl]{sl]
    [sl^s2}[pl^p199}Va cueillir des remords dans la fête servile,{pl]{sl]
    [sl^s2}[pl^p199}Ma douleur, donne moi la main; viens par ici,{pl]{sl]
  {stanza]
  [stanza=s3^poem}
    [sl^s3}[pl^p199}Loin d'eux.{s] [s^poem}Vois se pencher les défuntes {pl]
                                                [pl^p199}Années,{pl]{sl]
    [sl^s3}[pl^p199}Sur les balcons du ciel, en robes surannées;{pl]{sl]
    [sl^s3}[pl^p199}Surgir du fond des eaux le Regret souriant;{pl]{sl]
  {stanza]{page]
  [page=p200 [n}200{]}[stanza=s4^poem}
    [sl^s4}[pl^p200}Le Soleil moribund s'endormir sous une arche,{pl]{sl]
    [sl^s4}[pl^p200}Et, comme un long linceul traînant à l'Orient,{pl]{sl]
    [sl^s4}[pl^p200}Entends, ma chère, entends la douce Nuit qui {pl]
                                              [pl^p200}marche.{pl]{sl]{s]
  {stanza]
{poem]
...
{page]

in which each range can point to its parent range via its ID (IDs being set with the standard =id and the child relationship being indicated by ^id). Or various other ways of doing it, none of which are convincing.

XCONCUR (which is pretty much the same syntax as CONCUR in SGML, but using XML) does indicate hierarchy, using syntax like this:

<(phy)page n="199">
...
<(syn)poem><(pro)poem>
  <(pro)title><(syn)title><(phy)pl>Recueillement</(phy)pl></(syn)title></(pro)title>
  <(pro)stanza>
    <(syn)s><(pro)sl><(phy)pl>Sois sage, ô ma douleur, et tiens-toi plus </(phy)pl>
                                        <(phy)pl>tranquille.</(phy)pl></(pro)sl></(syn)s>
    <(syn)s><(pro)sl><(phy)pl>Tu réclamais le Soir; il descend; le voici:</(phy)pl></(pro)sl>
    <(pro)sl><(phy)pl>Une atmosphère obscure enveloppe la ville,</(phy)pl></(pro)sl>
    <(pro)sl><(phy)pl>Aux uns portant la paix, aux autres le souci.</(phy)pl></(pro)sl></(syn)s>
  </(pro)stanza>
  <(pro)stanza>
    <(syn)s><(pro)sl><(phy)pl>Pendant que des mortels la multitude vile,</(phy)pl></(pro)sl>
    <(pro)sl><(phy)pl>Sous le fouet du Plaisir, ce bourreau sans merci,</(phy)pl></(pro)sl>
    <(pro)sl><(phy)pl>Va cueillir des remords dans la fête servile,</(phy)pl></(pro)sl>
    <(pro)sl><(phy)pl>Ma douleur, donne moi la main; viens par ici,</(phy)pl></(pro)sl>
  </(pro)stanza>
  <(pro)stanza>
    <(pro)sl><(phy)pl>Loin d'eux.</(syn)s> <(syn)s>Vois se pencher les défuntes </(phy)pl>
                                                <(phy)pl>Années,</(phy)pl></(pro)sl>
    <(pro)sl><(phy)pl>Sur les balcons du ciel, en robes surannées;</(phy)pl></(pro)sl>
    <(pro)sl><(phy)pl>Surgir du fond des eaux le Regret souriant;</(phy)pl></(pro)sl>
  </(pro)stanza></(phy)page>
  <(phy)page n="200"><(pro)stanza>
    <(pro)sl><(phy)pl>Le Soleil moribund s'endormir sous une arche,</(phy)pl></(pro)sl>
    <(pro)sl><(phy)pl>Et, comme un long linceul traînant à l'Orient,</(phy)pl></(pro)sl>
    <(pro)sl><(phy)pl>Entends, ma chère, entends la douce Nuit qui </(phy)pl>
                                              <(phy)pl>marche.</(phy)pl></(pro)sl></(syn)s>
  </(pro)stanza>
</(pro)poem></(syn)poem>
...
</(phy)page>

The pro, syn and phy labels in brackets before the element names indicate the hierarchy to which each element belongs. Elements can overlap if they have different labels. As you can see, this syntax means a lot of repetition for elements that belong to more than one hierarchy and there’s a built-in limitation here regarding self-overlap (ie of elements that can overlap other elements with the same name).

Now this isn’t altogether rational, but I think that the fact that we haven’t managed to come up with a good syntax that expresses hierarchy, even without the restrictions of XML well-formedness, is an indication that it’s not meant to be. I am firmly of the opinion that simplicity and elegance are hallmarks of good design. If hierarchies can only be expressed through an ugly syntax, then it’s just not worth it.

Slightly more rationally: if the syntax for expressing hierarchies is that verbose and difficult to use, people won’t use it, and we’ll have to find a way to add dominance relationships programmatically. We might as well start from that point.

But perhaps someone out there can come up with a clean, elegant syntax for expressing dominance within overlapping markup?

Overlap, Containment and Dominance

Jeni — Sat, 06 Dec 2008 20:56:52 +0000

I’ve spent the last few days at a workshop on overlapping markup in Amsterdam. It was organised by Claus Huitfeldt and Michael Sperberg-McQueen under a GODDAG banner, but included representatives of other approaches, such as the XCONCUR crowd and the LMNListas Wendell and myself.

Overlap is arguably the main remaining problem area for markup technologists. Capturing and analysing the overlap between poetic and syntactic structures in poems and plays helps academics gain a deeper understanding of the ways poetic technique has changed over time. And the complexities of structures in documents such as the Bible simply cannot be represented without allowing overlap to happen.

But academic study aside, overlap is a really important problem because whenever we collaborate on documents and whenever we change documents, we create overlapping structures. One of the major projects that I’ve worked on at TSO deals with publishing consolidated legislation, showing the places where “current” legislation was amended over time from its original, enacted state. The authors of legislation care little for document structures, and amendments often overlap document structures such as paragraphs and list items, and each other.

An Example

I used the following example during my talk on the Creole schema language during the workshop. It uses TexMECS notation, in which <name| is a start tag, |name> an end tag and the normal XML syntax is used for attributes:

<page n="199"|
...
<poem|
  <title|<pl|Recueillement|pl>|title>
  <stanza|
    <s|<sl|<pl|Sois sage, ô ma douleur, et tiens-toi plus |pl>
                                        <pl|tranquille.|pl>|sl>|s>
    <s|<sl|<pl|Tu réclamais le Soir; il descend; le voici:|pl>|sl>
    <sl|<pl|Une atmosphère obscure enveloppe la ville,|pl>|sl>
    <sl|<pl|Aux uns portant la paix, aux autres le souci.|pl>|sl>|s>
  |stanza>
  <stanza|
    <s|<sl|<pl|Pendant que des mortels la multitude vile,|pl>|sl>
    <sl|<pl|Sous le fouet du Plaisir, ce bourreau sans merci,|pl>|sl>
    <sl|<pl|Va cueillir des remords dans la fête servile,|pl>|sl>
    <sl|<pl|Ma douleur, donne moi la main; viens par ici,|pl>|sl>
  |stanza>
  <stanza|
    <sl|<pl|Loin d'eux.|s> <s|Vois se pencher les défuntes |pl>
                                                <pl|Années,|pl>|sl>
    <sl|<pl|Sur les balcons du ciel, en robes surannées;|pl>|sl>
    <sl|<pl|Surgir du fond des eaux le Regret souriant;|pl>|sl>
  |stanza>|page>
  <page n="200"|<stanza|
    <sl|<pl|Le Soleil moribund s'endormir sous une arche,|pl>|sl>
    <sl|<pl|Et, comme un long linceul traînant à l'Orient,|pl>|sl>
    <sl|<pl|Entends, ma chère, entends la douce Nuit qui |pl>
                                              <pl|marche.|pl>|sl>|s>
  |stanza>
|poem>
...
|page>

The start and end tags mark ranges in the text. (In some discussions of overlap, the ranges are called “elements”, but I prefer to reserve that term for structures that are self-contained, such as those in XML, to avoid confusion.) In Creole’s compact syntax, you could articulate the structure as follows:

# a book is a sequence of pages; it is also a sequence of poems
start = element book { page+ ~ poem+ }

# a page is a sequence of page lines
page = range page { pl+ }

# a poem starts with a title; the body of the poem can be characterised
# as a sequence of stanzas, but also as a sequence of sentences
poem = range poem { title, ( stanza+ ~ s+ ) }

# a title is a self-contained structure that may contains several page lines
title = element title { pl+ }

# a stanza contains several stanza lines
stanza = range stanza { sl+ }

# a stanza line contains one or more page lines
sl = range sl { pl+ }

# a sentence contains some text
s = range s { text }

# a page line contains some text
pl = range pl { text }

You could go further: sentences are made up of phrases, which are made up of words, which are made up of syllables, which are made up of letters. Stanzas within a sonnet such as this one can be clustered into an octet and a sestet and classified as quatrains and tercets based on the number of lines they contain. Stanza lines are also made up of syllables. And so on. Analysing the way in which the syntactic (sentence/phrase) structure overlaps with the prosodic (stanza/line) structure is one important way in which you can analyse a poem.

Containment vs Dominance

When you’re talking about overlapping structures, it’s useful to make the distinction between structures that contain each other and structures that dominate each other. Containment is a happenstance relationship between ranges while dominance is one that has a meaningful semantic. A page may happen to contain a stanza, but a poem domainates the stanzas that it contains.

In LMNL, we view a document as consisting of a sequence of atoms, usually characters, and ranges over those characters. But the model makes no assertions about dominance relationships between the ranges. This document model is easy to construct from a serialised document like the one above.

Conversely, GODDAG document models are directed acyclic graphs (DAGs): the nodes within those graphs have children and parents, with leaf nodes containing characters, and the parent-child relationship implies dominance. This is a useful model for processing, and particularly querying. Navigating a DAG is a lot like navigating a tree, just one that represents multiple hierarchies. But it isn’t possible to construct a DAG from a serialised document like the one above without extra information about which containment relationships are actually dominance relationships, and which mere happenstance.

So an important challenge is how to get from a flat, containment-only model to a DAG. There are four approaches that can be taken:

For any document, for each pair of range names A and B, if every range named A contains a range named B, then assume that A dominates B; from that set of relationships, create a DAG.
Introduce additional syntax into tags, such that dominance relationships between ranges can be expressed explicitly within the serialisation.
Associate each document with a schema, and use the model expressed in the schema to identify dominance relationships; a Creole schema like the one above could be taking as asserting that poems dominate stanzas, for example, since stanzas are mentioned in the content model of the poem range.
Defer the construction of a DAG to the point of processing; a document would then not be a DAG in and of itself, but only in relation to a particular process.

I find the last of these the most satisfactory. 1 is too arbitrary. 2 requires too much syntax. 3 requires a single schema per document (which, from experience with XML, I think is a broken model). One could imagine being able to specify something like:

book > page > pl > #text
book > poem > stanza > sl > #text
book > poem > s > #text

and this generating a DAG in which a book node had page and poem children, page nodes had pl children which had text children, poem nodes had stanza children and s children, and so on. With this structure, it would be easy enough to find stanzas with four lines (/book/poem/stanza[count(sl) = 4]) without having to worry about the possibilities of happenstance containment, such as some stanza lines being contained by sentences that are contained by stanzas.

There’s lots more to talk about here. In particular, things about the useful and appropriate ways of querying and transforming these structures, and how to best serialise them in XML. But I’ll leave those thoughts for another post.

Partitioning overlapping markup

Jeni — Mon, 11 Jun 2007 20:36:09 +0000

Wendell Piez forwarded me an interesting poster by Bert Van Elsacker on automatic fragmentation of overlapping structures. That’s taking something like:

<bold> this is bold <italic> and italic </bold> text </italic>

and turning it into something well-formed, like:

<bold> this is bold <italic> and italic </italic></bold><italic> text </italic>

When you do this, you have to decide which elements can be split and which can’t, and their relative priorities. Wendell suggested that perhaps Creole might help to do this. I have been thinking about is using Creole to add annotations to markup (something like, you add attributes to the Creole patterns and they get copied on to the matched ranges, or are used to create new ranges), but I haven’t done that yet, and actually I think you probably want a different kind of language to do it (a new kind of schema language like James Clark suggested), because the way in which you break up overlapping structures has a lot to do with how you’re going to process them.

I’m reminded of the paper

Sperberg-McQueen, C. M., David Dubin, Claus Huitfeldt and Allen Renear. “Drawing inferences on the basis of markup.” In Proceedings of Extreme Markup Languages 2002.

in which (based on my memory of the talk) they discuss how different elements allow you to make different assertions about the text they contain, and consequently can be split in different ways. For example, a <paragraph> element can’t be split into two <paragraph> elements without changing the meaning of the document, whereas a <bold> element can be split into two <bold> elements with no problems because it’s really indicating “these characters are bold” rather than “this is a bold phrase”.

You can take a purist view (which would usually entail splitting hardly any elements, since most elements do mark up a range of text rather than the individual characters they contain), but I think the main reason you want to do this fragmentation is for presentation. And in that context, the notional semantics of the element don’t really matter: what matters is how they’re styled. For example, a <comment> element, marking up a range of text that has been commented on, might not be splittable at a theoretical level, but if you’re going to render it simply by turning the background yellow, then in fact you can split it for that purpose.

Since it’s related to presentation, I wonder whether you could use a (simplified) CSS stylesheet to provide both the fragmentation and the style. Block-level elements (display: block;) couldn’t be split whereas inline elements could. Elements that have the box model properties (margin, padding & borders) can’t be split, or, if they are, you need to mark the fragments as “left”, “middle” and “right”, and only apply the left margin/padding/border to the “left” fragment, and similarly with the right.

It wouldn’t be a general purpose transformation mechanism, but it would be darned useful!

A Creole by any other name...

Jeni — Wed, 25 Apr 2007 20:09:28 +0000

Argh. I’ve been contacted by the guys at WikiCreole who want me to change the name of Creole. What should I do? Not only is “Creole” a great name for a schema language that deals with concurrent markup, but it’s a great acronym too (Composable regular expressions for overlapping languages etc.)

I did Google when I first came up with the name in August 2006, but didn’t discover WikiCreole (unsurprisingly, since it was only coined in July 2006 itself). But now far more many people know, care about and use WikiCreole than Creole grammars. So any suggestions for alternative names?