[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Function arguments (was regexps once)

Subject: Function arguments (was regexps once)
From: David Carlisle <davidc@xxxxxxxxx>
Date: Sat, 12 Jan 2002 12:56:06 GMT
sat arguments

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 
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)


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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.