Re: XSLT Functions in XSLT (Was: Re: XSLT 1.1 comments

Steve Muench wrote:
> 
> 
> Some of the issues to think about on "Extension Functions in XSLT"...
> 
> Some folks see this as sugar syntax for an <xsl:call-template>.
> 
<snip!>
>
> This would mean that a function implemented in XSLT could
> only return the same kind of thing that a template can
> instantiate, that is, a result-tree-fragment.
> 
Atomic types can be converted from RTF strings using the appropriate
function. And in XSLT 1.1 RTF can be implictly converted to node-sets.
This makes even a syntax-sugar spec really rather useful. 

> Others see the potential to be more powerful, allowing
> the extension function returned in XSLT to return any
> kind of supported XPath expression of any type in
> the XSLT datamodel (XPath + ResultTreeFrag + External Object).
> This is the approach that <saxon:function> and it's
> <saxon:return> allow.
> 
> Allowing XSLT-implemented functions to be more powerful
> than templates in this way, makes some folks think that
> it is a move in the direction of making XSLT more into
> a programming language, when there are already lots of
> good general programming languages available. These are
> the folks that are fans of user-written extensions, letting
> XSLT be good for what it's good for, and letting
> external programming languages fill in when XSLT needs
> a helping hand to accomplish a task that's easier to
> do in a programming language.
> 
But XSLT is also good at providing cross-platform portability - indeed
one of it's strengths is that it is more portable than *any* 
language. This is something that the XSLT community are, I suspect from
feedback in this list, very keen on. 

Take my case. We (http://www.ie.com) do e-commerce retail finance
systems. Some of our systems can involve a multitude of backend trading
partners, with no common server platform or language. That's why we use
XML for our transactions. That's why when I was initially asked about
developing a Perl module that would act as a partner-side API to our
transactions, I recommended XML + XML Schema + SOAP instead.

So I don't want language or platform dependencies in XML, in SOAP, in
XML Schema (which is used by SOAP), in XPath (which is used by XML
Schema) *or* in XSLT.

For me, and I suspect for many on xsl-list, what XSLT does is provide
*platform-independent* XML processing. The more it does that - and I'd
accept that non-URL connectivity is outside that scope - the more I like
it. Introducing gratuitous platform dependency - as in forcing users to
write extension functions in platform specific languages - seems to me
to lose focus from the purpose and benefit of XML and its associated
standards.

> These are some of the issues that the XSL WG is working on
> tackling for XSLT 2.0.
>
On current proposals, putting this in for XSLT 2.0 will be like putting
Humpty Dumpty together again.

Francis.

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