tame/tamer/tests/xmli/template/src.xml

<?xml version="1.0"?>
<package xmlns="http://www.lovullo.com/rater"
         xmlns:c="http://www.lovullo.com/calc"
         xmlns:t="http://www.lovullo.com/rater/apply-template">

  <template name="_empty_" />

  <template name="_with-static-reachable_">
    All expressions here are reachable
      (having been derived from named statements).

    <rate yields="tplStaticA">
      <c:sum />
    </rate>
    <classify as="tpl-static-b">
      <any />
    </classify>
  </template>

  <template name="_with-static-unreachable_">
    This expression is on its own unreachable,
      intended to be expanded into another expression.

    <c:sum>
      <c:product />
    </c:sum>

    <c:product>
      <c:sum />
    </c:product>
  </template>

  <template name="_with-static-mix-reachability_">
    Both reachable and unreachable,
      with the intent of expanding into an expression but also providing
      itself with supporting expressions.

    <c:sum>
      <c:product />
    </c:sum>

    <c:product> <!-- depth N -->
      <c:sum /> <!-- depth N+1 -->
    </c:product>

    The above expression will end at depth N+1,
      to be auto-closed.
    The below expression will yield an Ident->Expr,
      and so will _begin_ at N+1.
    We must therefore ensure,
      and this test do so assert,
      that this matching depth does not cause the reparenting of this next
        expression into its preceding sibling.

    <rate yields="tplStaticMix" /> <!-- begins at depth N+1 -->

    <c:sum>
      <c:product />
    </c:sum>
  </template>

  Short-hand template application.
  These get expanding into the long form so that we don't have to translate
    back and forth between the underscore-padded strings.
  The fixpoint test will further verify that TAMER also recognizes the long
    `apply-template` form,
      asserting their equivalency.

  <template name="_short-hand-nullary_" />
  <t:short-hand-nullary />

  <template name="_short-hand-unary_" />
  <t:short-hand-unary foo="bar" />



  <template name="_short-hand-nary_" />
  <t:short-hand-nary foo="bar" bar="baz" baz="quux" />





  Shorthand template bodies desugar into the param `@values@`.
  Unlike in the XSLT-based TAMER,
    metavaraibles (template parameters) are purely lexical,
    and do not contain trees,
    simplifying its implementation.
  Desugaring instead takes advantage of existing features by generating a
    _new_ closed template with the body from the shorthand application.
  Since closed templates can be applied by referencing them as a value,
    which expands them in place,
    this ends up having the same effect as a `param-copy`.

  For now,
    the expected output asserts on this behavior,
    but if this has a significantly negative impact on performance of the
      XSLT-based compiler,
        then it'll have to inline during desugaring.

  This asserts verbatim on the output,
    which uses a generated id based on the span.
  This is fragile,
    and it may break often;
      just take the hex span from the test failure in that case.

  <template name="_short-hand-nullary-body_" />
  <t:short-hand-nullary-body>
    <c:product>
      <c:sum />
    </c:product>
  </t:short-hand-nullary-body>




  <template name="_short-hand-nary-body_" />
  <t:short-hand-nary-body bar="baz" baz="quux">
    <c:sum>
      <c:product />
    </c:sum>
  </t:short-hand-nary-body>






  <template name="_short-hand-nullary-outer_" />
  <t:short-hand-nullary-outer>
    <template name="_short-hand-nullary-inner-dfn-inner_" />
    <t:short-hand-nullary-inner-dfn-inner />
  </t:short-hand-nullary-outer>



  <template name="_short-hand-nullary-inner-dfn-outer_" />
  <t:short-hand-nullary-outer>
    <t:short-hand-nullary-inner-dfn-outer />
  </t:short-hand-nullary-outer>





  <template name="_short-hand-unary-with-values_" />
  <t:short-hand-unary-with-values foo="bar">
    <template name="_short-hand-unary-with-values-inner_" />
    <t:short-hand-unary-with-values-inner />
  </t:short-hand-unary-with-values>





  <template name="_short-hand-in-expr_" />
  <rate yields="shortHandTplInExpr">
    <t:short-hand-in-expr in="rate" />
  </rate>




  <template name="_tpl-with-short-hand-inner_">
    <template name="_tpl-with-short-hand-inner-inner_" />
    <t:tpl-with-short-hand-inner-inner />

    <c:sum>
      <t:tpl-with-short-hand-inner-inner in="sum" />
    </c:sum>
  </template>

  This next one is a bit awkward,
    because it creates an ambiguity when regenerating XML.
  Each of `match`, `when`, and `c:*` are represented the same on the graph,
    so it will not be clear until expansion how the body of the below

  The ambiguity will go away once template application is performed by
    TAMER in the near future;
      until that time,
        we cannot support the generation of each of those things within
        templates.

  <template name="_match-child_">
    <match on="foo" />
  </template>
</package>