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'" <xsl-list at lists dot mulberrytech dot com>
- Subject: Re: [xsl] XSLT 1.1 comments
- From: "Kaganovich, Yevgeniy (Eugene)" <ykaganovich at netfish dot com>
- Date: Mon, 19 Feb 2001 05:01:47 -0800
- Reply-To: xsl-list at lists dot mulberrytech dot com
: | This is actually an interesting point. Is it a viable option, then,to
: | define the Java bindings as escapes into XSLT
:
: Isn't this what the JAXP 1.1 "TRAX" effort did?
:
: The DOM group is looking at an XPath API as well.
In my mind JAXP is similar to the JDBC in its Java-centric perspective. I
was wondering about coming up with something similar to SQLJ, which is a
higher level framework defined to be SQL-centric when appropriate.
The closest thing I can think of for XSLT would be JSP (piped into
JAXP). One could use JSP to define XSLT stylesheets with some dynamic data
in them, such as <xsl:value-of select="<%= System:CurrentTimeMillis() %>"/>
I suppose if we make these escapes context-dependent, it doesn't much
matter whether we write <%...%> or <xsl:script>...</xsl:script> except
that in the first case it's much more obvious that the stylesheet is not
very portable...
: | I guess you didn't buy into Oracle's "Java in the database"
: propaganda?
:
: In Oracle, before you can use Java in SQL, you actually
: create a SQL-flavored interface for your static Java implementation
: class methods so to the rest of the database your Java code
: looks indistinguishable from a normal PL/SQL stored function
: or stored procedure.
Ok, that wasn't supposed to be taken seriously, I must've forgotten a
smiley. I'm actually somewhat familiar with Oracle's Java Stored Procedures
(not to be confused with JSP :), I think they behave a lot like XSLT
extension functions.
- Eugene
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list