This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: [exsl] EXSLT 1.0 - Common, Sets and Math
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] [exsl] EXSLT 1.0 - Common, Sets and Math
- From: Francis Norton <francis at redrice dot com>
- Date: Mon, 05 Mar 2001 10:45:05 +0000
- References: <18548457388.20010302205123@jenitennison.com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
Congratulations again. Stuff steam engines - when I grow up I want to
write proposals as clear as Jeni's.
Jeni Tennison wrote:
>
> Hi,
>
> Thanks to those of you that commented on the last EXSLT draft. I've
> put up a new draft for user-defined functions and a couple of handy
> extension functions at:
>
> http://www.jenitennison.com/xslt/exslt/common/
>
re "Issue: exsl:reference-of" - the reference-of and add-result issues
are so entwined. As you note, using the @select form of exsl:result does
in fact give you return-by-reference. I now think that having an
incremental return mechanism would probably cover the whole case - maybe
exsl:result-set (is this any better than exsl:append?) with the same
syntax and semantics as exsl:result, except the explicit assurance that
it can be used iteratively to build up a result nodeset from its
contents (by value) or from its select expression (by reference,
assuming that the expression returns a nodeset).
> There's a list of changes to the last draft there, but also of
> interest is that I've created a couple more documents at:
>
> http://www.jenitennison.com/xslt/exslt/sets/
> http://www.jenitennison.com/xslt/exslt/math/
>
> that hold some extension functions. These are intended to be a
> starting point for a number of groups of standard (built-in) functions.
>
> The most important issues for developing these functions are (a)
> whether there are other sets of functions that we should define and
> (b) what functions we should have in them. These documents are just a
> starting point - please post any comments and suggestions here.
>
Given that both sets of extension functions require the same
infrastructure (xslt, exsl, and the com:eval function), and that you
provide source for the functions in that infrastructure, I'd be inclined
to put them in a single namespace, or at least a single proposal. OK,
its inelegant, but as a transform author I'd rather not have to worry
about whether adding a math function call to my set function calls will
break the transform on someone's processor.
Francis.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list