RE: Future XSLT expansion. ( Re: Microsoft XSL and Conforman

It seems to me from this *long* discussion that what's lacking is the common
api for writing extensions. Ignoring Paul's beef with send/recv, one thing I
quickly learned while programming in perl is to go to cpan.org and search
for the modules which probably already implement 90% of the stuff I need.

On the other hand, with XSLT, Saxon and XT each provide an implementation of
the same functions because they implement extension mechanism differently,
instead of just being able to import each other's extensions. The current
situation is, people have to pick and switch between XSL processors
depending on which extensions they use. Yuck! Wouldn't it be great, instead,
to be able to download a package that implements some function, put it in
your classpath, and it's ready to work?

Returning to the argument at hand, it does seem like the document() function
should not be in core XSLT unless node-set() is as well. I would think that
node-set() should be added to the core so that other functions can use it as
API to generate processor-dependent nodeset structures.

I understand that there are cross-language issues here (a package
implemented in Python probably won't run in a Java processor) but these
issues have been solved for other specs (JNI and DOM come to mind), so maybe
it's possible?

- Eugene


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