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

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

---

---

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

	f:convert(@code)

	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

	count($param/root(.)//*)

	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
this:

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

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

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

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

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.

Comments?

/Roger

---