This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
At the moment mode in apply-templates is a token (http://www.w3.org/TR/2007/REC-xslt20-20070123/#element-apply-templates, http://www.w3.org/TR/2012/WD-xslt-30-20120710/#element-apply-templates). This works for most use cases by leaves out a number of use cases having to to do with secondary processing. It would be very useful if this could be an AVT to allow for a secondary processor to further specify the format of an output. An example usage might follow the following pipeline. Run an xsl transform on document: <?xml version="1.0" encoding="UTF-8"?> <document> <element>some text</element> </document> <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:math="http://www.w3.org/2005/xpath-functions/math" xmlns:parser="parsernamespace" exclude-result-prefixes="xs" version="3.0"> <xsl:param name="data" as="document-node()?"/> <xsl:template match="/document"> <ouputitem path="/document/element" mode="myrendermode"/> </xsl:template> <xsl:template match="/outputitem"> <html> <head> <title>A Page</title> </head> <body> <xsl:apply-templates select="." mode="rendercontents"/> </body> </html> </xsl:template> <xsl:template match="*" mode="rendercontents"> <xsl:variable name="datapoint" select="parser:eval($data, concat('$p1', @path))"/> <xsl:choose> <xsl:when test="@mode"> <xsl:apply-templates select="$datapoint" mode="{@mode}"/> </xsl:when> <xsl:otherwise> <xsl:value-of select="$datapoint"/> </xsl:otherwise> </xsl:choose> </xsl:template> <xsl:template match="*" mode="myrendermode"> <p> <strong>element</strong>: <xsl:value-of select="."/> </p> </xsl:template> </xsl:stylesheet> Then run the same transform on the output from the template as the primary document and the original document as the data xsl:param.
Personal response: We've tended to resist requests for call-template and apply-templates to be more dynamic, because sometimes allowing them to be more dynamic can inhibit optimizations even when the facility is not used. My instinct is that with higher-order functions in XSLT 3.0, there is a pretty clean and well understood way of doing this kind of thing. At its simplest, you could have for each mode a function that does apply-templates to a supplied set of nodes in that mode, and then you could bind a function item to the one of these functions that you wish to be invoked. You could even have a map that indexes these functions by mode name, allowing the dynamic apply templates call to take the form $mode-map($mode)($nodes) We're also getting to the point where we are trying to close the spec for XSLT 3.0 down, that is, to resist new "good ideas" unless the case is very strong.
The Working Group decided to confirm the response in comment #1.