RE: The evaluate function

Jeni Tennison wrote:
> Make it optional? Or partially optional if there's a subset of
> expressions that these implementers could handle.

>From one perspective (not necessarily that of the XSL WG's), it already is
optional. See "12.1 Multiple Source Documents", beginning at the fourth
paragraph.

XPointer becoming Recommendation may be the only thing keeping XSLT 1.0
processors from conformantly (and optionally?) implementing what effectively
can be used as an alternative to an explicit evaluate().

This wouldn't meet all of Jeni's use cases, but it would meet 90%+ of the
theoretical eventual uses of evaluate(), I bet.

Take the Linking use case:

> 3. Linking
>
> A third example is where someone has used XPath as a means of
> specifying the links between two pieces of data. The link needs to be
> interpreted on the fly in order to pull in information from the linked
> source.
>
> For example, you might have something like:
>
> <para>
>   The picture is <insert resource="images/image[3]" />.
> </para>
>
> And need to do:
>
> <xsl:template match="insert">
>   <xsl:copy-of
>     select="document('resources.xml')/resources/evaluate(@resource)" />
> </xsl:template>

With an XSLT processor that supported XPointer, I would just write the
following instead:

<xsl:template match="insert">
  <xsl:copy-of

select="document(concat('resources.xml#xpointer(/resources)/',@resource))"/>
</xsl:template>

The string passed to document() doesn't have to be a literal, so I've just
sneaked dynamic expressions into XSLT.

Evan


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list