Balisage Paper: From Word to XML via iXML

5.2.1. Top-level rule in the grammar

A simplified version of the top-level grammar rule in this grammar is:

                        
TLRR-generic-fields-0 =
-"<TLRR-rudimentary-XML>", para-or-field+
-"</TLRR-rudimentary-XML>".  

That is, the input consists of a start-tag for the element TLRR-rudimentary-XML, a series of things (in practice, all p elements) we will recognize as paragraphs or fields, and an end-tag for the TLRR-rudimentary-XML element. The heart of the grammar will lie in the rule para-or-field and its descendants.

In reality, however, as examination of the full grammar (given as an attachment) will show, the rule actually used is more complicated. Depending on the process used to produce the RXML input, the input may or may not have an XML declaration. And the elements in the input will typically be separated by whitespace, for legibility. We will need to add rules to recognize them, and refer to those rules from this one. And, finally, we would like to make the output more legible by injecting line breaks before the series of paragraphs-or-fields and after each individual paragraph-or-field. Making all these things explicit in the rule adds some visual clutter in the form of references to the nonterminals xml-declaration, s (for optional whitespace), and inject-NL (which matches the empty string and inserts a newline character into the output), so the rule takes the following form.

                        
TLRR-generic-fields-0 = s,
(xml-declaration, s)?, -"<TLRR-rudimentary-XML>", s, inject-NL,
(para-or-field, inject-NL) ++ s, s, -"</TLRR-rudimentary-XML>",
s.  

5.2.2. Recognizing paragraphs and fields

The grammar distinguishes four varieties of paragraph-or-field, as indicated in the following rule.

                        
-para-or-field = title | trial-number
| field | p .  

The mark “-” on the left-hand side indicates that the nonterminal will not be serialized as an element, so there won’t be a series of elements named para-or-field. (A significant part of the design effort involved in developing an iXML grammar for data one wants to work with lies in choosing which nonterminals should be serialized as elements, which as attributes, and which should be hidden, like para-or-field.)

5.2.3. The data after step 1

The result of parsing the RXML form of the data with the rxml-to-gfxml0 grammar can be illustrated by the beginning of the file, up through the trial number for trial #2. Line breaks have been introduced in long paragraphs, to simplify display. In the actual data, each field and each p element occupies a single line.

                        
<TLRR-generic-fields-0
xmlns:ixml="http://invisiblexml.org/NS"
ixml:state="version-mismatch"> <title>TLRR (2)</title>
<p/> <p/> <trial-number>1</trial-number>
<field><label>date</label><value>149
[1]</value></field>
<field><label>charge</label><value><i>quaestio
extraordinaria</i> (proposed) [2] (misconduct as gov. Lusitania
150)</value></field>
<field><label>defendant</label><value>Ser. Sulpicius
Galba (58) cos. 144 spoke <i>pro se</i>
(<i>ORF</i> 19.II, III)</value></field>
<field><label>advocate</label><value>Q. Fulvius
Nobilior (95) cos. 153, cens. 136</value></field>
<field><label>prosecutors</label></field>
<p indent="720">L. Cornelius Cethegus (91)</p> <p
indent="720">M. Porcius Cato (9) cos. 195, cens. 184
(<i>ORF</i> 8.LI)</p> <p
indent="720">L. Scribonius Libo (18) tr. pl. 149
(<i>promulgator</i>)</p>
<field><label>outcome</label> <value>proposal
defeated</value></field> <p/> <p>Cic.<i>
Div. Caec.</i> 66; <i>Mur</i>. 59;
<i>D</i><i>e
</i><i>o</i><i>rat</i>. 1.40, 227-28;
2.263; <i>Brut</i>. 80, 89; <i>Att</i>. 12.5b;
Liv. 39.40.12; <i>Per</i>. 49;
<i>Per</i>. <i>Oxy</i>. 49;
Quint. <i>Inst</i>. 2.15.8;
Plut. <i>Cat</i>. <i>Mai</i>. 15.5;
Tac. <i>Ann</i>. 3.66; App. <i>Hisp</i>. 60;
Fro. <i>Aur</i>. 1. p. 172 (56N); Gell. 1.12.17, 13.25.15;
see also Val. Max. 8.1. abs. 2; Ps. Asc. p. 203;
<i>Vir</i>. <i>Ill</i>. 47.7. [3]</p>
<p/> <p>[1] On the date see
Cic. <i>Att</i>. 12.5b.</p> <p>[2] See Brennan
(2000) 175. </p> <p>[3] Val. Max. wrongly portrays the
trial as a iudicium populi: see Briscoe (2019) 69.</p>
<p/> <p/> <trial-number>2</trial-number> ...

Several things are worth noting about this output:

The next step is devoted to addressing these issues. A further peculiarity visible in the data may be noted but will not be addressed yet:

5.3.1. Goals of step 2

The second step in this stage has the primary task of detecting cases where a given field takes up more than one paragraph in the RXML form. Since fields are recognized only by having a label at the beginning, any paragraphs beyond the first will have been left unchanged by the preceding step. Sometimes this is due to the value containing a list of names, as illustrated by the prosecutors field of trial #1; sometimes it’s the result of an erroneous hard return in a field value, as in the following example from trial #8:

                        
<field><label>charge</label><value><i>lex
</i>(<i>Calpurnia</i>?)  <i>de
repetundis</i> (misconduct as consul
and</value></field> <p>proconsul in Hither Spain)
[2]</p> 

At the same time, the grammar recognizes the notes and the lists of ancient and modern sources appearing at the end of each trial, and groups and tags the back matter in the input.

5.3.2. Organization of the input, organization of individual trials

The key drivers here are the definition of the top level of the document and the definition of trial. The top level defines the body of the document as consisting of a work title followed by a series of trials, followed by a list of abbreviations and a bibliography, with sections optionally separated by blank lines.

                        
TLRR-generic-fields-1 = s,
(xml-declaration, s)?, -"<TLRR-generic-fields-0", -~["<>"]*,
-">", s, inject-NL,

     work-title, s, (blank-lines ++ s, s)?, inject-NLNL,

     ((trial, inject-NLNL) ++ s), s, inject-NLNL,

     abbreviations, s, (blank-lines ++ s, s)?, inject-NLNL,

     bibliography, s, inject-NL, -"</TLRR-generic-fields-0>", s.

Since the abbreviations and bibliography begin with distinctive titles, they are not recognized solely by position. But some material within a trial is recognized by position. Neither the sources of a trial nor the notes have distinctive markup (although notes do begin with note numbers, which proves important); the rule for a trial recognizes them, essentially, by their position. The input consistently (at least so far!) separates the sources from the preceding labeled fields with one or more blank lines (represented at this point by empty p elements).

                        
trial = -"<trial-number>",
@trial-num, -"</trial-number>", inject-NL, s, (p, s)?, (field,
inject-NL) ++ s, s, blank-lines, s, sources, inject-NL, s,
(blank-lines, s, (notes, inject-NL, s, (blank-lines, s)?)?)?  .

5.3.3. Three forms of field

In the input to this step, individual fields can take any of three forms. Most common is a field element and nothing more, as illustrated by the first right-hand side of the field rule below. The second form has a list-structured value, where the first paragraph has only the label (and optionally a note references), and the actual value is recorded in a series of indented paragraphs immediately following. In the third form, the value spills to one (or possibly more) following p elements.

                        
field = -"<field>", label,
note-ref?, value, -"</field>" | -"<field>", label,
note-ref?, -"</field>", s, list-value | -"<field>", label,
note-ref?, extended-value .  

A note on the first line of the rule above: Defining the nonterminal field as a string beginning with an XML start-tag for a field element and ending with an end-tag for that element is the iXML equivalent of an identity transformation on the field element. (Unlike XSLT, iXML does not have the equivalent of a generic identity template, or a default mode="shallow-copy" treatment: every element to be treated must be given a rule. That means there are tradeoffs to consider in deciding whether to process XML data with iXML or with XSLT or XQuery. In the workflow described here, the markup is simple enough that providing identity rules is not a big burden. But as the markup becomes richer, the burden of providing the identity rules increases.)

The rules for label, note-ref, and value are also identity rules.

                        
label = -"<label>", phrases,
-"</label>".  note-ref = -"<note-ref>", phrases,
-"</note-ref>".  value = -"<value>", phrases,
-"</value>".  

For list-valued fields, we would like to wrap the value in a value element, as usual, and then within that wrap the list items in a list element. That leads to the following slightly indirect-looking set of rules. (Some inject-NL references have been deleted here to make the rules a little easier to read.) Any indented paragraph we see is a list item. The exact value of the indentation does not matter, because the input has no nested lists.

                        
list-value > value = value-list.
value-list > list = item++s.  item = -"<p indent=",
-~["<>"]*, -">", phrases, -"</p>".  

An ‘extended’ value, on the other hand, spills not to indented paragraphs but to unindented paragraphs, as shown in the following rule.

                        
extended-value > value =
-"<value>", phrases, -"</value></field>", s,
(-"<p>", +" ", phrases, -"</p>") ++ s.  

Because the rule for trial specifies that the main body of a trial consists of a sequence of fields separated only by whitespace, every p element following a field element in the input will be absorbed into that field. (To do this in XSLT, it is necessary to perform what is sometimes called a right-sibling traversal, which many XSLT programmers report finding difficult to get right — or use grouping constructs, which are somewhat easier to get right.) An attempt was made to make the grammar of the preceding step detect such multi-paragraph fields and handle them correctly, but the attempt failed, because the higher-level nonterminal had defined the document as a sequence of fields and paragraphs, so every multi-paragraph field could be read as a single field or as a field followed by paragraphs. Both were allowed, so the grammar became ambiguous, and no way was found to force one reading over the other. (It is, probably, not impossible. But no solution was found in the time available.)

5.3.4. Phrase-level information and well-formed XML

It may be worth spending a moment on the phrases nonterminal and on the handling of phrase-level content within fields and notes.

The nonterminal phrases matches zero or more occurrences of:

                        
-phrases = phrase*.  -phrase =
~["<>"] | note-reference | i | b | cruft.

note-reference > note-ref = "[", [N], "]".  i = -"<i>",
phrases, -"</i>".  b = -"<b>", phrases, -"</b>".

-cruft = -"<i/>"; -"<b/>".

The grammar also includes rules for structuring the abbreviations and bibliography; they are present in the attached grammar but will not be discussed here.

5.3.5. The data after step 2

The beginning of the data now shows the restructuring of the information. (Reformatted for legibility.)

                        
<TLRR-generic-fields-1
xmlns:ixml="http://invisiblexml.org/NS" ixml:state="ambiguous
version-mismatch"> <title>TLRR (2)</title>

  <trial n="1"> <field><label>date</label>
<value>149
<note-ref>[1]</note-ref></value></field>
<field><label>charge</label>
<value><i>quaestio extraordinaria</i> (proposed)
<note-ref>[2]</note-ref> (misconduct as gov.  Lusitania
150)</value> </field>
<field><label>defendant</label>
<value>Ser. Sulpicius Galba (58) cos. 144 spoke <i>pro
se</i> (<i>ORF</i> 19.II, III)</value>
</field> <field><label>advocate</label>
<value>Q. Fulvius Nobilior (95) cos. 153,
cens. 136</value> </field>
<field><label>prosecutors</label>
<value><list> <item>L. Cornelius Cethegus
(91)</item> <item>M. Porcius Cato (9) cos. 195, cens. 184
(<i>ORF</i> 8.LI)</item> <item>L. Scribonius
Libo (18) tr. pl. 149 (<i>promulgator</i>)</item>
</list></value></field>
<field><label>outcome</label> <value>proposal
defeated</value> </field> <sources>
<ancient>Cic.<i> Div. Caec.</i> 66;
<i>Mur</i>. 59; <i>D</i><i>e
</i><i>o</i><i>rat</i>. 1.40, 227-28;
2.263; <i>Brut</i>. 80, 89; <i>Att</i>. 12.5b;
Liv. 39.40.12; <i>Per</i>. 49;
<i>Per</i>. <i>Oxy</i>. 49;
Quint. <i>Inst</i>. 2.15.8;
Plut. <i>Cat</i>. <i>Mai</i>. 15.5;
Tac. <i>Ann</i>. 3.66; App. <i>Hisp</i>. 60;
Fro. <i>Aur</i>. 1. p. 172 (56N); Gell. 1.12.17, 13.25.15;
see also Val. Max. 8.1. abs. 2; Ps. Asc. p. 203;
<i>Vir</i>.
<i>Ill</i>. 47.7. <note-ref>[3]</note-ref>
</ancient> </sources>
    
    <notes> <note>[1] On the date see
Cic. <i>Att</i>. 12.5b.</note> <note>[2] See
Brennan (2000) 175. </note> <note>[3] Val. Max. wrongly
portrays the trial as a iudicium populi: see Briscoe (2019)
69.</note> </notes> </trial> ...  

5.4.1. Goal of step 3

At this point, the field structure of the input has been cleanly recognized. For further work, it will be more convenient if each type of field has a distinctive element type, rather than being tagged generically as a field with a label and value. So the sole purpose of this step is to retag the fields, using the value of the label as a guide.

For some fields, this is a simple matter of using the value of the label as the generic identifier for the element. So the date field of trial #1 (reformatted here to shorten lines)

<field> <label>date</label>
<value>149 <note-ref>[1]</note-ref></value>
</field> 

will be retagged more informatively and compactly as

<date>149 <note-ref>[1]</note-ref></date>

For other fields, the retagging is more complex. A survey of the first-edition data shows that the field which records the presiding magistrate in a trial, which will be tagged as a judge element, may in the displayed text be labeled in any of several different ways, often simply recording the Latin term used in the historical sources, and sometimes recording some uncertainty:

The variations in the label are, needless to say, important to preserve, even as all variations on the theme of “presiding magistrate𣀝 are merged into a single element type in order to support searches to find out whether a particular named individual is ever recorded as having presided over a trial.

So the field tagged generically as:

<field> <label>praetor</label>
<value>M. Popillius Laenas (22) (pr. by 142) cos. 139?
<note-ref>[1]</note-ref> </value> </field>

will be retagged as:

<judge label="praetor"> M. Popillius Laenas (22) (pr. by 142)
cos. 139? <note-ref>[1]</note-ref> </judge>

5.4.2. Recognizing fields

In this grammar, again the input is recognized as a series of trials, and each trial as a sequence of fields. The main work occurs in the rule describing fields, which classifies them by type.

                        
-field = date; charge; claim;
charge-or-claim; defendant; prosecutor; plaintiff; party; advocate;
judge; juror; witness; other; outcome .  

For each type, there is a simple rule: it’s a field element with an appropriate label and other content.

                        
 date =
-"<field><label>date</label>", note-ref?, value,
-"</field>".  charge =
-"<field><label>charge</label>", note-ref?, value,
-"</field>".  claim =
-"<field><label>claim</label>", note-ref?, value,
-"</field>".  charge-or-claim =
-"<field><label>charge? claim?</label>", note-ref?,
value, -"</field>".  defendant = -"<field>",
label-defendant, note-ref?, value, -"</field>".  prosecutor =
-"<field>", label-prosecutor, note-ref?, value,
-"</field>".  plaintiff =
-"<field><label>plaintiff</label>", note-ref?,
value, -"</field>".  party = -"<field>", label-party,
note-ref?, value, -"</field>".  advocate = -"<field>",
label-advocate, note-ref?, value, -"</field>".  judge =
-"<field>", label-judge, note-ref?, value, -"</field>".
juror = -"<field><label>juror</label>", note-ref?,
value, -"</field>".  witness = -"<field>", label-witness,
note-ref?, value, -"</field>".  other = -"<field>",
label-other, note-ref?, value, -"</field>".  outcome =
-"<field><label>outcome</label>", note-ref?, value,
-"</field>".  

As may be seen for some fields such as date, there is only one form of label, and it’s given as a literal. For others such as judge, the description of matching labels is packaged in a separate nonterminal such as label-judge, which we give here as a typical example:

                        
 -label-judge =
-"<label>judge</label>"; judge-label.  @judge-label >
label = -"<label>", ("praetor"; "peregrine praetor"; "peregrine?
praetor"; "urban praetor"; "(urban?) praetor"; "urban and peregrine
praetor"; "judge (triumvir capitalis)"; "praetor or iudex questionis";
"aedile or iudex questionis"; "iudex quaestionis"; "duumvir
perduellionis"; -"<i>", "quaesitor", ("es")?, -"</i>";
-"<i>", "iudices", -"</i>" ), -"</label>".

The effect of these grammar rules may be worth describing step by step in a procedural way. At any point where the grammar is expecting a field of any kind, the parser looks to see if the input matches the rule for field, which in turn translates to looking to see if the input matches the rule for date or charge or any of the other nonterminals on the right-hand side of the rule for field, including judge. If the input does match the rule for field, it will not be tagged as a field element in the output because the left-hand side of the rule is marked with a minus sign, meaning that the nonterminal field is to be hidden. Its children may be tagged, but not the nonterminal as a whole.

Matching the rule for judge requires a field element with contents matching the sequence of nonterminals label-judge, optionally note-ref, and value. If the input matches here, it will appear in the output as a judge element. Operationally speaking, we have thus used the iXML grammar to replace a field element with a corresponding judge element.

If the label child of the field we are processing has the form “<label>praetor</label>”, then it will match the nonterminal label-judge, which is hidden, and also the nonterminal judge-label which is (a) marked with “@”, which means it will be serialized as an attribute, and also annotated with “> label”, which means that the attribute will be serialized with the attribute name “label”, not “label-judge”. The literal strings which match the tags for the label element in the input are marked with a minus sign to be hidden, so they will not be copied to the output. Only the content of the label element will be copied, as the value of the label attribute in the output.

If the input had matched the string “<label>judge</label>” instead, there would be no label attribute. So operationally we have used iXML to copy the string used as a label into a label attribute on the judge element, but not if the label used was the string “judge”.

A comparison with the XSLT code that performed this work on the first edition about ten years ago shows that the iXML form is somewhat more compact. (However, as the expression "quaesitor", "es"? shows, for individual regular expressions, the notation used in XSLT and XQuery is somewhat more compact than that of iXML.)

5.4.3. Handling well-formed XML (revisited)

Fields recognized by the grammar rules shown above get retagged as described. Everything else in the input, meanwhile, should be left unchanged. The discussion of step 2 (above) included a description of how the grammar matched well-formed XML in the phrases nonterminal. That part of the grammar was simple, because every phrase-level fragment was either a character, an i element, or a b element, so only a few rules were needed.

In the grammar for this step, however, the input has significantly richer markup (and we are working on larger structures, not just on phrase-level material). So the relevant part of the grammar containing the iXML equivalent of an identity transform is somewhat longer, as shown below.

                        
 -wf-xml = wf-xml-bit*.  -wf-xml-bit
= ~["<>"] | abbr | ancient | author | author-group | b | bibl |
i | item | list | modern | note | note-ref | notes | p |
primary-sources | secondary-sources | sources | title | work .

         abbr = -"<abbr>", wf-xml, -"</abbr>".
abbreviations = -"<abbreviations>", wf-xml,
-"</abbreviations>".  ancient = -"<ancient>", wf-xml,
-"</ancient>".  author = -"<author>", wf-xml,
-"</author>".  author-group = -"<author-group>", wf-xml,
-"</author-group>".  b = -"<b>", wf-xml, -"</b>".
bibl = -"<bibl>", wf-xml, -"</bibl>".  bibliography =
-'<bibliography>', wf-xml, -"</bibliography>".  i =
-"<i>", wf-xml, -"</i>".  item = -"<item>", wf-xml,
-"</item>".  list = -"<list>", wf-xml, -"</list>".
modern = -"<modern>", wf-xml, -"</modern>".  note =
-"<note>", wf-xml, -"</note>".  note-ref =
-"<note-ref>", wf-xml, -"</note-ref>".  notes =
-"<notes>", wf-xml, -"</notes>".  p = -"<p>",
wf-xml, -"</p>".  primary-sources = -"<primary-sources>",
wf-xml, -"</primary-sources>".  secondary-sources =
-"<secondary-sources>", wf-xml, -"</secondary-sources>".
sources = -"<sources>", wf-xml, -"</sources>".  title =
-"<title>", wf-xml, -"</title>".  work = -"<work>",
wf-xml, -"</work>".  

At about this point, the absence of anything in iXML comparable to a default identity template in XSLT may begin to feel like a painful gap. The next section explores a potential work-around.

5.4.4. An alternative approach to handling well-formed XML

The rules given in the preceding section for the identity-transform behavior desired for much of the input are not very complicated, but very repetitive, and if any of the elements involved carried attributes, it would be even more tedious and probably a bit error-prone.

A generic form of the identity-transform part of the grammar would perhaps make things simpler. A simple version of the required rules was shown in Hillman et al. 2022. In the grammar fragment below, all nonterminals are written in all-caps and prefixed with two underscores, to reduce the likelihood of collision with other names in the surrounding iXML grammar and for reasons which will shortly become clear.

                        
  -wf-xml = __PCDATA?,
            ((__PI ; __COMMENT ; __ELEMENT)++(__PCDATA?),
            __PCDATA?)?.
   __PCDATA = (~["<>&"]; "&amp;"; "&lt;"; "&gt;"; "&apos;"; "&quot;")+.
       __PI = "<?", @__NAME, S, @__PI-DATA, "?>".
  __COMMENT = "<--", __COMMENT-DATA, "-->".
  __ELEMENT = __STARTTAG, wf-xml, __ENDTAG; __SOLETAG .
-__STARTTAG = -"<", @__GI, (S, __ATTRIBUTE)*, s, -">".
  -__ENDTAG = -"</", @__GI2, s, -">".
 -__SOLETAG = -"<", @__GI, (S, __ATTRIBUTE)*, s, -"/>".

__ATTRIBUTE = @__NAME, s, -"=", s, @__ATT-VALUE.
     __NAME = [L; "_"], [L; "_-."; Nd]*.
       __GI = __NAME.
      __GI2 = __NAME.

@__ATT-VALUE > VALUE = ['"'], ~['"']*, ['"']
                     | ["'"], ~["'"]*, ["'"].
-__COMMENT-DATA = ~["-"]*.
-__PI-DATA = ~["?"]*.

A few lines of trial #1 will give an idea of the flavor of the result of parsing the data using this grammar. As usual, linebreaks have been introduced to make the lines shorter.

<trial n="1">
<date><__PCDATA>149 </__PCDATA
  ><__ELEMENT __GI="note-ref" __GI2="note-ref"
  ><__PCDATA>[1]</__PCDATA></__ELEMENT></date>
<charge><__ELEMENT __GI="i" __GI2="i"
  ><__PCDATA>quaestio extraordinaria</__PCDATA
  ></__ELEMENT><__PCDATA> (proposed) </__PCDATA
  ><__ELEMENT __GI="note-ref" __GI2="note-ref"
  ><__PCDATA>[2]</__PCDATA></__ELEMENT><__PCDATA
  > (misconduct as gov. Lusitania 150)</__PCDATA></charge>
<defendant><__PCDATA
  >Ser. Sulpicius Galba (58) cos. 144 spoke </__PCDATA
  ><__ELEMENT __GI="i" __GI2="i"
  ><__PCDATA>pro se</__PCDATA></__ELEMENT><__PCDATA
  > (</__PCDATA><__ELEMENT __GI="i" __GI2="i"
  ><__PCDATA>ORF</__PCDATA></__ELEMENT
  ><__PCDATA> 19.II, III)</__PCDATA></defendant>
<advocate><__PCDATA
  >Q. Fulvius Nobilior (95) cos. 153, cens. 136</__PCDATA
  ></advocate>
<prosecutor label="prosecutors"
  ><__ELEMENT __GI="list" __GI2="list"><__PCDATA>
</__PCDATA
  ><__ELEMENT __GI="item" __GI2="item"><__PCDATA
  >L. Cornelius Cethegus (91)</__PCDATA></__ELEMENT
  ><__PCDATA>
</__PCDATA
  ><__ELEMENT __GI="item" __GI2="item"><__PCDATA
  >M. Porcius Cato (9) cos. 195, cens. 184 (</__PCDATA
  ><__ELEMENT __GI="i" __GI2="i"><__PCDATA>ORF</__PCDATA
  ></__ELEMENT><__PCDATA> 8.LI)</__PCDATA></__ELEMENT><__PCDATA>
</__PCDATA
  ><__ELEMENT __GI="item" __GI2="item"><__PCDATA
  >L. Scribonius Libo (18) tr. pl. 149 (</__PCDATA
  ><__ELEMENT __GI="i" __GI2="i"><__PCDATA
  >promulgator</__PCDATA></__ELEMENT><__PCDATA
  >)</__PCDATA></__ELEMENT><__PCDATA>
</__PCDATA></__ELEMENT></prosecutor>
<outcome><__PCDATA>proposal defeated</__PCDATA></outcome>

This format is, of course, not particularly easy to read or convenient for further processing, but it does preserve all the information in the material parsed as wf-xml. And it does allow an arbitrary number of XML element types to be passed through without change using a small number of rules in the iXML grammar, and without requiring one rule per element type.

One hitch is that iXML cannot easily be used to transform this format back into normal XML, because the names of elements and attributes must be assigned in the grammar, not taken from the input data. This is another extension to iXML which might make life easier in some cases.

Fortunately, a simple XSLT transformation with templates for elements ELEMENT, ATTRIBUTE, PCDATA, and so on can easily translate from this format back into conventional XML. Here are the templates for the three elements mentioned.

                        
<xsl:template match="__ELEMENT">
  <xsl:element name="{@__GI}">
    <xsl:apply-templates/>
  </xsl:element>    
</xsl:template>

<xsl:template match="__ATTRIBUTE">
  <xsl:attribute name="{@__NAME}"
                 select="@__VALUE"/>
</xsl:template>

<xsl:template match="__PCDATA">
  <xsl:sequence select="string()"/>
</xsl:template>

Since the material being processed has no XML comments or processing instructions, these suffice.

5.4.5. Would this step be simpler in XSLT?

Some readers may be thinking at this point that performing this step with an iXML grammar may be pushing things a bit far. Would it not be just as simple, or perhaps simpler, to do it in XSLT? After all, XSLT’s system of templates and priorities is very well suited to near-identity transforms.

The answer, unsurprisingly, is that yes, XSLT can indeed be used for this step. The key template is shown below.

                        
<xsl:template match="field">
  <xsl:variable name="label" as="xs:string" select="label"/>
  <xsl:variable name="gi">
    <xsl:choose>
      <xsl:when test="$label = ('date', 'charge', 'claim',
                      'plaintiff', 'juror', 'outcome')">
        <xsl:sequence select="$label"/>
      </xsl:when>
      <xsl:when test="$label = ('defendant',
                      'defendants',
                      'defendants?')">
        <xsl:sequence select=" 'defendant' "/>
      </xsl:when>
      <xsl:when test='$label = ("prosecutor",
                      "prosecutors")'>
        <xsl:sequence select=' "prosecutor" '/>
      </xsl:when>
      <xsl:when test='$label = ("party",
                      "opposing party",
                      "parties")'>
        <xsl:sequence select=' "party" '/>
      </xsl:when>
      <xsl:when test='$label = ("judge",
                      "praetor",
                      "peregrine praetor",
                      "peregrine? praetor",
                      "urban praetor",
                      "(urban?) praetor",
                      "urban and peregrine praetor",
                      "judge (triumvir capitalis)",
                      "praetor or iudex quaestionis",
                      "aedile or iudex quaestionis",
                      "iudex quaestionis",
                      "duumvir perduellionis",
                      "quaesitor",
                      "quaesitores",
                      "iudices"
                      )'>
        <xsl:sequence select=' "judge" '/>          
      </xsl:when>
      <xsl:when test='$label = (
                      "advocate",
                      "advocates",
                      "advocate for defendant",
                      "advocates for defendant",
                      "advocate for defendants",
                      "advocates for defendants",
                      "advocate for plaintiff",
                      "advocates for plaintiff",
                      "advocate for plaintiffs",
                      "advocates for plaintiffs"
                      )'>
        <xsl:sequence select=' "advocate" '/>
      </xsl:when>
      <xsl:when test='$label = (
                      "witness",
                      "witnesses",
                      "cognitor",
                      "procurator"
                      )'>
        <xsl:sequence select=' "witness" '/>
      </xsl:when>
      <xsl:when test='$label = (
                      "other",
                      "legate",
                      "legates",
                      "in attendance",
                      "present for defense",
                      "present for defendants"
                      )'>
        <xsl:sequence select=' "other" '/>
      </xsl:when>

    </xsl:choose>
  </xsl:variable>

  <xsl:element name="{$gi}">
    <xsl:if test="$label ne $gi">
      <xsl:attribute name="label" select="$label"/>
    </xsl:if>
    <xsl:apply-templates select="child::node() except label"/>
  </xsl:element>
</xsl:template>

Because the XSLT stylesheet can pass over in silence all elements and attributes to be left unchanged, the XSLT stylesheet is about ten per cent more compact than either of the two iXML grammars for this step: 150 vs 167 or 168 lines (including blank lines and comments). It is also much simpler than the corresponding XSLT step in the workflow for the first edition created ten years ago, probably because the task of assigning the correct element names to fields has been separated from the task of recognizing field boundaries.)

5.4.6. The data in FXML form

The form of the data in ‘fielded XML’ is shown below. All three versions of the previous step produce the same output, except for some variation in the namespace declarations and iXML attributes on the document element.

<TLRR-fielded xmlns:ixml="http://invisiblexml.org/NS" ixml:state="version-mismatch">
<title>TLRR (2)</title>

<trial n="1">
<date>149 <note-ref>[1]</note-ref></date>
<charge><i>quaestio extraordinaria</i
  > (proposed) <note-ref>[2]</note-ref
  > (misconduct as gov. Lusitania 150)</charge>
<defendant>Ser. Sulpicius Galba (58) cos. 144
  spoke <i>pro se</i> (<i>ORF</i> 19.II, III)</defendant>
<advocate>Q. Fulvius Nobilior (95)
  cos. 153, cens. 136</advocate>
<prosecutor label="prosecutors"><list>
  <item>L. Cornelius Cethegus (91)</item>
  <item>M. Porcius Cato (9) cos. 195, cens. 184 (<i>ORF</i> 8.LI)</item>
  <item>L. Scribonius Libo (18) tr. pl. 149 (<i>promulgator</i>)</item>
</list></prosecutor>
<outcome>proposal defeated</outcome>
<sources>
<ancient>Cic.<i> Div. Caec.</i> 66; <i>Mur</i>. 59;
  <i>D</i><i>e </i><i>o</i><i>rat</i>. 1.40, 227-28; 2.263;
  <i>Brut</i>. 80, 89; <i>Att</i>. 12.5b; Liv. 39.40.12;
  <i>Per</i>. 49; <i>Per</i>. <i>Oxy</i>. 49;
  Quint. <i>Inst</i>. 2.15.8;
  Plut. <i>Cat</i>. <i>Mai</i>. 15.5; Tac. <i>Ann</i>. 3.66;
  App. <i>Hisp</i>. 60; Fro. <i>Aur</i>. 1. p. 172 (56N);
  Gell. 1.12.17, 13.25.15; see also Val. Max. 8.1.
  abs. 2; Ps. Asc. p. 203; <i>Vir</i>.
  <i>Ill</i>. 47.7. <note-ref>[3]</note-ref></ancient></sources>
<notes>
<note>[1] On the date see Cic. <i>Att</i>. 12.5b.</note>
<note>[2] See Brennan (2000) 175. </note>
<note>[3] Val. Max. wrongly portrays the trial
  as a iudicium populi: see Briscoe (2019) 69.</note>
</notes>
</trial>
...