This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: XSLT 1.1 comments
- To: <xsl-list at lists dot mulberrytech dot com>
- Subject: Re: [xsl] XSLT 1.1 comments
- From: "Steve Muench" <Steve dot Muench at oracle dot com>
- Date: Mon, 12 Feb 2001 16:56:21 -0800
- References: <200102130028.RAA20549@localhost.localdomain>
- Reply-To: xsl-list at lists dot mulberrytech dot com
| > I think there are two main use cases here - [1] extension functions for
| > general processing, and [2] extensions for communicating with external
| > systems, including the OS.
|
| Before I get to the rest of your message, I'd like to point out that both
| layers can be handled in XSLT 1.0 quite handily by communication between XSLT
| extension library authors *without* muching with the XSLT spec. For instance,
| POSIX could be used as the OS access API and extension writers could set upon
|
| http://xml.org/posix
|
| or whatever as the namespace URI, and then disseminate extension
| implementations for different processors.
Uche,
XSLT 1.1 does not prevent this in any way.
The basic rules about a processor's built-in extension
functions do not change.
See the editor's note in Section 14.4 of the XSLT 1.1 working draft:
Ed. Note: Make sure that it is clear that it is allowed
to call extension functions without using
xsl:script to define them.
In other words, a processor can support "built-in"
extension functions for any namespace with an "opaque"
implementation, just as an XSLT 1.0 processor can do
today.
______________________________________________________________
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly
http://www.oreilly.com/catalog/orxmlapp/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list