[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: Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>
Date: Tue, 20 Feb 2001 08:15:34 -0700
Re: Designs for XSLT functions (Was: Re:  RE: syntax su
> Hi,
> 
> I think that the discussions that we're having are very useful in
> throwing up the issues involved in authoring extension functions in
> XSLT.
> 
> However, I'm concerned that we're losing focus a little and would like
> to explicitly state a few assumptions that I think we should be
> working under.  As always, if you disagree with these assumptions or
> if you would like others to be added, then do pipe up.
> 
> 1. There are three sets of extensions that we could be talking about:
> 
> (a) extensions to XSLT 1.0
> (b) extensions to XSLT 1.1
> (c) extensions to XSLT 2.0
> 
> I think that we should be addressing (a) and (b) and not even thinking
> about XSLT 2.0 as yet.  In fact, I think we should address (a) now,
> (b) immediately after we've done that and (c) at some far distant time
> when we've all recovered a bit and it's a little clearer what XSLT 2.0
> and XPath 2.0 are going to look like.

Strongly agreed.

> So, let's limit ourselves (for now) to extensions to XSLT 1.0.  This
> is a bit of a change 'cos I was talking about xsl:script before, but I
> think it will simplify some of the discussion.

Excellent.  Simplification is good.

> 2. I'm persuaded by Steve's observation that static invocation is very
> different from dynamic invocation and that dynamic invocation is
> something that could be applied to functions (and indeed XPaths)
> across the board.  I think that we should focus the discussion now on
> static invocation, and address dynamic invocation once we've got that
> out of the way.

Well, as I responded to Steve, I don't see the harm in having both 
conversations in parallel.  As we discuss common XSLT extensions do we *have* 
to do so serially?  Maybe it's enough to just discuss the matters in separate 
threads.  But I don't necessarily think one must precede the other.

> So, the order I'm suggesting to focus discussions is:
> 
> 1. how to define extension functions in XSLT 1.0
> 2. how to statically invoke extension functions in XSLT 1.0
> 3. how to dynamically invoke extension functions (+ other things?) in
>    XSLT 1.0
> 4. how to define extension functions in XSLT 1.1
> 
> I'll summarise the proposals and design questions that have come out
> so far for 1. in one of my following emails.

It looks as if you've pretty much taken up the gavel in this discussion.  
Good.  No better moderator.  I still think we should find a way to mark the 
conversation.  I, for one, am not often able to follow the huge volume of this 
list.  If we all agree on a common subject line marking or set up another 
list, I suspect we can draw other implementors in the same boat.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@xxxxxxxxxxxxxxx               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python



 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.