[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: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Wed, 21 Feb 2001 09:47:01 +0000
Re: Designs for XSLT functions (Was: Re:  RE: syntax su
Hi David,

> It would by syntactically XPath 1.0 but not semantically, so you can
> still not call it XPath 1.0. And if you are considering leaving the
> pure XPath 1.0 track it would be a small step implementationwise to
> have another syntax, though the particular syntax isn't that
> important here I think. One thing to consider though: if it by
> definition doesn't behave like an extension function, it probably
> shouldn't look like one.

Well OK, and I think that this is a good argument for not restricting
ourselves to only variables in the body of exsl:function.

Personally, I think that any kind of extensions to XPath are beyond
what can be legally done to extend XSLT. I am not sure that (other)
implementers would respond positively to the idea of having a
different, XPath-like syntax within a particular attribute in an
extension function. I also think that it would be hard to explain to
newbies why this particular attribute uses a slightly different
syntax (or rather why they can't use (.. ? .. : ..) in the rest of
their code.

> I think the important thing is that you have dedicated numerous of
> postings to try figuring out what should be allowed and not
> in the body of an exsl:function and in my opinion you haven't got
> close to the end. I'd say it isn't trivial to know that we've
> covered all the possible cases. Whereas with my proposal,
> the definition is straightforward and the implementation is
> straightforward. But maybe that's too boring :-)

Oh, certainly too boring ;)

The main reason that I disagree with your proposal is that I am
*certain* that it *doesn't* cover all the possible cases. For example,
I cannot see a way to create the key function that I want to create
using your restricted syntax. Show me how to create a key function
with the arguments:

  my:key(string, object, node-set, node-set?)

where the first two arguments are the normal arguments to key() and
the second two are the normal arguments to document() (but with the
third always a node-set rather than having the possibility of being a
string).  It should return the nodes that result from using the key
with the document(s).

I know that this will be possible in XPath 2.0.  All things will be
possible in XPath 2.0 :)  (Including some kind of conditional
construct.)

> I don't see how messing around with XSLT instruction semantics can
> be any more fruitful than a couple of simple add-ons to XPath in a
> well defined place: exsl:result/@select. But then, the beauty is in
> the eye of the beholder :-)

As you imply, I think we'll probably have to agree to disagree on
this. Personally, I find messing around with extension elements more
acceptable than messing around with XPaths.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/



 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.