Subject: [xsl] Function arguments (was regexps once) From: David Carlisle <davidc@xxxxxxxxx> Date: Sat, 12 Jan 2002 12:56:06 GMT |
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 . (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) > Here the result of the function call depends on the identity of the > context node. A processor has to be able to recognise that fact that > the result of the function depends on this context node. And that > dependency could be hidden deep in some other function within a > template call within another stylesheet altogether. It doesn't _have_ to recognise it it just has to act as if it does. Basically what the "functions depend on their arguments" pardigm means is that any externally testable property of the result should be set only using the values of the arguments (including any implied arguments coming from the focus). 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...) However if one takes the (reasonable?) view that all functions have an implied argument being any information in the current focus then xpath functions are only obliged to return the same value if they are evaluated at the same focus. so for $i in widget return my:f(1) can't be optimised to for $i in widget return $x where $x is just a single call to the function. On the other hand an expression such as 1 + my:f(1) + my:f(1) could be optimised to 1 + $x + $x as here both the function calls are evaluated at the same focus so with the same implied arguments. If in fact the two calls of my:f(1) in this second expression are allowed to generate different results then basically Xpath is no longer a declarative language at all. 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. (It probably isn't possible to mandate this for externally defined extension functions, but if you use those it's clear that you are going outside the declarative xslt/xpath world to java or some such language, and hopefully the need to do that will be much less in xslt2 given the extra built in functionality and the possibility of xslt defined functions) David _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Regular expression functions (W, Jeni Tennison | Thread | Re: [xsl] Function arguments (was r, Jeni Tennison |
Re: Regular expression functions (W, David Carlisle | Date | RE: [xsl] Selecting first descendan, Oleg Tkachenko |
Month |