[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] xsl:script: functions written in XSLT
Hello all, XSLT 1.1 introduces the xsl:script element as a means of defining extension functions that can be used in XPath. The language in which the user functions are defined is given with the 'language' attribute, which can take one of the three standard values, 'ecmascript', 'javascript' or 'java', or a QName to indicate another language. [Aside: HTML's 'script' element used to use a language attribute to specify the scripting language, but this was deprecated in HTML4 in favour of a 'type' attribute that gives a content-type style value instead (e.g. text/javascript). Presumably there were good reasons for this (?) and if so, might XSLT be better off using 'type' rather than 'language' from the start?] What I've been wondering is whether it would be useful to allow people to define extension functions *in XSLT* within the xsl:script element, in a similar way to saxon:function. Perhaps named templates within the xsl:script element could be interpreted as extension functions, with parameters being arguments defined in order. The returned value could either always be a node set (which could be evaluated to give a string, boolean, number or whatever) or something like saxon:return could be introduced to return other value types. One big advantage of this would be that it would diminish the current extremely verbose syntax for calling named templates. Rather than having to do: <xsl:variable name="intersection"> <xsl:call-template name="intersection"> <xsl:with-param name="set1" select="$set1" /> <xsl:with-param name="set2" select="$set2" /> </xsl:call-template> </xsl:variable> <xsl:for-each select="$intersection"> ... </xsl:for-each> I could do: <xsl:for-each select="set:intersection($set1, $set2)"> ... </xsl:for-each> There could also be advantages in using XSLT rather than ECMAScript, Javascript or Java, in that XSLT processors would all be able to support it relatively easily (presumably) and that it would be able to deal with nodes or node sets as arguments and return values, and with navigating the source tree, in a way that the other languages probably couldn't without some kind of extensions. Any comments? Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|