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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] xsl:function, Kurt Cagle | Thread | Re: [xsl] xsl:function, Jeni Tennison |
Re: [xsl] xsl:function, Kurt Cagle | Date | RE: [xsl] XSL:IF expression, Andrew Watt |
Month |