Balisage Paper: A Virtualization-Based Retrieval and Update API for XML-Encoded Corpora^[1]

Problem domain

XML-encoding a textual corpus is typically achieved through manual tagging, i.e. by human operators using a text editor or specialized annotation software, or through the application of algorithms that complete the tagging on the basis of a known schema.

The problem we address in this paper is to provide an algorithmic substrate, made accessible through an Application Programming Interface (API), to achieve automated tagging [Renders2007a, Renders2009a, Briquet2009a] of the digitized version of one of the most complex paper dictionaries. This dictionary is the Französisches Etymologisches Wörterbuch (FEW) [ProjectFEW, Wartburg1922a]. The FEW is the historical and etymological dictionary of the languages of the gallo-roman area (i.e. French, Franco-Provençal, Occitan and Gascon in all of their diatopic variations), written over the course of more than eighty years.

Each article of the FEW describes all derived words (i.e. lexemes) of a given root word (i.e. etymon) [Buchi1996a], instead of (as happens in most etymological dictionaries) describing the root word of a given derived word. Of course, several fields of information are offered for each article, such as the etymon and the language in which this etymon originates, the signature of the article, footnotes. The structure of the article is emphasized through hierarchical numbering and labeling of groups of paragraphs and cross-references to these. Several fields of information are offered for each lexeme, including but not limited to geolinguistic labels, bibliographical references to attestations of the lexeme and the definition of the lexeme. All of these types of information are well-delineated, thus good candidates for tagging. In a nutshell, each article of the FEW is a highly structured text that can be described through a model [Buchi1996a] and thus algorithmically processed.

Besides these semantic types of information that are expected to be identified through automated tagging, formatting markup (such as paragraph, bold, italic, exponent, break tags such as end of line or end of column,...) is also available in each article following the digitization process (the formatting markup is added either manually or through OCR). This enables an on-screen visualization of articles that is faithful to the paper version of the dictionary. The availability of paragraph tags is important not only to properly format the articles, but to make accessible a first level of structuring of the article. Likewise, the availability of break tags enables to correctly tag some types of semantic types of information. Many hyphens indeed do not indicate that a long word is being cut at the end of the line where they are found, but instead convey semantic information (e.g. as part of affixes). And there is no straightforward way to automatically disambiguate the syntactic uses from the semantic uses of hyphens at the end of lines in the FEW dictionary.

To put the FEW dictionary [ProjectFEW, Wartburg1922a] in perspective, here is a quick comparison with another complex dictionary, the well-known Oxford English Dictionary (OED) [OED]. Whereas the markup used to encode OED articles is proprietary SGML [OED], the markup used to encode FEW articles is standard XML complying with an XML Schema [Briquet2009a]. The FEW markup is referred to as FFML (FEW Font-style Markup Language) for files input to the automated tagging process. It is referred to as FSML (FEW Semantic Markup Language) for files output by the automated tagging process. FSML is comprised of mostly a superset of FFML, that is augmented with semantic markup. There currently exists no in-depth comparison of the scopes of the OED and FEW markups, and it is clear that there are differences if only because FEW entries are etymons instead of, typically, lexemes. Nonetheless, in very general terms, both markups are intended to encode dictionary articles and it is not surprising to see many common features. The FEW dictionary, though, is considered to be one of the most complex dictionaries in the world [Buchi1996a], notably because of the ever-present implicitness of many types of information. The Table here below provides a shallow quantitative comparison of both dictionaries.

Importance of the problem

Semantically tagging the articles of the FEW is a multi-year linguistics research project [Renders2007a] that is tremendously important to the historical linguistics community. Merely digitizing the FEW, without further processing would only enable full text search. Tagging the various fields of information would also enable so-called lateral search over the whole dictionary. Semantic tagging would disambiguate and resolve the implicitness of most of the fields of information contained in the dictionary.

Given the extreme linguistic complexity of the FEW, only highly-trained human experts could theoretically do the job. But there are not enough of them to process the twenty thousand articles of the FEW and this would be a tedious, error-prone job anyway. It was thus decided to use algorithmic automation to tag the fields of information of the FEW [Renders2009a]. Even though the articles of the FEW (implicitly) constitute a highly specialized textual corpus, we believe that the problem can be sufficiently abstracted so that our proposed approach is also relevant to other endeavors, particularly the processing of text-oriented XML documents (i.e. text with intersparsed markup) such as text corpora.

Scope of the problem

The input of our project is comprised of XML documents, each of which represents an article of the FEW and includes basic layout tags (article, paragraphs, bold, italic,...) that were added by human encoders and/or by OCR software. Obviously, all textual contents are eventually enclosed in paragraph and article tags. Nonetheless, the element hierarchy is often not the prime model of choice when accessing the FEW. Identifying fields of information in the FEW indeed focuses on linear regions of text where elements can be nested in many ways. Thus a very important property is that an FEW article should be considered as a text-oriented XML document, i.e. a text with intersparsed tags rather than a tree of elements with some textual contents found in the leaves.

The objective of our project is ultimately to add semantic markup around fields of information within a text-oriented XML document (fields of information of interest are listed in the Problem domain section here above). This requires to first identify these fields of information, then accordingly update the XML document.

Each article of the FEW dictionary typically features multiple occurrences of 25 or so types of information [Buchi1996a], each of which is detected and tagged by a specific tagging algorithm (see Figure 1 here below).

few-tagging-sequence

FEW tagging sequence

As the dependency graph of tagging algorithms is acyclic, it is possible - though not straightforward - to determine the sequence in which they should be applied (the so-called retroconversion sequence, e.g. tag definitions, then geolinguistic labels, then bibliographic labels,...) [Renders2009a, Briquet2009a]. An important property is that the order in which tags are inserted into the XML document representing an FEW article is known. Therefore, when designing a tagging algorithm, one knows which types of information have previously been tagged - and thus which ones might interfere with information retrieval and updates.

Identification of fields of information in an FEW article by a tagging algorithm is typically based on several retrieval primitives: keyword search, matching of regular expressions (regexp), as well as matching of contextual tag sequences. Most algorithms rely on a combination of several of these primitives, often in non-straightforward ways that involve secondary lookups in the contexts surrounding initial matches. The linguistic challenge resides in handcrafting combinations of retrieval primitives that lead to accurate identification of types of informations. As the design and implementation of tagging algorithms is beyond the scope of this paper, we now concentrate on issues that arise from the stated information retrieval requirements.

Among the issues that make information retrieval in the FEW quite challenging, two classes of issues stand out:

Update of (the XML document representing) an FEW article by a tagging algorithm typically includes the insertion, removal, displacement or update of text, as well as the insertion, displacement or removal of tags. The possible presence of many types of tags within updated text regions increases the complexity of update operations, as these should preserve the well-formedness of the XML document. Moreover, the tagging of a text region might be decided based on the identification of patterns in a neighboring text region. Support for match points is thus very important, as the locus of where to insert a tag is most often decided based on offsets in the textual representation of the XML document (these offsets being sometimes far away from the XML node whose contents were matched in the identification phase), not relative to tags of the XML document.

In addition to these retrieval and update challenges, one must keep in mind that the semantic tagging of FEW is a research project [Renders2007a] whose object of study is a very complex dictionary. Concretely, another layer added to these challenges resides in the lack of knowledge of where tags can appear in the text. Even though it might be known that a given tag type is always included in a specific parent element, this provides no information on where the given tag appears among the textual content of its englobing element. This is the kind of challenge one must face when searching both markup and textual contents at the same time [StLaurent2001a].

This leads to the following additional requirement: A mechanism must be provided to flexibly and easily configure the contexts where retrieval and update operations will be applied. This is a challenging requirement, as we desire to provide users of the mechanism a way to think of the dictionary and express themselves in a familiar environment: text without tags.

What is required is thus a mechanism that enables flexible, dynamic, tag-aware retrieval and update in a text-oriented XML document, in order to support natural linguistic reasoning. Based on our review of the state of the art presented in the section of this paper discussing related works (see below), we are not aware of any existing XML technology that addresses all of these requirements, specifically the provision of a familiar environment to users of the mechanism.

Our Approach

The key principle of our approach to the tag-aware retrieval and update problem is the virtualization of the text-oriented XML document. We propose a mechanism to allow one to easily construct, through an Application Programming Interface (API), a representation of selected sections of the XML document from which types of tags leading to ambiguities - as well as their contents, if required - have been removed. In practice, sections of the XML document are virtualized into multiple virtual strings, separated by so-called visible tags, according to dynamically-defined tag visibility rules. A definition of the virtual string data structure is provided in a further section; intuitively, a virtual string is the concatenation of adjacent text chunks, except those within elements that are configured to not be added to the virtual string.

For example, this section of XML document: <X><Y>some nice text</Y> <Z>and text to be made invisible</Z> and <W>finally</W> <Y>nice text again</Y></X> is virtualized into these three virtual strings: (1) some nice text, (2) and finally and (3) nice text again, if using the following configuration: <X> and <Y> tags should stop the virtualization mechanism, <Z> tags as well as their contents (if considered as elements) should be made invisible, and <W> tags (not their contents, if considered as elements) should be made invisible.

How do API users benefit from the virtualization? With ambiguity abstracted away through an appropriate configuration of what tags should be made invisible (with or without their contents, if considered as elements), the representation of the XML document as a sequence of virtual strings is more easily searchable, simplifying retrieval (keyword search, regexp matching, contextual tag sequence matching).

Importantly, each virtual string is backed by the underlying XML document. Updates to a virtual string are thus transparently propagated to the document. Therefore, this constructed representation is also easily updatable.

Our approach shares the intent of the Regular Fragmentations mechanism proposed by Simon St.Laurent [StLaurent2001a, RegFrag] and of the XML Fragments mechanism introduced by Carmel et al. [Carmel2003a], to the extent that we wish to devise a transparent mechanism that enables mixed-information (text/markup) retrieval in a text-oriented XML document. Our proposed virtualization mechanism may be viewed as a dynamic, more flexible and - importantly - updatable version of the Reading Context mechanism introduced by Xavier Tannier [Tannier2005a]. Mixed-information (text/markup) retrieval is provided by our proposed virtualization mechanism through the backing of virtual strings by the underlying XML document. The tag visibility model on which our proposed virtualization mechanism relies is an extended version (with slightly different semantics) of the tag visibility model initially introduced by Lini et al. [Lini2001a] and used by Tannier [Tannier2005a]. Our proposed API is comprised of exactly the operations that are required to digitize the FEW dictionary [ProjectFEW, Wartburg1922a], no more, no less. Nonetheless, we believe it is sufficiently general and extensible to be useful to other text-oriented XML document processing needs.

The rest of this paper is structured as follows. Typical use cases are first described in order to ground our work into real, concrete, albeit basic examples. Hypothetical use cases are also provided, in order to situate our work within a broader context. The proposed XML document retrieval and update API is then introduced. Related works are subsequently reviewed and their relationships with our work are explored. Finally, concluding remarks put the proposed API into perspective.

Use case 1: avoidance of false positives for regular expression matching

In this use case, the objective is to tag dates. To search for dates, a regular expression is applied to the full text version of the XML document.

Input (FEW 2, 982b, completus):

<geoling>Nfr.</geoling> <i>com-<lb merge="no"/>
plètement</i> <def>„action de mettre au complet“</def> (seit 1750,<lb merge="no"/>
text in <biblio>Fér 1787</biblio>).

Expected output, one <date> tag inserted:

<geoling>Nfr.</geoling> <i>com-<lb merge="no"/>
plètement</i> <def>„action de mettre au complet“</def> (seit <date>1750</date>,<lb merge="no"/>
text in <biblio>Fér 1787</biblio>).

If all tags were removed prior to full text search, the string 1787 would be matched as a licit date. This would lead to a false positive as it has already been tagged as part of a bibliographical reference.

Instead, <biblio> tags (as well as others, in practice) should be made totally invisible, their contents included, prior to full text search. The full text to which the search operation is applied thus becomes:

Nfr. complètement „action de mettre au complet“ (seit 1750, text in ).

Use case 2: avoidance of false positives for keyword search

In this use case, the objective is to tag grammatical categories. To search for grammatical categories, a keyword search is applied to the full text version of the XML document. In practice, the string f. belongs to the keyword list of grammatical categories (it's an abbreviation standing for: feminine substantive).

Input (FEW 2, 983a, completus):

<geoling>Nfr.</geoling> <i>fleur incomplète</i> <def>„f. dé-<lb merge="discard-hyphen"/>
pourvue de quelque organe, notamment de corolle“</def><lb merge="no"/>
(seit <biblio>Trév 1771</biblio>).

Expected output, no tag inserted:

<geoling>Nfr.</geoling> <i>fleur incomplète</i> <def>„f. dé-<lb merge="discard-hyphen"/>
pourvue de quelque organe, notamment de corolle“</def><lb merge="no"/>
(seit <biblio>Trév 1771</biblio>).

If all tags were removed prior to full text search, the string f. would be matched as a licit grammatical category. This would lead to a false positive as f. is here an abbreviation of the word fleur (i.e. flower) and has already been tagged as part of the definition of a lexeme.

Instead, <def> tags (as well as others, in practice and for the relevant algorithm) should be made totally invisible, their contents included, prior to full text search. The full text to which the search operation is applied thus becomes:

Nfr. fleur incomplète (seit Trév 1771).

Use case 3: avoidance of false negatives for regular expression matching

In this use case, the objective is to tag dates. To search for dates, a regular expression is applied to the full text version of the XML document. The – character is not a hyphen, but an en dash. This character, as well as the spacing around it, is accounted for in the regular expression used to match dates.

Input (FEW 25, 882a, augmentator):

<p>Emprunt de <geoling>lttard.</geoling> <geoling>mlt.</geoling> <i><etymon>augmentator</etymon></i>
(4<e>e</e>–<lb merge="no"/>
6<e>e</e> s., <biblio>ThesLL</biblio> ;

Expected output, one <date> tag inserted:

<p>Emprunt de <geoling>lttard.</geoling> <geoling>mlt.</geoling> <i><etymon>augmentator</etymon></i>
(<date>4<e>e</e>–<lb merge="no"/>
6<e>e</e> s.</date>, <biblio>ThesLL</biblio> ;

If <e> and <lb/> tags were not skipped, the date range 4e-6e s. (i.e. 4th-6th century) would be split into six fragments. This would lead to a false negative, i.e. the date would not be matched. By virtually removing the <e> and <lb/> tags (as well as others, in practice), the date can be matched by a regular expression. The full text to which the search operation is applied thus becomes:

Emprunt de lttard. mlt. augmentator (4e– 6e s., ThesLL ;

Use case 4: avoidance of false negatives for keyword search

In this use case, the objective is to tag affixes (i.e. prefixes and suffixes). To search for affixes, a keyword search is applied to the full text version of the XML document.

Input (FEW 8, 237a, perfectus):

<pref id="I 2 a">a</pref> mit dem suffix -<i>ivus</i>

Expected output, one <affix> tag inserted:

<pref id="I 2 a">a</pref> mit dem suffix <affix>-<i>ivus</i></affix>

If <i> tags were not skipped, the hyphen of the suffix -ivus would be separated from the rest of the word. This would lead to a false negative, i.e. the affix would not be matched. By virtually removing the <i> tags (as well as others, in practice), the affix keyword can be matched. The full text to which the search operation is applied thus becomes:

a mit dem suffix -ivus

In-memory Document Data Structure

An important design decision in XML document processing is the in-memory representation of its markup and content. A typical choice is the DOM tree representation [DOM]. However, as we are considering text-oriented XML documents only, there are at least two arguments against a tree representation.

We decide instead to represent an XML document as a list of nodes, with each node being either an XML tag or a text chunk. This in-memory representation matches the assumption of text-oriented XML documents. It allows straightforward access to contextual relationships (i.e. is-left-of, is-right-of) between nodes, without precluding to construct additional data structures on top of it in order to access parent/child relationships for specific sections of the document. In the rest of the paper, it will be referred to as a node list.

In practice, the node list can be easily constructed using a validating SAX parser that appends text nodes and tag nodes to the node list as they are loaded to memory. Tag attributes are not appended as nodes themselves, but instead are added as properties of tag nodes. Comments and processing instructions are currently discarded from the XML document (this is an implementation-specific limitation that can be removed through additional engineering hours).

The existing implementation of the API only considers UTF-8-encoded XML documents. Fragments of text of the XML document are normalized as they are inserted into the node list as text nodes. A character map enables the API user to configure all licit character, character entity references and numeric character references. Character sanity is enforced by checking all characters of the XML document against the character map. Character entity references and numeric character references are all resolved into one Unicode character each, possibly in a private use area. All spacing characters are converted to the space character (U+0020), then multiple spaces are compacted into one space only. Leading and trailing spaces within high-level structural tags (dictionary, article, paragraph) are removed. Break tags (e.g. end of line, end of column, end of page,...), despite being tags and not text, are also normalized, i.e. redundant break tags are removed.

Addressing API

The addressing API takes one node as input, and provides a node as output.

Addressing of XML elements, tags or text chunks, in the node list is always relative to a target node and always returns a single node (never a set of nodes). No mechanism of absolute addressing of XML elements in the XML document is currently provided because it was not a requirement for the tagging of the FEW dictionary. An absolute addressing mechanism featuring XPath [XPath] syntax might be supported but at the expense of a severe performance penalty, as the node list does not contain the hierarchical structure of a node tree (see In-memory Document Data Structure here above for the rationale).

Relative addressing of XML elements can be done in three ways: by neighbor access, by tag node search, by text node search.

In theory, the cost of relative addressing is bounded by the number of nodes in the node list. In practice, though, most addressing requests for the tagging of the FEW dictionary are fairly local, e.g. within a paragraph of the text encoded into the XML document. If the addressing API is considered for searches not exhibiting high locality, implementation of auxiliary data structures should be considered to guarantee lower bounds in the search cost. To this end, insights (though no direct reuse) could certainly be drawn from the skip list [Pugh1990a] data structure. The availability of such auxiliary data structures would pave the way for XPath addressing.

Text Retrieval API

Neither a dedicated node-level retrieval API (i.e. within individual nodes only) nor a document-level text retrieval API are provided (i.e. within all individual nodes of the document, considered individually), for two reasons.

Firstly, the text chunk of a text node is a classic Java string. To achieve node-level text retrieval, it is thus straightforward for user code to rely on standard Java facilities such as the operations on Java strings (java.lang.String methods), the regular expression engine (java.util.regex package), or user-supplied packages. This also enables one to plug advanced search mechanisms such as collocate search, or search for inflected forms (e.g. mouse/mice). For instance, in the context of the FEW dictionary, several semantic tagging algorithms depend on a keyword search seeking to match a list of keywords that may each exhibit several nontrivial variations. The decoupling of node-level text retrieval operations (as well as virtual text retrieval over selected sections of the document, which constitutes the core of this paper, see below) from other core operations thus offers great flexibility to users.

Secondly, document-level retrieval can be achieved by using an additional retrieval mechanism on top of the node list representation, such as one of those discussed in the Related Work section of this article.

Text retrieval over sections of the document (i.e. of its node list representation), though, is made possible using the virtual text retrieval API (see below).

Text Update API

The text update API takes one text node and an update specification as input, and updates/inserts/deletes text nodes as output. In the existing implementation, the updates are not in-place, i.e. text nodes are actually substituted with an updated copy of themselves.

Three operations applicable to a target text chunk are provided by the node-level text update API:

The node-level text update API is convenient but can update text or insert tags only between a pair of existing tags.

Text Virtualization API

The text virtualization API takes one node and a virtualization specification as input, and provides a (possibly empty) sequence of virtual strings as output.

Just one operation is provided by the API: the construction of a sequence of virtual strings based on a specification of tag types visibility provided by the API user. The text virtualization API addresses the issue of virtually removing specified types of tag, as well as their contents (if specified), from a sequence of sections of a text-oriented XML document. We define a section as the sequence of nodes starting at a target node and extending immediately prior to (and excluding) the first tag node matching a specified stopper tag type (if any), or the end of the document (in the absence, after the target node, of any stopper tag matching the specified type). The construction of a sequence of virtual strings thus virtualizes a sequence of sections of the XML document.

We define a virtual string as the data structure:

The construction of a sequence of virtual strings is controlled through the specification of a visibility partition of all types of tags that can appear in the XML document. It relies on a tag visibility model that is an extended version (with slightly different semantics) of the tag visibility model initially introduced by Lini et al. [Lini2001a] and used by Tannier [Tannier2005a].

Our tag visibility model is comprised of five classes:

A visibility partition is a partition of the set of all possible tag types that is comprised of five sets, each of which represents a visibility class. A partition is intrinsically comprehensive: all tag types must be included into exactly one visibility class each. At most four visibility classes can thus be empty. When defining a visibility partition, the API user has the option to specify explicitly only four visibility classes, with the remaining visibility class (whichever it is) implicitly considered as including all tag types not yet assigned to a visibility class. As will be illustrated through examples, this can be very handy in practice.

When invoked on a target node, the text virtualization API constructs a sequence of virtual strings, virtual string by virtual string. The text virtualization algorithm can be sketched as follows:

As an example, let us consider the following visibility partition over the tag set { <i>, <lb>, <s>, <t>, <u>, <v> }:

Let the text virtualization API be invoked on the following section of an XML document (the target node is the first node, i.e. the text node Once upon a time,), configured with the aforementioned visibility partition:

Once upon a time,<i /> there was a <s>sentence with an important</s> part,<lb merge="no" />
followed by an <i>irrelevant part</i>.<v />It was followed by<lb merge="no" />
a second sentence separated from the first by a visible tag.<lb merge="no" />
<v>A word near the end of the third sen-<lb merge="discard-hyphen" />
tence was split by a break tag.</v></t>

A sequence of three virtual strings is returned to the calling code: Each character of these virtual strings either is backed by a text node of the underlying XML document, or is a virtual space. A fourth virtual string would have been added to the sequence if there had been some text between </v> and </t>; indeed, empty virtual strings are never added to the returned sequence.

The construction of a sequence of virtual strings could be formalized as a generalized form of string projection [StringProjection] applied to a suitable representation of the selected sections of the XML document, based on classes of nodes of the node list. The projection alphabet would be comprised of one symbol only: text nodes that are not inside an invisible tag. The general alphabet would also include as individual symbols the nodes containing standalone tags (either opening, closing or empty) whose types match those included in the skipped, visible, terminal and unexpected tag visibility classes. The general alphabet would further include as individual symbols the sequences of nodes constituting complete elements (i.e. opening tag, matching closing tag and the sequence of nodes in-between) whose types match those included in the invisible tag visibility class.

Virtual Text Retrieval API

The virtual text retrieval API takes one virtual string and an information request as input, and provides either the text of the virtual string, a node, an offset or a stopper tag as output. Retrieval operations are independently performed by the API user on the text of the virtual string provided by the API.

The virtual text retrieval API implicitly allows tag-aware search by letting the API user perform full text search of a target virtual string. The virtual string exposes the string that was virtually constructed from a section of the XML document. This string is a normal, regular string that can be searched as any other string. In particular, the API user can apply her favorite regexp engine or pattern matching algorithm.

To obtain match points [Lini2001a] and otherwise access the nodes of the XML document backing the virtual string, all the API user needs to provide is the index of the character of interest (from 0 to N-1, if the length of the virtual string is N). Five operations are provided by the virtual text retrieval API:

A virtual space is a space character found in a virtual string, that does not belong to any node of the underlying XML document. Virtual spaces are inserted instead of break tags. If a break tag is preceded by a hyphen and if it contains a specific attribute (i.e. merge), the break tag can be processed differently based on the value of the attribute. Three behaviors are defined:

The text virtualization API thus takes care of automatically adding virtual spaces where specified, and otherwise virtually merges the two parts of hyphenated words, preserving or discarding the hyphen as specified. This mechanism lets the API user control how words split by a break tag are processed in the presence of a hyphen. All is required from the API user is to set the value of a specific attribute for each word split by a break tag that should be virtually recomposed into one word when a virtual string is constructed.

Virtual Text Update API and Virtual Tag Splicing API

The virtual text update API takes one virtual string and an update specification as input, and updates/inserts/deletes text nodes as output. The virtual tag splicing API takes one virtual string and a splicing specification as input, and inserts tag nodes as output.

The virtual text update API allows to modify the text of a virtual string. The virtual tag splicing API allows to splice (i.e. insert) tags into a virtual string. Both APIs allow to specify updates in a straightforward manner and have these updates transparently propagated to the underlying XML document. This may involve, in addition to the update of nodes, the insertion of nodes into the node list as well as the deletion of some of its nodes. To specify updates to a virtual string, all the API user needs to specify, besides the update description, is the index of the character (or indexes of the couple of characters) of interest (from 0 to N-1, if the length of the virtual string is N).

One operation is provided by the virtual text update API:

Similarly to XQuery updates [XQueryUpdateIntro], virtual text updates are not applied immediately. Virtual text updates are accumulated into a list of pending updates. The listed updates are all applied when the API user explicitly invokes the execution of the updates.

Two operations are provided by the virtual tag splicing API:

Also similarly to XQuery updates [XQueryUpdateIntro], virtual tag splicing updates are not applied immediately, but accumulated into a list of pending updates that are applied together when explicitly requested by the API user.

Query and Update Frameworks

Semantic Tagging of XML-Encoded Corpora

The semantic tagging of the Dictionary of Middle Dutch [Voort2005a] as well as of the TLFi dictionary [Dendien2003a, TLFi, TLFi04a] were partially automated. However, due to lack of support for virtualization of the XML document, there was little flexibility in the retrieval of the fields of information. Exceedingly complex and brittle regular expressions including hard-coded markup were used. In practice, this certainly limited any changes to the sequence in which fields of information were tagged, and also discouraged the use of attributes in the markup (because tags, attributes and attribute values all had to be hard-coded statically within the regular expressions).