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: xsl-list at lists dot mulberrytech dot com
- Subject: Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)
- From: Uche Ogbuji <uche dot ogbuji at FourThought dot com>
- Date: Tue, 20 Feb 2001 08:15:34 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
> 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@fourthought.com +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