Re: [xsl] [exsl] Draft 0.1 - call for comments

Subject: Re: [xsl] [exsl] Draft 0.1 - call for comments
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Tue, 27 Feb 2001 09:12:42 +0000
Hi David,

As usual, I agree with most of the points that you make, so I'll leave
others to argue their case on:

(a) restricting the content of exsl:function
(b) disallowing the creation of result nodes

> (I've also moved the param element into the exsl namespace, bit wary
> of overloading xsl:param for this as it's not being used with
> standard xsl constructs, and in particular it isn't being paired
> with with-param, but rather it's setting up a positional context. )

I guess the benefit of using xsl:param rather than
exsl:param/exsl:argument/exsl:arg would be that it's something that's
already familiar to XSLT users. I wonder how many times we'd have to
repeat "templates take parameters, functions take arguments". But
that's the extent of my argument.

>> Issue: Wrapper - should there be a wrapper element to contain the
>> exsl:function elements in a document?  
>
> Not if this is an XSLT 1.0 extension.
> For XSLT 1.0 you might want to look at what would be involved with
> merging this wth xsl:script.

With the current XSLT 1.1 WD, this can't be merged with xsl:script
because xsl:script allows only text as content.  It would have to
exist side-by-side.  The XSLT 1.1 WD explicitly says that xsl:script
doesn't prohibit other ways of defining extension functions, so that
would be OK...

...But obviously not perfect. Really, we want to be able to take
advantage of the defaulting mechanism in xsl:script that would allow
EXSLT or VBScript or Java versions of the same functions to sit side
by side and let the application choose which would be best.  The only
big impact that I can see at the moment is that the names of the
functions should be declared as NCNames rather than QNames, with the
relevant namespace prefix held in the 'implements-prefix' attribute on
xsl:script.

> Hmm does the XSLT 2.0 requirement to offer a mechanism for
> specifying the namespace for unprefixed names in XPath affect
> function (and mode and variable and .. ) names as well? (Not that
> that affects your paper, I'm just musing)

The XSLT 2.0 Requirements document only mentions *matching* with the
default namespace, not *selecting* or any other use of qualified names
(like the ones you mention), so I guess not.

>> Issue: Optional arguments - should there be an extension attribute
>> on xsl:param that indicates whether an argument is optional?
>
> If the element was out of xsl namespace, the attribute could be
> unprefixed but yes you might want such a thing, although it only
> makes sense to have things being optional "from the right" and so it
> might be simpler to just mandate that everything is optional an that
> a default is always specified (as is the case with named templates)
>
>> An XSLT processor must not signal an error if an extension function
>> is called with fewer arguments than there are parameters defined
>> for the extension function
>
> If you say this (which might be reasonable) then every argument is
> optional, so I'm not sure I understand the issue quoted above.

Put it another way - should there be something that indicates that an
argument is *required*?  It doesn't make sense to call
set:intersection with less than two arguments - should there be some
way of indicating that?

Also, with recursive functions (and with recursive templates), might
there be something to indicate whether a particular argument/parameter
is private - only used for the recursion rather than for direct use?

>> If no exsl:return element is instantiated during the execution of a
>> function, the return value for the function is the empty string
>> ('').
>
> see above for a possible alternative

So, if we allow result nodes to be created by exsl:function then the
lack of an exsl:return element indicates the return of an empty RTF
(node-set in new money).  Makes sense to me.

>> Issue: exsl:return expressions - should the select attribute on
>> exsl:return hold an extended XPath syntax that includes things such
>> as conditional constructs?
>
> I don't know what you have in mind here, but probably, no.

David Rosenborg argued that the bare minimum should be allowed in
exsl:function (i.e. just xsl:param, xsl:variable and exsl:return) and
that extra functionality like conditions should be included through
extending XPath within the select attribute of exsl:return to include
conditional constructs e.g.:

  test ? true : false

I don't personally think it should, but that's what I had in mind.

>> Extension functions defined using exsl:function can be called in the
>> same way as XPath functions. Calling extension functions in this way
>> causes arguments to be passed by position.
>
> I think this should say that functions defined via exsl:function
> should be added to the current XPath context. Thus the following two
> issues re calling syntax are moot. (They may be desirable features
> but they would need to apply to any XPath extension function not
> just these ones)

Can you explain what you mean by 'current XPath context'?

[Hmm... thinking about it, there are issues with imported and included
stylesheets and repeated exsl:function elements with the same name
that I haven't touched on in the draft - have to add that...]

Allowing calls by name is an interesting issue because it's not
something that makes sense for built-in functions (although I suppose
we could assign their arguments names of 'arg1', 'arg2' and so on.

>> Issue: exsl:if - should this specification define an exsl:if
>> function for conditional processing that doesn't involve evaluating
>> both the true and false parts?
>
> It would be nice but I'm not sure it can be done (as a pure XPath
> 1.0 extension)
>
>> Issue: exsl:if - should this specification define an exsl:if
>> function for conditional processing that doesn't involve evaluating
>> both the true and false parts?
>
> You'll need something like that, I think.

One of those times when your split personality comes through? ;)  I
agree with the former.  I don't think we *need* exsl:if() if we can
use xsl:choose.

>> com:eval
>
> Maybe it's just because I've a headache, and no voice, but this one
> eludes me at present, I'm sure it's doing something jolly useful
> but....

Oh it's jolly useful. Basically it's a hack to allow the
pseudo-dynamic evaluation of an XPath relative to the context node.

If you look at a lot of Mike's extensions on Saxon, e.g. saxon:max(),
they have optional second arguments that give an expression to be
evaluated for each node, so you can get the maximum of a number of
items with simply saxon:max(item) but you can get the maximum number
of cells in the rows in a table with:

  saxon:max(tr, saxon:expression('count(td)'))

So, to emulate that functionality I wanted to be able to have:

  num:max(tr, 'count(td)')

Now ideally I'd have an evaluate() function. Then com:eval will simply
be:

  <exsl:function name="com:eval">
     <exsl:arg name="node" select="/.." />
     <exsl:arg name="expr" />
     <xsl:for-each select="$node[1]">
        <exsl:return select="exsl:evaluate($expr)" />
     </xsl:for-each>
  </exsl:function>

(or some other hack around it if exsl:return isn't allowed in
xsl:for-each.)

However, I don't, so this is a way to do it without. The second
argument and the relevant tr element is passed to the com:eval()
function. At the moment, com:eval() just shifts it out to a template -
the idea is that users can add their own templates to deal with the
particular expressions that they use in their stylesheet. So if I want
to deal with that 'count(td)' I have to write:

  <xsl:template match="tr" mode="com:eval">
     <xsl:param name="expr" />
     <xsl:choose>
        <xsl:when test="$expr = 'count(td)'">
           <xsl:value-of select="count(td)" />
        </xsl:when>
        <xsl:otherwise>
           <xsl:value-of select="." />
        </xsl:otherwise>
     </xsl:choose>
  </xsl:template>

or something similar.

>> Function: node-set num:highest(node-set, string?) 
>
> I'd call this max (a name you'd stolen earlier)

Again, following the Saxon names. (Aside: these functions are just use
cases, we can start real arguments about naming and functionality when
we start discussing what should be in the core set of extension
functions.)

Cheers,

Jeni

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



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


Current Thread