Changeset 3052

Timestamp:

Apr 19, 2013, 3:56:55 PM (6 years ago)

Author:

lindanl

Message:

changes to GML2SVG section

Location:

docs/Balisage13/Bal2013came0601

Files:

• Bal2013came0601.html (modified) (66 diffs)
• Bal2013came0601.xml (modified) (4 diffs)
• threads_timeline1.png (modified) (previous)
• threads_timeline2.png (modified) (previous)

docs/Balisage13/Bal2013came0601/Bal2013came0601.html

@@ -274 +274 @@
 </div>
 <div id="mast"><div class="content">
-<h2 class="article-title" id="idp74624"></h2>
+<h2 class="article-title" id="idp74240"></h2>
 <div class="author">
 <h3 class="author">Nigel Medforth</h3>
@@ -324 +324 @@
 </div>
 <div class="mast-box">
-<p class="title"><a href="javascript:toggle('idp75744')" class="quiet"><img class="toc-icon" src="plus.png" alt="expand" id="icon-idp75744"></a> <span onclick="javascript:toggle('idp75744');return true">Abstract</span></p>
-<div class="folder" id="folder-idp75744" style="display:none"><p id="idp76048">Prior research on the acceleration of XML processing using SIMD and multi-core
+<p class="title"><a href="javascript:toggle('idp75360')" class="quiet"><img class="toc-icon" src="plus.png" alt="expand" id="icon-idp75360"></a> <span onclick="javascript:toggle('idp75360');return true">Abstract</span></p>
+<div class="folder" id="folder-idp75360" style="display:none"><p id="idp75664">Prior research on the acceleration of XML processing using SIMD and multi-core
             parallelism has lead to a number of interesting research prototypes. This work
             investigates the extent to which the techniques underlying these prototypes could result
@@ -339 +339 @@
 <p><b>Table of Contents</b></p>
 <dl>
-<dt><span class="section"><a href="#idp284352" class="toc">Introduction</a></span></dt>
-<dt><span class="section"><a href="#idp286144" class="toc">Background</a></span></dt>
+<dt><span class="section"><a href="#idp284144" class="toc">Introduction</a></span></dt>
+<dt><span class="section"><a href="#idp285936" class="toc">Background</a></span></dt>
 <dd><dl>
-<dt><span class="section"><a href="#idp286784" class="toc">Xerces C++ Structure</a></span></dt>
-<dt><span class="section"><a href="#idp330512" class="toc">The Parabix Framework</a></span></dt>
-<dt><span class="section"><a href="#idp404544" class="toc">Sequential vs. Parallel Paradigm</a></span></dt>
+<dt><span class="section"><a href="#idp286576" class="toc">Xerces C++ Structure</a></span></dt>
+<dt><span class="section"><a href="#idp330416" class="toc">The Parabix Framework</a></span></dt>
+<dt><span class="section"><a href="#idp404448" class="toc">Sequential vs. Parallel Paradigm</a></span></dt>
 </dl></dd>
-<dt><span class="section"><a href="#idp408928" class="toc">Architecture</a></span></dt>
+<dt><span class="section"><a href="#idp408832" class="toc">Architecture</a></span></dt>
 <dd><dl>
-<dt><span class="section"><a href="#idp409568" class="toc">Overview</a></span></dt>
-<dt><span class="section"><a href="#idp437296" class="toc">Character Set Adapters</a></span></dt>
-<dt><span class="section"><a href="#idp446192" class="toc">Combined Parallel Filtering</a></span></dt>
-<dt><span class="section"><a href="#idp474608" class="toc">Content Stream</a></span></dt>
-<dt><span class="section"><a href="#idp485264" class="toc">Namespace Handling</a></span></dt>
-<dt><span class="section"><a href="#idp528864" class="toc">Error Handling</a></span></dt>
+<dt><span class="section"><a href="#idp409472" class="toc">Overview</a></span></dt>
+<dt><span class="section"><a href="#idp437120" class="toc">Character Set Adapters</a></span></dt>
+<dt><span class="section"><a href="#idp446016" class="toc">Combined Parallel Filtering</a></span></dt>
+<dt><span class="section"><a href="#idp474496" class="toc">Content Stream</a></span></dt>
+<dt><span class="section"><a href="#idp485104" class="toc">Namespace Handling</a></span></dt>
+<dt><span class="section"><a href="#idp528320" class="toc">Error Handling</a></span></dt>
 </dl></dd>
-<dt><span class="section"><a href="#idp539088" class="toc">Multithreading with Pipeline Parallelism</a></span></dt>
-<dt><span class="section"><a href="#idp562720" class="toc">Performance</a></span></dt>
+<dt><span class="section"><a href="#idp538544" class="toc">Multithreading with Pipeline Parallelism</a></span></dt>
+<dt><span class="section"><a href="#idp560656" class="toc">Performance</a></span></dt>
 <dd><dl>
-<dt><span class="section"><a href="#idp565440" class="toc">Xerces C++ SAXCount</a></span></dt>
-<dt><span class="section"><a href="#idp590288" class="toc">GML2SVG</a></span></dt>
+<dt><span class="section"><a href="#idp563376" class="toc">Xerces C++ SAXCount</a></span></dt>
+<dt><span class="section"><a href="#idp588176" class="toc">GML2SVG</a></span></dt>
 </dl></dd>
-<dt><span class="section"><a href="#idp607904" class="toc">Conclusion and Future Work</a></span></dt>
+<dt><span class="section"><a href="#idp605296" class="toc">Conclusion and Future Work</a></span></dt>
 </dl>
 </div>
 <div class="mast-box">
-<p class="title"><a href="javascript:toggle('idp77472')" class="linkbox"><img class="toc-icon" src="plus.png" alt="expand" id="icon-idp77472"></a> <span onclick="javascript:toggle('idp77472');return true">Nigel Medforth</span></p>
-<div class="folder" id="folder-idp77472" style="display:none">
+<p class="title"><a href="javascript:toggle('idp77088')" class="linkbox"><img class="toc-icon" src="plus.png" alt="expand" id="icon-idp77088"></a> <span onclick="javascript:toggle('idp77088');return true">Nigel Medforth</span></p>
+<div class="folder" id="folder-idp77088" style="display:none">
 <h5 class="author-email"><code class="email">&lt;<a class="email" href="mailto:nmedfort@sfu.ca">nmedfort@sfu.ca</a>&gt;</code></h5>
 <div class="affiliation">
@@ -377 +377 @@
 </div>
 <div class="personblurb">
-<p id="idp59168">Nigel Medforth is a M.Sc. student at Simon Fraser University and the lead
+<p id="idp58880">Nigel Medforth is a M.Sc. student at Simon Fraser University and the lead
                developer of icXML. He earned a Bachelor of Technology in Information Technology at
                Kwantlen Polytechnic University in 2009 and was awarded the Dean’s Medal for
                Outstanding Achievement.</p>
-<p id="idp60176">Nigel is currently researching ways to leverage both the Parabix framework and
+<p id="idp59888">Nigel is currently researching ways to leverage both the Parabix framework and
                stream-processing models to further accelerate XML parsing within icXML.</p>
 </div>
@@ -387 +387 @@
 </div>
 <div class="mast-box">
-<p class="title"><a href="javascript:toggle('idp63840')" class="linkbox"><img class="toc-icon" src="plus.png" alt="expand" id="icon-idp63840"></a> <span onclick="javascript:toggle('idp63840');return true">Dan Lin</span></p>
-<div class="folder" id="folder-idp63840" style="display:none">
+<p class="title"><a href="javascript:toggle('idp63552')" class="linkbox"><img class="toc-icon" src="plus.png" alt="expand" id="icon-idp63552"></a> <span onclick="javascript:toggle('idp63552');return true">Dan Lin</span></p>
+<div class="folder" id="folder-idp63552" style="display:none">
 <h5 class="author-email"><code class="email">&lt;<a class="email" href="mailto:lindanl@sfu.ca">lindanl@sfu.ca</a>&gt;</code></h5>
 <div class="affiliation">
@@ -394 +394 @@
 <p class="orgname">Simon Fraser University </p>
 </div>
-<div class="personblurb"><p id="idp65552">Dan Lin is a Ph.D student at Simon Fraser University. She earned a Master of Science
+<div class="personblurb"><p id="idp65264">Dan Lin is a Ph.D student at Simon Fraser University. She earned a Master of Science
              in Computing Science at Simon Fraser University in 2010. Her research focus on on high 
              performance algorithms that exploit parallelization strategies on various multicore platforms.
@@ -401 +401 @@
 </div>
 <div class="mast-box">
-<p class="title"><a href="javascript:toggle('idp68112')" class="linkbox"><img class="toc-icon" src="plus.png" alt="expand" id="icon-idp68112"></a> <span onclick="javascript:toggle('idp68112');return true">Kenneth Herdy</span></p>
-<div class="folder" id="folder-idp68112" style="display:none">
+<p class="title"><a href="javascript:toggle('idp67824')" class="linkbox"><img class="toc-icon" src="plus.png" alt="expand" id="icon-idp67824"></a> <span onclick="javascript:toggle('idp67824');return true">Kenneth Herdy</span></p>
+<div class="folder" id="folder-idp67824" style="display:none">
 <h5 class="author-email"><code class="email">&lt;<a class="email" href="mailto:ksherdy@sfu.ca">ksherdy@sfu.ca</a>&gt;</code></h5>
 <div class="affiliation">
@@ -409 +409 @@
 </div>
 <div class="personblurb">
-<p id="idp270560"> Ken Herdy completed an Advanced Diploma of Technology in Geographical Information
+<p id="idp69552"> Ken Herdy completed an Advanced Diploma of Technology in Geographical Information
                Systems at the British Columbia Institute of Technology in 2003 and earned a Bachelor
                of Science in Computing Science with a Certificate in Spatial Information Systems at
                Simon Fraser University in 2005. </p>
-<p id="idp271296"> Ken is currently pursuing PhD studies in Computing Science at Simon Fraser
+<p id="idp271088"> Ken is currently pursuing PhD studies in Computing Science at Simon Fraser
                University with industrial scholarship support from the Natural Sciences and
                Engineering Research Council of Canada, the Mathematics of Information Technology and
@@ -423 +423 @@
 </div>
 <div class="mast-box">
-<p class="title"><a href="javascript:toggle('idp274032')" class="linkbox"><img class="toc-icon" src="plus.png" alt="expand" id="icon-idp274032"></a> <span onclick="javascript:toggle('idp274032');return true">Rob Cameron</span></p>
-<div class="folder" id="folder-idp274032" style="display:none">
+<p class="title"><a href="javascript:toggle('idp273824')" class="linkbox"><img class="toc-icon" src="plus.png" alt="expand" id="icon-idp273824"></a> <span onclick="javascript:toggle('idp273824');return true">Rob Cameron</span></p>
+<div class="folder" id="folder-idp273824" style="display:none">
 <h5 class="author-email"><code class="email">&lt;<a class="email" href="mailto:cameron@cs.sfu.ca">cameron@cs.sfu.ca</a>&gt;</code></h5>
 <div class="affiliation">
@@ -434 +434 @@
 <p class="orgname">International Characters, Inc.</p>
 </div>
-<div class="personblurb"><p id="idp275696">Dr. Rob Cameron is Professor of Computing Science and Associate Dean of Applied
+<div class="personblurb"><p id="idp275488">Dr. Rob Cameron is Professor of Computing Science and Associate Dean of Applied
                Sciences at Simon Fraser University. His research interests include programming
                language and software system technology, with a specific focus on high performance
@@ -450 +450 @@
 <div id="main">
 <div class="article">
-<h2 class="article-title" id="idp74624"></h2>
-<div class="section" id="idp284352">
+<h2 class="article-title" id="idp74240"></h2>
+<div class="section" id="idp284144">
 <h2 class="title" style="clear: both">Introduction</h2>
-<p id="idp284992"></p>
-<p id="idp285248"></p>
-<p id="idp285504"></p>
-<p id="idp285760"></p>
-</div>
-<div class="section" id="idp286144">
+<p id="idp284784"></p>
+<p id="idp285040"></p>
+<p id="idp285296"></p>
+<p id="idp285552"></p>
+</div>
+<div class="section" id="idp285936">
 <h2 class="title" style="clear: both">Background</h2>
-<div class="section" id="idp286784">
+<div class="section" id="idp286576">
 <h3 class="title" style="clear: both">Xerces C++ Structure</h3>
-<p id="idp287424"> The Xerces C++ parser 
+<p id="idp287216"> The Xerces C++ parser 
             
             
@@ -473 +473 @@
             parsing using either pull parsing or SAX/SAX2 push-style parsing as well as a DOM
             tree-based parsing interface. </p>
-<p id="idp289584">
+<p id="idp289440">
             
             
@@ -492 +492 @@
             expected that a comprehensive restructuring is required, involving all aspects of the
             parser. </p>
-<div class="table-wrapper" id="idp292544">
+<div class="table-wrapper" id="idp292400">
 <p class="title">Table I</p>
-<div class="caption"><p id="idm847680">Execution Time of Top 10 Xerces Functions</p></div>
+<div class="caption"><p id="idm848128">Execution Time of Top 10 Xerces Functions</p></div>
 <table class="table">
 <colgroup span="1">
@@ -549 +549 @@
 </div>
 </div>
-<div class="section" id="idp330512">
+<div class="section" id="idp330416">
 <h3 class="title" style="clear: both">The Parabix Framework</h3>
-<p id="idp331184"> The Parabix (parallel bit stream) framework is a transformative approach to XML
+<p id="idp331088"> The Parabix (parallel bit stream) framework is a transformative approach to XML
             parsing (and other forms of text processing.) The key idea is to exploit the
             availability of wide SIMD registers (e.g., 128-bit) in commodity processors to represent
@@ -576 +576 @@
              multiple
             classes can share the classification cost. </p>
-<div class="table-wrapper" id="idp342752">
+<div class="table-wrapper" id="idp342656">
 <p class="title">Table II</p>
-<div class="caption"><p id="idp343264">XML Source Data</p></div>
+<div class="caption"><p id="idp343168">XML Source Data</p></div>
 <table class="table">
 <colgroup span="1">
@@ -605 +605 @@
 </table>
 </div>
-<div class="table-wrapper" id="idp358656">
+<div class="table-wrapper" id="idp358560">
 <p class="title">Table III</p>
-<div class="caption"><p id="idp359168">8-bit ASCII Basis Bit Streams</p></div>
+<div class="caption"><p id="idp359072">8-bit ASCII Basis Bit Streams</p></div>
 <table class="table">
 <colgroup span="1">
@@ -674 +674 @@
 </table>
 </div>
-<p id="idp399328"> Consider, for example, the XML source data stream shown in the first line of Table II.
+<p id="idp399232"> Consider, for example, the XML source data stream shown in the first line of Table II.
 The remaining lines of this figure show
             several parallel bit streams that are computed in Parabix-style parsing, with each bit
@@ -686 +686 @@
             (using the technique of bitstream addition \cite{cameron-EuroPar2011}), namely streams
             marking the element names, attribute names and attribute values of tags. </p>
-<p id="idp401184"> Two intuitions may help explain how the Parabix approach can lead to improved XML
+<p id="idp401088"> Two intuitions may help explain how the Parabix approach can lead to improved XML
             parsing performance. The first is that the use of the full register width offers a
             considerable information advantage over sequential byte-at-a-time parsing. That is,
@@ -695 +695 @@
             individual decision-bits, an approach that computes many of them in parallel (e.g., 128
             bytes at a time using 128-bit registers) should provide substantial benefit. </p>
-<p id="idp402432"> Previous studies have shown that the Parabix approach improves many aspects of XML
+<p id="idp402336"> Previous studies have shown that the Parabix approach improves many aspects of XML
             processing, including transcoding \cite{Cameron2008}, character classification and
             validation, tag parsing and well-formedness checking. The first Parabix parser used
@@ -704 +704 @@
             \cite{HPCA2012}. Although these research prototypes handled the full syntax of
             schema-less XML documents, they lacked the functionality required by full XML parsers. </p>
-<p id="idp403696"> Commercial XML processors support transcoding of multiple character sets and can
+<p id="idp403600"> Commercial XML processors support transcoding of multiple character sets and can
             parse and validate against multiple document vocabularies. Additionally, they provide
             API facilities beyond those found in research prototypes, including the widely used SAX,
             SAX2 and DOM interfaces. </p>
 </div>
-<div class="section" id="idp404544">
+<div class="section" id="idp404448">
 <h3 class="title" style="clear: both">Sequential vs. Parallel Paradigm</h3>
-<p id="idp405184"> Xerces—like all traditional XML parsers—processes XML documents
+<p id="idp405088"> Xerces—like all traditional XML parsers—processes XML documents
             sequentially. Each character is examined to distinguish between the XML-specific markup,
             such as a left angle bracket <code class="code">&lt;</code>, and the content held within the
             document. As the parser progresses through the document, it alternates between markup
             scanning, validation and content processing modes. </p>
-<p id="idp406720"> In other words, Xerces belongs to an equivalent class applications termed FSM
+<p id="idp406624"> In other words, Xerces belongs to an equivalent class applications termed FSM
             applications\footnote{ Herein FSM applications are considered software systems whose
             behaviour is defined by the inputs, current state and the events associated with
@@ -722 +722 @@
             subsequent characters. Unfortunately, textual data tends to be unpredictable and any
             character could induce a state transition. </p>
-<p id="idp407632"> Parabix-style XML parsers utilize a concept of layered processing. A block of source
+<p id="idp407536"> Parabix-style XML parsers utilize a concept of layered processing. A block of source
             text is transformed into a set of lexical bitstreams, which undergo a series of
             operations that can be grouped into logical layers, e.g., transposition, character
@@ -731 +731 @@
 </div>
 </div>
-<div class="section" id="idp408928">
+<div class="section" id="idp408832">
 <h2 class="title" style="clear: both">Architecture</h2>
-<div class="section" id="idp409568">
+<div class="section" id="idp409472">
 <h3 class="title" style="clear: both">Overview</h3>
-<p id="idp410464"> icXML is more than an optimized version of Xerces. Many components were grouped,
+<p id="idp410368"> icXML is more than an optimized version of Xerces. Many components were grouped,
             restructured and rearchitected with pipeline parallelism in mind. In this section, we
             highlight the core differences between the two systems. As shown in Figure
@@ -761 +761 @@
 <p class="title">Figure 1: Xerces Architecture</p>
 <div class="figure-contents">
-<div class="mediaobject" id="idp417104"><img alt="png image (xerces.png)" src="xerces.png" width="150cm"></div>
+<div class="mediaobject" id="idp417008"><img alt="png image (xerces.png)" src="xerces.png" width="150cm"></div>
 <div class="caption"></div>
 </div>
 </div>
-<p id="idp419360"> In icXML functions are grouped into logical components. As shown in Figure
+<p id="idp419264"> In icXML functions are grouped into logical components. As shown in Figure
             \ref{fig:icxml-arch}, two major categories exist: (1) the Parabix Subsystem and (2) the
             Markup Processor. All tasks in (1) use the Parabix Framework \cite{HPCA2012}, which
@@ -784 +784 @@
             described in Section \ref{section:arch:errorhandling}. From here, two data-independent
             branches exist: the Symbol Resolver and Content Preparation Unit. </p>
-<p id="idp423520"> A typical XML file contains few unique element and attribute names—but
+<p id="idp423344"> A typical XML file contains few unique element and attribute names—but
             each of them will occur frequently. icXML stores these as distinct data structures,
             called symbols, each with their own global identifier (GID). Using the symbol marker
@@ -790 +790 @@
                Resolver</span> scans through the raw data to produce a sequence of GIDs, called
             the <span class="ital">symbol stream</span>. </p>
-<p id="idp426112"> The final components of the Parabix Subsystem are the <span class="ital">Content
+<p id="idp425936"> The final components of the Parabix Subsystem are the <span class="ital">Content
                Preparation Unit</span> and <span class="ital">Content Stream
             Generator</span>. The former takes the (transposed) basis bitstreams and selectively
             filters them, according to the information provided by the Parallel Markup Parser, and
             the latter transforms the filtered streams into the tagged UTF-16 <span class="ital">content stream</span>, discussed in Section \ref{section:arch:contentstream}. </p>
-<p id="idp429024"> Combined, the symbol and content stream form icXML's compressed IR of the XML
+<p id="idp428848"> Combined, the symbol and content stream form icXML's compressed IR of the XML
             document. The <span class="ital">Markup Processor</span>~parses the IR to
             validate and produce the sequential output for the end user. The <span class="ital">Final WF checker</span> performs inter-element well-formedness validation that
@@ -807 +807 @@
 <p class="title">Figure 2: icXML Architecture</p>
 <div class="figure-contents">
-<div class="mediaobject" id="idp434848"><img alt="png image (icxml.png)" src="icxml.png" width="500cm"></div>
+<div class="mediaobject" id="idp434672"><img alt="png image (icxml.png)" src="icxml.png" width="500cm"></div>
 <div class="caption"></div>
 </div>
 </div>
 </div>
-<div class="section" id="idp437296">
+<div class="section" id="idp437120">
 <h3 class="title" style="clear: both">Character Set Adapters</h3>
-<p id="idp437968"> In Xerces, all input is transcoded into UTF-16 to simplify the parsing costs of
+<p id="idp437792"> In Xerces, all input is transcoded into UTF-16 to simplify the parsing costs of
             Xerces itself and provide the end-consumer with a single encoding format. In the
             important case of UTF-8 to UTF-16 transcoding, the transcoding costs can be significant,
@@ -821 +821 @@
             other cases, transcoding may involve table look-up operations for each byte of input. In
             any case, transcoding imposes at least a cost of buffer copying. </p>
-<p id="idp439024"> In icXML, however, the concept of Character Set Adapters (CSAs) is used to minimize
+<p id="idp438848"> In icXML, however, the concept of Character Set Adapters (CSAs) is used to minimize
             transcoding costs. Given a specified input encoding, a CSA is responsible for checking
             that input code units represent valid characters, mapping the characters of the encoding
@@ -827 +827 @@
             item streams), as well as supporting ultimate transcoding requirements. All of this work
             is performed using the parallel bitstream representation of the source input. </p>
-<p id="idp440000"> An important observation is that many character sets are an extension to the legacy
+<p id="idp439824"> An important observation is that many character sets are an extension to the legacy
             7-bit ASCII character set. This includes the various ISO Latin character sets, UTF-8,
             UTF-16 and many others. Furthermore, all significant characters for parsing XML are
             confined to the ASCII repertoire. Thus, a single common set of lexical item calculations
             serves to compute lexical item streams for all such ASCII-based character sets. </p>
-<p id="idp440880"> A second observation is that—regardless of which character set is
+<p id="idp440704"> A second observation is that—regardless of which character set is
             used—quite often all of the characters in a particular block of input will be
             within the ASCII range. This is a very simple test to perform using the bitstream
@@ -839 +839 @@
             be skipped. Transcoding to UTF-16 becomes trivial as the high eight bitstreams of the
             UTF-16 form are each set to zero in this case. </p>
-<p id="idp442800"> A third observation is that repeated transcoding of the names of XML elements,
+<p id="idp442624"> A third observation is that repeated transcoding of the names of XML elements,
             attributes and so on can be avoided by using a look-up mechanism. That is, the first
             occurrence of each symbol is stored in a look-up table mapping the input encoding to a
@@ -846 +846 @@
             symbol look up is required to apply various XML validation rules, there is achieves the
             effect of transcoding each occurrence without additional cost. </p>
-<p id="idp443856"> The cost of individual character transcoding is avoided whenever a block of input is
+<p id="idp443680"> The cost of individual character transcoding is avoided whenever a block of input is
             confined to the ASCII subset and for all but the first occurrence of any XML element or
             attribute name. Furthermore, when transcoding is required, the parallel bitstream
@@ -857 +857 @@
             using bit scan operations. </p>
 </div>
-<div class="section" id="idp446192">
+<div class="section" id="idp446016">
 <h3 class="title" style="clear: both">Combined Parallel Filtering</h3>
-<p id="idp446880"> As just mentioned, UTF-8 to UTF-16 transcoding involves marking all but the last
+<p id="idp446704"> As just mentioned, UTF-8 to UTF-16 transcoding involves marking all but the last
             bytes of multi-byte UTF-8 sequences as positions for deletion. For example, the two
             Chinese characters <code class="code">äœ å¥œ</code> are represented as two
@@ -873 +873 @@
             may then be completed by applying parallel deletion and inverse transposition of the
             UTF-16 bitstreams\cite{Cameron2008}. </p>
-<div class="table-wrapper" id="idp451040">
+<div class="table-wrapper" id="idp450864">
 <p class="title">Table IV</p>
-<div class="caption"><p id="idp451552">XML Source Data and Derived Parallel Bit Streams</p></div>
+<div class="caption"><p id="idp451376">XML Source Data and Derived Parallel Bit Streams</p></div>
 <table class="table">
 <colgroup span="1">
@@ -925 +925 @@
 </table>
 </div>
-<p id="idp464640"> Rather than immediately paying the costs of deletion and transposition just for
+<p id="idp464464"> Rather than immediately paying the costs of deletion and transposition just for
             transcoding, however, icXML defers these steps so that the deletion masks for several
             stages of processing may be combined. In particular, this includes core XML requirements
@@ -938 +938 @@
             
          </p>
-<p id="idp467152"> In essence, the deletion masks for transcoding and for line break normalization each
+<p id="idp466976"> In essence, the deletion masks for transcoding and for line break normalization each
             represent a bitwise filter; these filters can be combined using bitwise-or so that the
             parallel deletion algorithm need only be applied once. </p>
-<p id="idp468464"> A further application of combined filtering is the processing of XML character and
+<p id="idp468288"> A further application of combined filtering is the processing of XML character and
             entity references. Consider, for example, the references <code class="code">&amp;</code> or
                <code class="code">&lt;</code>. which must be replaced in XML processing with the single
@@ -954 +954 @@
             UTF-16 code unit. In the case, that this is not true, it is addressed in
             post-processing. </p>
-<p id="idp473280"> The final step of combined filtering occurs during the process of reducing markup
+<p id="idp473168"> The final step of combined filtering occurs during the process of reducing markup
             data to tag bytes preceding each significant XML transition as described in
             section~\ref{section:arch:contentstream}. Overall, icXML avoids separate buffer copying
@@ -964 +964 @@
             Haswell architecture. </p>
 </div>
-<div class="section" id="idp474608">
+<div class="section" id="idp474496">
 <h3 class="title" style="clear: both">Content Stream</h3>
-<p id="idp475280"> A relatively-unique concept for icXML is the use of a filtered content stream.
+<p id="idp475168"> A relatively-unique concept for icXML is the use of a filtered content stream.
             Rather that parsing an XML document in its original format, the input is transformed
             into one that is easier for the parser to iterate through and produce the sequential
@@ -974 +974 @@
             
             through the parallel filtering algorithm, described in section \ref{sec:parfilter}. </p>
-<p id="idp477680"> Combined with the symbol stream, the parser traverses the content stream to
+<p id="idp477568"> Combined with the symbol stream, the parser traverses the content stream to
             effectively reconstructs the input document in its output form. The initial <span class="ital">0</span> indicates an empty content string. The following
                <code class="code">&gt;</code> indicates that a start tag without any attributes is the first
@@ -986 +986 @@
             null character in the content stream in parallel, which in turn means the parser can
             directly jump to the end of every string without scanning for it. </p>
-<p id="idp481120"> Following <code class="code">'fee'</code> is a <code class="code">=</code>, which marks the
+<p id="idp480960"> Following <code class="code">'fee'</code> is a <code class="code">=</code>, which marks the
             existence of an attribute. Because all of the intra-element was performed in the Parabix
             Subsystem, this must be a legal attribute. Since attributes can only occur within start
@@ -1000 +1000 @@
             that the appropriate scope-nesting rules have been applied. </p>
 </div>
-<div class="section" id="idp485264">
+<div class="section" id="idp485104">
 <h3 class="title" style="clear: both">Namespace Handling</h3>
-<p id="idp486352"> In XML, namespaces prevents naming conflicts when multiple vocabularies are used
+<p id="idp486192"> In XML, namespaces prevents naming conflicts when multiple vocabularies are used
             together. It is especially important when a vocabulary application-dependant meaning,
             such as when XML or SVG documents are embedded within XHTML files. Namespaces are bound
@@ -1019 +1019 @@
             uniquely-named items because the current vocabulary is determined by the namespace(s)
             that are in-scope. </p>
-<div class="table-wrapper" id="idp493520">
+<div class="table-wrapper" id="idp493312">
 <p class="title">Table V</p>
-<div class="caption"><p id="idp494032">XML Namespace Example</p></div>
+<div class="caption"><p id="idp493824">XML Namespace Example</p></div>
 <table class="table">
 <colgroup span="1">
@@ -1055 +1055 @@
 </table>
 </div>
-<p id="idp503056"> In both Xerces and icXML, every URI has a one-to-one mapping to a URI ID. These
+<p id="idp502800"> In both Xerces and icXML, every URI has a one-to-one mapping to a URI ID. These
             persist for the lifetime of the application through the use of a global URI pool. Xerces
             maintains a stack of namespace scopes that is pushed (popped) every time a start tag
@@ -1063 +1063 @@
             those that declare a set of namespaces upfront and never change them, and (2) those that
             repeatedly modify the namespaces in predictable patterns. </p>
-<p id="idp504192"> For that reason, icXML contains an independent namespace stack and utilizes bit
+<p id="idp503936"> For that reason, icXML contains an independent namespace stack and utilizes bit
             vectors to cheaply perform 
              When a prefix is
@@ -1077 +1077 @@
             found using a bit-scan intrinsic. A namespace binding table, similar to Table
             \ref{tbl:namespace1}, provides the actual URI ID. </p>
-<div class="table-wrapper" id="idp508608">
+<div class="table-wrapper" id="idp508352">
 <p class="title">Table VI</p>
-<div class="caption"><p id="idp509120">Namespace Binding Table Example</p></div>
+<div class="caption"><p id="idp508864">Namespace Binding Table Example</p></div>
 <table class="table">
 <colgroup span="1">
@@ -1120 +1120 @@
 </table>
 </div>
-<p id="idp525504">
+<p id="idp524960">
             
             
@@ -1126 +1126 @@
             
          </p>
-<p id="idp527408"> To ensure that scoping rules are adhered to, whenever a start tag is encountered,
+<p id="idp526864"> To ensure that scoping rules are adhered to, whenever a start tag is encountered,
             any modification to the currently visible namespaces is calculated and stored within a
             stack of bit vectors denoting the locally modified namespace bindings. When an end tag
@@ -1135 +1135 @@
          </p>
 </div>
-<div class="section" id="idp528864">
+<div class="section" id="idp528320">
 <h3 class="title" style="clear: both">Error Handling</h3>
-<p id="idp529536">
+<p id="idp528992">
             
             Xerces outputs error messages in two ways: through the programmer API and as thrown
@@ -1146 +1146 @@
             \ref{fig:icxml-arch}, icXML is divided into two sections: the Parabix Subsystem and
             Markup Processor, each with its own system for detecting and producing error messages. </p>
-<p id="idp531168"> Within the Parabix Subsystem, all computations are performed in parallel, a block at
+<p id="idp530624"> Within the Parabix Subsystem, all computations are performed in parallel, a block at
             a time. Errors are derived as artifacts of bitstream calculations, with a 1-bit marking
             the byte-position of an error within a block, and the type of error is determined by the
@@ -1179 +1179 @@
             detected, the sum of those skipped positions is subtracted from the distance to
             determine the actual column number. </p>
-<p id="idp536656"> The Markup Processor is a state-driven machine. As such, error detection within it
+<p id="idp536112"> The Markup Processor is a state-driven machine. As such, error detection within it
             is very similar to Xerces. However, reporting the correct line/column is a much more
             difficult problem. The Markup Processor parses the content stream, which is a series of
@@ -1193 +1193 @@
 </div>
 </div>
-<div class="section" id="idp539088">
+<div class="section" id="idp538544">
 <h2 class="title" style="clear: both">Multithreading with Pipeline Parallelism</h2>
-<p id="idp539792"> As discussed in section \ref{background:xerces}, Xerces can be considered a FSM
+<p id="idp539248"> As discussed in section \ref{background:xerces}, Xerces can be considered a FSM
          application. These are "embarrassingly
          sequential."\cite{Asanovic:EECS-2006-183} and notoriously difficult to
@@ -1203 +1203 @@
          well into the general model of pipeline parallelism, in which each thread is in charge of a
          single module or group of modules. </p>
-<p id="idp541648"> The most straightforward division of work in icXML is to separate the Parabix Subsystem
+<p id="idp541104"> The most straightforward division of work in icXML is to separate the Parabix Subsystem
          and the Markup Processor into distinct logical layers into two separate stages. The
          resultant application, <span class="ital">icXML-p</span>, is a course-grained
@@ -1224 +1224 @@
             <code class="code">T<sub>2</sub></code> to finish reading the shared data before it can
          reuse the memory space. </p>
-<p id="idp550720">
+<p id="idp550224">
         <div class="figure" id="threads_timeline1">
 <p class="title">Figure 3: Thread Balance in Two-Stage Pipelines</p>
 <div class="figure-contents">
-<div class="mediaobject" id="idp552112"><img alt="png image (threads_timeline1.png)" src="threads_timeline1.png" width="500cm"></div>
+<div class="mediaobject" id="idp551616"><img alt="png image (threads_timeline1.png)" src="threads_timeline1.png" width="500cm"></div>
+<div class="mediaobject" id="idp553392"><img alt="png image (threads_timeline2.png)" src="threads_timeline2.png" width="500cm"></div>
 <div class="caption"></div>
 </div>
 </div>
-        <div class="figure" id="threads_timeline2">
-<p class="title">Figure 4: Thread Balance in Two-Stage Pipelines</p>
-<div class="figure-contents">
-<div class="mediaobject" id="idp555488"><img alt="png image (threads_timeline2.png)" src="threads_timeline2.png" width="500cm"></div>
-<div class="caption"></div>
-</div>
-</div>
       </p>
-<p id="idp557904"> Overall, our design is intended to benefit a range of applications. Conceptually, we
+<p id="idp555840"> Overall, our design is intended to benefit a range of applications. Conceptually, we
          consider two design points. The first, the parsing performed by the Parabix Subsystem
          dominates at 67% of the overall cost, with the cost of application processing (including
@@ -1246 +1240 @@
          scenario, the cost of application processing dominates at 60%, while the cost of XML
          parsing represents an overhead of 40%. </p>
-<p id="idp558816"> Our design is predicated on a goal of using the Parabix framework to achieve a 50% to
+<p id="idp556752"> Our design is predicated on a goal of using the Parabix framework to achieve a 50% to
          100% improvement in the parsing engine itself. In a best case scenario, a 100% improvement
          of the Parabix Subsystem for the design point in which XML parsing dominates at 67% of the
@@ -1254 +1248 @@
          about 33% of the original work. In this case, Amdahl's law predicts that we could expect up
          to a 3x speedup at best. </p>
-<p id="idp559936"> At the other extreme of our design range, we consider an application in which core
+<p id="idp557872"> At the other extreme of our design range, we consider an application in which core
          parsing cost is 40%. Assuming the 2x speedup of the Parabix Subsystem over the
          corresponding Xerces core, single-threaded icXML delivers a 25% speedup. However, the most
@@ -1260 +1254 @@
          the entire latency of parsing within the serial time required by the application. In this
          case, we achieve an overall speedup in processing time by 1.67x. </p>
-<p id="idp560880"> Although the structure of the Parabix Subsystem allows division of the work into
+<p id="idp558816"> Although the structure of the Parabix Subsystem allows division of the work into
          several pipeline stages and has been demonstrated to be effective for four pipeline stages
          in a research prototype \cite{HPCA2012}, our analysis here suggests that the further
@@ -1268 +1262 @@
          the cost of application logic that could match reductions in core parsing cost. </p>
 </div>
-<div class="section" id="idp562720">
+<div class="section" id="idp560656">
 <h2 class="title" style="clear: both">Performance</h2>
-<p id="idp563392"> We evaluate Xerces-C++ 3.1.1, icXML, icXML-p against two benchmarking applications: the
+<p id="idp561328"> We evaluate Xerces-C++ 3.1.1, icXML, icXML-p against two benchmarking applications: the
          Xerces C++ SAXCount sample application, and a real world GML to SVG transformation
          application. We investigated XML parser performance using an Intel Core i7 quad-core (Sandy
@@ -1276 +1270 @@
          L1 cache, 256 kB (per core) L2 cache, 8 MB L3 cache) running the 64-bit version of Ubuntu
          12.04 (Linux). </p>
-<p id="idp564304"> We analyzed the execution profiles of each XML parser using the performance counters
+<p id="idp562240"> We analyzed the execution profiles of each XML parser using the performance counters
          found in the processor. We chose several key hardware events that provide insight into the
          profile of each application and indicate if the processor is doing useful work. The set of
@@ -1284 +1278 @@
          collection of hardware performance monitoring statistics. In addition, we used the Linux
          perf \cite{perf} utility to collect per core hardware events. </p>
-<div class="section" id="idp565440">
+<div class="section" id="idp563376">
 <h3 class="title" style="clear: both">Xerces C++ SAXCount</h3>
-<p id="idp566112"> Xerces comes with sample applications that demonstrate salient features of the
+<p id="idp564048"> Xerces comes with sample applications that demonstrate salient features of the
             parser. SAXCount is the simplest such application: it counts the elements, attributes
             and characters of a given XML file using the (event based) SAX API and prints out the
             totals. </p>
-<p id="idp566864"> Table \ref{XMLDocChars} shows the document characteristics of the XML input files
+<p id="idp564752"> Table \ref{XMLDocChars} shows the document characteristics of the XML input files
             selected for the Xerces C++ SAXCount benchmark. The jaw.xml represents document-oriented
             XML inputs and contains the three-byte and four-byte UTF-8 sequence required for the
             UTF-8 encoding of Japanese characters. The remaining data files are data-oriented XML
             documents and consist entirely of single byte encoded ASCII characters. 
-  <div class="table-wrapper" id="idp567600">
+  <div class="table-wrapper" id="idp565488">
 <p class="title">Table VII</p>
-<div class="caption"><p id="idp568112">XML Document Characteristics</p></div>
+<div class="caption"><p id="idp566000">XML Document Characteristics</p></div>
 <table class="table">
 <colgroup span="1">
@@ -1346 +1340 @@
 </div>           
 </p>
-<p id="idp583696"> A key predictor of the overall parsing performance of an XML file is markup
+<p id="idp581584"> A key predictor of the overall parsing performance of an XML file is markup
             density\footnote{ Markup Density: the ratio of markup bytes used to define the structure
             of the document vs. its file size.}. This metric has substantial influence on the
@@ -1353 +1347 @@
             of document-oriented and data-oriented XML files to analyze performance over a spectrum
             of markup densities. </p>
-<p id="idp585312"> Figure \ref{perf_SAX} compares the performance of Xerces, icXML and pipelined icXML
+<p id="idp583200"> Figure \ref{perf_SAX} compares the performance of Xerces, icXML and pipelined icXML
             in terms of CPU cycles per byte for the SAXCount application. The speedup for icXML over
             Xerces is 1.3x to 1.8x. With two threads on the multicore machine, icXML-p can achieve
@@ -1360 +1354 @@
             icXML-p performs better as markup-density increases because the work performed by each
             stage is well balanced in this application. </p>
-<p id="idp586352">
+<p id="idp584240">
         <div class="figure" id="perf_SAX">
-<p class="title">Figure 5: SAXCount Performance Comparison</p>
+<p class="title">Figure 4: SAXCount Performance Comparison</p>
 <div class="figure-contents">
-<div class="mediaobject" id="idp587744"><img alt="png image (perf_SAX.png)" src="perf_SAX.png" width="500cm"></div>
+<div class="mediaobject" id="idp585632"><img alt="png image (perf_SAX.png)" src="perf_SAX.png" width="500cm"></div>
 <div class="caption"></div>
 </div>
@@ -1370 +1364 @@
          </p>
 </div>
-<div class="section" id="idp590288">
+<div class="section" id="idp588176">
 <h3 class="title" style="clear: both">GML2SVG</h3>
-<p id="idp590960">       As a more substantial application of XML processing, the GML-to-SVG (GML2SVG) application
+<p id="idp588848">       As a more substantial application of XML processing, the GML-to-SVG (GML2SVG) application
 was chosen.   This application transforms geospatially encoded data represented using 
 an XML representation in the form of Geography Markup Language (GML) \cite{lake2004geography} 
@@ -1384 +1378 @@
 a known XML format for the purpose of analysis and restructuring to meet
 the requirements of an alternative format.</p>
-<p id="idp592288">Our GML to SVG data translations are executed on GML source data 
+<p id="idp590224">Our GML to SVG data translations are executed on GML source data 
 modelling the city of Vancouver, British Columbia, Canada. 
 The GML source document set 
@@ -1392 +1386 @@
 213.4 MB of source GML data generates 91.9 MB of target SVG data.</p>
 <div class="figure" id="perf_GML2SVG">
-<p class="title">Figure 6: Performance Comparison for GML2SVG</p>
+<p class="title">Figure 5: Performance Comparison for GML2SVG</p>
 <div class="figure-contents">
-<div class="mediaobject" id="idp594320"><img alt="png image (Throughput.png)" src="Throughput.png" width="500cm"></div>
+<div class="mediaobject" id="idp592304"><img alt="png image (Throughput.png)" src="Throughput.png" width="500cm"></div>
 <div class="caption"></div>
 </div>
 </div>
-<p id="idp596608">Figure \ref{perf_GML2SVG} compares the performance of the GML2SVG application linked against
-the Xerces, \icXML{} and \icXMLp{}.   
-On the GML workload with this application, single-thread \icXML{} 
-achieved about a 50\% acceleration over Xerces, 
+<p id="idp594592">Figure \ref{perf_GML2SVG} compares the performance of the GML2SVG application linked against
+the Xerces, icXML and icXML-p.   
+On the GML workload with this application, single-thread icXML
+achieved about a 50% acceleration over Xerces, 
 increasing throughput on our test machine from 58.3 MB/sec to 87.9 MB/sec.   
-Using \icXMLp{}, a further throughput increase to 111 MB/sec was recorded, 
+Using icXML-p, a further throughput increase to 111 MB/sec was recorded, 
 approximately a 2X speedup.</p>
-<p id="idp597440">An important aspect of \icXML{} is the replacement of much branch-laden
+<p id="idp595408">An important aspect of icXML is the replacement of much branch-laden
 sequential code inside Xerces with straight-line SIMD code using far
 fewer branches.  Figure \ref{branchmiss_GML2SVG} shows the corresponding
 improvement in branching behaviour, with a dramatic reduction in branch misses per kB.
-It is also interesting to note that \icXMLp{} goes even further.   
+It is also interesting to note that icXML-p goes even further.   
 In essence, in using pipeline parallelism to split the instruction 
 stream onto separate cores, the branch target buffers on each core are
 less overloaded and able to increase the successful branch prediction rate.</p>
 <div class="figure" id="branchmiss_GML2SVG">
-<p class="title">Figure 7: Comparative Branch Misprediction Rate</p>
+<p class="title">Figure 6: Comparative Branch Misprediction Rate</p>
 <div class="figure-contents">
-<div class="mediaobject" id="idp600144"><img alt="png image (BM.png)" src="BM.png" width="500cm"></div>
+<div class="mediaobject" id="idp597520"><img alt="png image (BM.png)" src="BM.png" width="500cm"></div>
 <div class="caption"></div>
 </div>
 </div>
-<p id="idp602432">The behaviour of the three versions with respect to L1 cache misses per kB is shown
+<p id="idp599808">The behaviour of the three versions with respect to L1 cache misses per kB is shown
 in Figure \ref{cachemiss_GML2SVG}.   Improvements are shown in both instruction-
 and data-cache performance with the improvements in instruction-cache
-behaviour the most dramatic.   Single-threaded \icXML{} shows substantially improved
+behaviour the most dramatic.   Single-threaded icXML shows substantially improved
 performance over Xerces on both measures.   
-Although \icXMLp{} is slightly worse \wrt{} data-cache performance, 
+Although icXML-p is slightly worse with respect to data-cache performance, 
 this is more than offset by a further dramatic reduction in instruction-cache miss rate.
 Again partitioning the instruction stream through the pipeline parallelism model has 
 significant benefit.</p>
 <div class="figure" id="cachemiss_GML2SVG">
-<p class="title">Figure 8: Comparative Cache Miss Rate</p>
+<p class="title">Figure 7: Comparative Cache Miss Rate</p>
 <div class="figure-contents">
-<div class="mediaobject" id="idp604544"><img alt="png image (CM.png)" src="CM.png" width="500cm"></div>
+<div class="mediaobject" id="idp601936"><img alt="png image (CM.png)" src="CM.png" width="500cm"></div>
 <div class="caption"></div>
 </div>
 </div>
-<p id="idp606832">One caveat with this study is that the GML2SVG application did not exhibit 
+<p id="idp604224">One caveat with this study is that the GML2SVG application did not exhibit 
 a relative balance of processing between application code and Xerces library
-code reaching the 33\% figure.  This suggests that for this application and
+code reaching the 33% figure.  This suggests that for this application and
 possibly others, further separating the logical layers of the
-\icXML{} engine into different pipeline stages could well offer significant benefit.
+icXML engine into different pipeline stages could well offer significant benefit.
 This remains an area of ongoing work.</p>
 </div>
 </div>
-<div class="section" id="idp607904">
+<div class="section" id="idp605296">
 <h2 class="title" style="clear: both">Conclusion and Future Work</h2>
-<p id="idp608592"> This paper is the first case study documenting the significant performance benefits
+<p id="idp605984"> This paper is the first case study documenting the significant performance benefits
          that may be realized through the integration of parallel bitstream technology into existing
          widely-used software libraries. In the case of the Xerces-C++ XML parser, the combined
@@ -1456 +1450 @@
          technologies, this is an important case study demonstrating the general feasibility of
          these techniques. </p>
-<p id="idp609872"> The further development of icXML to move beyond 2-stage pipeline parallelism is
+<p id="idp607264"> The further development of icXML to move beyond 2-stage pipeline parallelism is
          ongoing, with realistic prospects for four reasonably balanced stages within the library.
          For applications such as GML2SVG which are dominated by time spent on XML parsing, such a
          multistage pipelined parsing library should offer substantial benefits. </p>
-<p id="idp610640"> The example of XML parsing may be considered prototypical of finite-state machines
+<p id="idp608032"> The example of XML parsing may be considered prototypical of finite-state machines
          applications which have sometimes been considered "embarassingly
          sequential" and so difficult to parallelize that "nothing
@@ -1466 +1460 @@
          point in making the case that parallelization can indeed be helpful across a broad array of
          application types. </p>
-<p id="idp612016"> To overcome the software engineering challenges in applying parallel bitstream
+<p id="idp609408"> To overcome the software engineering challenges in applying parallel bitstream
          technology to existing software systems, it is clear that better library and tool support
          is needed. The techniques used in the implementation of icXML and documented in this paper
@@ -1473 +1467 @@
       </p>
 </div>
-<div class="bibliography" id="idp613504">
+<div class="bibliography" id="idp611376">
 <h2 class="title" style="clear:both">Bibliography</h2>
 <p class="bibliomixed" id="XMLChip09">[Leventhal and Lemoine 2009] Leventhal, Michael and

docs/Balisage13/Bal2013came0601/Bal2013came0601.xml

@@ -798 +798 @@
             </imageobject>
           </mediaobject>
-          <caption>
-          </caption>
-        </figure>
-        <figure xml:id="threads_timeline2">
-          <title>Thread Balance in Two-Stage Pipelines</title>
           <mediaobject>
             <imageobject>
@@ -952 +947 @@
         
 <para>Figure \ref{perf_GML2SVG} compares the performance of the GML2SVG application linked against
-the Xerces, \icXML{} and \icXMLp{}.   
-On the GML workload with this application, single-thread \icXML{} 
-achieved about a 50\% acceleration over Xerces, 
+the Xerces, icXML and icXML-p.   
+On the GML workload with this application, single-thread icXML
+achieved about a 50% acceleration over Xerces, 
 increasing throughput on our test machine from 58.3 MB/sec to 87.9 MB/sec.   
-Using \icXMLp{}, a further throughput increase to 111 MB/sec was recorded, 
+Using icXML-p, a further throughput increase to 111 MB/sec was recorded, 
 approximately a 2X speedup.</para>
 
-<para>An important aspect of \icXML{} is the replacement of much branch-laden
+<para>An important aspect of icXML is the replacement of much branch-laden
 sequential code inside Xerces with straight-line SIMD code using far
 fewer branches.  Figure \ref{branchmiss_GML2SVG} shows the corresponding
 improvement in branching behaviour, with a dramatic reduction in branch misses per kB.
-It is also interesting to note that \icXMLp{} goes even further.   
+It is also interesting to note that icXML-p goes even further.   
 In essence, in using pipeline parallelism to split the instruction 
 stream onto separate cores, the branch target buffers on each core are
@@ -982 +977 @@
 in Figure \ref{cachemiss_GML2SVG}.   Improvements are shown in both instruction-
 and data-cache performance with the improvements in instruction-cache
-behaviour the most dramatic.   Single-threaded \icXML{} shows substantially improved
+behaviour the most dramatic.   Single-threaded icXML shows substantially improved
 performance over Xerces on both measures.   
-Although \icXMLp{} is slightly worse \wrt{} data-cache performance, 
+Although icXML-p is slightly worse with respect to data-cache performance, 
 this is more than offset by a further dramatic reduction in instruction-cache miss rate.
 Again partitioning the instruction stream through the pipeline parallelism model has 
@@ -1002 +997 @@
 <para>One caveat with this study is that the GML2SVG application did not exhibit 
 a relative balance of processing between application code and Xerces library
-code reaching the 33\% figure.  This suggests that for this application and
+code reaching the 33% figure.  This suggests that for this application and
 possibly others, further separating the logical layers of the
-\icXML{} engine into different pipeline stages could well offer significant benefit.
+icXML engine into different pipeline stages could well offer significant benefit.
 This remains an area of ongoing work.</para>
       </section>