xslt 2.0 suggestion -- explicit extensions, and support for next-match

For xslt 2.0, I suggest that you consider adding a mechanism for explicitly
specifying that one template is a specialization of (or extends) another one
(ie is more specific / higher priority).  When combined with the proposed
"next best matching" template capability, this mechanism could provide a
convenient and understandable way to handle specializations.  Such
specializations could be instead of, or in addition to, the default
behavior.

For example, suppose one wants to generate date references that are
sensitive to today's date.  You could use a hierarchy of templates like
this, with examples in parens:

IdentifyDate ("October 31")
  IdentifyDateWithinADay ("today")
  IdentifyDateWithDifferentYear ("October 3, 2000")
  IdentifyDateWithinAWeek ("Friday, October 5")  [not invoked directly]
    IdentifyDateLastWeek ("last Friday, September 28")
    IdentifyDateNextWeek ("next Friday, October 12")
    IdentifyDateEarlierThisWeek ("this past Monday, October 1")
    IdentifyDateLaterThisWeek ("this Friday, October 5")

To specify this in xslt 2.0, you might do something like this:

<!-- default -->
<xsl:template name="IdentifyDate" match="date">
  [code for eg "October 31"]
</xsl:template>

<!-- overrides default -->
<xsl:template name="IdentifyDateWithinADay"
              extends="IdentifyDate"
              match="[code to test date wrt today's date]"
>
  [code for "today", "tomorrow" or "yesterday"]
</xsl:template>

<!-- adds year to default -->
<xsl:template name="IdentifyDateWithDifferentYear"
              extends="IdentifyDate"
              match="[code to test date wrt today's date]"
>
  <xsl:next-match/>  <!-- outputs eg "October 31" -->
  [code for eg ", 2000"]
</xsl:template>

and so on -- hopefully this is enough to illustrate the point.

The effect of the "extends" attribute would be to specify that the template
is a specialization of (more specific than) the one it extends.  This could
perhaps be implemented by assigning increasing priorities behind the scenes.
Of course, you could do without explicit extensions and instead make the
user assign priorities, but this would be less user friendly.

It would also make sense to have the matching conditions implicitly and-ed,
so that eg IdentifyDateLastWeek is not invoked unless its conditions are
true in addition to those of IdentifyDateWithinAWeek and IdentifyDate.
(This would go beyond what is currently possible with priorities.)

A related desirable capability would be to have the xslt processor choose
which specialization to use with call-templates as well as apply-templates.

I might also note that the proposed next-match capability could work well
with is-a hierarchies in XML Schema (with our without explicit extensions),
a use case not discussed in the current (Feb 14) draft.  For example,
suppose one has a type definition A, and a complex type definition B, which
is an extension of A.  In this case, one might one want to define templates
like these (this is reminiscent of the Visitor OO design pattern):

<!-- default for A -->
<xsl:template name="DoA" match="A">
  [code for handling things of type A]
</xsl:template>

<!-- adds to default by handling B's extensions -->
<xsl:template name="DoB" extends="DoA" match="B">
  <xsl:next-match/>  <!-- invokes DoA for what's in common -->
  [code for handling B's extensions]
</xsl:template>

The capabilities discussed above have been implemented in a Java-based
framework called Exemplars that pre-dates XSLT.  (See eg the INLG '98 paper
available at http://www.cogentex.com/technology/exemplars/index.shtml, if
interested.)  We have found these capabilities to be very useful in
developing applied natural language generation systems, including two
commercial deployed systems and several prototypes.

I hope this input is useful,

Michael White
CoGenTex, Inc.

Received on Friday, 5 October 2001 10:28:16 UTC