Re: [xsl] [exsl] EXSLT 1.0 - Common, Sets and Math

Subject: Re: [xsl] [exsl] EXSLT 1.0 - Common, Sets and Math
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Mon, 5 Mar 2001 16:42:39 +0000
Hi Mike,

> I think it might be prudent to take <exsl:function> out of this, or
> at least park it in a separate section, on the grounds that
> specifying it is causing some difficulty, and it's probably an area
> where implementors will want to wait and see what the official
> standard comes up with.

Which part of which official standard are you referring to? As far as
I can gather from comments here and the current WDs, it seems unlikely
that XSLT 1.1 will incorporate user-defined functions written in
(anything like) XSLT, but that it's slated for XSLT 2.0. That means a
long wait for the functionality - it'd be really disappointing if we
did have to wait that long, especially if other languages were
supported (via xsl:script) before then.

Or perhaps you were just referring to xsl:script? I kind of see the
two as orthogonal - exsl:function could reside at the top level of the
stylesheet (in XSLT 1.0 or XSLT 1.1 implementations) or within
xsl:script (in XSLT 1.1 implementations).

Putting function definitions in a separate section would give us just
exsl:node-set() and exsl:object-type() in EXSLT 1.0 - Common (or
perhaps exsl:object-type() should go in EXSLT 1.0 - Functions as it is
mainly required for that functionality).

I'd like to see something more in EXSLT 1.0 - Common, particularly as
EXSLT 1.1 - Common will be completely superfluous as there won't be a
need for exsl:node-set(). It might be a good place to define qualified
output methods, system properties and so on. Or perhaps some of the
*really* common numerical and set functions should be put in there,
with only fairly strange stuff (e.g. trig functions) being relegated
to the separate parts.

> exsl:eval is another area that causes some controversy: I'm a great
> enthusiast for it myself, but not everyone shares my views. Some of
> the things done in Saxon using higher-order functions such as sum()
> and max() are done in XQuery using explicit syntax or an (implicit)
> mapping function that maps a node-set to a list of numbers; again,
> implementors will want to wait and see which way the wind is blowing
> before committing themselves.

Yes, my feeling is that we should leave any kind of dynamic evaluation
for now, and make the functions as simple as possible.

> You don't seem to define a namespace URI for set:* and num:*
> functions.

Um, I have:

they're defined in:

But I need to get Uche to OK them.



Jeni Tennison

 XSL-List info and archive:

Current Thread