[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: HTML forms with XSLT slideshow question

Subject: Re: HTML forms with XSLT slideshow question
From: James Clark <jjc@xxxxxxxxxx>
Date: Mon, 27 Sep 1999 12:49:28 +0700
xpathcontext javascript
Kay Michael wrote:

> > I love the idea of extension functions, but they are unusable 
> > as is to me.
> > While I have some SAXON specific XSLT stylesheets, my norm is parser
> > independence.  With extension functions parser independence 
> > is not possible.
> 
> There does seem to be a need for a standard here: perhaps an informal
> standard created in the same way as SAX. Any volunteers to propose one and
> run the process?

The XSLT WD states that the XSL WG intends to define a standard both for
extension functions and extension elements.

> - how to provide context information (this has been my main reservation in
> adopting xt's style of interface: it's fine for "pure" functions but doesn't
> extend easily to functions that use context, e.g. the current node or the
> system id of the containing stylesheet node.

Why can't you extend it by defining an interface along the lines of:

interface XPathContext {
  Node getCurrentNode();
  String getStylesheetSystemId();
  ...
}

?

Then if the first argument of the Java function is of type XPathContext,
the XSLT processor will automatically pass the Java function an
additional argument of type XPathContext representing the current
context.

There are a couple of other areas where XT's API for extension functions
in Java needs further work:

(a) it needs to support overloading
(b) it ought to do more conversions automatically

Making both (a) and (b) work together in a predictable well-defined way
is not trivial.  It might be possible to leverage Netscape's work in
defining LiveConnect for this (see
http://www.mozilla.org/js/liveconnect/lc3_method_overloading.html).

Beyond that is the issue of allowing extension functions to be written
in other languages.  In particular it would be nice to support
JavaScript (using Rhino).

Closely related is the issue of supporting extension elements.  I
haven't yet tried to implement this, so I'm very open to suggestions. 
The one major constraint that may be peculiar to XT is that the public
interfaces to XT are based on SAX not DOM, and I want to keep it that
way.

James



 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.