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

Re: Function arguments (was regexps once)

Subject: Re: Function arguments (was regexps once)
From: "Thomas B. Passin" <tpassin@xxxxxxxxxxxx>
Date: Mon, 14 Jan 2002 11:15:52 -0500
r function arguments in list
[Jeni Tennison]

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

There's a very important thing about this - a normal stylesheet writer must
be able to predict what will happen when the function is invoked.  With
xslt/xpath 1.0, there aren't too many candidate possibilities, so it's
reasonable to work out, but still, as many questions on this list attest to,
not always obvious.

If there is some possibility that a function might behave differently in
different situations (e.g., contexts), it must be made clear to the
***user*** as well as to an optimizer.  This isn't the case for your
examples below.  You may think it is by reading the function definitions,
but chances are they will end up being imported a lot of the time, rather
than recreated and thought about each time they are used.

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

This suggests either a different keyword for functions that may depend on
the current context vs those that may not, or never allowing functions to
implicitly depend on the current context (and thus function that wanted to
do so would have to be written like Jeni's second example, with

<xsl:call-id select="my:resolve-uri($url, $node)" />

).

For example, you could have xsl:function and xsl:function-context-rel.
Still, there could be trouble if a function that was expected to be
context-independent were to invoke a context-dependent function as part of
its definition.  That would have to be disallowed.

Cheers,

Tom P


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

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.
Email
First Name
Last Name
Company
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.