[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Designs for XSLT functions (Was: Re: RE: syntax su

Subject: Re: Designs for XSLT functions (Was: Re: RE: syntax sugar for call-template)
From: David.Rosenborg@xxxxxxxxxx
Date: Tue, 20 Feb 2001 14:49:22 +0100
xslt extended functions
Hi Jeni,

> I think the upshot of this is that unless we introduce a proper
> construct like (test ? true : false) that only evaluates the relevant
> expression, we *have* to enable xsl:if/xsl:choose to be specified
> within function declarations. An exsl:if() function will not be
> sufficient.

That's correct.

> So would I. In the long long long term, there shouldn't be any
> extension functions because everything that's usefully done within an
> XPath should be in the XPath core.

Here I don't agree, I think there will always be room/need
for extension functions. For performance reasons and
functionality reasons, e.g. interaction with applications
outside of the XSLT/XPath engine. But by introducing
a few enhancements in XPath we could singnificantly reduce
those situations.

> Of course, working on creating common extension functions that do all
> the node set manipulation we need to do is a very worthwhile aim. In
> fact if you have the energy and feel strongly enough then I urge you
> to lead the process of doing so.

I was actually thinking of suggesting XQuery for exactly this purpose
in my previous post, but then I remembered what my feelings for it are ...
In my opinion they have obfuscated XPath. Instead of describing
the XQuery language as an extended subset of XSLT/XPath they went
inventing their own syntax and semantics which are similar but not
compatible with XSLT/XPath. I cannot se any sensible reason for this at
all but that's a different story.

> IMO the process of creating common extension functions will become
> easier when we have a means of defining extension functions in XSLT
> (and [sorry Uche] in other languages). Implementers that have the time
> to build in support for these common extensions will be able to do so.
> We will be able to use our own definitions for those that don't.

I fully agree.

> > Expr := VarBinding* OrExpr
> > VarBinding := QName ':=' Expr ';'

> :)  You might be interested at looking at the syntax used in XQuery.

Well, I did, that's where the ':=' came from, but see my previous comment
on XQuery :-)

Cheers,

</David>

David Rosenborg
Pantor Engineering AB


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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.