This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
- From: Uche Ogbuji <uche dot ogbuji at fourthought dot com>
- Date: Thu, 01 Mar 2001 10:16:24 -0700
- cc: Francis Norton <francis at redrice dot com>, script Petitioners <no-xsl-script at clarkevans dot com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
> Hi Francis,
>
> >> How would you like to see the easy distribution of extension
> >> functions being addressed?
> >
> > For me, I'd like to see things like *plucks examples from this
> > morning's thinking-in-bath session*: RDF parsers (RDF has multiple
> > elements or attribute serialisation options) or - for XSL FO or SVG
> > - exsl:text-depth($text, $box-width, $font-name) distributed as exsl
> > libraries.
>
> Sure, but what about distributing extension functions that do things
> like returning the current date or working out whether a directory
> exists on the file system? Things that can't be done with EXSLT?
>
> Or is your position that such things should only be allowable through
> (community-based or implementer-based) extension functions?
This is my position, or more precisely, that general efforts to standardize
such extensions in a separate layer should be explored and found wanting
before jimmying XSLT itself.
Certainly exploring the main reasons as to why extension functions are popular
in the first place is an important first step, IMO.
--
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