[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Function arguments (was regexps once)
Hi David, > taking the functions depending on context issue first, I think that > is a different from the "functions return same result given same > arguments" issue. One can argue that some built in functions take . > as an argument but just as a top level syntax issue you can omit the > . I agree that you can think of the pertinent aspects of the focus as being an additional argument to the function. I just wanted to bring out the point because the only exising built-in function that returns a node tree - document() - returns the same tree *across the stylesheet* rather than *in a particular context*. This is important, I think, because it's certainly won't be the case for extension functions, and might not be the case for other built-in functions that return node trees (e.g. current-match() as described). > (It's not clear to me whetehr for user defined functions this > implied . argument should always be there, or never, or only if the > function uses a function that has that feature, or only if the user > declares (somehow) that the function takes an implied . argument) Yes, that's not clear to me either. A processor could check whether the focus was important within a user-defined function by going through all the content and checking whether . or position() or last() was ever used within it to distinguish between them, I guess, but getting that information up front (a use-context attribute or something) might be easier on the processor. > It maybe that a processor can recognise that some arguments are the > same as some previous call and so reuse some previous result sitting > in memory somewhere or it may not and it may work it out again. This > doesn't matter so long as whatever it uses internally for > generate-id (and thus == in xpath2) only uses some attributes that > depend on the function arguments (which better not be a low level > pointer to some in memory object if there's a chance there might be > two of them considered equal, but that's an implementation issue...) Ah, yes, good point. If the ID is something like "foo-element-created-by-call-to-my:foo-with-argument-abc-in-context-bar" then it will all work out OK. > so I think the statement that > generate-id(document(...)=generate-id(document(...) which only > applies to document() at xpath1 because that's all there was should > apply to any functions defined within xpath2, including xslt-defined > extension functions. Sure, but conversely, if you have: <xsl:variable name="foo" select="document($x)" /> <xsl:template match="bar"> <xsl:if test="document($x) == $foo"> ... </xsl:if> </xsl:template> then under XSLT 1.0, the test in the xsl:if is always true. That would not be the case with user-defined extension functions in XSLT 2.0 and might not be the case with any future built-in functions that return node trees. Actually the document() function in XSLT 1.0 gives the same tree based on the *resolved URI* from its combined arguments. Assuming that the current document, and the stylesheet are in the same directory, under XSLT 1.0, the document() function returns the same thing with: document('file.xml') and: document('file.xml', /) and: document('file.xml', .) and various other things as long as the first node in the node set in the second argument is from the same document as the context node. Again, it's not going to be possible to articulate those kinds of semantics about user-defined extension functions. To support this kind of thing I think you'd need each function definition to be able to specify some kind of expression that gives a unique identifier for the function call. So if you had a function that depended solely upon the context node you could do: <xsl:function name="foo"> <xsl:call-id select="." /> ... </xsl:function> whereas for something like the document function it would be something like: <xsl:function name="document"> <xsl:param name="url" /> <xsl:param name="node" /> <xsl:call-id select="my:resolve-uri($url, $node)" /> ... </xsl:function> and if it should always return the same thing no matter what, you could have any literal value: <xsl:function name="bar"> <xsl:call-id select="'bar'" /> ... </xsl:function> Cheers, 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
|