[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[xsl] Streaming best practice: no user-defined functions with node parameters ... Do you agree?

Subject: [xsl] Streaming best practice: no user-defined functions with node parameters ... Do you agree?
From: "Costello, Roger L." <costello@xxxxxxxxx>
Date: Fri, 15 Nov 2013 10:32:41 +0000

Hi Folks,

Yesterday Michael Kay wrote:

	Suppose you have a user-defined function
	that converts strings to upper-case, and
	then you call it as


	Now, the streamability analysis doesn't know
	what f:convert() does. It might not have access
	to the code of the function, or the code might
	be overridden subsequently in another package.
	So there's the possibility that f:convert(@code)
	might do something like


	in other words, it might navigate all over the
	document containing the node that was supplied,
	which clearly wouldn't be streamable.

	What we are saying in the latest draft is that
	f:convert(@code) is streamable provided the
	function signature of f:convert() declares its
	argument with an atomic type.

Outstanding explanation Michael. Thanks!

So, what I have learned from that is: when writing a streaming XSLT program,
do not create functions which have node parameters. For example, don't do

    <xsl:function name="f:convert">
        <xsl:param name="param" as="attribute()" />

Instead, only create functions which have atomic parameters. For example, do

    <xsl:function name="f:convert">
        <xsl:param name="param" as="xs:string" />

Streaming Best Practice: When writing XSLT programs, do not create any
functions that have node parameters. Only create functions with atomic

In fact, it might be a while before XSLT processors can handle any
user-defined functions, so it might be a good idea to completely avoid
user-defined functions in your XSLT programs.



Current Thread