This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Designs for XSLT functions (Was: Re: RE: syntax sugar for call-template)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]