I agree with Scott that this can be done by performing the compilation required by the EXSLT dynamic functions at run-time. It might be a little ugly, but it wouldn't be impossible.
One of the complications that comes up is in accessing variables, settings of xsl:key, etc. - those things that are part of the run-time state of the translet - from within a dynamically compiled XPath expression. These aren't trivial problems, but I don't think they're insurmountable either. Scott: I'm not sure what you mean by "user extensions that mutate the stylesheet at runtime." Could you expand on that a bit or provide a reference? Thanks, Henry ------------------------------------------------------------------ Henry Zongaro Xalan development IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044 mailto:[EMAIL PROTECTED] Scott Boag/Cambridge/[EMAIL PROTECTED] 2003-08-28 06:29 PM Please respond to xalan-dev To: [EMAIL PROTECTED] cc: Subject: RE: XSLT and XPath 2.0 development You can still implement dynamic evaluation in a compiled environment... it just means a) the compiler needs to be available as part of the runtime, and b) we would need to set these things up to compile fragments. But, I guess what you really loose is that I've seen some user extensions that mutate the stylesheet at runtime. This becomes a harder proposition. My knee-jerk is that the world could live without this, though I'm not so sure when I think of some editing environments. Sigh. -scott "Rick Bullotta" <[EMAIL PROTECTED]> wrote on 08/28/2003 10:45:20 AM: > A few thoughts: > > Our application work requires considerable usage of extension functions, > notably some of the Xalan/EXSLT dynamic functions (evaluate, min, and > max), which appear to be "structurally unsupportable" in XSLTC. As > such, we would certainly be interested in seeing Xpath 2.0 support on > Xalan-J interpretive. As a use case, example, suppose an XML document > contains rows and columns of data in a format such as: > > <ROWS> > <ROW> > <COL1>FOO</COL1> > <COL2>100</COL2> > <COL3>0.5</COL3> > </ROW> > <ROW> > <COL1>GOO</COL1> > <COL2>200</COL2> > <COL3>0.75</COL3> > </ROW> > </ROWS> > > ...and we allow a user to provide an "ad-hoc expression", e.g. > "sin(COL2) * 0.6 + COL3 / 45", and we use XSL to transform this > recordset into something that looks like: > > <ROWS> > <ROW> > <COL1>FOO</COL1> > <COL2>100</COL2> > <COL3>0.5</COL3> > <CALCULATED>0.12455</CALCULATED> > </ROW> > <ROW> > <COL1>GOO</COL1> > <COL2>200</COL2> > <COL3>0.75</COL3> > <CALCULATED>0.00378</CALCULATED></ROW> > </ROWS> > > ...in which case we really need to leverage things like the evaluate > function. > > Another example is an XSL stylesheet which performs basic > grouptotal/grandtotal functions on a dataset, but the sort and subtotal > rules are dynamic. Once again, we have to resort to using the evaluate > extension function to meet our application needs. > > That would be the only showstopper for us, as far as I can see. > > Best regards, > > Rick Bullotta > CTO > Lighthammer Software (http://www.lighthammer.com) > > > > -----Original Message----- > From: Henry Zongaro [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 28, 2003 5:55 AM > To: [EMAIL PROTECTED] > Subject: XSLT and XPath 2.0 development > > > Questions, comments, endorsements and objections would be welcomed! > > Thanks, > > Henry > ------------------------------------------------------------------ > Henry Zongaro Xalan development > IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044 > mailto:[EMAIL PROTECTED] >
