Re: xsl:function with optional parameters

Michael Kay <mike@saxonica.com> writes:

> Just putting my thoughts down here in case it helps me come up with a
> solution, or in case anyone else can offer insights.

I won't claim any insights, but some questions and alternatives do occur
to me.

> Allowing xsl:function to define optional parameters is easy enough,
> it's largely a matter of removing the restriction that you currently
> aren't allowed to say required="no".

> The interesting part is, what happens to the rules for overriding
> declarations?

> As regards "old-style" overriding using import precedence, we
> currently say:

>     An xsl:function declaration defines a stylesheet function which
>     forms a component in its containing package, unless

>       * there is another stylesheet function with the same name and
>         arity, and higher import precedence,

> So what happens if a module with higher import precedence declares a
> function with an overlapping arity range? Do we try and override some
> of the arities and not others (a "partial eclipse")?  Allowing that
> level of complexity isn't useful, so is there an easy way to avoid it?

First, I have what seems like a logically prior question.  If a
stylesheet has something like the following

    <xsl:function name="my:f" as="...">
       <xsl:param name="p1" as="node()"/>
       <xsl:param name="p2" as="xs:integer" required="no" select="42"/>
       ...
    </

then how many functions is it declaring?

It seems to me the spec can answer in at least two possible ways,
formally speaking:

   (a) It is a declaration of a function (one function) which has one
   required and one optional parameter, which can therefore be called
   with either one or two arguments.

   (b) It is a declaration of two (related) functions, one of which is
   my:f#1 and the other of which is my:f#2.  The xsl:function element in
   question is in effect shorthand for 

    <!-- my:f#1 (just calls my:f#2 with the default value for p2) -->
    <xsl:function name="my:f" as="...">
       <xsl:param name="p1" as="node()"/>
       <xsl:sequence select="my:f($p1, 42)"/>
    </

    <!-- my:f#2 -->
    <xsl:function name="my:f" as="...">
       <xsl:param name="p1" as="node()"/>
       <xsl:param name="p2" as="xs:integer"/>
       ...
    </

    I'll call the collection of functions thus declared a 'function
    family'.

I think your notes are assuming (a), which is perfectly reasonable.  But
I wonder if (b) might be worth thinking about.  It would have the
advantage that it would require not change (that I can see, at the
moment) to the type system as it relates to functions.  At least, that
looks like an advantage to me.

If we look ahead to parameters with a cardinality of 'multiple', then
(b) would mean that a single xsl:function element might declare an
unbounded number of functions.  That would mean that implementors will
need a way to avoid materializing all the instantations of such a
function family and to materialize the ones they need when they need
them.  But there too, the rules remain relatively straightforward, since
every instantiation of the function familiy has the same fixed arity
currently expected by our type system.

> I think the simplest rule is that it's an error to have declarations D
> and E, where the import precendence of D is higher than that of E, if
> D's arity range includes part but not the whole of the arity range of
> E.

If it's a single function, that's probably simplest, yes.

It does mean that while under today's style of handling such groups of
related functions I could override my:f#1 without overriding my:f#2, I
would not have that ability under the new dispensation.  (This does not
matter to me in practice: since I normally want anything I write to be
runnable under Saxon HE, I don't actually use packages even where it
would make sense to use them.  That also means I lack useful experience
in this part of the spec.)

If we take approach (b), then I don't think we would need any change to
the rules.  (That's not the same as claiming implementors won't need to
change anything in the way they check the rules.)

I see that the day has now reached its end without my getting back to
this; I'll go ahead and send it, fragmentary though it is, for what it
is worth.

Michael


-- 
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
http://blackmesatech.com

Received on Friday, 30 September 2022 00:52:00 UTC