[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Streaming best practice: no user-defined functions wit
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
|
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
|