This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Designs for XSLT functions (Was: Re: RE: syntax sugar for call-template)
- To: David dot Rosenborg at pantor dot com
- Subject: Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)
- From: Jeni Tennison <mail at jenitennison dot com>
- Date: Tue, 20 Feb 2001 14:55:26 +0000
- CC: xsl-list at lists dot mulberrytech dot com
- Organization: Jeni Tennison Consulting Ltd
- References: <H000006d0001f9f2.0982675362.stan.pantor.com@MHS>
- Reply-To: xsl-list at lists dot mulberrytech dot com
Hi David,
>> 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.
Actually I agree with that. My 'long long long term' meant
'so hugely far in the future that it's impractical to really consider
it'. And you make a good point about the kind of feature bloat in
XSLT processors that we'd see if every function we can think of were
in the XPath core.
>> 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.
I must admit to being completely confused by XQuery. It seems like
reinventing XSLT but without XML syntax for programming constructs
(admittedly a fair step to take). I thought that it might be that
XQueries are for building XML from things other than XML, but the
XPath-like syntax seems to imply that the source (e.g. database) is
accessed as a node tree anyway. I feel sure that I must be missing
something.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list