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

Re: Future XSLT expansion.

Subject: Re: Future XSLT expansion.
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Mon, 20 Mar 2000 11:49:59 -0800
Re: Future XSLT expansion.
----- Original Message ----- 
From: David Carlisle <davidc@xxxxxxxxx>

> > But the 'node-sets'  they are returning ( and RTFs also ) 
> > are vendor specific.
> No. If it returns something of type node-set then it is (or should be)
> usable by any xslt function expecting a node-set expression.

import com.jclark.xsl.sax.*;

public ResultTreeFragment getSelf() {
     return (ResultTreeFragment) this;

What should I write if I want to return some 'node-set' from the extension 
and I want that to be portable across different vendors engines ? 

> If it is returning a vendor-specific datatype (which is allowed as well)
> then that should be a variable of type other than node set, and that
> variable will only be usable in extension functions that understand the
> new datatype.

Yes, that's about 'opaque' datatype.

> There is currently no standard API for producing (or using) node-set
> expressions from within an extension function, but there is no standard
> API for producing extensions at all, so this seems to be a lack of
> standard API for extensions rather than a problem with XSLT itself.

Not realy. If I'm returning the String from extenstion - I'm fine.
If I get to-node-set(String) in the core - I'm more than fine. 
I could write extension which is vendor-independent. 

Maybe that'l be not written on some paper ( no 'standard' )  - but 
that will work.  Almost any vendor has binding of 'string'  to / from 

> Currently you have to follow the API advertised for each system and you
> can't in general write an extension function that works cross platform

I can write an extension function that works cross platform, if that extension 
function returns String. Of course, we could end defining what is 'cross-platform'
e t.c., but I suggest not to start with that right now. Being possible to 
switch from / to  Xalan from / to  Oracle XSL  from / to XT  should be enough.

> (in general that probably isn't possible anyway but hopefully the
> implementors of at least the java versions will agree a common API and
> namespace for extensions) 

Yes, that's a political workaround. Actualy I don't like when some 
technology is based on a hypotetical agreement between vendors. 

Returning Strings and allowing the typecast from Strings to node-sets is better. 
Much scalable. Some day I would like to use extensions written in C with Java
XSLT engines. At that point it would be better to have to-node-set 
typecast  in the core.
> > Because node set  *is*  'some private datatype'.
> Not according to the spec, it isn't.

What do you mean? As you are saying above, there is no specs about 
extensions, so node-set  *is*  'some private datatype' ( vendor-specific ).

Of course all those things are not important. XSLT is still a technology 
known to very small number of marginals ( growing rapidly, as I can say from 
monitoring DICE) and there is plenty of time to fix all the inconviniences and 
self-limitations that XSLT has before it will hit the market. 


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Current Thread


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.
First Name
Last Name
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.