Re: [xsl] xsl:function

Subject: Re: [xsl] xsl:function
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Sat, 10 May 2003 11:17:48 +0100
Hi Kurt,

> Just wanted to drop a note saying that the Saxon 7.5 implementation
> looks good. One thing that did occur to me -- with the ability to
> specify data types now an intrinsic part of the language, I wonder
> if the two functions
>
>  <xsl:function name="ol:func">
>   <xsl:param name="arg1" as="xs:integer"/>
>   <h1>This is an integer</h1>
>  </xsl:function>
>
>  <xsl:function name="ol:func">
>   <xsl:param name="arg1" as="xs:string"/>
>   <h1>This is a string</h1>
>  </xsl:function>
>
> should in fact be considered the same thing (they are in the
> implementation and apparently the current spec) or whether in fact
> they have distinct signatures. Put another way, does the introductio
> of the as attribute make overloading of functional names a
> possibility?

As it says in the definition of in-scope functions in 2.1.1 Static
Context:

 "Each function is uniquely identified by its QName and its arity
  (number of parameters)."

There's no facility in XPath 2.0 to have polymorphic functions: you
can have two functions with the same name and different numbers of
arguments, but you can't have two functions with the same name and the
same number of arguments. This was an explicit design decision made, I
think, to make it easier/possible for implementations to work out
statically which function definition would be used for a particular
function call without having to do static typing.

Of course it's important that this constraint is satisfied by XSLT
2.0. In 10.3.1 Defining a Stylesheet Function, the XSLT 2.0 WD says:

 "[ERR078] It is a static error for a stylesheet to contain two or
  more functions with the same expanded-QName, the same arity, and the
  same import precedence, unless there is another function with the
  same expanded-QName and arity, and a higher import precedence."

This prevents you from defining two functions with the same name and
number of arguments. If you have a stylesheet with the two function
definitions as above, you will get an error.

What you *can* do (and what is done for the legacy XPath 1.0 functions
that are polymorphic) is have the function accept a very general type
and then have internal tests that determine the behaviour based on the
type of the argument. For example:

<xsl:function name="ol:func">
  <xsl:param name="arg1" as="xdt:anyAtomicType" />
  <xsl:choose>
    <xsl:when test="$arg1 instance of xs:integer">
      <h1>This is an integer</h1>
    </xsl:when>
    <xsl:when test="$arg2 instance of xs:string">
      <h1>This is a string</h1>
    </xsl:when>
    <xsl:otherwise>
      <xsl:message terminate="yes">
        ol:func() expects an integer or a string
      </xsl:message>
    </xsl:otherwise>
  </xsl:choose>
</xsl:function>

Of course this way you won't get any static error checking to tell you
that the type of the argument you're passing to the function is
wrong...

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


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


Current Thread