nsIXULTemplateBuilder in Firefox 3.0

 A template builder, given an input source of data, a template, and a
 reference point, generates a list of results from the input, and copies
 part of the template for each result. Templates may generate content
 recursively, using the same template, but with the previous iteration's
 results as the reference point. As an example, for an XML datasource the
 initial reference point would be a specific node in the DOM tree and a
 template might generate a list of all child nodes. For the next iteration,
 those children would be used to generate output for their child nodes and
 so forth.

 A template builder is attached to a single DOM node; this node is called
 the root node and is expected to contain a XUL template element as a direct
 child. Different template builders may be specialized in the manner in
 which they generate and display the resulting content from the template.

 The structure of a template is as follows:

 <rootnode datasources="" ref="">
   <template>
     <queryset>
       <query>
       </query>
       <rule>
         <conditions>...</conditions>
         <bindings>...</bindings>
         <action>...</action>
       </rule>
     </queryset>
   </template>
 </rootnode>

 The datasources attribute on the root node is used to identify the source
 of data to be used. The ref attribute is used to specify the reference
 point for the query. Currently, the datasource will either be an
 nsIRDFDataSource or a DOM node. In the future, other datasource types may
 be used.

 The <queryset> element contains a single query and one or more <rule>
 elements. There may be more than one <queryset> if multiple queries are
 desired, and this element is optional if only one query is needed -- in
 that case the <query> and <rule>s are allowed to be children of the
 <template> node

 The contents of the query are processed by a separate component called a
 query processor. This query processor is expected to use this query to
 generate results when asked by the template builder. The template builder
 then generates output for each result based on the <rule> elements.

 This allows the query processor to be specific to a particular kind of
 input data or query syntax, while the template builder remains independent
 of the kind of data being used. Due to this, the query processor will be
 supplied with the datasource and query which the template builder handles
 in an opaque way, while the query processor handles these more
 specifically.

 Results implement the nsIXULTemplateResult interface and may be identified
 by an id which must be unique within a given set of query results.

 Each query may be accompanied by one or more <rule> elements. These rules
 are evaluated by the template builder for each result produced by the
 query. A rule consists of conditions that cause a rule to be either
 accepted or rejected. The condition syntax allows for common conditional
 handling; additional filtering may be applied by adding a custom filter
 to a rule with the builder's addRuleFilter method.

 If a result passes a rule's conditions, this is considered a match, and the
 content within the rule's <action> body is inserted as a sibling of the
 <template>, assuming the template builder creates real DOM content. Only
 one rule will match a result. For a tree builder, for example, the content
 within the action body is used to create the tree rows instead. A matching
 result must have its ruleMatched method called. When a result no longer
 matches, the result's hasBeenRemoved method must be called.

 Optionally, the rule may have a <bindings> section which may be used to
 define additional variables to be used within an action body. Each of these
 declared bindings must be supplied to the query processor via its
 addBinding method. The bindings are evaluated after a rule has matched.

 Templates may generate content recursively, using the previous iteration's
 results as reference point to invoke the same queries. Since the reference
 point is different, different output will typically be generated.

 The reference point nsIXULTemplateResult object for the first iteration is
 determined by calling the query processor's translateRef method using the
 value of the root node's ref attribute. This object may be retrieved later
 via the builder's rootResult property.

 For convenience, each reference point as well as all results implement the
 nsIXULTemplateResult interface, allowing the result objects from each
 iteration to be used directly as the reference points for the next
 iteration.

 When using multiple queries, each may generate results with the same id.
 More than one of these results may match one of the rules in their
 respective queries, however only the result for the earliest matching query
 in the template becomes the active match and generates output. The
 addResult, removeResult, replaceResult and resultBindingChanged methods may
 be called by the query processor to indicate that the set of valid results
 has changed, such that a different query may match. If a different match
 would become active, the content for the existing match is removed and the
 content for the new match is generated. A query processor is not required
 to provide any support for updating results after they have been generated.

 See http://wiki.mozilla.org/XUL:Templates_Plan for details about templates.