One -- admittedly ugly -- solution for evaluate would be to have XSLTC invoke interpretive Xalan (eg, via XPathAPI) to process that request. But I think I agree that this is a very low-priority item.
Re the BSF scripting hooks... Again, I agree that this isn't a top priority, but it may be worth thinking about. Some of the need for inline scripting in arbitrary languages will probably go away when XSLT 2.0 comes along, since it's expected to add the ability to write functions in XSLT itself. But BSF is convenient for integration with specific environments, and for users who don't yet know Java very well... and it shouldn't impose any run-time costs unless it's actually invoked. I think I'd be willing to assume that if someone does use an extension they really needed it and make them manage the performance issues themselves... so the big issue here seems to be whether you're willing to make the BSF jarfile part of the XSLTC environment. The best answer might be to code the extension elements to support it, but set them up so they fail semi-gracefully if bsf.jar isn't available. (Just do a try/catch and issue an error in the catch?) (Disclaimer: I'm one of the original developers of BSF, so I'm somewhat based.) ______________________________________ Joe Kesselman / IBM Research
