The sxt:rule element contains one rule for the transducer.

It can carry three attributes: match resembles the match of XSLT: it indicates which nodes are matched by the rule. The match pattern must be a QName or one of the standard node tests text(), comment(), or processing-instruction(). mode resembles the mode of XSLT, but the emulator requires that the name begin with one of the characters d, D, u, or U. Mode names beginning with d or D are names of down modes; names beginning with u or U name up modes. All modes are down modes or up modes. pos indicates a constraint on the position of the node matched. It can take any of four values: leaf indicates that the node matches only leaf nodes (nodes with no children) not-leaf indicates that the node matches only non-leaf nodes (nodes with at least one child) last indicates that the node matches only final nodes (nodes with no right sibling) not-last indicates that the node matches only non-last nodes (nodes with a right sibling)

An sxt:rule element contains either a sequence of result tree fragments, with exactly one SXT movement instruction (see below), or else zero or more sxt:close elements followed by one SXT movement instruction. (In principle, the SXT movement instruction should be the rightmost leaf node in the rule, but this is not currently enforced. However, any nodes located to the right of the movement instruction will be ignored.)

Result tree fragments are specified literally as elements, text nodes, comments, and processing instructions. In the current version (v1) of the emulator, attributes are not supported.

For example, the following rule fires for non-leaf h1 elements in down mode:

It means, roughly: add a div element to the current location in the output tree, and within that div add a head element. Then move to the first child of the input h1 element, in mode down-2.

An example of a ‘closing rule’ is the following, which fires on h1 elements in mode up, when the h1 is the last child of its parent:

This rule moves the write-head up two levels, closing first the head element and then the div element, and then traversing to the parent of the h1 element, in mode up.

The closing rule illustrates two of the ways in which the emulator goes beyond SXT automata as defined by Jana Dvořáková: first the emulator allows more than one sxt:close instruction in a rule, thus moving up more than one level in the output; pure SXT closing rules move up just one level. Moving multiple levels is possible but requires additional states. Second, the sxt:close element accepts an optional name attribute to specify what element the transformation author expects to be closing and the emulator signals an error if the name doesn't match; the pure SXT automaton does not cater to human frailty in this way.

The SXT movement instructions signal that at that point in the rule, the SXT automaton should move to the node indicated. They are roughly equivalent to xsl:apply-templates with specific select values. Each can also carry a mode attribute, which has essentially the same meaning and behavior as in XSLT.

The allowed movements are subject to constraints which ensure that every node is visited in the prescribed order. Every rule must satisfy one of the following descriptions: In a down-mode rule matching a non-leaf node, the movement instruction is sxt:self in an up mode. In a down-mode rule matching a leaf node, the movement instruction is sxt:down in a down mode. In an up-mode rule matching a non-last node, the movement instruction is sxt:right in a down mode. In an up-mode rule matching a last node, the movement instruction is sxt:up in an up mode. In a down-mode rule, the movement instruction is sxt:self in a down mode. In an up-mode rule, the movement instruction is sxt:self in an up mode.

The sxt:close element signals that at that point in a rule, the write head should be moved up one level in the output tree. (Unreconstructed imperative programmers may prefer to think of this in imperative terms as meaning “Emit a close tag for the element on the top of the output stack, and pop that stack.”)

The sxt:close element may optionally carry a name attribute, which records the generic identifier of the element the programmer expects to be closing with the close instruction. The emulator will signal an error if the name doesn't match the name on the top of the output stack.

The sxt:copy element makes sense only in a rule matching a text node, comment node, or processing instruction; it signals that the node should be copied to the output.

The copy instruction does not correspond to any primitive operations in SXT automata as defined; it was added to make it possible to write more interesting transformations as exercises.

The sxt:stop element indicates that the automaton should stop.

Like sxt:copy, this instruction does not correspond to anything in the formal definition of SXT automata. It may in fact be completely unnecessary; the paper defining SXT is a bit vague about halting conditions (or at least I have failed to understand cleary what the exact halting conditions are). The justification is wholly pragmatic: the first versions of the emulator had a little trouble knowing when to stop, which went away when this explicit stop instruction was added.