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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--